Webvanta Blog: Creating Effective Websites

Expand Typographic Freedom on the Web

Expand Typographic Freedom on the Web Image

Typography on the web has long suffered in comparison to print. HTML was designed to deliver content without regard to styling. With CSS, we have had flexible styling controls for years, with—in theory—easy ways to specify fonts.

The biggest limitation of web typography has been the limited number of fonts that a designer can use. HTML and CSS were designed with the assumption that fonts are defined by the viewer’s browser and computer; all your CSS does is suggest your preferred fonts, by name.

This scheme saves your web pages from needing to include any font data, but it has a huge downside: it means that the number of fonts that you can count on being displayed as you expect is small. Essentially, it is the small set of fonts that are installed on nearly all Macs and Windows PCs (even fewer if you also consider Linux and mobile devices).

This state of affairs is what has led to the overwhelming use of Arial, Verdana, Times, Geneva, and a little Trebuchet, Courier, and Comic Sans across the web. It has become a boring sameness that takes away a key dimension of typography: selection of fonts.

Font Stacks

CSS includes a clever feature designed to deal with the unknown availability of fonts: the font stack, or font-family. When you specify a font-family, you provide a list of as many font names as you’d like. The browser starts at the beginning of the list, and keeps going down the list until it finds a font that it can use.

You can use this to your advantage to widen your font choices, as long as you can accept that some fraction of web users will see different fonts. The number of ‘web safe’ fonts is actually much larger than the core set, if you’re willing to accept a slightly more compromised definition of ‘safe’. There’s another 80 or so fonts that are installed on the vast majority of Windows and Mac computers. You can specify these at the beginning of the font stack, and include generic ones as a fallback later in the stack.

The book Fluid Web Typography, by Jason Cranford Teague, has a nice reference list of all the common fonts (and goes into much more depth on everything covered in this article, as well as more general typographic issues).

Font Replacement

There is a simple way to gain unlimited type on the web, and that is to put the type into images. While visually effective, this approach has crippling problems: it is terrible for accessibility, hurts SEO, makes text hard to update, and adapts poorly to mobile devices.

Long ago, designers came up with ways to use images for headline text while eliminating at least some of these issues. The basic approach is to include the text as plain text, and then use either CSS or JavaScript to replace the plain text with text rendered however you want.

You can use an image for the text, or have either Flash or JavaScript paint the pixels to create the text. Our our site, we’re currently using Cufon, an example of this last approach, to render our headlines in the handsome Omnes font.

To use Cufon, you upload a standard font file to the Cufon site, and it produces for you a JavaScript file. On your web page, you load both the Cufon library file and the JavaScript version of your font, and specify which elements (such as h1, h2) should be replaced. Your web page includes standard HTML text; after the browser loads the page, the Cufon JavaScript hides the normal text and paints characters in the font you selected.

(For the technically curious: Cufon uses the HTML5 Canvas element in browsers other than IE, and VML for IE, to draw the characters.)

Real Fonts for the Web

Font replacement hacks have worked reasonably well for headlines, though they’re still hacks — and they are untenable for body type. What many people have hoped for, and worked toward, is real fonts for the web.

In concept, it is simple: just as your CSS file may specify another file as a background image, it can also specify a font definition file that specifies how to render whatever font is desired. You’d add a font file to the set of files that constitute your site, reference the font file in the CSS file, and then use the new font with abandon in your CSS rules.

CSS has long had a directive—@font-face—that enables this, and, in concept, it remains simple. (You’ll often see @font-face referred to as a CSS3 feature; in fact, it was defined in CSS2 but not widely implemented until recently.) The reality of making use of it is far more complex, however, for one key reason: typefaces are intellectual property, and the companies that produce them generally license them with care.

If you put a typeface file on your web server, just like an image file, then anyone can download it. Then they could upload it to their own server, and presto! an illegal copy of a font that you licensed is now running on someone else’s site.

Because most font owners don’t want their fonts so easily pirated, only fonts that are either in the public domain or are very liberally licensed can be used in the simple way that we’ve described.

Font Protection

The opportunity to sell fonts for the web is not one that will be missed forever, however; a diverse assortment of companies is working to make more fonts available in ways that font owners are comfortable with.

What the font makers need is a system that allows a licensed web site to access a particular font, without making it possible for others to access the font data and use it unlicensed. There’s two common ways to do this:

  1. Encode the font file in such a way that the browser can check the domain name for which it is licensed, making it useless if not used on the authorized domain, essentially adding DRM (digital rights management) to the font.
  2. Instead of storing the font as part of the web site, deliver the font to the web server each time it is needed, from a service that will only provide it to licensed domains, and may use various techniques to make the font data hard to steal.

The first approach has been pursued by Microsoft, with its EOT (Embeddable OpenType) format. This format has been supported by Internet Explorer for more than a decade, but it is not used by other browsers and has therefore not been widely used.

There’s a proposed open standard for encoding OpenType (OTF) and TrueType (TTF) fonts for the web, called WOFF, that provides compression to reduce file sizes. Today, only Firefox supports it, but its future potential is promising.

So far, Apple is going its own way and supporting only SVG fonts for Safari. So you’ll need yet another format to support those devices, unless Apple decides to join the crowd at some point and support WOFF.

Web Font Service Bureaus

The second approach listed above, to have a service bureau deliver the font, is another promising new option. The service bureau takes care of:

  • Negotiating with font foundries to allow the service bureau to be a reseller of its fonts.
  • Storing the fonts on the service bureau’s high-capacity servers, which serve as a sort of content delivery network (CDN) for font files.
  • Allowing designers to purchase licenses to desired fonts for use on certain web sites.
  • Delivering the font files on demand, when pages are loaded on any licensed site.

This approach promises to give designers a complete, easy-to-use solution. Today, the range of fonts available from web font service bureaus is limited, but it is likely to expand greatly in the future—and even the current limited set is an enormous improvement over web-safe fonts.

Using this approach, you are depending on the service bureau to deliver the font file every time someone loads a page from your site. Font files are cached by the browser, so they won’t generally have to be loaded more than once per site, but nevertheless you are counting on another server to deliver data that is critical to the rendering of your site. Web font service bureaus need to have fantastic performance and uptime to be accepted.

Typekit is one of the first such service bureaus. When using Typekit, you use JavaScript that they provide to load the fonts, rather than using standard @font-face declarations.

Kernest is another service bureau that takes a different path to a similar result. As with Typekit, you purchase a license to the desired fonts on the Kernest site. When your web pages are rendered, Kernest delivers the font file. Instead of use JavaScript to load the fonts, however, Kernest simply provides a CSS file that you link into your site.

With any of these solutions, once you have loaded the fonts from the service bureau, you can use the font by name in your CSS font-family declarations.

The web font service bureaus take care of providing the fonts in the assortment of formats necessary to cover the major browsers. Here’s TypeKit’s statement about browser compatibility; as you can see by reading the comment thread there, it is not as simple as one might hope. But they do seem to do a good job of covering all the important bases, and they even have experiemental support for iPhones and iPads that you can enable if you want (but be forewarned, there are bugs in Apple’s software that can cause crashes if you aren’t careful).

More Font Sources

There are many sources of fonts, and we can’t begin to give a complete rundown here, but there are a couple of particular note.

Google has recently begun hosting fonts with open-source licenses through the Google font directory. Because these fonts are provided under an open-source license, you can install them on your server and load them directly in your CSS. Google also provides a JavaScript-based Web font loader, which fetches the fonts from the Google content delivery network. The Web font loader was developed in collaboration with TypeKit and uses the same techniques, saving you from most of the worries about browser compatibility.

You can also find licensed web fonts at The Font Shop, which offers some of its fonts in EOT and WOFF formats. That covers IE and Firefox, but not Safari or Chrome, so they too have partnered with TypeKit so you can buy fonts from The Font Shop and then have them delivered via TypeKit, which provides compatibility with the additional browsers.

Which approach to choose?

Fonts on the web are going to be a moving target for some time, as browser support for WOFF increases, more foundries begin offering fonts in that format, the industry updates its licensing approaches to deal with the reality of the web, and web font service bureaus mature.

Which approach to use depends on the availability of the fonts you want to use:

  1. If you can find an acceptable font that allows @font-face linking (such as one that is in the public domain, or licensed for this use), then life is simple: just put the font on your server, link it in your CSS, and use it with abandon.
  2. You can use a wider range of fonts by licensing them from a web font service bureau, and then using the JavaScript or CSS code that the service bureau provides to load the font.
  3. If the font you want to use is not available from a web font service bureau, then you’ll need to see if the foundry’s license allows embedding using techniques such as Cufon. Many do, many do not, and often you need to ask—most foundries are behind the curve in dealing with the web. Here’s a useful table showing which font foundries allow which types of web usage.

WOFF holds great promise, but for now browser support it too limited for it to be interesting except as one part of a multi-format solution.

Using Fonts on Your Site

In part 2 of this post, I’ll dive into the code to use to work with web fonts and web font service bureaus.

Topics: Web Design

Add Your Comments

(not published)