For years, web designers have been yearning for custom fonts in web design. It's a real shame that web fonts didn't really take off with IE4 in 1997! The web was a different place back then, web design was a pretty new thing. Bandwidth was highly constrained at the time, so one could not imagine waiting for web fonts to load. Microsoft's container format of choice is also EOT, which is a Microsoft proprietary technology. Although everybody slates it's proprietary and closed nature, it was sort of a good idea. EOT provides domain locking, encryption, sub-setting and compression - all good things for convincing those behemoth font foundries to allow web embedding licenses.

Now is a better time than ever to move away from the standard web-safe fonts. Mainstream browsers have caught up with IE, over a decade later. Here is a short history lesson on the many techniques that Web Designers have been using to get beautiful type into their pages.

Fonts in Images #

With the introduction of high-speed internet, the web has become a much more multimedia oriented place. With lack of web fonts in anything other than IE, developers concentrated on alternative methods to get aesthetically pleasing fonts onto their pages. We began using images to display custom typefaces. This was great, as you could have the page look how your designer wanted it to. Not very accessible though, as people with screen-readers couldn't read any of your image-font headings.

Designers began using images as backgrounds using CSS, using various methods to hide the original text (with varying success). These methods make certain assumptions on how screen readers handle CSS and Flash content. Unfortunately, one of the more popular accessibility suites for Windows - JAWS - wouldn't read "hidden" text as everybody expected it to. This lead to the use of overflow: hidden and a negative text indent.

Licensing for this method is the least worrying. You just need to have the font on your machine and produce an image to then upload, which doesn't require a font embedding license. If you are generating images from a server, you may potentially require some form of extended license.

Fonts in Flash #

The other issue with using images was the effort involved. Unless you had a complex set of server code to dynamically generate images (and produced 24-bit transparent PNGs or solid-colour background), you would have to create the header image text each time you wanted to change the text. If you generated a lot of content, this was going to lead to a lot of extra work. This is where Flash Replacement techniques came about. These solutions use Adobe Flash .swf files, which have the ability to store font data embedded, and can then be sent text data as a parameter. This is then used to replace the text on the page with the desired font.

This solution had it's problems. Some web browsers / versions of flash under more exotic operating systems lacked support for the wmode=transparent feature, which renders the background of a flash element as transparent; letting the html content beneath the flash show through. Lacking support for wmode also breaks overlays in some cases, so Flash has to be hidden when an in-content overlay (e.g. a lightbox) is displayed on the page. There is also the issue of font licensing, as the flash file can be copied and re-used on other web sites in some cases. JavaScript is required to dynamically replace text. It also requires that Flash Player plug-in be installed an enabled on the system, though in most cases detection occurs before replacement is done. The same accessibility issues can arise as with images too, so text-indent would still be used as with image replacement.

Fonts in JavaScript #

More recent additions have been developed, in the wake of HTML5 canvas element support. These involve re-rendering the font into JavaScript code. Cufón and Typeface.js are two such solutions. Support is provided by canvas in fairly recent browsers - VML in IE -  so coverage of browsers is relatively high. VML was added to IE from version 5. These solutions typically support sub-setting, and cufón includes domain locking, though not true encryption so reverse engineering is feasible (this lacks benefit in most cases, as the conversion process simplifies the font paths to lower file-sizes).

The drawbacks to these methods are that styling support is limited, even text selection is an issue that has to be worked around. JavaScript has to be enabled for replacement to work, too. Licensing issues are similar to that of Flash Techniques.

CSS3 Font Face Support #

The most favoured method for font embedding is through the use of CSS Fonts, which make up one of the modules of the CSS3 standard. It's considered a Working Draft over at the w3c, although it's usage in modern web design is on the increase and browsers are now backing it. The specification was included in CSS2 but removed from CSS2.1. Browsers support different font formats, as mentioned EOT is IE only. Chrome, Firefox, IE9 and Opera support the WOFF format, which is a step forward for open specification web font formats. SVG fonts are supported by Safari and Opera. TTF fonts are supported by Firefox, Chrome, Safari, Opera and IE9. A good compatibility list is provided at webfonts.info, though bare in mind that it's a wiki page.

The main drawbacks to font-face font embedding are unanimous format support. TTF is the most widely supported, though until very recently you were required to use SVG for supporting iPads and iPhones. Opera only added support for TTF fonts since version 10. So for each version of each browser you hope to support, you need to serve up the correct set of font formats.

For each font-style (bold, italic, oblique, etc.) you will need to provide a separate font file. Some web browsers will try to emulate these if they are missing, though support for this isn't unanimous.

There is also the potential to have the same font licensing issues for commercial fonts.

Why CSS Font Embedding is the Future #

A lot of the time, you can side-step the licensing issue simply by using fonts which are licensed for web embedding, and where applicable free to use for commercial purposes. Font Squirrel is a great resource for such fonts, though I would advise that you check over the licence for yourself before using the fonts. The fantastic feature of this site, is that they (in many cases) provide a font-face download kit for their fonts. This includes all the subsets and formats needed for browser support, and a CSS file ready for embedding. What makes this site really special is that you can provide your own font and upload it, and you get a font-face kit ready made for you. Always check that the font you wish to use supports the character set that you intend on using. The issue with free fonts is that they can quite often be incomplete, and quite often they lack the polish and effort put into commercial fonts.

You no longer need to host your own fonts, either. Typekit is just one 3rd party service which provides commercial web fonts, ready to embed, and you sidestep any licensing issues. Google also provides the Google Font Directory, which is basically a CDN for freely available web fonts. These services also only provide the supported font format to the requesting browser, whereas with home-brew solutions rely on multiple declarations and smiley faces.

This site is using the League Gothic kit from Font Squirrel (as I couldn't find a CDN for it), and Droid Sans via the Google Font CDN. My chosen fallbacks for League Gothic look awful, so I think that some more alterations could be in the pipeline.