Nov 14 2010

web fonts

a short history of rendering fonts on the web

In 1995, when I first started website design and in the days before CSS, the options for typeography on the web were pretty limited. The body type was dictated by the default font of the browser, specified by the web viewer. We could design a site with a readable sans-serif typeface only to discover that the viewer’s browser default font was set to 18px serif, which destroyed text flow around images, text set within buttons, the flow of the page and the look of the page. Display faces had to be rendered as .jpg or .gif images.

When CSS became available most of us used it primarily to style text. It was a great leap forward. However, the availability of fonts is determined by those that are present in the viewer’s OS. This remains the method that many people rely on, until @font-face came on the scene, so I’ll go into a little more detail in a later post. Rendering display faces evolved from images to Flash to Javascript.

sIFR (or Scalable Inman Flash Replacement)

sIFR became an alternative to image rendering with the chief advantage being that the font was not required to be present in the viewer’s OS. However, to view properly, the Flash player and Javascript must be enabled, otherwise the text is displayed in whatever is specified in CSS. Additionally, if the page contains several instances of text generated with sIFR, there can be a noticeable delay in the rendering of the text in the specified font. Security issues have caused some people to disable Javascript, but more conerning is the growing number of viewers affected by the Apple/Adobe war which makes Flash unavailable on the iPhone and iPad. In addition, sIFR can be tricky to install and use. Two leaps forward, one back.

Cufon

Cufon entered to solve part of the problem. The fonts still need not be present on the viewer’s OS, font rendering engine is web-based and relatively easy to use, the text is editable and Flash is not required, however Javascript must be enabled and the browser must support HTML5 (which leaves IE 6, 7 and 8 out). Additionally, some typefaces are not licensed properly so that uploading your typeface for rendering may not (strictly) be legal. However, if Cufon fails, CSS comes to the rescue and assuming you have styled the type class or tag with an acceptable alternative, all is not lost. We’ll call this a step forward, but not a leap.

@font-face generator

At this writing, @font-face, a CSS3 rule, is the next leap forward. To implement, font files must be compressed and served in format that are somewhat browser-specific. It does not rely on Javascript, the text remains editable and it is the most cross-platform compatible solution so far. The @font-face generator produces CSS that points to versions of the font to be served in compressed formats, according to browser type.

You may upload either TTF or OTF fonts that you own (with the proper licensing, of course) to the generator, or there are several sources for (non-free) versions of many common typefaces with pristine licenses, or there is at least one source for (free) typefaces. Warning: the free versions tend to be a little funky–some with haphazard letter spacing (print-quality kerning is not available for the web) or sloppy x-height consistency.

There are several options that help to overcome browser inconsistencies with the @font-face rule. That isn’t to say that there aren’t problems but most have work-arounds or, as ever, there is the CSS-fallback. A detailed description of @font-face, the options and work-arounds can be found on John Dagget’s blog.

There are still other solutions for web font rendering, such as Typekit (not free), but @font-face remains my preference. Whichever engine/method you use to render your fonts on the web, the old standards of good design still apply. No “ransom note” styling or using display typefaces for body text, please.