sIFR vs Typeface.js: The Verdict

[Update: If you're looking for the typeface.js :hover workaround, it's here]

Months ago, in my mission to find a good solution for using fancy fonts on the web, I had a choice between sIFR and typeface.js. sIFR uses Flash to render text, and typeface uses the <canvas> element (or VML in IE). Other than the difference in implementation, however, their feature-set looked about the same, at least for my simple purposes: they were both javascript driven, both allowed text to be selected, and they both looked damn good.

But typeface.js had one crippling debilitation. It didn’t have :hover support. Weak. So I went with sIFR.

First, I found sIFR’s configuration to be a pain. Well, that’s OK. I only have to learn the setup once, then I can copy+paste my code.

Then I found that it had z-index issues in IE, particularly when using them as links and tying the :hover directive together with an image change. Annoying, but it’s flash based and IE is always a pain. Fine.

Then I noticed that my jQuery animations (slide effects) were slowed down when sIFR elements were included in the animated element. Hmmm.

Then I started using a lot of sIFR elements on one page… significant loading delay. Hrmph.

Then it came to my attention that every once in a while the sIFR elements would fail to load altogether in IE on those sIFR-heavy pages. Uh…. sIFR, we’re through. This just isn’t going to work out. It’s not me, it’s you. It was great while it lasted (wait, no.. not really). Ciao.

And then I said hello to typeface.js. Configuration? Piece of cake. Speed? Fast! Reliability? Hasn’t failed me yet. Z-index issues? None. Lack of :hover support?

I can live with that.