Why semantic markup?

A big part of the push towards consistency in our XHTML is a move towards web standards, and a big part of that involves using semantically correct code. But what is all this talk about semantics? This blog post highlights the discussion.

When we talk of semantics, we mean that we’re striving to use tags in our markup that imply meaning, rather than just presentational instruction. Are you rendering a list of items? Then structure it that way. Are you rendering a table of data? Structure it as such. If you have a heading, use one of the heading tags, starting with <h1> and working through to <h2> as needed. If you have a paragraph, use the <p> tag. If you have a list, use one of the list tags available, and so on.

Benefits

By simply striving to build pages with semantic markup, we achieve several important benefits along the way:

1. We move closer to separating content from presentation.
2. We increase the likeliness that our pages will be understood properly, the way we intend them to be, by a wider variety of browsers, devices and search engines.
3. In most cases, page weight and download costs are decreased.

Ensuring semantic XHTML – things to avoid

Here are some common problems with initial implementations of standard markup. They are discussed here in the hope that they can be spotted as they occur, and prevented early in the development cycle.

Extraneous tags

Pulling presentational <table> tags from the markup is not of much benefit if the bytes removed are simply replaced with other tags. Less is more. Tags should, for the most part, clearly relate to the content that they contain.

Too much reliance on class attributes

If you’re finding that many tags have classes applied to them, ask yourself why. Perhaps a more semantic structure and shift to contextual styling will help.

• It’s a far better approach to use tags, id and descendent selectors in CSS as the style hook mechanism. This contextual approach to styling is key for reducing the size of the XHTML.
• It should also be noted that it is harder to maintain class than id. ID’s generally refer to sections of a document, which when set to appropriate values don’t change over time or design. The page will likely always have a header, footer, navigation and content area. Since classes define styles that apply against groups, they are often more prone to change with design refreshes.

Of course, care should be taken in assigning values to id attributes. Consider values like navprimary and navsecondary over values like navleft and navright, since right and left may swap or even evolve to top and bottom.

Additionally, care should be taken in assigning values to class attributes. Consider values like navlinks over values like bluelinks, since you’ll likely always have navigation links, though they may not always be blue. At the point someone likes orange better, you’re stuck with XHTML that uses class="blue" which is now meaningless.

The point here is that the styling of the site should indeed be separated from the markup. You should not have to change the XHTML to incorporate a new design, or to rename classes or id’s.

This is especially important in cases where the same shared templates of markup are used across a lot of pages contained in a lot of sites.

Poor containment

Look for cases where a <div> is used as a parent for one and only one tag and the child tag is block display by default. In most cases, such <div> tags should be removed, since they are really serving no purpose other than bloat.

Start at the content and walk up the containing elements. There should be valid and defendable reasons why each element needs to be there. If not, make the page lighter and remove it.

Beware of confidence in validation

A fine but important point to make here is that it’s possible to have XHTML that successfully validates against the W3C validators that is not semantically as good as it could be. The thing to watch for is the extent to which extraneous tags are used. One common failure in moving to standards is to pay too much attention to validation. Compliance with the markup can be validated against the XHTML schema, but the schema is complicated and limited in terms of what it will understand, recognize and interpret. Validation can enforce basic stuctural rules, but it will not interpret the intent of your structure, or be able to provide any guidance on better structures from a semantically-appropriate point of view.

Next post (newer)

Rules for valid XHTML Strict

Previous post (older)

The Rolling Stone's top 500 albums of all time