Lost In Translation
“Web design is 95% typography”. So much of the content produced and consumed on the web is text yet designers and users have been confined to a set of compatible fonts available across client operating systems. Escaping this typographical island has involved everything from cross-browser CSS workarounds, graphics-based solutions and even plug-ins, with trade-offs ranging from extra storage and bandwidth to reduced accessibility.
As a result, typefaces have too often been one of the first casualties of the translation from Photoshop design mock-up to live web page.
Not The Same CSS
Solving this challenge required an interoperable CSS syntax to describe font resources. While IE added support for CSS2’s @font-face rule as long ago as 1997, the differences between this earliest of implementations and the far more recent ones supporting CSS3 Fonts have given rise to CSS design patterns built to ensure the same rule works for all users. A notable example is the bulletproof @font-face syntax developed by Paul Irish from Google, et al.
But crafting a cross-browser @font-face declaration turned out to be half the problem.
No Common Web Font Format
Internet Explorer’s @font-face implementation supports EOT (Embedded OpenType) fonts, a compressed font encoding submitted to the W3C in 2008. Following WebKit’s lead in 2007, Mozilla and Opera added support for raw TrueType and OpenType fonts. Raw fonts work well if your fonts’ end-user license (EULA) allowed you to serve them from your web server. While this is true for many free fonts, this is not the case for the vast majority of commercial fonts. Web authors are thus effectively cut off from the richest font catalogs available. If they choose EOT they are able to license a number of commercial fonts for web use but only IE renders them.
This leaves a challenge for the industry. The major browsers support two incompatible solutions and commercial font EULAs are generally incompatible with one of them. This spawned dedicated hosting services like TypeKit to help designers license typefaces for their site and use them across browsers. These services, however, may not offer all or even any of the desired fonts that a web developer needs for their site. In some cases, a font set could even require multiple subscriptions.
WOFF
In late 2009, type designers Tal Leming and Erik van Blokland working together with Mozilla’s Jonathan Kew proposed a new web font container format to address the concerns of font vendors without reducing web author choice. It was well received and submitted to the W3C in April 2010 by Mozilla, Opera and Microsoft. Today, Firefox 3.6 supports WOFF and other browser vendors will be following soon.
Font foundries have also rallied behind the new format and already offer WOFF-encoded fonts for web use. Among them, Monotype Imaging, Ascender Corporation, FontShop and Typotheque provided us with the great WOFF fonts used in our our Testdrive demos.
Same CSS, Same Web Font Format
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.
In future posts, we will look into IE9’s web font support in more detail, as well as the available techniques for cross-browser typography. In his latest post on the FontBlog, Greg Hitchcock offers rich context on the art and science behind the technologies involved in web typography.
We look forward to your feedback on this Preview release, as well as ongoing work within the W3C to extend the reach of the typographic web.
Sylvain Galineau
Program Manager