On semantic markup, conveying its usage to those who generally don’t need to care, and a reusable markup guide for your enjoyment.
This is how I like to define the term ‘semantic markup’:
Semantic Markup is the result of using (X)HTML elements for their proper, intended usage.
This is a pretty limited definition, better examples exist, and it’s by no means the only viewpoint out there. The terseness is partially the result of HTML being semantically limited to begin with. We don’t exactly have a rich vocabulary of element types capable of capturing the meaning and nuance behind every piece of text: We have code, but we don’t have caption; We have kbd, but we don’t have childlikescrawl; We have emphasis, but we don’t have publicationtitle. And so on.
Why care? It’s a good question, one I’ve also asked. If you spend time putting semantic markup into a page, there ought to be a payoff. Unfortunately, the payoff is less than visible. Since CSS is able to make any element look like any other element, you won’t see the result in a visual browser. It’s only when you load a semantically-rich page in a text-only browser, or in a screenreader (or other alternative access device) when you’ll start to understand the benefit of authoring this way. Additionally, various stabs have been made at extracting the semantics from a document and putting them to more general use. See Mark Pilgrim’s Million Dollar Markup and Tomas Jogin’s Hierarchy.
XML gets us the ability to work around this limitation, of course. By defining new, semantically rich languages, we can add extra meaning to our documents (and while we’re at it, create tools to pull that meaning back out later and actually do something useful with it). But that’s strictly tangental, considering the utility of HTML here and now. We use HTML for web pages, so the limitations are something we have to think about.
Semantic debates about which element to use in which scenarios are usually quite arbitrary and prone to subjective interpretation. Here’s a good example: the
address element. The spec has this to say:
addresselement may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.
Then it goes on to list an example with virtual addresses, in this case URI’s to the page author’s profiles. Presumably, email addresses would be acceptable in this space, but does that hold true for physical addresses? You may be surprised at how many different individual opinions exist about this, as evidenced by this SimpleQuiz from a year ago.
The ambiguity lies in the fact that the term ‘contact information’ is undefined in the spec, and therefore it’s left to the user’s best judgement to fill that in with whatever contact information they deem relevant. So one person’s email address is another’s street address, which is yet a third’s PO box, which is a fourth’s airport locker number.
And that’s all okay, you know. The spec is loose enough that it provides guidance, but actual usage is going to determine the most relevant and appropriate ways to use the markup in question. Individual preferences will guide deployment of the elements, and if a consensus is ever formed, so be it. Until then, vive la différence. HTML elements are basic constructs, it’s up to you to build something with them.
But even this gets tricky when you no longer have control of the semantics of a particular document. What happens when you pass your markup on to a client? Ever worked with a content management system that allows multiple authors to mix and match their own elements for whatever purposes they have in mind? How often do you find them choosing elements based on how they look, rather than what they mean? I see more than a few heads nodding.
“Just educate your clients”, you may think. I hope you understand why this doesn’t always work. As an analogy, compare and contrast these situations:
- You just built a site for a plumbing company, complete with a CMS. You tell them to make sure to use <ol> elements for parts lists, and <h2> elements for product names on their respective pages. 6 months from now, you check the site and find a ton of <br /> elements to separate the list items, and headers in <font size=”5”> tags. D’oh.
- In exchange for your work on the site, the plumbing company gives you some advice on your kitchen remodeling. They suggest copper pipes for your water lines running through the exterior walls, with a small length of flexible CPVC inside the house. You decide to go all CPVC because it’s slightly cheaper. 6 months later, your pipes burst during a particularly cold winter night. D’oh.
In both cases, a little bit of education goes a long way. In both cases, the client needs to take a little initiative of their own to ensure higher quality. In both cases, there will be people looking for shortcuts who simply won’t take the advice of the expert.
Simply, you can’t assume the client will care unless the task they need to perform is personally relevant to them. Education can only go so far, there has to be motivation. But that doesn’t mean it’s not worthwhile to try anyway; the site may be delivered to a single person or company, but after that it will be used by a far wider audience who will benefit from proper semantics. That’s why it’s important to care about semantics, as a web designer/developer, and at least try to convey some of that importance to your client.
To that end, I’ve recently started work on a rough style guide that I distribute to clients as a part of my completed deliverables. This is a single HTML document, marked up with both examples and descriptions of various elements. It also serves as a palette of sorts, graphically depicting the various elements when rendered in the site’s style sheet (assuming the CSS file has been linked.) It’s a rough start, and will evolve over time, but it’s important enough for the education process (and easy to re-use) that I’ve been relying on it since I wrote it.
Here it is, the mezzoblue Markup Guide, available in formatted and bare-bones unformatted flavours, with a permanent home in the Downloads section of this site. Feel free to use, edit, and share alike. I’d love to see this expanded and improved upon by all of you, with revisions released under the same CC license.