In terms of design aesthetics, good typography has always been one of the biggest stumbling points of the internet. For a long time web designers have been restricted to the use of about 10 choices of “web-safe” typefaces – a tiny quantity compared with the many hundreds of thousands of different typefaces at the disposal of other graphic designers. Up until now, the only real browser-compatible way around the problem was to use space-wasting, time-consuming, slow downloading and non-dynamic images of other typefaces, and while this has been the accepted way to use additional typography in web design for some time now – this is not really the ideal, since it sacrifices accessibility and search engine friendliness, and due to the subsequently increased webpage downloading times, it is always restricted to very selective usage anyway. This invariable means the use of a couple of beautiful image headings and some nice navigation interfaces, but overall the majority of any website’s typography is written in the same old Verdana or Arial seen on every other website – not an environment conducive to creating unique online identities.

But times are changing – and internet users are in for a very swift change in the way the web is presented to them. With the publication of the first working draft of CSS3 in 2001, a new rule governing typeface usage on websites was introduced, called @Font-face. The @font-face rule allows web designers to reference fonts not installed on end user machines, which ushers in a new era in web design.

For those who understand CSS, the rule looks like this:

@font-face {
font-family: “Fertigo”;
src: url("Fertigo.otf") format("opentype");
}

With the subsequent implementation:

font-family: "Fertigo";

So, what are we waiting for?

Since the rule has been around for over 8 years now, you might want to ask what is taking so long. A key problem with the implementation of the @font-face rule previously was the issue of browser compatibility. Up until now, browser support was restricted to Apple Safari (since version 3.1) and surprisingly, Intenet Explorer (since IE 4). However, we are finally on the brink of change – Mozilla has just launched version 3.5 of their popular Firefox internet browser, which now includes support for @font-face. Google Chrome and Opera are also following suit, with support for the rule included in their forthcoming beta releases. While older browsers will likely be around for some time, the rule degrades well provided alternative web-safe typefaces are specified:

@font-face {
font-family: "Fertigo", "Georgia", "Big Caslon", serif;
src: url("Fertigo.otf") format("opentype");
}

Browser support for @font-face

Webkit/Safari 3.1

True Type .ttf
Open Type .otf

Opera 10

True Type .ttf
Open Type .otf

Internet Explorer 4

Embedded OpenType (EOT) created by Microsoft's WEFT tool

Firefox 3.5

True Type .ttf
Open Type .otf

Chrome 2.0 beta

True Type .ttf
Open Type .otf

Netscape 4

Portable Font Resource (.pfr)

Copyright issues

A potentially serious problem with the @font-face implementation involves copyright infringement by web designers who will be making the fonts inadvertently accessible for download by any website viewers. With as little as 3 mouse-clicks viewers will be able to retrieve a download url for the particular typeface used. While this is certainly no problem with open source free typefaces, bought and copyrighted typefaces present the web designer a big concern, for increased freedoms come added responsibilities and making copyrighted typefaces available for download puts them at risk of a lawsuit.

As for whether this will hamper future implementation of @font-face – I don’t think it will. Already there are some measures that can be taken to secure embedded fonts from being stolen, and certain type foundries are welcoming the ubiquitous distribution of their fonts. This doesn’t mean piracy won’t occur – there is almost always some way around the system – but at least responsible web designers will be able to take the necessary precautions to put themselves in the clear.

Alternatives – sIFR, FLIR and Cufon

Clearly current implementation of @font-face comes with some serious issues with regards to browser support and copyright infringement – and while everyone likes standards and things are set to change someday – present implementation comes with some difficulty – which leads the web designer begging for a safe alternative.

sIFR

sIFR (or Scalable Inman Flash Replacement), is an open source system developed by Mike Davidson and Mark Wubben. sIFR uses a combination of javascript, CSS, and Flash to render your website’s typography in Flash. Flash text normally sets off all the alarm bells with regards to accessability and search engine optimization issues, but in this case sIFR is different - your code is untouched and sIFR is completely abstracted to the javascript layer, so your text is fully accessible to screenreaders and search engines, and sIFR text can also be selected, copied, and pasted by users. sIFR also degrades well, so browsers without the prerequisites for sIFR will see the exact same content, only without the sIFR text. Standard browser text will appear instead.

sIFR works on Mac, Windows, and Linux machines with javascript turned on and Flash 6 or greater with browser support on IE 5+, Safari, Firefox, Opera 7+ and a few minors. The only real snag with sIFR is that it is a touch difficult and tricky to implement.

The Copyright Problem.

sIFR has a security issue here where it is possible to decompile the flash file and steal the font. While this presents an unfortunate problem, if the web designer obtains the adequate licencing for web-embedded fonts, at least you would be in the clear on the legal side of things.

Font Burner

While I would encourage web designers to learn to use sIFR from scratch, there is an easy to use online sIFR script generation service that makes sIFR as easy as cut-and-paste. The Font Burner website lets you pick a font from an expansive list of open source fonts, and then it generates a string of code that you simply cut and past into your website's coding. Provided your CSS is free of conflicitng commands, sIFR should begin working immdediately.

FLIR

FLIR is similar software to sIFR. But instead of using flash, it embeds plain images that are generated automatically from the text on the webpage. So even if user does not have flash plug-in installed, he will see the text replaced by FLIR. However, FLIR requires that the website host is capable of running PHP. Not a big snag nowadays, so this is an alternative to sIFR with slightly less complex implementation. The other issue of course is that we are back to square one with images of text, but at least it gives a more dynamic method to creating the text images.

Cufon

Cufon is an alternative that converts fonts to VML paths stored in JSON and then renders the fonts using a JavaScript rendering engine, so it works without flash (sIFR) and raster graphics (FLIR). It works on every major browser including Internet Explorer 6, Mozilla Firefox 1.5+, Safari 3+, Opera 9.5+ and Google Chrome 1.0+. There is little configuration needed for standard use, and it is fast, even for sufficiently large amounts of text. Implementation is extremely easy compared to sIFR, requiring only a few simple steps to achieve satisfactory results.

There are a couple of snags with Cufon. Firstly, text is unselectable, except word by word, which is not really ideal. Cufon also has a few bugs that the developers are still working on, and it's still a touch incomplete in regards to support for certain font styling tags, such as text alignment options, but overall it is a much easier alternative to sIFR and a development thats defintly worth keeping an eye on.

The Copyright Problem.

When generating your Cufón javascript file, you are given the option to restrict the use of your font to certain domains. Whether this is truly secure or if it can still be hacked remains to be seen, but at least an additional anti-theft security measure can be taken on the web designer’s side. Again, obtaining proper web-embedded font licencing is the resposibility of the designer. If someone steals the font after this - who cares? There's only so many precautions you can take.

As of today my new website is up online and glitch free. Some additional features will soon be added, including my own RSS feed subscription and an interactive music player for my blog readers. In the mean time, please feel free to browse some other design related feeds inthe RSS reader on the left-hand side. There are many interesting RSS newsfeeds to choose from under the "Menu."