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.

Having recently set out on the long journey of mastering a new CMS I’ve found myself searching for and stumbling upon¹ all manner of plugins, customizations and tweaks for WordPress.

The latest clever addition I found is the use of footnotes. When used properly, footnotes are an appropriate way of commenting on or referencing a portion of text².

Footnotes serve as a more graceful way to add an aside compared to the long-winded parenthetical. (For instance, here I could give some personal insight into the guilty pleasure of using lengthy digressions, but as you can see, by the time you reach the end of this amusing passage, the original point is confused with a new idea).

So let’s have a look at the requirements for this project:

1. A format for referencing footnotes
2. A format for displaying footnotes
3. A method of moving between the two
4. Making your footnotes accessible

A format for referencing footnotes

This first requirement is easy: footnotes are referenced nearly universally with superscript. Deciding what form of superscript to use: number, letter, figure or symbol is entirely up to you. I personally chose numbers.

Fortunately, support for superscript is part of the W3C recommendation for paragraphs, lines and phrases – thereby making it perfectly valid for appropriate use.

In practice, your code may start off looking something like this:

<sup>1</sup>

A format for displaying footnotes

Footnotes are commonly placed at the bottom or “foot” of a page or section. There is no rule stating a footnote cannot go elsewhere, but sticking to traditional conventions is a recommended best practice.

How you choose to style your footnotes is also a personal choice. Perhaps you can peruse your library or book collection to see how it’s been styled elsewhere.

However you choose to style your footnote, using CSS provides the most flexibility to differentiate it from preceding paragraphs.

The resulting code may start off looking something like this:

<div id="footnote">
	<ol>
		<li>Footnote</li>
	</ol>
</div>

By applying an id to the containing div we can cascade the styling of content within. By using an ordered list we retain the continuity of footnotes throughout the page.

A method of moving between the two

Ideally, references should link to their respective footnotes and footnotes should link back to their references. This provides the user with an effortless method of jumping to the footnote and then returning to the passage.

The resulting code may look something like this:

This is some text<sup><a href="#32066" id="fn1">1</a></sup>

<div id="footnote">
	<li id="32066">This is a footnote <a href="#fn1">↑</a></li>
</div>

… and the resulting output may look something like this:

Making your footnotes accessible

For some, the example above may appear perfectly usable. You see a linked number in superscript, click and you’re taken to a footnote. A link in the footnote returns you to the sentence you last read. It doesn’t take much to deduce this just by looking at it.

For those who aren’t looking however the purpose isn’t as clear. Questions arise for those visiting the page with an assistive device such as JAWS: What is this linked number? Where does the link #32066 take me? Once I get there what will I find and how will I get back? Users of JAWS and other assistive devices are simply not seeing a page with the same clarity.

Once again we check the W3C HTML 4.01 specification for a solution and find a fitting one in section 12.1.4: Link Titles.

The title attribute may be set for both A and LINK to add information about the nature of a link. This information may be spoken by a user agent, rendered as a tool tip, cause a change in cursor image, etc.

The resulting code may look something like this:

This is some text<sup><a href="#32066" id="fn1" title="see footnote">1</a></sup>

<div id="footnote">
	<li id="32066">This is a footnote <a href="#fn1" title="return to article">↑</a></li>
</div>

Add a little CSS and the possibilities are endless!

That’s all there is to it. Your methods may vary but this should serve as a good starting point. See below for how we do it here at Like Wow Online.

In a future article we’ll learn how to automate footnote creation with AppleScript. Stay tuned for Part II.. Using AppleScript to create HTML footnotes