Getting Back to Basics: Effective Use of Images

Published 7 years 7 months ago on July 20, 2009 — 5 min read

As per usual, I spent the past week or so getting back to basics with a single element. Images are a huge part of the Web. Even more-so, images are a huge part of design. Imagery contributes to aesthetics which support design, but on the Web, imagery can be a subject by itself (and it is).

Two types of images

As designers, we realize that there are two ‘types’ of images. Those which we reference in our style sheets which in turn inject imagery into a document, and those referenced within the markup itself.

Each type of image carries with it a specific purpose and value. At the most basic level, the fundamental difference between the two types of images is meaning. Images referenced in markup should contribute to that document in some meaningful way. Images included via stylesheets, however, should not carry with them any informational value.

I think it’s sometimes easy to forget that, even as you become a seasoned developer. The biggest issue I’ve noticed with myself, which in turn sparked my recent focus on the subject, was the arbitrary inclusion of image replacement when it wasn’t completely necessary.

Images versus image replacement

Image replacement is a technique near and dear to the hearts of many. Countless articles have been published on the subject, and it seems to be an applicable conversation to have on a fairly consistent basis. I myself have tried to add some value to the conversation by publishing a few pieces on the subject over the past couple years. Some of which include:

Looking back on those articles, I realize that I was still a bit overzealous when writing them. I think it’s part of every developers growing process to take new techniques under his or her wing after it is first learned, and run for the end zone with it. Image replacement is one of those techniques. When we first learn that our style is completely separate from our structure, every image becomes stylistic. We want to remove everything from the document and focus on keeping our markup and lean as possible. It turns out that for many, we optimize to a fault.

As of late, I’ve been questioning image replacement itself. By definition, when we use image replacement, we’re effectively injecting a meaningful image into the style layer of a document, all the while using various techniques to ensure the original content provided from markup is hidden from view. Through this process, we make it very difficult for assistive technologies to properly recognize the content as valuable.

Looking at Monday By Noon today, we can see that not only was I overzealous with image replacement, but also itching to use an image sprite as well. I can add those two items to the list of reasons I’d like to redesign!

Taking a step back and looking at the big picture, we can see that:

  1. Our markup is (mostly) solid, as we often need to include a possibly unnecessary class/id to act as a hook for our CSS
  2. We’re abstracting a meaningful image
  3. We’re attempting to inject that meaningful image through CSS
  4. We force our original content out of sight by way of properties designed to obscure existing data

We do all of this, yet HTML has provided us with an element dedicated to taking care of everything in one fell swoop. I’ve come to realize that img is an underused, undervalued element by many developers.

Remembering to use img properly

HTML provides us with the img element. Not only can we include our meaningful images (i.e. headings) within the markup as intended, we can provide directly applicable alternate content (alt attribute and longdesc attribute) directly within the original document. It is by far the best way to gracefully degrade for imageless browsing, and abundantly more straightforward than any of the various image replacement techniques available to us.

We can’t forget the reasons we’ve tried and tested image replacement techniques, however. Modern Web design is far and beyond more complicated than HTML and CSS can support alone. We’re using the tools to their fullest potential, and then some. We have to get creative sometimes, and image replacement originated from a need.

My personal focus for the past few projects has been to get back to basics and use images in their original intention, and I must say that documents feel more stable, more structured. I like that I’m not obscuring information in any way, instead using the gifts HTML gave us to provide a seamless experience.

This approach has really only come into play for me when it comes to headings, more specifically static headings. Dynamic headings are a different subject entirely, something that deserves an entire article. The biggest hurdle with headings, however, is to make sure they blend with the surrounding environment. Make sure you’re using the Matte when saving a transparent GIF for Web, it will make your life that much easier:

Screenshot of the Matte option in a Save for Web dialog in Adobe Photoshop CS4

Setting the matte on a transparent GIF will help you to match the edges of text to the background over which you’re laying the image. You’re probably wondering why we don’t use PNGs instead. I won’t get in to details but it starts with an I, ends with a 6, and has an E in there somewhere. Enough said on that topic.

Using images directly within headings can be an effective way to retain document structure for assistive technologies and search engine friendliness. Your heading markup can look something like:

<h1><img src="images/companyname.gif" alt="Company Name" /></h1>

Google should much prefer something like the above as opposed to an obscure image replacement technique. The information is blatantly available, and there is no overlapping meaning when it comes to the separation of structure and style, right?

In conclusion

I hope this throwback topic helps you to analyze how you’ve been using images in your designs as of late. Perhaps you, as I did, needed a quick refresher on the overall document as opposed to overusing a particular technique when it may not be needed.

Copyright © 2006—2017 Jonathan Christopher