Typekit has been fully released (without so much as a Beta tag) and it’s about time to give it another shot. Last time I checked out Typekit, there were as many bugs as you’d expect from a developer preview release. Thankfully, a lot has changed and it’s all quite promising.

sIFR and Cufon

The CMS-based websites we produce nearly always require some sort of dynamic text replacement to allow non-system fonts to be used as page or section headings. sIFR is often our only feasible option when:

1. the heading font license is restrictive
2. the heading font can’t be adequately rendered by a server-side technology
3. the design calls for text manipulation beyond Cufon’s capabilities

sIFR sidesteps any font licensing issues by embedding the font into an Adobe Flash file and allows for heavy tweaking and customisation, beyond what Cufon offers. sIFR also produces selectable text, which is a nice (if not completely necessary) addition.

Where it can be used, Cufon is a great solution. Unlike sIFR, there is no noticeable jump or flicker when text is replaced and it’s a relatively small Javascript package to include.

The beauty of Typekit

sIFR and Cufon are both useful but are complete hacks. The appeal of Typekit is that is uses the @font-face CSS rule, which is the ‘proper’ way to do things. The Javascript you include with Typekit works around font licensing problems and the discrepancies in @font-face support between the different browsers. Of course, you are restricted to Typekit’s library of fonts, the growth of which will be key to its success.

Typekit isn’t free, which prompts the question of who manages the Typekit account. When delivering a site, we prefer to be completely transparent with hosting (our clients pay the Web host and any service providers directly) which is how we would handle a client’s Typekit account. Ideally, Typekit would receive a one-off payment for use of a font on a single domain (well, ideally it would be free!) which removes any need to justify an additional administrative overhead, just for the use of a particular font on their website.

Pros:

• complete typographical control with CSS
• works without images or Flash
• easy set-up

Cons:

• original font sometimes appears an instant before Typekit loads
• pricing model could be problematic for clients
• font file cannot be tweaked to reduce its size
• limited choice of fonts
• does not support Chrome or Opera

Chrome and Opera will hopefully be supported quite soon and Typekit must be eager to expand the font library with quality fonts as soon as possible. However, the first two cons are show-stoppers for me. Every site I’ve seen using Typekit suffers from a noticeable text replacement in Firefox and Internet Explorer. The closest web-safe font to the sans-serif Le Havre Rounded I tested was Arial. Below, you can see the Arial text that flashes up an instant before Typekit replaces the font.

Relating to a wider debate on Web typography, I noticed the differences between Apple and ClearType rendering meant that some of the library fonts had a completely different appearance on a Mac than on Windows. Of course this is nothing new, but slightly concerning given that Typekit allows developers to very easily use any font for any area of copy on a website. Below are some shots from the same Typekit configuration viewed on different browsers.

Safari:

IE (or Firefox with XP ClearType):

Firefox without XP ClearType:

Of course this is in no way a fault of Typekit, but worrying to think legibility and readability of standard web fonts may be shunned in favour of prettier typefaces.

Overall, I’d encourage any developer to try Typekit as it’s already a real alternative to sIFR and Cufon. I’ll be eagerly following its progress.

Tags: cufon, fonts, sifr, typekit, web typography