@font-face is the new darling of Web designers. With it, we can break out of the traditional web-safe font stacks and explore the full range of typography available to us in print. Of course, @font-face isn’t the first technique available to us, we’ve progressed through a number of others over the past few years so let’s take a brief recap.

Fahrner Image Replacement

FIR is a catch-all term for a number of techniques designed to replace text with an image of text. Pros included sharp rendering and the ability to add more style to text than otherwise possible, but this technique prompted accessibility questions and was difficult to apply to dynamic text, such as headings generated by a content management system. There’s a good roundup of classic image replacement techniques over at Dave Shea’s Mezzoblue. Onward and upward.

FaceLift Image Replacement

FLIR is another take on the idea of replacing text with a rendered image of the text in a non-standard font, this time generated dynamically with PHP’s GD library. While it solves the problem of dynamic content, it still suffers from the fact that it’s an image and as such the generated text is not selectable. It also relies on PHP and GD being installed, and introduces a server-side performance hit.

Scalable Inman Flash Replacement

sIFR is yet another approach, based on Shaun Inman’s method of replacing basic text with Flash text. It’s pretty, scalable (hence the name) and allows for the selection of text. Downsides include the fact that it relies on both Javascript and Flash, which has far less market penetration since Apple decided to exclude support from iOS-based devices.

Cufón

Cufón brings the HTML5 <canvas> element to the table, in conjunction with VML and Javascript. At the time of writing it still doesn’t allow for selectable text, which is a step backward from sIFR (although a step in the right direction in terms of open standards).

So where does that leave us?

A discussion I had recently with a fellow designer about why he still uses Cufón is what prompted me to write this post. As far as I was concerned, @font-face is the Holy Grail of web typography – the ability to use whatever fonts we choose (licensing permitting, obviously) to lay out our designs. Text is the ground state of a Web document; we’ve had text-based browsers since the beginning of the Web (and earlier, if any of you remember Gopher) and we shouldn’t need Javascript and vector graphics to display it.

My erstwhile opponent was unconvinced, and pointed to the aliasing and artifacts which can sometimes be created by web-embedding fonts for display on systems with varying levels of antialiasing (and different approaches to pixel-mapping type). It’s true, at larger sizes, some fonts tend to display signs of the dreaded jaggies, like so:

Museo 500 Regular, 48px

Clearly some work still remains to be done, as evidenced by the CSS3 property font-smoothing – but this only tells the browser whether or not to force use of the operating system’s font anti-aliasing (Safari does its own thing, regardless of the OS).

CSS to the rescue!

It’s possible to achieve some measure of faux anti-aliasing with the CSS property text-shadow. Compare this sample with the aliased example above:

Museo 500 Regular, 48px

It’s still not perfect, but the use of a 1px text-shadow with no offset creates a faux anti-aliasing effect and for a tiny trade-off in sharpness is far more pleasing on the eye. The trick is in the colour, and different faces at different weights will require different rules but for the text above, here’s what I came up with:

text-shadow: 0 0 1px rgba(51,51,51,0.3);

The text-shadow is the same colour as the text: hex #333333 expressed as RGBa (51, 51, 51) with 30% opacity, which gives the subtle blur that takes away the jaggies.