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:
- Our markup is (mostly) solid, as we often need to include a possibly unnecessary
idto act as a hook for our CSS
- We’re abstracting a meaningful image
- We’re attempting to inject that meaningful image through CSS
- 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
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:
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?
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.
“Google should much prefer something like the above as opposed to an obscure image replacement technique. ”
But is that how Google behaves? Do they index alt attribute values as page content? If they do, wonderful. If not, you’d miss out on valuable keyword enrichment.
Another issue with using image-as-text, especially in headlines: the text cannot be resized by the browser. Sure, lots of browsers default to zooming now, but text resizing is still available and possibly the preferred option for the visually impaired (hello, no horizontal scrolling).
So, while I do think people overdo sometimes with image replacement, you still need to use those techniques where text is concerned.
Oh, and with the advancement of @font-face and the emergence of tools like TypeKit, this discussion will probably become moot anyway 🙂
[…] Webseiten gibt es zwei Arten von Bildern (so jedenfalls steht das bei Jonathan Christopher). Nun, prinzipiell kann ich dem zustimmen. Den Unterschied allerdings daran festzumachen, dass die […]
I agree that sometimes we get over zealous in image replacement because it’s a “cool trick,” but I still fail to see why an image/logo of the company name is more meaningful than the company name simply rendered in text, Google has okay-ed responsible image replacement and sIRF. I just don’t see a solid benefit to using an image.
@Chris: Google is a very smart search engine, and definitely takes into consideration the
altattribute. Take a look at this quick video from Matt Cutts in 2007 in which he doesn’t describe images in headings per-se, but does state that the copy within the
altattribute is “very helpful for Google” and the copy also states “As the Googlebot does not see the images directly, we generally concentrate on the information provided in the “alt” attribute.” While I’d love to hear Matt Cutts’ directly respond about headings, from what I’ve read, indications are good about
alttext in headings. Have you had any adverse experiences with Google ignoring
alttext? There are definitely other associated issues with using images-as-text, but hopefully, as you said, browsers will officially support
@font-face(or some alternative) and we can move on with our lives! Thanks for leaving your thoughts!
@Ben Carlson: The example included above was just as an example, and now that I look at it, a poor one. I should have instead used a more applicable heading instead of a company name as it would have made more sense. My apologies! Yes, Google has indeed not penalized you for responsible image replacement, but as I thought more about it, there are certain circumstances where an
imgmakes more semantic sense. We’re told that images injected through CSS support the design and should have no meaning. Images with meaning should be included within the markup, else the meaning is lost. Image replacement, in a way, skirts around the issue by including both the information in the markup, and the image in the CSS, all the while achieving the same goal by obscuring the original information through the use of more CSS. To me, if Google were to see an inline image with an
altattribute, and compare that to a heading with a background image and
text-indent:-9999pxor any sort of
visibility:hidden, it should put more faith in the inline image with no additional styling gimmicks. What do you think?
Google ignores CSS completely, no? So an h1 with a background image of the text and
text-indent: 9999pxis still an h1, while an image of a heading is…an image. If anything,
h1<img>h1is less meaningful—surely a heading should consist of text.
From a search point of view I guess it depends on whether Google simply inserts the
alttext within the h1 tags and conjures up a heading that way. That would be interesting to find out.
@Leon Paternoster: I was under the impression that Google did indeed ignore CSS completely, until I read an article (I’ll need to dig out the link) referencing that Google may in fact process some CSS to check for spammy behavior. Hopefully someone may be able to shed some light on that issue specifically while I try and find the link!
@Jon I would say there’s a fine line on what’s meaningful image content and what’s design or aesthetically relevant, but not contextually relevant. I think as long as you’re not abusing it and using CSS background images for things inside your content, then you’re doing it right. What I do is frequently turn off styles with web dev toolbar, and make sure that content images are there. If the Company Name is actually an image replaced logo and renders as text with styles off, that’s fine, I haven’t lost enough meaning for me to instead insert an image. I’m not really adding any information in the markup, I’m going to have a anyway, I can just target the inside it. It’s tough to say what Google values more, an image with appropriate alt text, or text itself. I would doubt it matters too much in the large scheme of things.
@Leon I think I have read, also, that Google can tell if you’re using too much (or the wrong kind) of image replacement in order to catch “black hat” behavior. I think in general you can think that Google acts as if there were no style sheets, but in reality I’m sure they take them into account.
Comment ate some code, the phrase should have been “I’m going to have a [div class=”header”] anyway”.
@Ben it can come down to preference sometimes, but there’s marginal productivity increases, and no image replacement technique is perfect.
@Chris I’m fairly sure Google indexes alt attributes.
Overall, I think this falls under the ‘no bull’ category when marking up your sites. I agree, an image replacement for a headline is overkill. But I can still see a practical application in navigation and buttons where css sprites are more useful and prevent flashes of unstyled/unimaged content.
I absolutely agree that image replacement has its place when it comes to certain circumstances. I do believe, however, that it shouldn’t be the de-facto standard when marking up your site. I do plan on researching any adverse effects to using an image in a heading specifically, and try to determine if Google gives greater weight to one technique over another.
Thanks very much for the input so far!
I don’t believe that Google doesn’t “like” image replacement. I never had a problem with it…
As SEO experts always talks, image replacement isn’t that bad since you just write (exactly) what is on background…
I’d use an image inside an H1 only in the website’s logo/title, maybe.
For H2 till H6 throughout the document, I would prefer to use simple text for all titles.
Basically, if I have a heading inside the document, it should probably be marked up as H1, H2, H3, etc. I don’t see a reason to put an IMG inside the heading; I think heading tags + simple text inside, works the best. Then, if I like, I can replace the text with a background image. People who cannot see the image, will see/read the text (as it should be). People who can see the image, will see a styled heading. Sounds logical:)