Jeff Cutsinger → Semantic Nonsense → On Presentational Elements

N

On Presentational Elements

Another lively debate we are seeing on the public-html mailing list is about semantic vs. presentational markup. Now, it should be clear that the best practice for web design today is:

  1. Design semantically structured HTML.
  2. Validate.
  3. Write CSS to make the result look as desired.
  4. Test in all browsers.

The focus being point 1. Why is it that it’s best practice to design your HTML to be a semantically structured document which you then style, rather than to simply design presentational markup that looks like you want?

  • In general, semantic markup is more accessible (although this is not always the case).
  • Semantic markup tends to gracefully degrade.
  • The semantics in the document can be harvested.

Et cetera. My point is, that semantic markup is best practice because of its fruits, not because it is semantic. There is a conception that if it’s more semantic it must be better, on which I will call BS. If there is no benefit to the semantics, they are wasted and pointless. So for a new feature it’s not enough to simply show that it’s better semantically, it needs to also be shown what use cases exist.

Switching gears. There’s a lot of misunderstanding about semantics out there and a lot of well-meaning people get it all wrong. For instance, many people view semantic markup as:

  1. No tables.
  2. XHTML + CSS.
  3. Using em and strong in place of i and b.

Which is complete rubbish. Tables have perfectly good semantic meaning. I saw someone the other day who tried marking up calendars as nested ordered lists. What a horrid abuse! Calendars are naturally semantically marked up as tables (just make sure you use caption, summary, th, etc). XHTML is not more semantic than HTML and, while CSS enables semantic markup to look nice, it does not add any semantic value to a document.

The last one is probably the worst. The web standards movement has brought us a lot of good stuff, but it killed em and strong. That’s right, it killed them. It is absolutely, completely untrue that em and strong are drop in replacements for i and b, and to use them as such is to do violence to their meanings. To understand this it is important to consider that it is not the name of an element that gives it its meaning. The name of an element is only a useful mnemonic. The semantics of an element are granted by their usage. If ul was magically changed to bacon but it was used in all the same situations, it would not have lost its semantic value at all. I would know that if I grabbed an element called “bacon”, it would be an unordered list. What has happened to em and strong is that people have been using them in all the same places they would have used i and b. What does that tell you? It tells you that if you grab an element called em, you have gotten something that someone wanted italicized! So the point being that the web standards advocacy meant to add semantic value to the web has actually robbed it of the meaning of two important elements!

This is one reason why it is important to have presentational elements alongside semantic ones. The knowledgeable author can use semantic elements to the exclusion of presentational markup with great effect. But the vast majority of users of HTML don’t even know what semantic or presentational markup is, much less how to choose the element with appropriate semantics in a given situation. If we design a language with no presentational elements, they will be forced into making these decisions in ignorance. The result will be a net loss of meaning on the web.

Comments

  1. This is one reason why it is important to have presentational elements alongside semantic ones.

    There is never an important reason to have presentational elements. The HTML part of a webpage should be served to a user agent completely free of any presentational markup, it is the job of that user agent to interpret the document in the first instance, not for the designer to assume. If the user is viewing the page with a web browser that is fully enabled then it can use the CSS and DOM scripting provided by the designer, and be displayed as the designer wished, but what if the user is blind? or is dyslexic and uses his own CSS to browse the page, all of a sudden the presentational markup removes meaning from the document.

    (ps. In Ff2 at 1024x768 on Win XP, the input and textarea on your comment page breaks out of it's container.)

  2. Of course tables have a legitimate place in the web. I don't know that I would agree that a calendar fits into that use semantically, though, as the data in the cell is not tabulated. I suppose that is debatable.

    Still, the fact that website coders misuse semantic tags doesn't necessarily highlight a problem with the markup, but with the mindset of writers/programmers. I imagine that much of the misplaced em or strong tags originated from the HTML validity parser, which feels compelled to suggest replacement tags to users. The parser doesn't know what the writer meant, and it's not necessarily right to assume that someone using bold is writing in a strong manner. Perhaps the parser might teach users to markup their documents with tags of what they mean to say, not how they want it to look.

    And as the previous comment noted, not all users can see the page, and may need to have audio or tactile cues for certain tags. If a writer is constructing his page on the basis that his audience is using the same browser, at the same size, in the same manner that he does, then he's already off to a bad start, IMO. After all, one Firefox user can set his ems to appear bold and underlined and his strongs to appear in all caps and colored red, while most others might leave them at their default.

    Rather than opening up the can of worms that is presentational markup, I would see considerably more benefit in outright educating users in the form of hard error messages that they need to convey intent, not appearance, in their writing on the web.

  3. Less knowledgeable users have been doing what they were told to do: No tables and using em and strong in place of i and b. But they could be taught the meaning of em and strong just as easily. Every author knows what he wants to emphasize. Maybe he doesn't know if the heading should be blue or green yet but he knows it's a heading. The vast majority of users of HTML might not know what semantic markup but they know what they want to say and it's enough. "Think about the meaning now and worry about the way it looks later." Anyone could understand this.

  4. Still, the fact that website coders misuse semantic tags doesn't necessarily highlight a problem with the markup, but with the mindset of writers/programmers.

    I don't disagree. But my point works the other way around: the mindset of writers/programmers causes a problem in semantic markup. And there will always be users who don't "get" semantic markup. Education will help, but there's no way to "fix" all the ignorant people out there.

    And as the previous comment noted, not all users can see the page, and may need to have audio or tactile cues for certain tags. If a writer is constructing his page on the basis that his audience is using the same browser, at the same size, in the same manner that he does, then he's already off to a bad start, IMO.

    And you want this person to try to figure out what disabled people are going to want?

    "Think about the meaning now and worry about the way it looks later." Anyone could understand this.

    But yet the vast majority of users don't.

  5. Also: sorry about the CSS on the site, I'm still finishing the rough edges, so please bear with me. :) And thanks for the friendly discussion.
  6. And you want this person to try to figure out what disabled people are going to want? What disabled people want is to be served a well structured and semantic document, that their user agent can interpret, without any presentational croutons.

  7. What disabled people want is to be served a well structured and semantic document, that their user agent can interpret, without any presentational croutons.

    This is an oversimplification. For one, presentational markup doesn't hurt accessibility. For instance, if I throw in an i, I'm not making my page less accessible.

    But additionally, I don't think it's enough to have semantic markup to be accessible (although it doesn't hurt). Two examples: the datetime microformat is semantic but hurts accessibility, and the metadata tables on this site are semantic but I'm thinking they probably aren't great for accessibility purposes.

  8. the datetime microformat is semantic but hurts accessibility

    But the datetime microformat is an open data XHTML microformat designed to be human readable first. You cannot really use it in an argument about accessibility.

    The little meta tables are accessible, they are tables containing tabular data that have been marked up correctly...no problems.

Sorry, comments on this entry are closed. Thanks for participating.

CC *