Rich Text Headlines with sIFR – Experiences

The other day, I decided to give sIFR a try. In case you didn’t know, sIFR allows you to embed fonts on web page, letting you choose fonts of your choice, for rich headlines in blogs or websites.

Unfortunately, sIFR isn’t all good.

Having used it for a couple of days now, I have summed up my experiences with the system.

The System

It is quite clear that sIFR has been through a lot of development. Great effort has been put into making it work as consistently as possible, and be as easy to work with as possible.

And it is easy, and it does work great. Once in place, one simply specifies which headline to replace (in my case, #main h1), and sIFR works its magic. This magic includes detecting Flash, analyzing headlines (including headline links), and replacing with properly sized and padded Flash headlines.

The beauty part is, that it truly does degrade gracefully. If the end user doesn’t have Flash installed, it simply makes no sound or noise, and shows regular HTML headlines. If the end user doesn’t even have JavaScript enabled, it also fails silently. No annoying or scary error messages. Furthermore, out-of-the-box it works flawlessly in most browsers, without extra work.


It should be mentioned, that this article is mainly evaluating in this article sIFR 2.0rc1. Thus, while it works great, it is not yet final, and some bugs / issues may be fixed or changed in the final version. Update: sIFR RC2 has been released.

I mentioned the installation process was fairly simple. This is not entirely accurate, as sIFR requires a fair bit of knowledge of CSS and semantic XHTML. When you download the current sIFR pack, you get a Flash movie called sifr.fla, a few script files, some pre-made “fonts” and an example page (which is also viewable online). The example will work fine if you run it—the somewhat tricky part is separating out from that example, only that which you need, to apply sIFR to your page.

After an hour messing around with stylesheets and the IFR JavaScript, I had it working. Based on these experiences, I have some suggestions on how to improve the sIFR download / “starter pack” in future releases:

  • Simplify the example page
  • Currently, it looks great, but is simply too complex for basic usage. It tries to show everything that sIFR can do (which is cool), but most people will only be confused by this. If necessary, create a separate documentation for sIFR, instead of keeping this inside the code. Here, more advanced examples can be provided.

  • Separate sIFR CSS into an external stylesheet
  • This is easy to do yourself, but everyone will do it, so why not have it this way by default?

  • Rename “sifr.fla” to, for instance, “sifr-font-template.fla”
  • It’s a detail, but why not speed up deployment by doing a simple rename? Few will know, by heart, what it is “sifr.fla” does, but most will identify it directly with a better filename.

  • Include more international characters in the default template

I had the need for special characters such as ? ? ? ? ?, but these weren’t shown “out-of-the-box”. I had to re-do my font movie, with these characters embedded in the textfield.

Bugs and Limitations

As mentioned, the sIFR system is not all fun and games. Introducing the system to your site, will also introduce a few usability problems and inconsistencies. Most are related to sIFR relying on Flash, which has inherent usability problems. Some of these issues were also mentioned in my previous article about sIFR, but I thought I’d repeat them here in their final form.

  • Dynamic (on the fly) font scaling breaks
  • If you adjust the font size using your browser, headlines won?t scale along with the rest of the text until after you reload the page.

  • No visual feedback on text selection
  • Since each headline becomes an embedded Flash movie, text selection won’t be visually indicated by sIFR replaced headers. You will, however, still be able to copy/paste the text, including the headline.

  • In some instances, links can?t be copied
  • If your header links somewhere (as in my case, to permanent archive locations), you will only be able to right-click/copy target links if you do not use an sIFR hover color.

  • Firefox users can?t middle-click
  • Since the interaction behavior of Flash movies is dictated by the Macromedia Flash Player plug in, and not the end browser, Firefox users won’t be able to use their beloved “middle-click /open link in new tab” feature.

  • Rollover status bar link target disappears
  • Once again, related to the headlines being Flash—rolling over links usually reveal their targets in the status bar. Not the case here.

  • Firefox seems to have trouble with links
  • This is most likely a Firefox bug, related to embedded Flash movies. Nonetheless, Firefox seems to show erratic behavior as to when sIFR links work. Sometimes, links require two clicks, sometimes a rollover won’t work, and won’t show a “hand cursor”. Update: sIFR RC2 fixes this problem.

  • Hover effects are not reset when releasing outside

A common Flash button mistake. If clicking a link, and releasing outside, the button hover state won’t be reset. This can simply be fixed using on (release, releaseOutside).

Pros and Cons

  • + 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)


I truly think sIFR is the one of the best uses of Macromedia Flash the web has seen yet. It gives power to the designer, and asks very little in return.

But it is not for all websites. The usability problems introduced by sIFR are grave, especially when used improperly. As mentioned, Flash has usability issues, including a non-standard interaction behavior. For example, copying links, selecting text and plainly right-clicking, works as defined by Macromedia, not by the browser. This is bad, and should seriously be considered before you jump on the sIFR train.

As such, consider your website audience, and how you will use sIFR, before you even consider it part of your design. Will the end users notice how much better your website looks? Will they care? Will it even make your website look better, or could you simply have chosen a Helvetica or Georgia? Also give serious thought to where you will apply sIFR. After all, it is your choice what headlines to “enrich”. As I see it, the worst usability problems lie in the link aspects of sIFR. If your site relies on people clicking on headlines to get to the content, you should seriously reconsider making those headlines sIFR. After all, you’re breaking not one but several usability rules by doing so.

I have a gut feeling many issues with Flash usability will be addreassed in Flash 8, but no-one can really know for sure. Until then, consider whether the (possible) improvements in design are worth the hassles and usability problems.

In my case, I’m loving sIFR, and I’ll definately be keeping it.

14 thoughts on “Rich Text Headlines with sIFR – Experiences”

  1. Great article Joen.

    You might remember that, some time ago, we talked about toolkits on my website…

    I agree with every single point you’ve made about sIFR. But remember the toolkit analogy – sIFR has its place, it’s not suitable for every website as you have correctly identified, but if the design demands it – then it’s an absolute gift from God (well a gift from Mike anyway).

    For myself, the right place is anywhere where the font is a required branding element. Outside of “the brand”, I wouldn’t use sIFR because of the issues you have highlighted.

    Now if only it handled transparent backgrounds…

  2. Joen says:

    Glad you enjoyed the reading. Just looking over it now, I’m surprised it became so long an article.

    But yes, it all has it’s place. And I think it looks great on Noscope, even though I am, in fact, breaking one of my own pieces of advice. I mentioned that one shouldn’t rely on links through sIFR, at the same time I’m doing just that by linking to permanent article locations in headlines.

    My justification for this was, that the articles that needed to be read in their permanent link locations, would have “read the rest of this entry” links anyway. Additionally, it is on the rarest of occasions that such things as Firefox middle clicks would be needed for these links (or not?).

    As for background transparency, sIFR actually does support this, although not on older browsers. As part of the sIFR replace function, one can specify background mode. Default is “opaque”, but changing that parameter to “transparent” will do the trick. It is not recommended though, as it slows down rendering. However, considering the text is not being animated or anything, I don’t really think it’ll slow down that much.

  3. Mark Wubben says:

    Joen, thanks for this excelent review. Mike hasn’t written the let-your-grandma-do-it documentation yet, therefore you were stuck with the show-off example. There’ll be documentation when we release version 2.0 final. I bet most of the time you spent on implementing sIFR was “wasted” by digging through the example page, right? Actually, I think it’s great you spent but an hour on that. I mean, an hour isn’t that much for something that works site-wide, is it?

    About sIFR 2.0 final, there are some minor JavaScript improvements. Perhaps Mike has updated the Flash a bit, but I’m not sure. I do like your suggestions though! (Mike, what ya say?)

    Could you please elaborate on the IE issues? Can they be fixed or is it truely IE which is screwing up?

    You can find some excellent use of sIFR at Prosper Magazine.

    Again, thanks 🙂

  4. Mike D. says:


    I pretty much agree with everything in this post… except maybe the word “grave”. Not being able to middle-click is not exactly a “grave consequence”, but whatever.

    I personally use sIFR most of the time for non-linking items. I don’t link my headlines, instead opting for a “permalink” text-link at the bottom of the entry excerpt. I think 95% of the concerns you raise are eliminated by just not using linking on sIFR items.

    Great post.

  5. Joen says:

    I’m thrilled we all agree, and what an honor it is to have developers commenting on my article.

    I’m also glad that my opinion of sIFR wasn’t entirely misrepresented. After all, I truly think sIFR is MUCH more good than it is bad. I was a little worried that might not shine through.


    Indeed an hour is not much, and the installation process has come a long way since the plain IFR, which I didn’t install for the same reason.

    As for the IE bugs I mentioned—I will update my article and make it sound less intimidating. I am all but certain that the IE problems I experienced were related to my markup, not the sIFR system. The problem, in my case, was with the replacing Flash being a 100% width block element, which for some reason wouldn’t work along with a left margin—or something. I solved it by setting the width of my main h1 to 99%.

    Great examples on Prosper magazine, and I’ll be looking forward to 2.0 final.


    You are absolutely right, most usability problems are related to linking, and as I wrote in a comment, I’ve tried justifying my own personal usage of my header linking. Let me also just say that I love the fact that linking works at all! Upon installation, I was surprised to see this, not having expected it.

    With regards to the “grave usability issues”, I stand by that. The very fact that the Flash Player has it’s own right-click menu, is just one example, and in this case, the deciding factor. Ideally, Flash would rely on the browsing client, to provide not only right click menus, but also proper click behavior—in the case of Firefox, middle-click behavior.

    But that’s Macromedia’s fault, not yours, and having followed both IFR through sIFR, it is clear that there’s been a tremendous focus on both author and end-user usability. This deserves credit, definitely.

  6. Jina says:

    Thank you so much for this article. I have heard nothing but good, and I needed a more realistic article such as this to help me make my decision. 🙂

  7. Joen says:

    Glad it helped you out, hope you can make an informed decision now!

  8. As for background transparency, sIFR actually does support this, although not on older browsers.

    Cool. I hadn’t realised this. No I might just have a use for it…

  9. Ash Haque says:

    I also decided to not go with sifr, mainly because I was having some error at being able to show things properly. When I tried to use sifr on one h2 class every other h2 heading disappeared, and my headers (in WP the title of your posts) which were under so many characters turned into like 1/4 the size they were supposed to be.

  10. Ash, if you’re going to use sIFR for only one H2, it should work to give it a class. But you must do that in the JS replacement calls as well as the decoy (make sure to use a descendant selector).

    As far as the sizing goes, that generally happens when the sIFR isn’t properly tuned (the decoys) and/or the same amount of padding isn’t put on the JS replacement calls as the original CSS Selector. There’s excellent documentation now — so I would read that and the wiki and be sure you had everything done properly. Especially with the final release having just been issued.

    I’ve been having excellent luck with sIFR. 🙂

  11. stretchdog says:

    Great stuff and very interesting.

    I have one issue that I am unable to get to work, that is the BG transparency of the H tags laid over an image, is this possible? Can someone help me?

    thank you,


  12. Joen says:


    To get transparency, you have to add a parameter to the insert code. I don’t quite remember it, but it’s probably somethign like wmode=transparent. There’s an SIFR wiki, maybe there’s something there.


    look at the replacement syntax.

  13. TO add transparancy you need to add sBgColor:”#a2a2a2″ i the page script as this..

    sColor: “#ffffff”, sBgColor:”#a2a2a2″, sCase: “”}));

    I totally agree with the problem and complex way of adding this to a website.

    I tried to add it to and but locally it felt slow and not convenient to its

    purpose. It is a designer issue and it has diffferent usage but for now, Slow and

    I did’nt like it really.


Comments are closed.