Why are IE10 "IE8 Standards" different from IE9?

I have the following HTML:

<!DOCTYPE HTML> <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=8" /> <link href='https://fonts.googleapis.com/css?family=Bitter:400' rel='stylesheet' type='text/css'/> <style type="text/css"> h1 { font-family: Bitter; font-weight: normal; } </style> </head> <body> <h1>Why is this different?</h1> </body> </html> 

When viewed in IE9 on Windows 7, the Bitter font loads and applies correctly: HTML on IE9 Windows 7

But when viewed in IE10 on Windows 8, this does not apply to the default font ( Times New Roman ): HTML on IE10 Windows 8

Since both browsers use the same Document Mode (due to the X-UA-Compatible meta tag), I would have thought that both would either have a Bitter font or crash and return to the Times New Roman font. However, one does work (IE9 on Windows 7) and one does not work (IE10 on Windows 8)

Is this a known issue or a documented feature?

+7
source share
4 answers

If the font does not actually work in IE8 itself, then it looks like IE10 has a better IE9 compatibility mechanism - since it actually correctly displays what IE8 does.

Why does IE9 Compat 8 really show the font, and why does the font not work in IE8? I would like to write this down to a problem with the font file. @font-face seems to be chasing down - setting font properties seems to be one of them. See: Why is one of these font rendering in IE8 and the other not? .

After downloading the font, placing it through the Font Squirrels generator and placing the font file set locally with my own @font-face code, you said that the font works in IE10. 8. I can confirm that it also works in IE9 in all compatibility modes, as well as in IE7 / 8.

Font Bitter works in IE10 compatibility mode with Font Squirrel generated files / font code.

Having seen that you indicated that other Google fonts work in IE9 / 10 8 compatibility mode, I think this really seals the deal in which the problem lies inside the font file itself - and the problem that IE seems to have in random cases with its properties. The Font Squirrel generator seems to fix most people's problems when it comes to @font-face questions, but as you can see in Why is one of these font renderers in IE8, but the others don't? , it is not always so.

Since this is not a compatibility issue, it does not work at all in IE8 - it looks like your only option is to place the fonts locally.

If you need more control over your fonts and the ability to manipulate CSS elements when loading or crashing fonts: How do I know if a font (@ font-face) has already been loaded?

+5
source

Update.

Due to the nature of IE, this seems to be a bit of a tricky issue. To cover what might be a problem that arises in different ways, depending on your specific situation, here are options that seem to come from a study of the participants here.

Note. Be sure to clear the cache that you have on the pages to ensure they load correctly.


Option 1:

Change the compatibility meta tag to <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" /> .

Changing from IE=8 to EmulateIE8 , you invoke DOCTYPE compatibility mode, which in turn causes IE to correctly load the font settings from the CSS file.


Option 2:

Make sure the file format you are using is in a format that IE can use and understand.

 @font-face { font-family: 'Bitter'; font-style: normal; font-weight: 400; src: url(https://themes.googleusercontent.com/static/fonts/bitter/v4/XexqN1a_o27MhVVdJFKAcA.eot); src: local('Bitter-Regular'), url(https://themes.googleusercontent.com/static/fonts/bitter/v4/XexqN1a_o27MhVVdJFKAcA.eot) format('embedded-opentype'), url(https://themes.googleusercontent.com/static/fonts/bitter/v4/SHIcXhdd5RknatSgOzyEkA.woff) format('woff'); } 

An important element to consider when viewing is the font file format. Now, as far as IE font support is supported, this is something like this:

  • IE8 support for .eot only .
  • Support for IE9 / 10 .woff and .eot formats.

Option 3:

If you use this option here, you are probably dealing with IE, sometimes with poor adoption and implementation of web standards. What is likely to happen is that IE9 displays the page in IE8 mode, but also adds native support for the .woff format to it. On the flip side, IE10 displays the page correctly in IE8 mode using the file formats that it actually supports. So my conclusion is that IE10 actually displays the page while IE9 tries to hide the disgusting standards support.

Another thought here, as you mentioned in the comments below that it seems to be working now, it is possible that Google was mistakenly doing the wrong format since the browser was IE10 but displayed content in IE8 mode. If so, then a β€œcorrect” display of IE8 will mean that the .woff file acceptable for IE10 is NOT for IE8.


Side note:

This is one of the biggest causes of problems for all web developers. The IE contest points to very low support and incorrect implementation, but is still at a disadvantage because IE comes preloaded with a very large percentage of PCs on the market, since most of them run this particular operating system. This is a very strong argument in favor of the adoption, implementation and use of standards and best practices.

+13
source

I checked that in IE8 (unlike another version of IE running in IE8 Document mode) the above HTML does not work (i.e. it displays the same way as in my IE10 in the Windows 8 example), so it looks like IE10 has a more accurate version of IE8 document mode.

0
source

If your server is apache, you can replace this directive with two lines in the .htaccess file in the root of your site:

 BrowserMatch MSIE best-standards-support Header set X-UA-Compatible IE=8 env=best-standards-support 

With this, I no longer have problems with Google fonts in IE10 or IE11, even mimicking IE8.

0
source

All Articles