Graphics and Structural Markup: Keeping "pretties" out of content

By Dimitri Glazkov
Posted on 04/18/05

Pet peeve time! Let's talk graphics. You know, the catchy visual dujibobs that have been part of the Internet since the Gopher went south. As far as I know, there are only two types of graphics on the Web: content graphics and presentational graphics.

  • Content graphics comprise the content of the page or serve as illustration for text content. For example, a news story on nuclear research breakthrough may feature a photo of a glowing (pardon the bad pun) scientist in a hazmat suit. A page containing a gallery of pictures with cut lines could serve as another example of images as content.
  • Presentational graphics serve the decorative purposes of a page. Typically, these are ingredients for what you'd call "page template" – they survive, with some degree of consistency, from page to page on a site. Taking away or changing the presentational graphics does not affect the content of the page. The nice white-space background texture that makes your eyes feel happy, or the heading that expresses the spirit of the site, or rounded corners that give your sidebars the look of a candy bar – all of the above are presentational graphics.

Another, less obvious example of presentational graphics is using images to convey textual information. Very often, Web sites can be found using titling (and sometimes more) that is rendered as images. See, text looks much better when kerned by hand and licked clean with anti-aliasing in Photoshop in a font that's something other than the common serifs and sans-serifs given to us by Web gods. And in the absence of a standard font delivery/rendering mechanism, provided by CSS or (X)HTML, developers use ye olde GIFs to compensate.

However, as I mentioned earlier, these images are context, not content. Why? Well, because from the perspective of content, we could care less about how it looks. We just want information. The "pretty" part is thus presentational, and only the actual textual information that is represented by the image is content. Can't decide who you really are, eh?

Images and structural markup

Obviously, presentational graphics have no place in structural markup. Only content graphics deserve to have their own designated image elements in the markup. The rest will have to take a ride on a CSS bus. Luckily, the color and background family of properties gives you more than enough flexibility in accomplishing that, and A List Apart is a good starting place in getting a taste of common techniques.

What of that MPD-afflicted "text as graphic" case? If we tuck our graphical titling into CSS backgrounds, we hide content in the presentational land, because these graphics contain textual information. If we make them into image elements, we have presentational elements in the content, which is even worse. What shall one do?

Because the initial reason for having text as graphics is due to incomplete rendering paradigm, there is no perfect solution. But there are a few that come pretty darn close. I am talking about the family of image replacement techniques. They all approach the issue from the same angle: textual information is marked up as text, but replaced with images using clever hacking with CSS, client- or server-side rendering. That way, the markup stays structurally correct, and the layout engine of the browser is augmented with new capability to make the text look more appealing. The major limitation of these techniques is that they're hacks, and like any hack, each technique has it Achilles' heel:

  • Static image replacement (FIR being the first, Leahy being my current favorite) still requires you to break out your Photoshop if the text information in the images changes.
  • Client-side dynamic image replacement (sIFR is the best example) has additional expectations on technology support (Flash is required), does not provide enough presentational flexibility (you can't hand-kern something that's generated on-the-fly), and may have accessibility problems (try reading sIFR-enabled page with the latest version of JAWS).
  • Server-side dynamic image replacement (DTR comes to mind) places extra computational burden on the server and has the same flexibility and, to a lesser degree, accessibility issues as its client-side counterpart.

However imperfect, image replacement is an enabling technology. Without it, presentational aspects of the page would have been the sacrificial lamb of structurally-correct markup. I doubt structural markup would've had a chance of making it to the mainstream.

Brand is content?

Very often, it is tempting to regard branding elements on a page as presentational. Branding elements are part of the letterhead, not the letter itself (letterhead being the presentational part of the page, of course). But in reality, the situation is a little trickier. In most cases, brand is as important as content on the page and deserves to be counted as content. Here are a few examples:

  • Point: The university seal is often used on a page to signify that the content comes from official university sources. Removing the seal from content diminishes the authority of the page. Thus, the seal is content.

    Counterpoint: This is the case of mistaken identity. The seal itself is not content. The content is the phrase "This page is part of the official university content", which is implicitly stated by the presence of the seal.

  • Point: The logo of a company on a page was re-colored to match the theme of the page, has been given gradient fill and a drop shadow to make it look "pretty". Anything "pretty" is part of presentation, thus making the logo a presentational graphic.

    Counterpoint: The changes in logo appearance are indeed presentational. However, being the unique mark (title) of the company, the unaltered logo itself is still content. Therefore, the unaltered logo graphic may be part of page content, only to be later replaced by the spruced-up presentational version. Think of it as using image replacement technique for an image.

Hyperlinkin' graphics

Web wouldn't be Web without hyperlinks. Those pesky anchor elements define the essence of surfing, the brand new user experience that was born with the Web. Many times, the item that the Web surfer clicks on is a graphic. Now, quick: is this a presentational graphic or content?

To answer this question, let's examine the nature of a hyperlink. A hyperlink is a way to link from one page to another, which identifies the target of the link on the page that's the link's starting point. Naturally, identification of this link is content.

Yes, but what kind of content? As any of known accessibility guidelines (WCAG, Section 508, etc.) would tell us, this content must be textual in order to be interpretable in absence of the agent that supports visual content. Therefore, from the perspective of user experience, the textual nature of the link is more important than its visual representation.

This means that any graphics that are part of hyperlink are probably presentational. They are there to make the link look "nice" or "pop", not to identify the target of the link.

Comrade, what about my image maps?

Image maps are about as evil as you can get from the perspective of structural markup. Think about it: it's a markup construct that was devised to arrange links (content) on a graphic using 2-dimensional, pixel-oriented system of coordinates, which is as presentational as you can get. Stay away from the image maps, they are the heathen borne from Devil's womb. Especially, since you already have a presentational vehicle such as CSS.

Rules of Thumb

  • The image is definitely content, if
    1. It is referred to in the textual content. For instance, "This diagram depicts the relationship between good and evil (see figure 1)"
    2. If removed from the page, affects the value of content
  • The image is probably content, if
    1. It was created specifically for this page
    2. It is unique for this page
  • The image is probably presentational, if:
    1. It's clickable
    2. It was borrowed from stock library
    3. It is present on multiple pages with a degree of consistency
    4. It lends itself better to a GIF format
  • The image is more than likely presentational, if:
    1. If removed from the page, does not affect the value of content
    2. It contains textual information that would be considered content if it were just text.

Image element Quiz 1

Following the spirit of this article, how many image elements will you need to develop markup for the following composition?

Quiz 1

Image element Quiz 2

Think of what XHTML markup you would write for the composition below. Specifically, what would you use to express the icons (I assume it's obvious that they are clickable)?

Markup Quiz 2

Image element Quiz 3

Visit the following Web sites, view their source and point out images are incorrectly marked up as their own elements:

Note to the user from the utopian future: If you are looking at my page and can't find any examples of bad structural markup, you bring me the happy thought that I finally did find time to redesign my site. If you can't find anything wrong with any of the Web sites listed, you are either overlooking something or the future is looking so bright that I might just have to get me a pair of shades.

With any luck, this article shares your current thinking. Or maybe it gave you something to argue about (that's what the comment form at the bottom is for). In either case, next time you code presentational graphics as image elements, I hope you see it as adding ugly warts to the beautiful face of your Web site.

Comments

  1. re: Graphics and Structural Markup: Keeping "pretties" out of content
    Posted by Al Gaspar on 04/18/05
    Stay away from the image maps, they are the heathen borne from Devil's womb.-- I like that!
  2. re: Graphics and Structural Markup: Keeping "pretties" out of content
    Posted by FataL on 04/20/05
    Useful article. Bookmarked. :)
  3. image maps
    Posted by fantasai on 04/22/05
    Image maps are often (though perhaps not /usually/) used to combine a /map/ or diagram of some sort with a set of corresponding links. Defined carefully with text fallbacks, this is a perfectly appropriate use of an image map.

    A few examples:
    - Links to sub-pages specific to each US state, given as a map of the US
    - Links to descriptions of the different parts of a GUI interface, given as a screen shot
    - Links to personal sites, given as a group photo with each person clickable (and text fallbacks visible for navigating by name rather than face)
  4. Image element quizzes
    Posted by Nicholas Shanks on 04/23/05
    For the quizzes, do we have to make the text aliased and render it in 11pt Arial too? That's going to be pretty hard, especially as most self-respecting people will have purged Arial from their systems, and I know of no way to tell a browser not to anti-alias the text.

    Therefore I suggest the following:

    body { background: url(http://www.glazkov.com/Resources/Images/GraphicsAndMarkup/quiz1.png) no-repeat; }

    :-P
  5. re: Graphics and Structural Markup: Keeping "pretties" out of content
    Posted by Dimitri Glazkov on 04/23/05
    Nice try Nicholas :) Do you really need to rub it in for us Windows people about aliasing? We do have ClearType now.

    And you didn't answer the question, which has nothing to do with how the fonts are rendered :)

    By the way, this is not Arial, but Lucida Sans, which I hope you (and the "self-respecting people" club that you mentioned) haven't purged from your computer yet.
  6. re: image maps
    Posted by Dimitri Glazkov on 04/23/05
    Fantasai (Fyrna?),

    As you undoubtedly know, about the only thing that HTML image maps can do that can not be accomplished with CSS (which is what I implicitly suggest to be the preferred way of implementing image map functionality) is the ability to define non-square "hot" areas.

    And, if the specific implementation has a requriement for such areas, I will begrudgingly submit to the necessary evil of the image maps.

    In all other cases, there's no need for image maps. They are a mix of presentation and structure, rolled into the markup, which is about as bad as the font tag.
  7. re: Graphics and Structural Markup: Keeping "pretties" out of content
    Posted by Max Khokhlov on 04/29/05
    Nice article.
    And I'd agree that image maps are evil. I can't remember myself using them by now anyway.

    As for the quiz:
    1. none
    2. I'd normaly make them an inline <ul>–list and put <img> in each list–item — I don't see the point of using text links and image replacement for that. And text links won't fit in the header anyway.

    P.S. Why don't you have an option to sign up for the following comments and receive them via E-mail? It's more convenient than checking the site to see, how the conversation is progressing.
  8. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Lachlan Hunt on 04/29/05
    Image maps can be presentational in some circumstances, and there are many bad examples like this, including the one found in the HTML 4 recommendation. However, there are valid, non-presentational uses for image maps that should not be replaced with a CSS version.

    When image maps are used in a way that describes the content of a structural image, they're not presentational.For example:

    * Defining regions on a map (this is the most common non-presentational example, also given by fantasai above)
    * Regions of a photo, for which there is more information/close up photos available. eg.(see the example at the end) http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-April/003518.html
    * A schematic diagram
    * etc.

    The same rules you provided above for content vs. presentational images applies to image maps.
  9. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Dimitri Glazkov on 04/30/05
    The fact that the image maps are indeed necessary to implement the examples that you've listed does not diminish their unholy nature.

    It simply illustrates that due to the limitations of the graphics delivery vehicle (that being the current raster formats), there is no other alternative but to disclose in markup the information that should really be part of the graphic.

    Consider the example of the park diagram that you described your list post. Suppose that this diagram has been redesigned and as a result, the dimensions of the graphic have changed.

    Obviously, this immediately invalidates information in the markup. Why? The actual content, i.e. the information in the diagram remained the same: there's stil that swing and the old willow tree. What has changed? Its presentation. Logically, if the change of presentation affects the validity of markup, the markup contains presentational aspects.

    In the ideal world, the image maps in markup would not use "coords" to identify the logical areas on the image. They would contain idrefs to content on the image, and then the image would actually contain the coordinates for each logical area. Naturally, that would require the raster formats to grow up and accept their responsibilities.
  10. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Dimitri Glazkov on 04/30/05
    Max,

    Thank you for reading the article. And for actually taking time to answer the quizzes. As you may have suspected, I was trying to use them to reinforce the message in the aricle.

    In my mind the answer to the second quiz is 0, as well. While the current presentation of the composition has icons for the channel actions (this is the composition portal channel, by the way), it is entirely possible that in a different presentation, these actions will be items in a drop-down menu. Thus, I would definitely see them as text items in a list and use image replacement to get the look desired. In fact, that's exactly what I did -- both examples are screenshots of live Web sites.

    Speaking of Web sites. I have no doubt you are familiar with the Russian idiom "sapozhnik bez sapog", which is the rough equivalent of the English "cobbler's kids go barefoot". Well, that's me to the tee. This site is currently running on the most basic install of .Text with only a 5-second tweak of the stylesheet applied to it. Maybe one day I will actually find time to design this site the way I want it. And then maybe there will be subscription service for comments :)
  11. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Bob Easton on 04/30/05
    Superb! I'll be pointing to your Rules Of Thumb when I get around to building an <a href="http://access-matters.com">Access Matters</a> quiz about text links with icons beside them.

    The answers, BTW, are that neither quiz needs images in the content. They're all riding in that "CSS bus." The text belongs in UL markup.
  12. 2 Dmitri
    Posted by Max Khokhlov on 05/01/05
    I see. But you could then expand your solution for the 2nd task? You're using image replacement (FIR?) setting display:none property for the text items? Or what?

    As for the CMS for your site, have you considered using Movable Type? I started my own blog with it, and it turned out to be great: flexible, fast, convenient. And plug-ins give great opportunities for further expanding and tweaking. It has nice system for comments with built in e-mail notification, however there're special plug-ins for more detailed tweaking of the process. Strongly recommended.

    And it also allows to implement MT as the CMS for non-blog sites. I'm considering using it for this purpose, but didn't yet had an opportunity to do that. If you're interested, you can check out
    http://a.wholelottanothing.org/features/2003/07/beyond_the_blog
    http://bradchoate.com/
    http://www.stopdesign.com/log/2003/07/11/adaptive_paths_mt_setup.html

    to get info on using MT for non-blog sites. Or you can contact me if you have questions — my e-mail is listed on my web site.

    Best regards!
  13. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Jens Meiert on 05/02/05
    "The image is probably presentational, if it's clickable"?

    Hmm, I'd say that if an image is clickable, it's likely that the image contains text, which means it's <strong>likely to be content</strong>. Even if a hyperlink only contains an image which does not contain any text (for example, it symbolizes an arrow or something like this), it's <strong>probably content</strong> (for example, meaning "next page").
  14. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Dimitri Glazkov on 05/02/05
    Jens,

    I understand that this may be a little confusing at first, but you have to start seeing distinction between content and presentation of content.

    If an image contains text, the image itself is not content, but presentation of content, because it "represents" textual information in a graphical way.

    And if an image "symbolizes" anything, it is by definition of a symbol, a presentation. If the hyperlinked arrow symbolizes a link to the next page, the markup should say <a href="/nextpageurl/">Next Page</a>, and let your presentational layer (CSS) shape it into an arrow.

    On the other end of a spectrum, text is not always content. For instance, the picture of a scientist, mentioned in the post is _content_, and its alternative presentation is the textual description, "The photo of a happy scientist in a hazmat suit".

    I hope this explanation clarifies the issue a bit more.
  15. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Dimitri Glazkov on 05/02/05
    Max,

    Thanks for the links. I must say, the Movable Type is looking pretty good, and I like the hosting options available. I might just make a jump -- I hope my Windows overlords will forgive me :)

    As for the answers to the quiz -- I am planning to dedicate an entire post to it. Right after the next article, which I am writing now and I promise will be a good one :)
  16. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Jens Meiert on 05/02/05
    Okay okay, I didn't see some of the fine distinctions you made - need to reflect about it again.
  17. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Brad Wright on 05/02/05
    Unsure about this:

    "The image is probably presentational, if...(i)t lends itself better to a GIF format"

    What about graphs or maps? Surely content based on line-art is better represented by GIFs (or PNGs) rather than JPEGs? Not to mention the fact that graphs and maps are definitely content. It's a small point, I know, but one worth making.

    Otherwise an excellent article on discerning the finer points of semantic mark-up and design.
  18. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Dimitri Glazkov on 05/03/05
    Brad,

    Oddly enough, "the GIF rule" almost got chucked from the article (in fact, I did remove the rule about JPG being probably content)

    You are exactly right, the image format itself does not imply directly how the image is being used.

    However, in my experience, the presentational images are GIFs most of the time, and it just seemed like a simple and straightforward indicator. So, I put it in the "probably" category in hopes that people realize that this is not a hard and fast rule.
  19. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Terry on 05/04/05
    You make some very valid and cogent points.

    What I would like to add is that, IMHO, images that are considered "if'y" are justified in the (x)HTML if you're using a content management system that can be used to:

    a) deliver content sensitive images
    b) pull the images site wide from the content at any time without disastrous consequences or need to do so over and over and over again.

    Thanks for the article.
  20. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by John on 05/11/05
    Great article. I've been practicing this for a little while now. It was definetly strange at first getting my head around the content vs presentational thing. But, really once you start doing it, it becomes second nature.
  21. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by michael mckee on 05/13/05
    This dscussion strikes me as being very similar to the Apple v. KHTML debate that has reached media attention recently. How pure is pure? Is it better to be pure than practical?

    As a long-time admirer of the Apple Human Interface Guidelines, I think that the very existence of small, clear icons by functional links, like "print this page" or "email this page" go a long way towards increasing the usability of a web page. Pure text links require people to slow down and read. The recognizable shapes of icons can greatly improve the usability of a page. Can the markup that displays them be moved to a CSS and taken out of the html? Of course. However, an important question is, "is it worth the time?" Mostly not.

    Inline images work. They work in old browsers. They work across platforms. They don't require an assortment of obscure CSS hacks or JavaScript. If used intelligently, they don't even mess up screen readers. I know. I have a blind friend who uses JAWS and is kind enough to let me listen. They offer an extra place to use keywords. They don't require me to consult a cheat sheet to remember, "Did I use print or printme for that class?" I can insert them with a few clicks in Dreamweaver or BBEdit. The kinds of icons used in the examples take up negligible bandwidth, which would be the same if used as CSS background elements or as html images.

    So f***ing what if I have less than total and complete separation of presentation and markup? The world is an imperfect place. Browsers do an imperfect job of rendering CSS. People do an imperfect job of coding. I have built a couple of sites using as pure and clean a separation as I am capable of creating. The took longer to build and are less reliable at large text sizes than those I make by picking and choosing between the most reliable and clean options, whether those options are semantically pure or not. For all of you with good eyesight, an excellent design test is to increase the font size of every design by two or three steps to see if your layout holds together. Most image replacement examples that I've seen don't.

    I'm not saying that articles like this one are not useful. This one is excellent as a practice piece for when CSS and the real world come closer together. Until then I intend to pick and chose between the intended good and the day-to-day practical. Life never has complied with theoretical standards. Live with it.
  22. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by michael mckee on 05/13/05
    Looking through your list of examples, ironically I find your personal solution to be pretty ineffecient. I'm also surprised that you don't include width, height or alt attributes. I know that the alt is semantically meaningless here but and empty alt tag will not impede accessibility and is required to validate.

    For the image in front of the date you used:

    <h1 class="block_title">
    <a id="id.asx" style="border-width:0px;height:15px;width:12px;"><img src="images/link.gif" border="0" /></a>
    Monday, May 02, 2005
    </h1>

    Now,if you wanted to really go semantic and taken the image out of the html, you could have used
    <ul><li class="block_title"><a ..........>Monday 02, 2005</a></li></ul>
    and given the CSS of
    .blocktitle li {list-style: url("images/link.gif") none;
  23. re: Graphics and Structural Markup: Keeping &quot;pretties&quot; out of content
    Posted by Dimitri Glazkov on 05/18/05
    Whoa, a blast from the past.

    Michael, while I can understand your reluctance to accept "the new stuff", but it the CSS-driven layouts and structural and semantically valid markup are a fact of life, and ignoring them would be detrimental to your professional development.

    I use the practices, outlined in this article, in all of my Web projects, and believe me, having presentation separated from markup has paid off many times over on multiple occasions.

    As for critiquing my site, I appreciate it, but as I already stated in the article and in my comments, it is not something I developed and by no means consider perfect.

Post your comment

  • Name:
  • E-mail:
  • Title:
  • Comment: