Over the last several months, a small group of web developers and designers have been hard at work perfecting a method to insert rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics. The method, dubbed sIFR (or Scalable Inman Flash Replacement), is the result of many hundreds of hours of designing, scripting, testing, and debugging by Mike Davidson (umm, that’s me) and Mark Wubben. Through this extensive work, sIFR, along with a invaluable stable of beta testers, supporters, and educators like Stephanie Sullivan and Danilo Celic of Community MX, have completely rebuilt a DOM replacement method originally conceived by Shaun Inman into a typography solution for the masses. It is this technology which provides the nice looking custom type headlines , Nike, ABCNews, Aston Martin, and others. sIFR released sIFR to the world as open source, under the CC-GNU LGPL license, so anyone can use it free of charge.

How it works

sIFR is meant to replace short passages of plain browser text with text rendered in your typeface of choice, regardless of whether or not your users have that font installed on their systems. It accomplishes this by using a combination of javascript, CSS, and Flash. Here is the entire process:

1. A normal (X)HTML page is loaded into the browser.
2. A javascript function is run which first checks that Flash is installed and then looks for whatever tags, ids, or classes you designate.
3. If Flash isn’t installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you’ve designated as something you’d like “sIFRed”.
4. Once measured, the script creates Flash movies of the same dimensions and overlays them on top of the original elements, pumping the original browser text in as a Flash variable.
5. Actionscript inside of each Flash file then draws that text in your chosen typeface at a 6 point size and scales it up until it fits snugly inside the Flash movie.

This all happens in a split-second, so all of the checking, replacing, and scaling is not visible to the user. It is not uncommon to notice a very short delay as the Flash loads, but to the user, none of the internals of this process are exposed.

From a technical standpoint, a lot more stuff is happening, but that is a top-level overview. The only other material part of the process that is important from a developer/designer perspective is how CSS styles change during all of this. Your (X)HTML document starts off with its standard styles. Then, once sIFR determines it will run, your html and body tags are classed with “.sIFR-hasFlash”. This is done in order to accomplish two things: 1) to hide your browser text as the method is running, and 2) to create “decoy” styles for the text you are replacing. Decoy styles are never seen by the user. They are meant to adjust the space the browser text takes up before the measurement and replacement occurs. This is necessary because your browser text might be a narrow font and your Flash text might be a wide font. So in other words, something that takes up one line in browser text might take up three lines in Flash text. In the above case, you’d set your decoy style on the browser text to something like “letter-spacing: 10px;” to widen it to match the Flash text. This process is called “font tuning” and it’s really the only potentially tricky part of sIFR. Everything else is cake. Because you can’t explicitly set the size of your fonts in sIFR, your sIFR fonts will take their cues from your browser fonts. Match them up by adjusting your decoy styles and sizing will take care of itself