Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is IE10's "IE8 Standards" mode different from IE9's?

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-face is loaded and applied correctly:HTML on IE9 Windows 7

But when viewed in IE10 on Windows 8 it is not, falling back on a default font-face (Times New Roman): HTML on IE10 Windows 8

As both browsers are using the same Document Mode (because of the X-UA-Compatible meta tag) I would have thought that both would either have the Bitter font or fail and fall back on the Times New Roman font. However, one is working (IE9 on Windows 7) and one is failing (IE10 on Windows 8)

Is this a known issue or documented feature?

like image 523
Andy Smith Avatar asked Sep 25 '12 16:09

Andy Smith


2 Answers

Updated.

Due to the nature of IE this seems to be a bit of a complex issue. In order to cover what is likely to be issues that come up differently depending on your particular situation here are the options that seem to have come up out of the research of the participants here.

Note: Be sure to clear any cache you may have of the pages so as to ensure they are loaded/served correctly.


Option 1:

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

By changing from IE=8 to EmulateIE8 you cause the compatibility mode to respect the DOCTYPE which in turn causes IE to correctly load the font preferences from the CSS file.


Option 2:

Check that the file format your are using is served up 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');
}

The important item to note when looking over this is the file format of the font. Now as far as IE font support goes it is a bit like this:

  • IE8 support for only the .eot format.
  • IE9/10 support for .woff AND .eot formats.

Option 3:

If you are reaching this option here then you are likely dealing with IE's sometimes poor adoption and implementation of web standards Likely what is happening is that IE9 is displaying the page in IE8 mode but also adding in it's own support for the .woff format. On the flip side IE10 is correctly displaying the page in IE8 mode using the file formats that it actually supported. My conclusion is therefore that IE10 is actually correctly displaying the page while IE9 tries to cover up lousy standards support.

One other thought here since you also mentioned in the comments below that it seems to working now, is that possibly Google was mistakenly serving the wrong format since the browser was IE10 but was displaying content in IE8 mode. If that is the case then the "correct" display of IE8 would mean that the .woff file that is acceptable to IE10 is NOT for IE8.


Side Note:

It is this kind of thing that is one of the largest causes of trouble for all web developers. The IE competition points out very poor support and improper implementation but are still at a disadvantage since IE comes preinstalled on a very large percentage of the PCs on the market since most run that particular operating system. This is one very strong argument for the acceptance, implementation, and use of standards and best practices.

like image 189
Bradley A. Tetreault Avatar answered Oct 04 '22 01:10

Bradley A. Tetreault


If the font doesn't actually work in IE8 itself, then it sounds like IE10 has a better compatibility engine over IE9 - since it actually depicts correctly what IE8 renders.

Why does IE9 Compat 8 actually show a font though, and why doesn't the font work in IE8? I would chalk this up to a font file issue. @font-face seems to be pretty plagued with issues - font property settings seem to be one of them on occasion. See: Why does one of these font-face render in IE8, but the others don't?.

Upon downloading the font, putting it through Font Squirrels generator, and hosting the set of font files locally with my own @font-face code, you have reported that the font works in IE10 Compat 8. I can confirm it also works in IE9 in all Compat modes, as well as IE7/8.

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

Seeing as you have stated other Google fonts work in both IE9/10 Compat mode 8, I think it really seals the deal that the issue lies within the font file itself - and the issue that IE seems to have on a random occasions with its properties. The Font Squirrel generator seems to fix most peoples problems when it comes to @font-face issues - but as you can see in Why does one of these font-face render in IE8, but the others don't?, that's not always the case.

As this is not a compatibility only issue - it doesn't work in IE8 at all - it looks like your only option will be to host the fonts locally.

If you want greater control over your fonts and the ability to manipulate the elements CSS while fonts load or fail see: How to know if a font (@font-face) has already been loaded?

like image 25
Patrick Avatar answered Oct 04 '22 03:10

Patrick