The first release of IE9 Beta has some serious flaws in it’s @font-face web font support. I’ve stopped testing until the next release. A programmer on the IE team graciously took the time to respond to an email about it. He said that many of the problems have already been fixed and that the next Beta release will be a lot better.
Here are some of the problems I found:
In my test page of first resort, the Droid Family @Font-Face Test Page, the fonts did render OK.
That was promising. But the question I wanted answered was, “Which file or files in the stack is IE taking?”. Where and when does it grab the WOFF, the EOT, or the TTF?
To determine that, I turned to Fiddler, the excellent (and free) HTTP traffic analyzer by IE veteran and security expert Eric Lawrence.
The results were weird. For some reason, IE9 requests each and every font in the stack: EOT, WOFF, and TTF or OTF. All of them.
IE9 Downloads Every Font In The Stack
That giant sucking sound you hear is IE9 Beta downloading every font in sight. If I had included an EOT, it would have sucked that down, too.
No Gordon, Greed Isn’t Good
I was looking forward to testing web fonts in IE9 Beta. But I had to give up after two or three hours. (I found other problems, as well, but there’s no point in reporting them.) IE9 is clearly not ready for any kind of serious, systematic testing of @font-face support.
With the next IE9 Beta, two questions are of special and immediate interest to me:
This “embedding permission” stuff may be unfamiliar to you so let me explain:
In an interoperability clash with Firefox, Safari, Chrome, and Opera, Microsoft announced that, as of Platform Preview 3, IE9 would enforce embedding permissions. The embedding permissions (usually called “embedding bits”) is DRM data that’s internal to the font. There are four levels of permission. This means that IE9 will decline to load a TTF or OTF font unless the permission level is set to Installable. (That’s Zero for the font techies out there.)
Now, IE can’t know if the font’s internal data is set to “Installable” until it downloads it. So what’s the fallback scenario? What does this mean for page load times and the order in which you have to list the font files in the stack?
All of this, of course, is an effort on Microsoft’s part to discourage web authors from posting “raw” TTF or OTF files. Microsoft has reaped great competitive advantage from its investment in fonts and they are concerned about loss of control. And they are having trouble letting go. (Big surprise.)
I was keeping an open mind about this approach. But in preparing the test fonts and pages for IE9 my mind got made up for me. Enforcing the embedding bits creates a hidden “gotcha” – a possibility that, mysteriously, a font won’t load in IE9 – and there is no justification for this complication. It’s misguided. And as a policy, poorly thought out. It will backfire – producing exactly the opposite of its intended effect.
I would rather see IE9 not support raw TTF or OTF files at all, than this. I would have no complaint.
Should this decision persist into the next Beta release, I’ll go into more detail in a separate post.
Lastly – the phrasing of the announcement about this on the IE blog went way beyond spin and into the realm of disingenuous. The wording makes it seem like restricting the loading of fonts based on the embedding bits is in conformance with the CSS3 module.
Here’s what was written on the IE blog:
“Starting with Platform Preview 3, IE9’s @font-face implementation conforms to the CSS3 Fonts module; supported font formats include EOT and WOFF as well as raw fonts with embedding permissions set to installable.”
EOT is NOT a part of the CSS3 Fonts module. Neither is font loading restrictions based on embedding permissions. I do, however, admire the wordcraft involved in grouping them all together in the same sentence so as to create the impression that they are all a part of the CSS3 Fonts Module.
Very slick. Very Bushy. 😉