To sIFR or not to sIFR

Hop Studios is on a quest to make the internet easier to use and prettier to look at. Sometimes, however, these two goals come into direct conflict - The techniques needed to create unique and attractive websites are sometimes unwieldy and buggy. Take for example, sIFR, or Scalable Inman Flash Replacement, a brilliant idea from Shaun Inman to allow for more diverse typography on the web. You can read more about its recent incarnation on Mike Davidson’s Blog. Hop Studios has used sIFR on several of our projects.

Websites are composite creatures, and when you look at type on the web it’s not coming from the internet at all, it’s pulling the fonts from your personal computer. Because of my job I have hundreds of fonts, but you may only have twenty or thirty. Using CSS I can ask your computer for any font, but if you don’t have the font I request it will get replaced with something else. If I want my designs to look the same across many user’s computers (and i do!) i need to pick from a limited selection of standard fonts. You know these guys, you’ve seen them before…. everywhere.

sIFR is a way around this limitation. It works like this: You create a parallel typeface file in flash and attached its use to any HTML tag you like using CSS. This file is stored on the server. When a page is loaded a short javascript checks to see that the Flash player is installed, then replaces any tagged content with the flash generated letterforms.

Why is this good? Well it means that you can have diverse type that is dynamic - pulled from a database, and you don’t have to create images for all the instances of interesting typography on your site. It’s searchable, something that images are, and for a long time, flash was, not. And it’s scalable - you can deploy this tool once and use it across your site many times in many ways.

Why is it bad? It’s complex and problematic, sIFR employs four different technologies to functions correctly, XHTML, CSS, Javascripts and Flash. This means it has multiple fail points. It’s tough to maintain and can sometimes behave oddly in the page. If you place sIFR next to a floated element it explodes to many times its original size. Finally you cannot replace large blocks of text, sIFR works best on display type, like titles and pull-quotes.

The creators of sIFR fully admit its limitations, Mike says:

While sIFR gives us better typography today, it is clearly not the solution for the next 20 years. It is but a nice stopgap for people who value the importance of typography and don’t want to wait 1, 5, or 10 years for browser makers, OS vendors, and type foundries to figure out a better solution.

In short, it’s a complex solution to a complex problem, and should be used with care. Hop Studios generally tries to pick the best possible cases to use sIFR, and implements it sparingly.


Have a Project for Us?

Request a Proposal