In Defense of Fahrner Image Replacement

In: Articles

By Dave Shea

Published on August 5, 2003

The CSS-based background image replacement technique, also known as Fahrner Image Replacement (FIR), is a vital cornerstone of all future Web design.

As the Web moves away from presentational, hacked-up HTML towards a structural future, code is becoming abstract and graphic designers are losing their traditional control. CSS offers wonderful methods of regaining it, and in many ways goes further than HTML ever did. But it doesn’t go far enough yet, and designers still need images.

Whether they’re photographs, individual headlines, or crisply anti-aliased and typographically beautiful pullquotes, images play a large part in a designer’s role on the Web. We can continue to use the img tag and lock ourselves into its quirks (and face its demise in XHTML 2.0, but I digress). FIR, however, offers more flexibility due to its fundamentally configurable nature. We don’t just drop an image onto a page; instead, we create a structure for the image and then lay it over the structure. Plus, we can modify the image from the style sheet itself—a true separation of content and presentation.

FIR is an absolutely essential tool to both the designer and the coder as HTML becomes less and less about presentation. It is far too important to be cast aside over some of the problems it has encountered, and this article aims to tell you what it is, how to use it, some of the problems in using it, and possible solutions.

The Technique

The technique and its syntax are discussed at StopDesign, but here’s a quick summary in case you don’t yet know why you need it.

What FIR does is allow a further layer of structure and information underneath an image. Whereas img tags allow for alt text, titles, and the later-added longdescriptions of each image, FIR goes a step further and allows you to replace something like this:

<div id="recipe">
   <h3>Marinara Sauce</h3>
   <ul>
     <li>2 lbs washed, seeded Roma tomatoes</li>
     <li>2 cloves garlic</li>
     <li>1 Tbsp olive oil</li>
     <li>1 Tbsp sugar</li>
     <li>1 Tbsp oregano</li>
     <li>1 tsp salt</li>
   </ul>
</div>

With a single image:

The code required is trivial. Take a simple header for example:

<h3 id="firHeader"><span>Sample
Headline</span></h3>

The CSS required to replace it boils down to:

#firHeader {
   width: 300px;
   height: 50px;
   background: #fff url(firHeader.gif) top left no-repeat;
   }
#firHeader span {
   display: none;
}

The first declaration places the image in an appropriately-sized container, the second one hides the text. If we didn’t have the second, the text would overlap the image — not what we want. In the prior recipe example, we could safely eliminate the span and hide the interior elements (h3 & ul) instead with display: none.

Whether the code comes first and the image added later, or the image is created and meaningful code generated afterwards, doesn’t matter. The point is that a designer is able to create a visually complex but structurally sound site. View the css Zen Garden for examples of FIR at work.

With the recipe example (in a perfect world), the sighted viewer would receive a nice image with the recipe, the blind viewer would hear the text of the recipe read to him, Google and other robots would be able to index the text of the recipe, devices like PDAs which don’t have the capable color depth or resolution to display the image would get the text instead, and it would be fully possible to port the recipe to and from XML-based applications.

There are problems though. As the proprietor of a project that heavily relies on FIR, I receive a consistent volume of email detracting the method. Let me take some time to analyze the major problems and suggest some possible solutions.

Accessibility Problems

The number one problem is that screen readers render display: none, hiding the content which the image is meant to replace. We can’t even do so much as provide alt text to compensate. Any accessibility advocate worth their copy of JAWS would tell you something’s fishy, and they’d be right.

If you add a media type to your style, however, you may serve the proper CSS to each user agent. Since FIR assumes image display is acceptable, if we restrict its use to screen media style sheets only, then devices like PDAs and screen readers will not hide our valuable text.

<style type="text/css" media="screen">@import
url(style.css);</style>

The kink is that some screen readers don’t respect our media types. If a style sheet is linked instead of imported, they will render screen media style, contrary to what we’d assume. The simple solution is to import all style which hides content, as above.

Note: Using Tantek’s box model hack in a screen media style sheet causes validation errors. See the first three replies in this thread for more information, and the resulting dialogue between myself and Michael Cacciottolo (MikeyC) for possible fixes.

Foreign Language Support

Committing to image-based text introduces translation problems. For example, view the Greek translation of the Zen Garden — text that’s left as HTML shows up in Greek characters, but the header images are still English. You face this problem whether you’re using img tags or FIR, but CSS offers a unique fix.

CSS-2 introduced the :lang(n) selector, which allows style definitions for variants of n. In a few years time, when support for this selector is more universal, serving a French header will be as easy as defining a style for h3:lang(fr). Unfortunately, we’ll have to wait until browser support is better to use this.

For now, the best approach is to serve multiple style sheets based on document language. Placing all FIR-substituted text into its own language-specific .css file allows you to selectively call in image-based headers for each translation. For example, you could build a site with three style sheets:

<style type="text/css" media="screen">
   @import url(basic.css);
   @import url(en.css);
   @import url(de.css);
</style>

Basic.css would contain most of your site-wide style rules. En.css and de.css would contain your English and German FIR translations, respectively, and you wouldn’t use both at the same time. Based on the document’s current language, you could script one of the @imports out of the list and be sure to see only the language you expected.

CSS On, Images Off

It’s possible to prevent your browser from downloading images, while still allowing it to render CSS. Very few people do this, but it’s important to consider those who do. Just as screen readers don’t render display: none, this combination will not provide any alternate text either.

No solutions have been found for this yet. Accessibility problems have a way out with media types, but this continues to be a problem. Some of the alternative methods discussed below might have an answer for this as well.

Semantically Speaking…

Semantics conjures up images of narrow-minded professorial types arguing the definition of words like “this.” It’s a concept that makes the average person cringe. Semantics on the Web can be just as tedious, but in many cases more important.

The simple problem is that FIR relies on extra spans to add hooks in the code that are later used to hide content. These spans are completely meaningless to the document, and act as nothing but empty containers.

So what, you’re asking? Well, the theory goes that a structural document is made up of the necessary elements, all the necessary elements, and nothing but the necessary elements. Adding empty containers is a concession to presentation, and makes the document “impure.” Tedious enough for you?

Unfortunately, for these purists’ arguments though, today’s technology requires the spans. Purity of a W3C ideal is nice in theory, but as we all know it’s a whole different ball game when we try applying it to some of today’s browsers. Read below for some of the ways the development community is working around this problem.

Daylight Breaks

So if there are so many problems, how can we, in good conscience, use FIR? Some smart minds are currently working on this very question. Methods to get rid of the spans and solve the accessibility problems are starting to develop.

Dave Hyatt (of Safari fame) proposes using XBL instead, which keeps the code simple (and theoretically accessible!) but completely obfuscates the style. Radu Darvas has approached me about the possibility of re-introducing spacer.gifs and creative use of alt text to duplicate the text within the hidden element ( View source), but that adds a further non-structural element; purists everywhere cringe.

Seamus Leahy and Stuart Langridge have each independently discovered that using overflow: hidden will hide the interior text without the use of spans. Brilliant thinking as this alleviates the accessibility problem and drops the unnecessary spans, their technique shows the most promise of replacing FIR, once the remaining “CSS On, Images Off” complication is resolved. It’s even possible to use the title attribute of the containing element to restore the mouse-over tooltip we all know and love.

These methods all offer strengths and weaknesses to varying degrees, and the final solution hasn’t been found yet. But we’re working on it.

Conclusions

Structure is good, but unformatted structure is arguably as useless as unstructured design. To move forward with a harmonious balance of compelling visuals and well-built code, the remaining issues with FIR need to be resolved. We all need this technique: coders, to keep the structure clear; accessibility advocates, to keep the page viewable to alternative user agents; and designers, to make the Web a more beautiful place.

It is not up to you as a designer to solve this problem. That job rests squarely on the shoulders of software developers whose products take issue with FIR. As long as you are responsible in your usage, make sure your media types are safe, and provide every reasonable means for a person to get at the information you are presenting, then you may start (or continue) to use FIR with a clear conscience.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: CSS, Web Standards

 

Dave Shea is the cultivator of the CSS Zen Garden. A graphic designer by trade, he writes about all things web for his daily weblog, mezzoblue.com. Hailing from Vancouver, B.C., he can most often be found at the local farmer's markets or independent coffee roasters.