Fonts Now!
While we wait for a standard, broadly supported, approach to web fonts to emerge there are a few good options for us to use fonts on the web now—sIFR, Cufon, and TypeKit among others. These techniques work well although they all have their limits. Most of these substitution techniques work best for replacing small areas of type; for example all of the headers and sub-headers on a page. Each technique has its advantages and disadvantages.
sIFR is a Flash and JavaScript approach to substituting fonts. It’s been around several years, it’s on its third iteration and it has a mature code base. It renders text as Flash so it comes with most of the advantages and disadvantages that Flash brings. One nice thing is that you can count on the text being anti-aliased (no ugly jaggies). You can also select and copy text and most font vendor EULAs will allow you to embed fonts in Flash. But, of course, it requires Flash player to be installed in the browser to work. Also, my work colleagues tell me that it’s difficult to implement. Here’s an example of sIFR in action.
Cufon has been popular around the office lately. We used it in the redesign of Cramer online—check out the headers. It is a new technique based on JavaScript/JSON which basically means it doesn’t require any plug-ins to work. The text will always be anti-aliased (so that’s another thing you don’t have to worry about), there are compression options and it is relatively easy to set up. One downside is that text is not currently selectable but this could be worked out in future versions of Cufon. Also, if you try to apply this technique to large bodies of text you may see a slight performance hit as the browser renders and scrolls type on the screen. I wouldn’t recommend using Cufon for body text.
TypeKit is an exciting new option. I was just allowed into an early release/beta so I’ve had a few days to experiment. Basically, TypeKit is a service that hosts fonts that you can use with a subscription. At it’s core, they use JavaScript to substitute text with web fonts (EOT and TrueType/OpenType). They check which browser is being used and serve the correct font format that will work with that browser. It’s really easy to set up and unlike Cufon and sIFR there’s no perceivable performance hit for having a lot of text on the screen. But there is a split second when you see the original font that is substituted. Other disadvantages include aliased text on XP (only noticeable at small sizes), a subscription model, it only works in browsers that have some sort of support for web fonts (it won’t work on older versions of Firefox or Safari) and reliance on a 3rd party to host the fonts. You also have to use their library of fonts, which to give them credit is quickly growing. Here’s an example of TypeKit in use.
The idea of hosted fonts is catching on and there are a few other options covered in Elliot’s excellent article: The Font-as-Service which I recommend checking out.
That’s it – the end of my font series! The landscape of web design is changing quickly and even now we can start using fonts that haven’t been available. The transition to web fonts will be tricky but there are options even now.
The Web Fonts Series
- Part 1: An Overview of Font Embedding, Font Linking, & the Current State of Fonts on the Web
- Part 2: Stakeholders & Browser Support
- Part 3: Technical Hurdles
- Part 4: The W3C Fonts Working Group
- Part 5: Fonts Now!
Tags: web-fonts