CSS image replacement for… images? It makes sense for print.

Sites with dark backgrounds lend themselves well to white or light-colored logos. The result can be nice on screen, but if the site is printed, there can be undesirable results: either the logo doesn’t show up, or if it was saved as a transparent gif, it shows with jagged pixelated edges where the edges are meant to blend in with a dark background color.

One way people get around this is by including two logos on their site, hiding the one for print in the screens css, and vice versa. It works, but it includes twice as many img tags as what is really necessary.

A method I’ve had success with is calling a print-optimized image in the html, and using CSS to swap out the image with a screen-friendly one.

Compare what happens when you don’t do this to when you do.

HTML

<img id="logo" src="logo_print.gif" alt="my bloggy-blog" />

CSS

#logo {
   background:transparent url(logo_screen.gif) no-repeat top left;
   height:0;
   overflow:hidden;
   padding-top: 100px; /* height of logo for screen */
   width: 100px; /* width of logo for screen */
}

The height:0; and overflow: hidden; combo makes sure that I don’t see the logo intended for print on the screen. By adding a width and padding-top to that image, I can set my screen-optimized logo as the background-image. The width and padding-top should match the width and height of the image you want to show up.

This came about by reading David Shea’s image replacement tests. I like the Leahy/Langridge method of image replacement because it requires no extra markup, but this image replacement technique has some cons (as they all do) when it is used to replace text.

If it has cons, why do you think it’s an ok idea?

One usually reads about image replacement to replace text, and issues that typically come up are what to do when images are disabled, when CSS is disabled, or what extra markup has to be included to make the effect work. Since I’m using image replacement technique to replace an image, these become non-issues. If images are off, it’s the same effect as not using the technique at all – alt attribute values are shown instead. If CSS is off, the print-friendly logo is likely the favored image to show anyway. Also, no extra markup is needed – we manipulate the existing img tag and nothing else.

Presenting a src for the print-optimized logo in the HTML, even though it doesn’t get shown, feels a little weird, though, doesn’t it? You might feel better if you set the src for the screen-optimized logo, and then use a rule in the print style sheet to swap out for the print-optimized one. But that doesn’t work – remember that printing of background images is not enabled in browsers (by default, anyway).

So I’m sure you’ve seen plenty of sites that have a dark background with a white logo on them. You may even have one yourself. Go give them print preview and see how it’s handled. Sometimes (as in the case of this site), text is an acceptable fallback, but if the logo is set as an image, hopefully it is represented well in print.


This post was ported from an old host and CMS, so many comments were lost. Below are the comments that I found were most helpful regarding this post that I salvaged. Some links or attributions may not be working correctly.


Christopher Werby said:
I like this and think it’s clever. I’ve had this issue in the past and dealt with it by putting both the normal and the print versions of the logo in the HTML and then switched them on and off with either the screen or print versions of the stylesheet. But with the CSS turned off, both logos appear. So I make the print version of the logo 1px wide by 1 px high in the img tag markup.
One point is that I make the print version of the logo a 300dpi file. I still use the same pixel dimensions as the screen version of the logo, but when the logo prints, it doesn’t have that soft smeary look you get when you print 72 dpi images. For an example, see http://www.garnetthelfrich.com/
I like your idea of using the background image to flip in the screen version. But there’s a downside for logos. I’ve had clients who wanted to allow people to quickly grab their logo from the Web site. When it’s a background image, it’s harder to grab. Just a trade-off to be aware of.