Web design has certainly come a long way since the first HTML files were published, and Cascading Style Sheets have given designers lots of freedom to specify typefaces, sizes, and styles for text. But most type on the Web is still limited to the 10 common "Web fonts" commissioned and distributed by Microsoft in the late 90s. Web designers and developers have done their best to work within these constraints, and even developed clever workarounds using images, Flash, and/or JavaScript.

A number of solutions have been proposed which would let developers use their preferred fonts directly, but getting everyone involved on the same page, so to speak, has revealed a morass of competing needs. Web designers want to be able to design websites using just the right typefaces—something that they can do with relative ease when working in print and other non-Web media. Browser vendors want to implement widely adopted standards so webpages render as well in one browser as they do in another. Type designers and font foundries want to make sure their font files aren't trivially easy to download, especially since fonts are already often pirated.

Current tools

Web designers have over a decade of experience using CSS to specify what fonts should be used when displaying a webpage. While a designer can specify any font by name, there's no guarantee that the viewer has that particular font installed. Thankfully, CSS allows designers to specify fallback fonts, and the browser will essentially go through the list specified in the stylesheet until a match is found among the installed fonts. CSS even allows a generic fallback such as "serif" or "fixed-width," and the browser will use whatever fonts are specified in its preferences for each of these generic classes.

Microsoft also decided to help by creating a set of fonts that it hoped would be widely distributed with operating systems. Known as the core "Web fonts," these are included with Windows and Mac OS X, and they are freely downloadable for Linux. These typefaces were specifically designed for screen use, and have since become the most commonly used type on the Web.

The collection includes 10 typefaces: the popular Verdana and Georgia, reworked versions of Times and Courier, Trebuchet MS, Andale Mono, Impact, the Helvetica-esque Arial (the default for Ars text), the Webdings dingbat font, and the generally-reviled Comic Sans. While the collection is certainly serviceable—especially Verdana and Georgia—it doesn't leave a whole lot of room for creativity and variety.

Designers can specify other fonts if the target audience can be reasonably expected to have those fonts installed. For instance, a blog about using Adobe Creative Suite software might reasonably assume that readers have Myriad Pro installed, since it comes with most Adobe design software. A Mac-centric website might specify Lucida Grande, Zapfino, or Helvetica, since those fonts are included with Mac OS X. As long as fallback fonts are defined, the page can be displayed on any computer, though it may lose some of the flair that the designer intended.

Designers have also developed a number of workarounds that allow them to design with whatever fonts they want. The simplest is to simply convert the type into static graphics—though that method can quickly eat up bandwidth, and prevents the type from being scaled. Another involves converting type into small Flash files in a method known as sIFR.

These methods share some drawbacks, however. Usability can be compromised, especially for those that rely on screen reading software. Users that either can't or don't have Flash installed won't be able to view all of the content as intended. As a result, the use of these methods is generally limited to headlines and banners, while the bulk of the text uses one of the common Web fonts.

More recently, a method known as Cuf�n text replacement has been implemented. This uses only HTML and JavaScript, displays type in whatever font a designer desires, and is still accessible to those with visual impairments. It works with most browsers, but it does require fonts to be converted to a special format, and the JavaScript is more complex than simply specifying a typeface. The rendering is also much slower than that of the browser's built-in text handling.

Latest method: @font-face

The most flexible method would be a way for a designer to link to a specific font file, have the browser download it once, and then use it as needed. The great thing is that this capacity already exists: the @font-face rule. This was originally part of the CSS2 spec, and Internet Explorer and Netscape initially supported it. However, both browsers used differing, proprietary font formats, so it was not widely adopted, and ended up being dropped from CSS2.1.

The @font-face rule is still a part of the expanded type specifications for CSS3, and Safari and Firefox have recently added support for @font-face use with standard TrueType and OpenType fonts. It's relatively trivial for designers to take advantage of @font-face—all that's needed is to host the font file on a Web server and add a link to it in a style sheet. Two Tokyo-based designers were commissioned to design a webpage that shows off Firefox 3.5's support for the feature, but you can also see @font-face in action for yourself if you have a recent version of Safari or the latest beta of Opera.

Unfortunately, there are two problems with @font-face. The first is that support for standard font formats isn't included in Internet Explorer, which still command a large percentage of the desktop browser market. Second, fonts are software, and software generally comes with licenses. While some fonts are freely licensed for Web use (for instance, the Open Font Library), many font distributors expressly forbid putting fonts on a Web server. Mozilla had to license the fonts used in its @font-face example specifically for that page alone.

Can't we all just get along?

So, type designers and font foundries don't want their fonts ripped off, browser vendors want a single standard, and designers want to be able to use whatever font best suits the design at hand. So far there isn't one clear solution that reconciles these competing desires.

One proposal involves standardizing Microsoft's EOT format, though you can be sure none of the browser vendors except for Microsoft are too keen on that idea. Another solution from The Font Bureau's David Berlow amounts to including a table of permissions within the metadata of a font file that could control their use on the Web. Font vendor Ascender has even proposed creating yet another format specifically for fonts to be used on the Web.

The latest idea is from a company called Small Batch, which has developed a tool called TypeKit. TypeKit relies on fonts that it hosts itself, and designers use the fonts by adding some JavaScript to their code. It's designed to abstract all the hard stuff away from the developer, and even uses Cuf�n or sIFR as fallbacks for browsers that don't support @font-face. Small Batch is working with foundries to develop a Web-specific license for the fonts it hosts, and the company has recently secured a round of funding from venture capital firms and several new media luminaries.

So far these solutions have generated a lot of debate, but very little consensus. Designers aren't really keen on new font formats. Adding support for @font-face using standard TTF and OTF fonts is appealing to browser vendors, since they can simply tie into an OS's built-in font handling. And type designers and font foundries are left worrying that their creative work will end up being given away. (Although anyone who would go through the trouble of finding a font file in a browser's cache or pulling the URL out of a CSS file isn't likely the sort to care much for a font's EULA in the first place.) TypeKit seems to show the most promise, but designers might not want to rely on a third party's servers to make sure the fonts they specified actually display for an end user.

You can be sure designers will continue to push the envelope by using @font-face for browsers that support it and other solutions like Cuf�n for those that don't. Until there is one solution that everyone can agree on—whatever it is—expect to still see lots of Verdana, Georgia, and Arial on the Web. For now, it seems, we're just left with the promise of better, more varied typography.