Since there is obviously a great deal of interest in it, a rational analysis of what sIFR means is in order.
At WE04 earlier this month I was asked on-stage once and a few times privately what I thought of sIFR, or scalable Inman Flash Replacement, the new Flash replacement technique. While I don’t for a second pretend like I know everything about it, I believe I’m familiar enough with its usage issues to offer an opinion. And that’s what this is, an opinion — take it with a grain of salt.
sIFR has evolved quite a bit in its year-long life cycle. Initially crossing my radar in October 2003, a lively argument between Mike Davidson (creator and maintainer of the code) and myself is still preserved at holovaty.com. Mike won, because he had obviously thought about it in great detail and had good answers for most questions.
Since that time, he and some others (notably Shaun Inman, hence the ‘I’ part of sIFR) have taken it much further, and solved many of the problems with the original version.
sIFR is easier to implement than any image replacement technique. Instead of manually generating each header through an image editor, you’re able to skip the editor completely. Elegantly, it will skim through an XHTML document and find the relevant bits, swap out the text and drop in the typographically rich replacement.
And that is what makes it so exciting. It’s a useful piece of non-intrusive scripting that adds an extra dimension to a page. And the scripted effect is by no means required, it degrades gracefully. sIFR allows for dynamically-generated snippets of text which can use any font, not just VerdanaGeorgiaArial. And that’s a major benefit to those of us resigned to the same five fonts.The immediate reaction of purists and purist wannabes is, inevitably, ‘ew’. Invoking Flash is reason enough to cause the reaction, but using it for such trifling detail as a header? Who could be that insane?
Well, Mike was, and others were, and now sIFR is a real technique to contend with. But on to the cons.
First, as far as I’m aware, the accessibility of the technique is a question mark right now. I haven’t heard of any screenreader testing, and I’m unaware of anyone having done a more in-depth look into the implications on assistive technologies. ( Mike confirms that it has been tested, and appears to work just fine.)
And there are a few usability niggles. You can’t select the text within a sIFR headline. Well, you can… but not in the same swaths as you’d select body text. You have to make a separate pass for each. This is an improvement over image replacement, though, since no text within an image is selectable. ( Mike and others note that the text does get selected, there’s just no visual feedback mechanism.)
Text within sIFR also doesn’t scale. Well, it does… but only according to your font size when loading the page. Any subsequent instances of Ctrl + “+” are ignored, until you reload the page. This is also an improvement over image replacement, since no image-bound text has ever scaled. And I’m inclined to say it’s more a consistency problem than an accessibility problem anyway, since those who need the larger text size are more likely to be browsing with their font scaled appropriately to begin with.
My personal peeve is speed. A page with more than one instance of sIFR has a much longer load time. Jeff Croft has pushed his adaptation of sIFR to the limit, and waiting for the headers to load so I can determine whether I’ll read the block of content below is a little irksome.
Finally just a little thing, but an important one — a sIFR header is able to act as a hyperlink. When I hover over a normal link to decide whether I want to follow it or not, I very frequently check my browser’s status bar to see where it’s taking me, and whether the destination in question is worth viewing. sIFR doesn’t have any way of reporting back to the browser where that link is going, so I don’t get the preview, and links become a little more blind.
One Solution, of Many
At the same conference I referenced earlier, Doug Bowman mentioned in his presentation that advanced techniques come about because someone was trying to solve a problem. sIFR is just that: a solution.
The problem is that there aren’t enough fonts in a web designer’s palette. We are technologically (and quite probably legally) bound to 5 or 10 fonts that we can be reasonably sure the end user has installed, and that’s all we’ve got to work with. Solutions have been proposed, and font embedding was even a part of the CSS2 standard (though it was ditched in CSS2.1 since no one uses it). But the problems are much broader, ranging from font licensing to delivery to rendering, so there’s no clear solution in sight.
sIFR is one proposed solution by those in the trenches. It works, it’s here today, it works around licensing problems, and despite the other problems above, it’s usable. It’s not the perfect solution by any means, but until the standards bodies, font foundries, and browser manufacturers can all agree on one thing, it’s what we’ve got to work with for now.
It may not be for you. Image replacement may not be for you either. I personally plan to continue using the latter, and may investigate sIFR at some point in the future, but I’m in no hurry to shake up my development practices at the moment. It’s one choice amongst many, but the important thing is having the choice.
This article is meant to provoke discussion, it is not the final word. Feel free to fact-check me and report back in the comments. The information in this article is true to the best of my knowledge, but without having used it or tested it I can’t be considered a sIFR authority.