Web fonts aren't 'something around the corner' – they're here. For the past year, they've been growing in availability, reliability and ease of implementation. They're already in use in a huge number of major brand websites and cropping up across numerous site creation services and Content Management Systems such as the Drupal®, WordPress® and Joomla® platforms.

While each Web font service handles font specification and inclusion in sites a little bit differently, the ultimate control comes in adding the fonts to the site's Cascading Style Sheets, or CSS. Why bother with the extra effort? Because your users matter. If you want to provide the best experience for them – with new browsers or old, JavaScript™ settings enabled or not, or desktop, mobile device or even gaming platforms – you must specify what should happen when those fonts you've selected don't load (or simply haven't loaded yet).

This is where 'fallbacks' come in. Web designers have been specifying 'font stacks' for years – first in HTML and then in CSS. This practice had more to do with the operating system originally: Mac® platforms had the Helvetica® and Times® fonts, and PCs had the Arial® and Times New Roman® faces. A 'font stack' is simply a list, in order of preference, of fonts that will do the trick for the look you're after. When a user visits your site, if they have the first font listed installed on their system, that's what displays on the page for them. If not, the browser looks for the next one and uses that, and so on. That was all we had to work with for years: a limited set of about 16 fonts that we could reasonably expect to find on a user's system. Anything beyond that we had to make as a graphic.

While font availability has improved on individual systems, the proliferation of mobile devices is stymying us again in that each device has a different and MUCH more limited set of fonts. This limits us even further in finding any one font that is available on every OS, platform and device. Thus, knowing a good 'stack' of fonts with similar characteristics (i.e. Helvetica, Arial, the Droid™ Sans fonts, etc.) is crucial. Unfortunately, that only gets us to 'reasonably similar' but still substantially curtailed in our ability to represent brand identities and provide richer, more distinct and engaging user experiences.

Two steps forward…

The advent of font embedding that works reliably on desktop and mobile devices dramatically changes the landscape of what we can do as designers. There are two key elements central to using Web fonts successfully: handling font fallback and font loading. The CSS 'font stack' handles fallbacks and 'Font Events' helps us know if the fonts are loading, when they are loaded or if none load at all. Most Web font services, including Fonts.com Web Fonts, support this new technology and it's quite clever. When the page is loading, a bit of JavaScript adds CSS classes to your page indicating that fonts are loading and a different class is added once they are. While good fallbacks can be relatively easy to accomplish, doing something useful with the Font Events can be a bit trickier. Typical of most new developments on the Web, with every success comes a few new wrinkles with which we must contend. This time it's much to-do about 'nothing.'

Since browser vendors are still sorting out what they support and how, font embedding is still a bit of a 'Wild West' affair, with various font formats and embedding techniques making it all not quite universal. This is where the 'nothing' creeps in. What you will hear most frequently are complaints of 'FOUT.' While not related to any specific joint ailments, FOUT (or 'Flash of Unstyled Text') occurs when users of the Firefox® browser see text appear in a system default font for a few moments before the font loads and then everything reflows. Of course, that may be preferable to what happens with Safari® implementations and some Internet Explorer® versions, where nothing shows up until the font loads. Generally one or the other happens within a few seconds, so you may feel it's not a big enough detractor to spend a lot of time on it.

Put in the effort – the ease with which both outcomes can be mitigated makes it really worthwhile. [Here's where I have to admit to not having done this on all of the sites for which I manage – 'Do as I say, not as I do!' quoth the parent…] The trick is to create CSS styles first that reference your font stack 'sans Web font' –thereby only showing your fallbacks. Then once the Font Events insert their new CSS classes in your page, when the fonts are loaded you can have your 'true' font stack called into play popping your copy into the desired (and now fully loaded) Web font.

…have a good fallback

This combination of a carefully selected set of fallback fonts and judicious use of extra overlapping CSS selectors doesn't require much work beyond sorting it out the first time both on the part of the designer and that of the developer. It just takes a bit of forethought and practice. The real benefit is once you have this workflow in place you generally don't have to keep thinking about it. It's a scenario that can help give a much more seamless and considered user experience and when coupled with a good font service can dramatically improve the whole experience.

While formats and standards are still evolving (plus issues with how well individual fonts render within Web browsers), letting the font service handle those changes will greatly simplify the process. embed once and let the service 'serve up the updates' automatically. Fallbacks and Font Event handling will take care of the times when odd user settings, corporate firewalls or storms brewing in the Bermuda Triangle lay waste to your best chosen font pairings.

With a little effort it can add a wonderful new dimension to your Web design and user experience vocabulary.

In my next article, I'll go into greater detail about some of the techniques in how you embed fonts, and how to write CSS styles to more closely match fallback fonts with the preferred embedded ones. In the meantime, just jump in with both feet and give it a try. There's lots to explore and much to gain even without getting into more advanced topics. So go forth and embed your fonts!

Supporting resources:

CSS properties for letter-spacing and word-spacing:

http://www.w3schools.com/Css/css_reference.asp

Smashing Magazine article on Web safe fonts and font stacks:

http://www.smashingmagazine.com/2009/09/22/complete-guide-to-css-font-stacks/

Code Style survey of available desktop fonts across Mac, Windows and Linux® platforms

http://www.codestyle.org/css/font-family/index.shtml

Fonts on the iOS® platform

http://iosfonts.com/

Explorations in Typography

Carolina de Bartolo with Erik Spiekermann

http://explorationsintypography.com/

Slide presentation on Web Typography by Pascal Klein

http://www.slideshare.net/klepas/beautiful-web-typography-5

Of course, have to include Wikipedia:

http://en.wikipedia.org/wiki/Web_typography