Let’s Talk about Semantics

Semantics and the Web #

Semantics are the implied meaning of a subject, like a word or sentence. It aids how humans (and these days, machines) interpret subject matter. On the web, HTML serves both humans and machines, suggesting the purpose of the content enclosed within an HTML tag. Since the dawn of HTML, elements have been revised and adapted based on actual usage on the web, ideally so that authors can navigate markup with ease and create carefully structured documents, and so that machines can infer the context of the wonderful collection of data we humans can read.

Until — and perhaps even after — machines can understand language and all its nuances at the same level as a human, we need HTML to help machines understand what we mean. A computer doesn’t care if you had pizza for dinner. It likely just wants to know what on earth it should do with that information.

HTML semantics are a nuanced subject, widely debated and easily open to interpretation. Not everyone agrees on the same thing right away, and this is where problems arise.

What’s the point? #

Discussions over the importance of semantics are happening all the time, and every so often there’s an uproar over specific articles on the subject. Divya Manian caused a stir in her Smashing Magazine article Our Pointless Pursuit Of Semantic Value in November 2011, in which she argued we have become too caught up in trying to use HTML5’s semantics, and that the benefits aren’t worth it:

Allow me to paint a picture:

1. You are busy creating a website.
2. You have a thought, “Oh, now I have to add an element.”
3. Then another thought, “I feel so guilty adding a div. Div-itis is terrible, I hear.”
4. Then, “I should use something else. The aside element might be appropriate.”
5. Three searches and five articles later, you’re fairly confident that aside is not semantically correct.
6. You decide on article, because at least it’s not a div.
7. You’ve wasted 40 minutes, with no tangible benefit to show for it.

This generated a storm of responses, both positive and negative. In Pursuing Semantic Value Jeremy Keith argued that being semantically correct is not fruitless, and he even gave an example of how <section> can be used to adjust a document’s outline. He concludes:

But if you can get past the blustery tone and get to the kernel of the article, it’s a fairly straightforward message: don’t get too hung up on semantics to the detriment of other important facets of web development.

I’ll admit I’ve been in a situation where I’ve dug myself a mind hole, trying to decide which element is “correct” and then depressing myself with thoughts of how irrelevant it all seems. What gives me strength is the thought that I’m not marking this up for me, but for everyone who can benefit from the enhanced meaning. Whether it’s the browser, a search engine spider, an accessibility tool, the person you pass the project on to, or even future you returning to the project in six months time, the markup indicates how the content should be interpreted. As long as your markup makes sense and isn’t over the top (e.g., if you just replace all your HTML 4 <div>s with <section>s, you may be misunderstanding the element or even your content), then don’t worry so much about it all.

To help you choose the most appropriate element, we released a flowchart of HTML5 sectioning elements that you can print off and follow whenever you get stuck. If all else fails, don’t forget about your old buddy <div>. Then again, maybe you’ve stumbled across a need for something new…

Naming Things #

Of all the possible new element names in HTML5, the spec is pretty set on things like <nav> and <footer>. If you’ve used either of those as a class or id in your own markup, it’s no coincidence. Studies of the web from the likes of Google and Opera (amongst others) looked at which names people were using to hint at the purpose of a part of their HTML documents. The authors of the HTML5 spec recognised that developers needed more semantic elements and looked at what classes and IDs were already being used to convey such meaning.

Of course, it isn’t possible to use all of the names researched, and of the millions of words in the English language that could have been used, it’s better to focus on a small subset that meets the demands of the web. Yet some people feel that the spec isn’t yet doing so.

What about adding more elements? #

When I first met fellow HTML5 Doctor Bruce Lawson, I asked him this question: If we have elements like <article>, why don’t we have one for products of a shop? I understand more about HTML now than I did then, but at the time it seemed like a very logical element to add. Why restrict ourselves to documents with <article>s when the web has evolved beyond that with shops, applications, and games? I’m sure many of you have felt the same way. Some have even put cases to the WHATWG suggesting more elements like the often requested <comment>.

Recently, editor of the HTML5 spec Ian Hickson wrote responses to some of these requests for new elements for comments, explaining why <article> within <article> suffices for marking up comments:

<article> isn’t just for articles. That’s the point.

Note that its name is irrelevant here. It could be called <pineapple> — what matters is what it is defined to mean, not what its name is. And its definition is one that covers both articles and comments. They are both self-contained compositions.

As much as I am all for the much needed addition of <pineapple>, Ian makes a good case for why we don’t need <comment> (or similar). Dr Bruce often uses the following analogy when trying to explain <article>:

Don’t think of <article> as a magazine article. Think of it as an article of clothing, an independent entity that can be arranged in conjunction with other articles of clothing, but is a complete thing in itself.

I hear you ask, That’s all well and good, Mike, but what does understanding <article> have to do with adding new elements? To add something to the spec, you need to:

1. document actual use cases,
2. show how developers are working around the lack of this feature now, and
3. make a compelling case for why HTML5 needs it.

Step one is to make sure what you’re asking for can’t be achieved with what already exists. This is exactly the problem with the proposals for <comment>. Any difference from <article> is so minimal that it isn’t worth adding.

If every proposal for a minor deviation of an existing element was accepted, the spec would be bloated with far more elements than necessary. User agents would have to keep up with the vast array of markup possibilities for a given bit of content — as would you, the author. And think about this: at the end of the day, what are you actually going to use that new element for? Really?

That’s not to say you should be discouraged from putting your ideas forward. Take it as advice on what to look for when you want to contribute something to the spec. It may even help you to think differently about your work. Some problems just need a fresh perspective to help solve them.

HTML5 Doctor, or: How I Learned to Stop Worrying and Love HTML #

Once you learn to look past element names and think of their essential meaning, it gets a bit easier to write markup. Think of your chunks of content in terms of how they relate to each other and in which contexts they can be used. In our article archive, we’ve covered a lot of elements with examples of their use. If you’re ever in doubt, I highly recommend our flowchart of HTML5 sectioning elements to help you along.

Try to keep things simple. Overthinking your markup will only cause more problems than it’s worth. And let’s face it: it’s not like you can’t change it later!

You may also be interested in adopting Microformats, something Dr Oli Studholme has written about here on HTML5 Doctor. Extending HTML5 — Microformats is recommended reading for those who want to take their markup a bit further. Dr Oli has also looked at Extending HTML5 with Microdata, which gives us a whole new way to add extra semantic information.

Finally, try utilising HTML5 markup in ways that gain the benefit of these new elements. Create tools, use your own documents to test how well-formed and structured they are, and test how portable your content really is. Who knows, you may even find yourself writing a proposal for the next addition to the spec.

Do you know something the web needs that’s missing from HTML5? Let us know in the comments.