Scalable Inman Flash Replacement or sIFR for short, combines Flash and JavaScript to enable the display of custom fonts on a web page. sIFR is attractive to both web designers and developers as it provides an accessible and semantic alternative to other methods of font replacement.

sIFR enhanced sites require a modern web browser with the Adobe Flash plugin installed and JavaScript enabled. For visitors lacking these features, sIFR will degrade to a suitable baseline font and continue to render both on the page and in the generated source code.

In theory, sIFR is a perfect response to one of the more frustrating restrictions imposed on web designers by the medium. Unfortunately, the technology is not without its flaws and ultimately should not be considered a viable choice for web professionals.

The limitations of sIFR include: localization, extended character support, fouc, page zooming, text scaling, text wrapping, page load, cpu load, scalability, utf-8 compliance, QA testing, future-proofing, upgradability, wmode support, dynamic text sizing, DOM support, and z-index collisions.

While there may be solutions or workarounds to some of the issues illustrated here, collectively they remain a barrier to the technology’s adoption as a standard.

Related articles

• Wizardworks: sIFR – Point Of View (Publish date unknown)

  Jim offers a god breakdown on the pros and cons of sIR and I will elaborate briefly on item #5: sIFR and Special Characters

  • In order to truly support localized content, a separate .swf file would need to be created for each language, each of those .swf files would then need to contain the entire character set for that country.
  • The more characters added, the larger the .swf file becomes. This is noteworthy as few if any fonts families contain every character set for all languages.
  • Web designers may encounter much difficulty testing the site with different languages as the text and spacing is rendered differently depending on the user’s country and whether or not the Flash plugin is installed.
  • Support for dynamic widths is also a serious issue as the Flash movie width must be explicitly set. This further reduces sIFR’s practicality as fixed widths cannot be used for text on localized websites.
• Usable Type: How and When to Use sIFR (December 24, 2004)

  Andy discredits much of the misinformation and concludes sIFR is best used to replace no more than one headline per page.

• Virtual Elvis: Why I hate sIFR (April 29, 2005)

  A fabulous tirade about the difficulties of keyboard navigation and screen zooming for an Opera user.

• Leftlane: ESPN.com Looking a Bit Pixelated (February 9, 2006)

  Interesting to note in the comments here that while ESPN is one of the sites often quoted to be using sIFR it is a) not currently using sIFR and b) (quoting Mike Davidson) “It was actually not sIFR at all, and even pre-dated Inman’s IFR by at least two years. It was basically inline Flash files with text… that’s all. And yes, the page is huge and so are all of those images.”

• Drupal: sIFR Module discussion (February 16, 2006)

  In the comments section, a user notes that sIFR text is not searchable and cannot be made both selectable and linkable. The commentary further notes a lack of respect for user-specified font settings. Someone else points out that sIFR is not utf-8 compliant.

• Mezzoblue: The Pros and Cons of sIFR (October 26, 2006)

  A notable article which points out the need to refresh the browser once Command/Ctrl + is used to increase font size. The inability to use sIFR for headers which are also links (the link destination will not show in the status bar) is also mentioned.

• Devshed Forums: SIFR … Innovative or Designer’s junk? (April 13, 2007)

  A flaming forum rant that suggests using a pre-rendered PNG instead. The author also further points out the load and latency issues inherent in sIFR.

• Sitening: New Flash player breaks sIFR (December 14, 2007)

  This is an important occasion to make note of. When Adobe released the latest version of their Flash browser plugin, earlier implementations of sIFR malfunctioned. While awaiting a fix, sites deploying sIFR were forced to remove the code – assuming they were even aware the feature stopped working.

Live sIFR examples

As a test, interact with these (or any other) sIFR enabled web sites using different browsers such as Opera, Firefox, Safari, Internet Explorer and Konqueror. Try printing, previewing, selecting text, searching for text, increasing and decreasing font size, and other page-level interactions. Keep in mind that while every individual may use the internet in a unique way, all web browsers offer the same set of features to each of their users.

For the following examples I have included sample videos showing scripted interactions with each web site. These videos are made available as a point of reference should one of them cease using sIFR or the technology evolves.

• Aston Martin See demo video
  1. Visit www.astonmartin.com
  2. Notice how the sIFR headers render after the content.
  3. Try increasing the browser font size using the keyboard or option menu. Notice the header text size does not increase with the rest of the page.
  4. Using the keyboard, try selecting all the body copy (Ctrl +A in Windows, Command +A in OSX). Notice the header is not selected.
  5. Using your mouse, try selecting the entire body text including the header. Notice the header is not selected or selected irregularly.
  6. Using Firefox, first select the header text with your mouse and then try to deselect it.
  7. Select print preview and notice the header missing (FWIW: this is supposedly fixed with media=screen in the css link)
  8. Try searching for text transformed with sIFR using Ctrl/Command +F. Notice how the text is not selected.
• Hollywood Reporter
  1. www.hollywoodreporter.com has recently undergone a redesign and chosen not to continue using sIFR.
• Offbeat See demo video
  1. Visit http://www.offbeat.com/
  2. Watch how the content loads first and the headers second.
  3. Notice how the first header is hidden when the navigation menu floats over it.
  4. Using Firebug, inspect each header element. Notice how they all use a fixed width.
  5. Search for text contained in a header. Although the text is found, it is not highlighted by the browser.
  6. When viewing the demo video, note that although the word “Bach” is found 3 times in the header, it is not highlighted during a page search until a fourth attempt to find the word (which also appears in the body) or after selecting Highlight All as an option.
  7. Attempt to open any of the header links in a new tab or window.
  8. Block futura.swf using the AdBlock Plus plugin for Firefox and watch the headers disappear (FYI: This has been fixed in a recent release of sIFR).

Final thoughts

When designing web sites, our foremost concern should be usability and the user experience. At no point should our visitors be forced to relinquish the basic comforts and features afforded by every modern browser.

As it stands, sIFR is not the hot topic it once was, likely for some or all of the reasons noted above. Many big-name sites are touted across the Web as using sIFR including: MSNBC, ESPN, Nike, ABC News, Visit Las Vegas, and The US Navy. At the time of this writing, none of these web sites are using sIFR.

With that said, sIFR continues to be actively developed and version 3 is already in beta. As an entirely volunteer-based effort, the sIFR team should be applauded for their continued contributions to this ambitious project.