Image Replacement is becoming a more common technique in CSS development. Essentially, it allows image-based headers to appear normally in the HTML, just like a text-based header. So, instead of something like this:
<img src="images/pageheader.png" width="100" height="25" alt="Page header" />
… you can now have something like this:
<h1 id="pageheader">Page header</h1>
The original idea was developed by Tood Fahrner and it came to be known as the Fahrner Image Replacement technique (FIR). He used display:none alongside a CSS-based background to hide the HTML text while displaying the appropriate image.
It seemed like a good idea at the time, but real-world testing showed that it wasn’t accessible. Todd’s reasoning when he came up with it was that display:none wouldn’t affect screen readers, but it did anyway. In time, other developers came up with additional image replacement techniques, each with different advantages. In all there’re about ten known ways of going about it. So, which to choose? Well, Dave Shea wrote up a handy summary of the various image replacement techniques.
Most of them use the same basic procedure as the original FIR: hide the HTML text with CSS and then insert an image through a CSS-based background image. And, this generally works fine, though these techniques do have the minor disadvantage that on the off-chance that if someone has both CSS turned on and images turned off , he/she wouldn’t see the text (since the text itself would be hidden but the image wouldn’t be loaded to replace it).
However, Tom Gilder and Levin Alexander came up with a variation that works even in that scenario. The Gilder/Levin image replacement technique doesn’t actually hide the HTML text; rather, it simply places the image right on top of the text (which covers up the text). The only disadvantage to the Gilder/Levin technique is that it doesn’t work with image headers which require transparency. (Because the HTML sits underneath the image, any transparent portions of the image would allow the text to peek through.)
In scenarios where the design requires transparent image headers, the next-best image replacement technique is probably the Revised Phark technique. The Revised Phark technique is more traditional in that it hides the HTML text via CSS and then uses a background image to display the image header (as many of the other techniques). However, in contrast to many of the other techniques, it’s fairly straightforward to implement — the header tag (<h3> et al) requires no redundant <span> tags and the CSS is only three lines.
Because image replacement techniques greatly simplify HTML, I think it makes sense to make use of them on a regular basis. Not only is the HTML more readable, but the image properties (width, height and filename) are separated into a centralized external file which eases maintenance. Of the many techniques, I’d go with Gilder/Levin as a first choice unless the design required transparent headers (in which case Revised Phark is probably your best bet).
What about using something like this?
http://www.tjkdesign.com/articles/a_perfect_Image_Replacement_technique.asp
While some make the arguement that image replacement should be done with JavaScript instead of CSS. Peter-Paul Koch, an expert on JavaScript has written his own method for image replacement.
However, we feel that this is more of a presentational aspect and should, if possible, be handled by the CSS. Also the method you refer to puts the burden of the image name and dimensions back on the HTML markup.
But don’t you think it address more issues than other solutions, which – in my opinion – is the most important aspect of an Image replacement technique.
Which issues are you referring to, ursu?
Javascript is used to insert the Images, there is nothing in the markup.
The solution seems to degrade nicely depending on _many_ combinations (JS on / CSS on / IMG on, JS off / CSS on / IMG on, JS on / CSS off / IMG on, JS off / CSS off / IMG on, JS on / CSS on / IMG off, etc. ).
And the images are sent to the _printer_, not like with background-images.
Hi ursu. JavaScript-based image replacement has some advantages — as you mention, the headers are visible in some form (whether as text or images) in many combinations.
All the same, I also see a couple potential disadvantages. One consideration is that, in the context of what’s needed for full-replacement, JavaScript-based image replacement has 3 points of failure (markup, CSS, JavaScript) rather than CSS-based image replacement’s 2 points of failure (markup and CSS). This may not be as much a concern with “screen” browsers, but “handheld” browsers which often have incomplete in CSS and JavaScript support might cope better with CSS-based image replacement.
Another concern, potentially, is that JavaScript is an interpreted language. Granted, most client machines are fairly speedy these days and the speed hit may be virtually unnoticeable on pages which are fairly straightforward. However, with pages that make use of Ajax or libraries such as YUI or Prototype, they may have a considerable JavaScript-interpretation load already; and if a given page is on the verge of perceived slowness, additional JavaScript may push things over the edge.
Hi Alex,
In my opinion, “what’s needed for full-replacement” is irrelevant as we’ve moved from the _original_ idea (which was only about showing an image rather than text – see FIR) to solutions that address accessibility guidelines etc.
The “points of failure” you mention seem only related to the success of the method in showing the image not in its ability to _degrade_; which, in my opinion, is very different.
In any case, it is the responsability of the author to know what’s the best solution to implement; taking into consideration the few issues you’ve cited (small devices, heavy JS files, etc.).
This site served as a reference.
http://kikky.net/pc/css_ir_e.html