A long time ago, Microsoft started making use of @font-face (also called web fonts) in CSS. This would have been revolutionary if not for the fact that using fonts required the designer to encode them into a weak DRM file called an EOT, which stands for Embedded OpenType. Open indeed. Things are starting to look up now.
The great thing about Microsoft trying to introduce this is that it would have ended an era of Web Safe fonts and “download this font to view my page properly” messaging before Web Safe fonts were understood. Unfortunately, no other browser bothered implementing the CSS or EOT and @font-face fell into obscurity for many years, forcing web designers to use images of text. EOT’s major flaw was that it pandered to font makers and left web designers jumping through hoops to create font files.
Microsoft apparently has strong corporate ties to certain Font Industry big-wigs, and they didn’t want to upset them. Better to make life hard for your developers than help font makers come up with workable solutions for licensing web fonts (like hosting font files and checking the HTTP_REFERER for the correct domain before allowing access to the font file, which seems as good as the weak DRM of EOT files). When you are the most commonly used browser, I guess you can do stuff like that and still have your CEO chant, “Developers! Developers! Developers!” The problem is that Microsoft didn’t anticipate empowering font creation software like FontStruct that lets mere mortals create fonts under Creative Commons licenses. Frankly, it’s unfair to force me to put DRM on stuff I create if I don’t want it.
Eventually, some good people created sIFR, which allowed designers to (with great effort) cobble together a Flash file that embedded a font. Adding some JavaScript code to the page allowed designers to add fonts in a more accessible, user-friendly manner than simply using images of text. While sIFR had some problems (for example, links in headings were buggy and the text wouldn’t resize with the browser), it was a breath of fresh air. Suddenly, it was only a little work to have nice typographic options for limited use in headers and the like.
Recently, Apple (in the form of WebKit) and Opera have brought back the @font-face. Luckily, Apple and Opera didn’t bend over for the Font Industry. They boldly allowed support of plain-old TrueType fonts. With half of the major rendering engines supporting easy web fonts (and Firefox support on the way), I decided to give EOT another shot. That would allow me to have four out of five browsers (that I support) rendering my fonts out-of-the-box with sIFR as a worse-case fallback.
The results were mixed. Using @font-face is progressive enhancement with CSS and using sIFR is progressive enhancement with JavaScript and Flash. To start, I went through the lengthy and buggy trial and error process of creating an EOT with WEFT. After getting that worked out, I added the following to my screen stylesheet:
1
2
3
4
5
6
7
8
9
10
11
| @font-face {
font-family: "MyFont Sans";
src: url("../media/myfont_sans.ttf") format("truetype");
}
@font-face {
font-family: "MyFont Sans IE";
font-style: normal;
font-weight: normal;
src: url("../media/MYFONTS0.eot");
} |
I could then set a font by specifying font-family: MyFont Sans, MyFont Sans IE, sans-serif;. In Safari, Opera, and Internet Explorer, my site used a custom font. Other browsers fell back so a system chosen sans serif font if the font MyFont Sans was not installed on the system. That gets us half way there.
The next step is to create the sIFR and load it only if it is needed.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| var MYSITE = {
sifr: true,
init: function() {
if(window.getComputedStyle) {
var ff = document.defaultView.getComputedStyle(h,null).getPropertyValue('font-family');
switch(ff.toLowerCase()) {
case 'myfont sans':
case '"myfont sans"':
case "'myfont sans'":
MYSITE.sifr = false;
}
} else {
MYSITE.sifr = false;
}
if(MYSITE.sifr) {
MYSITE.setSifr();
}
return true;
},
setSifr: function() {
// Code enabling sIFR
}
};
if(window.addEventListener) {
window.addEventListener('load', MYSITE.init, false);
} else if(window.attachEvent) {
window.attachEvent('onload', MYSITE.init);
} else {
window.onload = MYSITE.init;
} |
The script runs after the page loads. Checking for window.getComputedStyle ensures that any standards compliant browser that supports web fonts will not get sIFR, since the browser will report that it is using MyFont Sans. Firefox, if I remember correctly, reports a list of fonts, but it ends up in the result of Firefox getting sIFR. Once Firefox has web fonts support, this script will need to be reevaluated. If the browser doesn’t support getComputedStyle, the browser is (probably) Internet Explorer, which supports web fonts. So, we can turn sIFR off.
Finally, any browser that needs sIFR will execute MYSITE.setSifr();, adding the custom fonts to the page.
This should provide custom font support in most major browsers. The only caveat is that a suitable fallback should be chosen (one that looks similar to the @font-face font, rather than sans-serif mentioned above), as browsers without Flash or without JavaScript will see the fallback font if the browser doesn’t support web fonts.
Since we have a suitable fallback with sIFR when web fonts aren’t available to the browser, there is a good enough methodology for implementing custom typography on live sites that don’t support web fonts. Until Firefox releases support for web fonts, it may be too much trouble to implement. However, in the spirit of progressive enhancement, one could skip the sIFR step and simply allow the installed system font fallback, as pixel-perfect cross browser support is turning into an obsolete, undesirable practice and progressive enhancement is becoming common place.
The final rub is Microsoft’s persistence in supporting EOT and not TrueType or OpenType fonts. While it is possible to get web fonts in Internet Explorer, it is a royal pain to create EOT files. If it’s too much effort, using sIFR or keeping the tenants of progressive enhancement with CSS may be a workable solution.
So, it seems web fonts have almost come of age. Once Firefox supports @font-face, web fonts can be used on a wide scale. While you may not want to jump on the bandwagon yet, it is definitely time to start looking into web fonts.