Introduction to web typography and @font-face

With the arrival of broad browser support for CSS3 @font-face, typography on the web has taken a huge step forward: you can finally use real fonts in your web pages without resorting to workarounds that rely on images, Adobe Flash, or other nontext-based techniques. But this new era of typography on the web comes with new legal, technical, and design challenges. This article reviews how we got here and describes how to use web fonts in a way that overcomes the new challenges involved, giving you the freedom to apply successfully the centuries-old principles of typography in your web design and development projects.

The craft of typography has been honed over hundreds of years in the medium of print to encompass fundamental principles like using contrast, repetition, alignment, and proximity to communicate meaning with clarity and style, and maintaining legibility within the presence of branding. These principles are as important on the web as anywhere else—web design is 95% typography, after all. One could even argue that typography takes on even more importance in an interactive medium like the web, where, because text can be clickable and have behavior, it is more than just content; it is user interface.

In all of this, having the ability to choose the right typeface is key. And in today's world of dynamic, constantly updated websites that are accessed by a diverse array of search engines, devices, and assistive technologies, being able to choose the right typeface in a way that's accessible, maintainable, and standards-based is a necessity.

For most of the history of the web, that holy grail has been out of reach.

Despite the fact that the rich history of the craft of typography has resulted in thousands and thousands of typefaces being produced, when the web was born, designers working in this new medium literally had no choice of what typeface to use. In 1993, for example, the first graphical web browser, NCSA Mosaic, included a single, default font (see Figure 1).

Web-safe fonts

This situation improved only marginally over the next fifteen years as the set of what's called "web-safe" fonts grew to about eighteen by 2008 (see Figure 2). Web-safe fonts are the subset of system fonts that come preinstalled in the major personal computer operating systems—a sort of lowest common denominator. Because web designers and developers knew all of their site's visitors would have at least those eighteen fonts available, they could safely use them in their web pages by referencing them via the font-family property in their CSS. Nevertheless, considering the many thousands of fonts available in the world of print design, being able to use eighteen fonts was still a pretty abysmal state of affairs. The potential for differentiated expression, for branding, for finding just the right typeface for the job, was still frustratingly small.

Workarounds: Text as image, script, or object

Routing around such limitations, some designers have come to rely on various hacks and workarounds to push web typography forward. Perhaps the most common of these is using an image to render text in the desired nonweb-safe font. This makes it possible to use any font in a web page, but it does so with some significant costs: since the text is trapped inside an image, it isn't selectable, searchable, translatable, or accessible to those using assistive devices, unlike normal HTML text. Techniques such as CSS image replacement can take care of some of these problems by using CSS to position the images over underlying text that actually is in the HTML source code of the page and therefore searchable and accessible, but the problems of selectability and translatability remain. Moreover, for text elements that change frequently—such as the headlines on a news site, for example—this technique incurs the maintenance cost of needing to create a new image whenever the text changes, unless a site's developers set up a server-side mechanism to generate those images on the fly. Bottom line: using images to render text makes richer web typography possible, yes, but in a clunky way that usually seems more complicated than it's worth. A valiant effort, but not ultimately the best way forward.

Other workarounds, like the JavaScript-based Cufón and typeface.js, automate the rendering of text in canvas or VML elements. While this minimizes the sort of maintenance and set-up costs that can come with using images to render text, it still results in rendered text that doesn't feel quite web native: the text isn't selectable or resizable. Also, using this technique to render large amounts of text—many paragraphs of body copy, for example—can have negative performance implications.

Another take on rendering font-styled text as something other than HTML text uses Flash instead of canvas or VML. In this approach, a designer embeds a font in a Flash object and applies it to text within the object, which is then rendered via the Flash platform's built-in text rendering engine. This can certainly lead to beautiful and effective typography, but it can also lead to some of the same problems inherent in using images or other nontext elements to render text. Even more important, though, is the fact that the increasingly popular iOS platform from Apple doesn't support Flash. That means users of iOS devices like the iPad and iPhone won't benefit from the lovely typography made possible by this approach—or, worse, they won't see the text at all.

The right way forward—the way that's based on how the standard, building-block web technologies of HTML and CSS are designed to work together to present content in an author-defined style—is quite simple, really: it is to use a feature of CSS called @font-face to define a font family by linking to a font file (instead of by referencing a preinstalled system font) and then to apply that font to web page elements by referencing it via the font-family property in CSS, much like you'd apply a web-safe system font.

This basic CSS mechanism works as follows. First, you use an @font-face declaration to define a font family by giving it a name using the font-family descriptor and then pointing to a file that contains the font itself using the src descriptor:

Here, a font family named Awesome Font is defined by linking to a font file with the name awesome-font.ttf.

Then, in your CSS, you simply apply the font to an HTML element using the font-family property, much like you would a web-safe system font:

Here, the Awesome Font family (defined earlier with the @font-face declaration) is applied to level one headings.

Text rendered this way is just normal HTML text styled with an author-defined font-family instead of a default system font-family. That means this approach avoids the problems of nontext-based workarounds: the text is searchable, selectable, resizable, accessible, and easily maintainable.

At its core, that's really all there is to CSS @font-face . This basic mechanism was defined by the web's standards body, the World Wide Web Consortium, way back in the late 1990s. Unfortunately, due to inconsistent implementations as a result of the browser wars of that era and other factors, it never quite took off—until recently. By 2009 all of the major web browsers supported @font-face , and soon after the mobile Safari browser on the iPhone and iPad did as well. The right way to go beyond web-safe fonts was finally at hand.

But the simple, open, standards-based quality of @font-face raised a new problem. Those who sold fonts for a living were concerned that once you could link a font file into a web page—and thereby expose a link to it—there would be nothing to keep that file from being stolen. At the time, this worry kept most commercial foundries from allowing their fonts to be used as web fonts.

That's where the first hosted web font services—including Typekit, the service I cofounded—stepped in with solutions that allow designers to use fonts as web fonts while still keeping those fonts protected from unauthorized use.

Here's how it works in the case of Typekit: As a designer, you buy a subscription to Typekit's library of fonts, choose the fonts you want to use, and specify what site you want to use those fonts on. Typekit then provides you with a snippet of JavaScript code to put in the head element of your HTML pages. When users visit your site, that JavaScript requests the fonts from Typekit's system. If the request comes from the site you registered with Typekit, the fonts are dynamically injected into the page using standard CSS @font-face ; if it's not, the fonts are withheld. You pay Typekit for using the fonts, and Typekit then shares revenue with the fonts' owners.

Of course, many web developers know that this method of protection, called referer checking, can easily be sidestepped by spoofing a referer using simple, widely available command line tools. That's why Typekit also protects fonts by modifying font files in a way that doesn't change how they render or perform but does make them uninstallable in an operating system. That way, even if you do get around the referer checking or you dig the fonts out of a browser cache or the like, they still wont be installable and usable in applications like Adobe Photoshop—which is the sort of use many foundries were traditionally in the business of providing, and therefore concerned with protecting. That extra layer of defense, though still breakable by someone with the right font editing software and expertise, is enough to deter the casual misuse of fonts, and it has made many font foundries comfortable with allowing their fonts to be used as web fonts via Typekit.

Typekit isn't the only hosted commercial web font service, of course. The space now includes many options, including Kernest, Fontdeck, Fonts.com Web Fonts, WebINK, FontsLive, WebType, and more. While differing in features, selection, and price, each of these services share the same basic function: they host commercial font files licensed for web use and provide access to them to web designers via CSS @font-face.

Certain foundries and web font services, including FontFont, Process Type Foundry, Fontspring, and Monotype's Fonts.com Web Fonts, now also in some cases provide web fonts that you can download and host yourself without relying on a hosted third-party service. This is often permitted in conjunction with the use of a new emerging standard web font format called WOFF, which is essentially a wrapper around a font file that makes it uninstallable in an operating system but still usable as a web font in browsers that support the format. Not all widely-used versions of the major web browsers support WOFF, though, so, depending on the font and foundry/service, using a hosted web font service may still be the only way to serve fonts to the majority of browsers in use by your site's visitors.

With hosted, commerical web font services plus WOFF—not to mention free sources of web fonts such as Font Squirrel and Google Web Fonts—the issue of web font licensing has been solved. The best path towards rich typography on the web has been cleared.

But, unfortunately, that's still not the end of the story.

Web font formats and browser support

It turns out that web fonts come in a number of different formats—and, not surprisingly, the various web browsers support different subsets of those formats (see Figure 3).

This presents a technical challenge. In order to support all of the major web browsers, an @font-face CSS declaration can't actually be as simple as noted earlier:

Instead, it has to look something more like this:

This is what's known as the Fontspring @font-face syntax, which is the latest version of what began as the bulletproof @font-face syntax. Using combinations of the @font-face format descriptor and various hacks, this syntax was developed to trick browsers into using the best (or, in some cases, only) web font format they support. Unfortunately, the original syntax turned out to be less than bulletproof. Over various iterations, it has had to be updated to overcome issues like limitations to its mobile support and its support for the latest browser versions, such as, in one case, IE9.

What's important here, though, is not necessarily to walk through the details of each iteration of this syntax, but rather just to realize that the CSS syntax required to use web fonts changes as the browser landscape evolves and as the web font community learns more about browser support and font technology. This means it's important to continue to test your web font–enabled sites periodically after you've implemented them, particularly when browser vendors release new browser versions. It's also a good reason to consider using a hosted web font service, where the logic of choosing which font format to serve to which browser can be taken off your hands—and, ideally, be continually updated by the web font service. Instead of personally maintaining a complicated and likely brittle @font-face syntax, you can instead abstract that complexity behind something as simple as this:

That's a sample of the JavaScript code used to enable Typekit on a website. Other hosted web font services offer similarly simple mechanisms, some using JavaScript to deliver @font-face fonts in order to gain control over loading behavior (more on the benefits of that below), others relying on CSS only.

Whichever path you choose—hosting your own web font files and maintaining the @font-face syntax required to use them or outsourcing that work to a hosted web font service—the good news is that it is possible to navigate the complexity of web font formats and browser support and thereby finally open the door to a large and ever-growing choice of typefaces.

The flash of unstyled text

Another challenge in using web fonts is dealing with a phenomenon called the "Flash of unstyled text" or FOUT.

A web font is a remote resource, just like an image or video, and that means it must be downloaded. So, what should happen to web font–styled text while the web font is being downloaded? Various browsers take different approaches to this.

IE9 and some versions of Mozilla-based browsers like Firefox will show the text in a fallback font while waiting for the web font to download, as shown in Figure 4. In this example, the first line of text has a web font in its font-family stack, followed by a web-safe fallback font. The second line of text has just the web-safe fallback font. While waiting for the web font to download, Firefox renders both lines in the fallback font.

Once the web font has downloaded, Firefox switches the first line to render in the web font (see Figure 5).

This can be a jarring experience, causing flickers and layout shifts, particularly when the metrics of the web font (things like optical vertical/horizontal size, default line-height, etc.) are different from those of the fallback font. This is the "flash of unstyled text."

By contrast, WebKit-based browsers like Chrome or Safari will hide the web font–styled text while waiting for the web font to download, leaving space for it in the layout, as shown in Figure 6. This is the same two-line example from before, but, as you can see, the first line is not visible.

When the web font has downloaded, Safari makes the text visible, and it's already rendered in the web font (see Figure 7).

This experience is smoother and tends to be preferred by many users and designers.

Fortunately, you don't have to stand by and accept this inconsistency across browsers. You can gain control over these cross-browser differences using WebFont Loader, a JavaScript library developed by Typekit in collaboration with Google. Released as an open source project, it's compatible with various hosted web font services and even your own self-hosted web fonts.

Note: if you're using Typekit, you can take advantage of WebFont Loader without loading an additional JavaScript file, as it's built right into the Typekit JavaScript code that you put in your pages to enable Typekit fonts.

WebFont Loader loads fonts via JavaScript in order to be able to tell when a font has started loading, when it has finished loading, and whether it is not going to load at all (because it's being requested with an old browser that doesn't support web fonts, for example).

For each of those events—each of those states—WebFont Loader dynamically adds a class name to the HTML element of the containing page. Those classes are wf-loading for when fonts are downloading, wf-active for when fonts have loaded, and wf-inactive for when fonts are not going to load. You can use those classes in your CSS to change the style of page elements during each state, as shown in this pattern:

How does this help with FOUT? You can use the wf-loading class to hide text while fonts are loading, but still leave a space for that text in the layout. This would mimic Safari's behavior across all web browsers. Here's the code required:

Translated into human language, this example says "when an h1 is contained within the scope of wf-loading, make its 'visibility' hidden." Doing that hides the text while fonts are loading, leaving space for it in the page's layout flow. Then, once the fonts are loaded, this CSS no longer applies (because WebFont Loader removes the wf-loading class at that point), so the text then becomes visible.

This brings WebKit's smoother font loading experience to all browsers, making FOUT a thing of the past.

Web font rendering

Another challenge in using web fonts is the issue of rendering. If you've used web fonts before, you may have wondered, why is it that the same font can render so differently in different browsers? Or why is it that two different fonts, rendered at the same size, can have such different levels of readability?

A typeface is an idea—it is a shape that can be scaled up and down in size—and, as an idea, it has infinite resolution. Rendering that idea on a computer screen means doing so on a relatively low resolution grid of pixels. This can cause problems for some typefaces, particularly those originally designed for print, where resolution isn't as much of a limiting factor as it is on a screen. For an idea of how things can go wrong, see the left-hand "O" in Figure 8 below, an example from an excellent blog post on this subject by type designer Tim Ahrens. Here, the right side of the "O" character happens to fall across a single column of pixels, just because of the overall shape of the character and its placement on the grid. The left-hand side of the "O", though, falls across two columns of pixels. That makes the rendered character look lopsided, which, when combined with similar artifacts on many of the font's other characters, can hurt the readability of text styled with this font.

Fortunately, some fonts that exhibited problems like this when first used for web text instead of printed text have since been improved—optimized to render better on a grid of pixels—through a technique called hinting. Added to a font by a type designer using font editing software, hinting is a set of instructions for text rendering engines about what to do when problems like this arise. In the right-hand "O" in Figure 8 above, you can see hints represented as linkages on each side of the glyph. These specify that certain corresponding parts of the glyph should always be the same number of pixels in width, regardless of how the glyph might naturally be shaped given how it falls across the pixel grid. This can dramatically improve the readability of text set in this font, particularly at smaller sizes and in browsers running on older versions of Windows. (If you're interested in more of the mechanics of this, Tim Ahrens' A closer look at TrueType hinting provides some fascinating details.)

That last fact—that some browsers and operating systems need help from hinting more than others do—points to another reality of web font rendering: the different text rendering engines used by the various browser and operating system combinations simply render text differently, sometimes subtly, sometimes quite noticeably. This makes it critical to know how a font you're considering using actually renders in the browsers you care about: would the font benefit from hinting in any of those browsers, and if so, has it been hinted? Does the font render well in each of those browsers at the text size you'll be using? While getting answers to questions like these adds a new layer of cross-browser testing to web design and development—and at the beginning of a design project, no less—it can avert unexpected rendering surprises late into a project, which can result in a lot of wasted work if you have to backtrack to the typeface selection stage.

If you're using Typekit fonts, you can save time and resources by using Typekit's Browser Samples feature to see how a font you're considering renders in every browser and operating system combination that Typekit supports (see Figure 9).

Simply put, paying attention to web font rendering early in your design process will help you choose the right font from the web fonts available to you. But if you must commit to using a web font that doesn't render well in all the environments you care about, you still have options. You could consider using CSS- or JavaScript-based browser targeting to show a web-safe fallback font to browser and operating system combinations that render your preferred font poorly. If you have access to the font in various outline formats, you also could sort out sending the best outline format to certain browser and operating system combinations (as Typekit and others have done as part of their hosted services). You could even work with the font's designer, or another font designer skilled in hinting, to optimize the font for the way you want to use it on the web. Advanced approaches such as these illustrate what's possible when it comes to achieving high-quality web font rendering—but, in many cases, when you have the freedom to choose a great-rendering font early on, you'll be able to avoid that kind of technical work and focus on designing with type, instead of designing type.

Using web fonts can seem daunting because of the complexities discussed above—but they can be tamed. Now that you know where to get web fonts legally, how to include them in your web pages in a maintainable way, how to gain control over cross-browser font loading differences, and how to understand web font rendering in order to choose the right font for your designs, you have what you need to participate in the ongoing renaissance in web typography, without the headaches. So jump in, and do great work! Here are some useful resources to add to your toolbox as you move forward.

Where to get web fonts:

• Fontdeck
• Fonts.com Web Fonts
• FontsLive
• Font Squirrel
• Fontspring
• Google Web Fonts
• Just Another Foundry
• Kernest
• The League of Moveable Type
• MyFonts Webfonts
• Process Type Foundry
• Typekit
• Typotheque
• Web FontFonts
• WebINK
• WebType

Working with web fonts:

• Bulletproof @font-face syntax
• Fontspring @font-face syntax
• Lettering.js
• WebFont Loader

Articles, tutorials, and discussion:

• A List Apart articles on typography and web fonts
• The Elements of Typographic Style Applied to the Web
• Nice Web Type
• Typblography: The Adobe Type Team Blog
• Typophile