Pros and Cons of using sIFR
sIFR (scalable Inman Flash Replacement): allows for dynamically-generated snippets of text to use any font supported in Flash using a combination of JavaScript and Flash embedding to replace characters on the page.
In my last post regarding sIFR, I compared sIFR against a few of the other popular font replacement methods such as Cufon and FLIR. Since there is obviously a great deal of interest in the subject of font replacement, I figured it would be beneficial to show a deeper analysis at sIFR which I believe is the superior out of the three.
A deeper look at pros of sIFR
sIFR is quite different to the many font replacement techniques in the wild. Instead of manually generating each header through an image generator such as FLIR and Cufon do, sIFR is able to load a flash object and replace each element on the fly. The scripted effect works for roughly 95% of world wide web users according to statistics for Flash support and JavaScript support in modern browsers. Note also, that sIFR is by no means required, and degrades gracefully if the user does not have one of these components required. I’m sure some purists would react with contempt, but this method causes no harm to usability and only effects load time if used incorrectly (such as replacing body text rather than headers).
sIFR… what’s not to love?
First and foremost, implementation can be slaughtered. For an inexperienced developer, sIFR can take up to an hour to implement (from what I’ve heard in complaints anyways) and can cause pages to load slowly. From my experience, both are due to an incompetent developer, as sIFR is quite easy to implement if you understand all front-end technologies (which you should be a front-end developer) and only causes slow load time if its used for large blocks of text. Compare sIFR to the first wave of Web 2.0 technologies.. to this day I see wannabe developers implementing 20k+ javascript libraries to do one simple “jiggle” or “ajax” ability, which you can do with a few lines of code if you understand raw JavaScript. We can’t blame the technology for human error.. sIFR is brilliant. It may have a ways to go before it’s perfect, but respecting the principles of semantics, usability, and accessibility.. sIFR by far is winning the race against Cufon and FLIR.
Now to address the purists and their complaint about flash and JS dependency. Plain and simply, if a user falls within the 3-10% that doesn’t have Flash or JavaScript enabled, then BIG DEAL. That’s what good old HTML/CSS are for.. a fall back solution. Should we punish those with modern browsers and technologies for the minority that will get a slightly-less-quality rendering? I don’t punish modern browsers by neglecting the wonders of CSS 3. If Internet Explorer sees a box with square corners instead of rounded.. BIG DEAL. So why should we fight about whether a user has JS or Flash enabled? Heck, you can even use image replacement at that point, if you really want to.
The Big Picture
The real issue is that there aren’t enough fonts supported in Internet Explorer. If we want to point fingers and find something to criticize, there it is. Firefox, Safari, Chrome, Opera.. they’re all supporting more CSS properties such as @font-face. However, due to copyright laws and support from Internet Explorer we are bound to 5-10 fonts that we can reasonably assume the user has installed, and that’s ALL we’ve got. Solutions have been offered and argued but the problems are still much broader.. ranging from font licensing, support and rendering, with no clear solution in sight.
sIFR is one solution of many offered by developers fighting a war for creative freedom. It’s here and now, it’s legal despite the font, and regardless of the few quirks.. it’s usable. If you use it, then I hope you implement it well. If you protest it, then I hope you have valid reasons, and aren’t just complaining because you’re ignorant. Take this post with a grain of salt.. it’s my 2 cents and nothing more.
Read further:
Cufon vs sIFR vs FLIR
Style vs SEO
Fonts and the Law
