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.
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 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.
My opinion remains that we should still try and use web safe fonts, certainly for main text blocks. For static headings (for example sidebars and panels) I still think CSS image text replacement, cunningly crafted with CSS sprites, is still the optimum technique, especially in a world where JavaScript heavy sites are becoming more common. In instances where we do need dynamic text, providing it's using sparingly I'm tempted to go with Cufon; it is relatively easy to implement and has provided us with some good results so far.
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!
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.
sIFR
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...Cufon
In an attempt to tackle sIFR's shortcomings, a clever guy called Simo Kinnunen came up with Cufon - a JavaScript rendering engine that made use of VML in Internet Explorer, and the HTML5 <canvas> element in other browsers, to render custom fonts. It doesn't need Flash, it's faster to render than sIFR and from what I can see from it's demos page, it's suitable for navigation too. My colleague Paul (@paulmasek), has just started a project using it, so I'm sure we'll be talking about it soon. Watch this space.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
Whilst these techniques are great in providing credible solutions to the lack of available fonts to web designers, it does suggest that there should be a better solution; one that wouldn't require messing around with JavaScript and Flash. After all, other fonts can be specified in the regular CSS 'font-family' property, but there is no guarantee of their installation on users' computers.@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 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 | |
|---|---|---|---|---|
| Dynamic Text | No | Yes | Yes | Yes |
| 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 |
| Rendering speed | Fast | Slow | Fast | Fast |
| Selectable text | No | Yes | No | Yes |
| 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!
No comments:
Post a Comment