Reconsidering sIFR

A while back, I decided to try out sIFR and see how I liked it. In case you didn’t know, sIFR is a fantastic combination of JavaScript and Flash that allows websites to use a custom font for headlines. It is highly scalable, and very easy to install.

In fact, when I first tried it out, I weighed the pros and cons and was so impressed that I happily decided to use it.

Now I’m not so sure anymore.

Pros and Cons Revisited

In the original article, I listed the pros and cons of using sIFR:

+ Truly choosing your own fonts is great, and it looks great

+ Once it is deployed, it works flawlessly

+ It degrades very gracefully

+ It is transparent (literally) to search engines

+ Compared to other rich headline techniques, such as FIR, sIFR provides much lower file sizes – sIFR introduces various usability problems. See above, in ?Bugs and Limitations? – Since sIFR is Flash, it has nonstandard interaction behavior – If too many headlines use sIFR, it may affect scrolling and system performance – If used improperly, it will significantly lower website usability (see conclusion)

These pros and cons remain unchanged. However, new things have come to light, and a few things have started to annoy me:

  • 1. Headlines are invisible until entire page is loaded
    Until just recently, I didn’t really have any long articles, so I never noticed the problem. Then I wrote about Favatars, and the bulk of comments made it quite obvious.

    Because of the way sIFR works, all headers will be invisible until the entire page (html + images) is loaded. This is due to the fact that the JavaScript that replaces all <h2> headers is initiated onload.

    Impatient as I am, this annoys me.

  • 2. Since sIFR uses Flash Player, it behaves differently when selected, scaled or clicked
    Most of the problems with sIFR are related to it being based on Flash, that is, a 3rd party plugin with it’s own custom interface. This means selection, right-clicking, scaling and linking works differently. Most of these issues are small, but the linking problems really represent a problem. More specifically, I am longing for my beloved “middle-click / open in new tab” Firefox feature.

Great For Some Things

Make no mistake. sIFR is the best thing to happen to typography on the web. I cannot stress this enough. On pages such as ESPN articles, it works wonders. It looks great and since no linking is involved, all those issues are avoided. Additionally, the JavaScript loads much faster as the articles are generally short.

I am letting go of sIFR for the reasons mentioned above. I might bring it back at some point, but for now, I’ll see how things work without it. I am very aware that I am sacrificing a design element in favor of just a little bit of speed and usability.

Why? Because this is my place; where I test things and see how they work. On client sites I will have little trouble applying sIFR and my clients will love it.On Noscope, however, I want my middle-click feature.

Responses to “Reconsidering sIFR”

  1. AkaXakA says:

    1. Headlines are invisible until entire page is loaded [..] This is due to the fact that the JavaScript that replaces all headers is initiated onload.

    So you could call siFR at the end of the body, right?

    Nr 2 is of course a issue and, depending on the content, quite a big one. I’ve seen the Flash 8 video though and it looks amazing. Macromedia have obviously been working on video-in-flash but I have a hunch they’ve been working on accessibility aswell. Once it’s out it’ll take about a year though before enough people have it though (90% penetration I believe).

    I’m wondering though how FI do it (http://www.fantasy-interactive.com/), as their text is fully selectable eventhough it’s all in flash (rightclick to see the flashmenu).

  2. Jeff Croft says:

    Nice write up. Although I am a fan of sIFR, I can’t really argue with your points. I remember not long ago Shaun Inman (who is at least one-third responsible for sIFR) saying himself that it’s really not appropriate (right now) for text that is linked. Since I don’t link the headers on my blog, I find it works great. But you’re absolutely right — when you start getting into links, things get screwy. Hopefully Shaun, Mike, and their other cohorts will eventually be able to work this all out.

    I’ve said this before, but it bears repeating: the legacy of sIFR may not be as a standalone script/product, but rather as a means to push the W3C and browser manufacturers the somehow incorporate 100% choice by the designer of typeface into some standard. sIFR proves that it’s highly desirable, and that if the W3C doesn’t give us a way, we’ll find on our own own.

  3. Mark Wubben says:

    The hiding of the to-be-replaced elements is necessary because otherwise it’d show the sometimes weird styles which are needed to force the Flash text into shape. It’s a CSS setting though, so you could disable it if you wanted to.

    As for the links… we don’t encourage you to use sIFR for links. It’s possible, but it’s not optimal.

  4. Joen says:

    Aka,

    So you could call siFR at the end of the body, right?

    I suppose so. I suppose I could even make a function call after the last laden headline. Still, that’s too much of a hassle for me.

    As for Flash 8, I do hope they’ve made some accessability updates, especially with regards to tighter browser integration. On the Fantasy Interactive site, however, they don’t do anything special as I recall – text selection is a textfield option box in Flash. The problem is when you select text and html text at once.

    Jeff,

    [...] but rather as a means to push the W3C and browser manufacturers the somehow incorporate 100% choice by the designer of typeface into some standard.

    Not a bad idea. Might just happen. However, I think we’re going to see so massive changes to how the web works / can work in the next 3 or 4 years that these limitations will be a thing of the past (i.e. overkill compared to just giving us the ability to embed fonts).

    Mark,

    It’s a CSS setting though, so you could disable it if you wanted to.

    Jeez you’re right. But you’re right, that would look pretty weird.

    As for the links… we don’t encourage you to use sIFR for links. It’s possible, but it’s not optimal.

    Exactly, and that’s why I let go of it for now. Quite simply, inappropirate use on my part.

  5. Rob Mientjes says:

    It’s a loss in terms of design, but I much prefer normal links. Flash is a serious problem with links, so I avoid it at all times possible.

  6. Mike D. says:

    Incidentally, if we wanted to lose Flash 6 compatibility (which perhaps might be ok in a few months), we could very easily enable right-clicking on links. In fact, we can do a whole lot more than that. In Flash 7 and greater, you can add whatever you want to the contextual menu. We could even add “Look up this word on Google” or “Define this word”. Piece of cake, really.

  7. Joen says:

    In Flash 7 and greater, you can add whatever you want to the contextual menu.

    Yeah, that’s pretty cool. But that still wouldn’t allow me to middleclick / open in new tab.