A comparison between sIFR, Cufon and @font-face
Every now and again we at Solid State like to review the current trends in dynamic text replacement techniques; getting text on a web-page in a non 'web safe' font.
Traditionally, 4 years ago, if you really, really needed to use a particular non web-safe font, you would have had to use an image instead, alongside a CSS technique like one of these. This is an approach that is still widely used due to the fact that it's easy, SEO friendly and relatively fast to render, providing you use CSS sprites.
For static web sites this worked well, up until the text needed changing, creating the tiresome process of starting Photoshop whenever a website required an edit, creating the new heading, uploading it and proofing it. A content management system vendor, such as ourselves, is always on the lookout for a better solution.
The three options below represent the current state of the art. Unfortunately none of them are clear winners in terms of overall functionality. Like most things in web development, it's a compromise; chose the right tool for the task in hand.
Back in around 2005, sIFR appeared, and everybody thought it was going to change everything. It did, sort of. Beautiful, SEO friendly, dynamic text was now possible, but it was slow to render on the page, created complications using AJAX, and despite what the documentation suggested, was a nightmare to implement with links and navigational elements. Oh - and Flash was required too. And so it is for these reasons why most web-developers wince slightly whenever the technique is mentioned. In fact, even though the 3rd version of SIFR is a little better than its original incarnation, I'm grimacing a little as I write this...
The main drawback with Cufon is that you can't select the rendered text as you can in sIFR. If the user wants to select it in order to copy it somewhere else, they are going to end up confused. Interestingly, it is worth mentioning Typeface.js, which works in a similar manner to Cufon. If you are happy to sacrifice a little rendering performance, it is possible to select the text rendered with Typeface, though it has to be said it did work quite slowly when we tested it.
@font-face is a css technique that has actually been around for a while; it was first defined in the CSS 2.1 specification. It allows a font to be hosted on a web server and referenced within a web page, creating the 'perfect' solution to this issue.
Well, almost! Apart from the thorny issue of font copyright that needs to be dealt with, together with increased page loading times due to the download of the font file itself, there is something of a show stopper to this technique.
Unsurprising, it's Internet Explorer that causes us the grief. Not that IE doesn't support this CSS property - in fact IE4 was the first browser to do so back in the dark ages. But to this day it only supports @font-face using an Embedded Open Type (.eot) font, which would be fine, but for the fact that creating one of these involves the most unnecessary and laborious process using Microsoft's WEFT tool, which is where most people give up. And to be honest, so did we.
And the winner is...
So, to summarize:
|Images with text replacement||sIFR||Cufon||@font-face|
|Browser compatibility||All modern browsers, inc IE6||All modern browsers, inc IE6||All modern browsers, inc IE6||Limited support in IE|
|Needs plugin||No||Yes (Flash)||No||No|
|Relative ease of implementation||Easy||Difficult||So-so||Easy|
|Suitable for hyperlinks||Yes||Eventually||Yes||Yes|
I would love to say otherwise, but regardless of the hype that @font-face seems to be generating at the moment, I can't see it's widespread adoption happening any time soon. Microsoft still needs to resolve the font DRM issue, so it can allow more common font types. It might seem a while off, but together with every other web developer out there, I can't wait for that day to arrive!