We’ve covered structural markup in some depth; now let’s get down to the nitty-gritty. HTML5 redefines several inline and block-level elements and introduces a few more. We’ll run through some of the changes and additions and then consider the broader philosophy behind these elements.

Be Bold or Die Trying

Let’s start our look at these elements with something as seemingly innocuous as the <b>, <i>, <strong>, and <em> tags and  what’s changed in HTML5.

Only in web standards land can we turn something as straightforward as bold and italic into a complicated mix of dogmatism, high-level theory, and broken pragmatic reality.

When web standards took off, we all endeavored to separate presentation from content. No longer would font tags and tables clutter our markup. Instead, we’d style our pages with CSS and describe our content in a meaningful (in other words, semantic) way with appropriate tags.

This put the poor old <b> and <i> tags in a tough spot. They were ostensibly presentational—they described how text should look, not what it meant—and we were running away from presentational tags as fast as our fingers would carry us. So, we all embraced the <em> tag instead of <i> (for “emphasis”), and the <strong> tag instead of <b> (for “strong emphasis”). These new tags now described the meaning of the text—it was emphasized, and how ”emphasized” text looked (or sounded) was (theoretically) up to the browser or screen reader. We could then use <b> and <i> for purely stylistic reasons and <strong> and <em> for semantic purposes—a subtle difference but a difference nevertheless.

I embraced the change (you may have, too), thinking that mattered. But it didn’t. Yes, it helped draw a line in the sand between presentational and semantic markup, but this was splitting rather narrow hairs. There was no pragmatic benefit. Here are some examples:

• We just swapped one for the other: Given <strong> still bolded text and <em> still italicized text, we all just swapped <b> for <strong> and <i> for <em>, and that was that. The difference between what was “emphasized” and what was just bold or italicized styling without any particular emphasis was lost, given we kept using them for presentational purposes anyway. WYSIWYG editors were particularly guilty of this. The difference was just too subtle.
• Screen readers ignored them altogether: The main benefit of these “semantic” tags (supposedly) was that screen readers could read the text with “emphasis” or “strong emphasis.” In fact, screen readers, by and large, ignore them altogether. (See www.paciellogroup.com/blog/2008/02/screen-readers-lack-emphasis/ for further discussion.)
• Search engines don’t care: Google treats <strong> and <b> and <em> and <i>exactly the same. (See Matt Cutts’ video here: http://www.youtube.com/watch?v=awto_wCeOJ4.)

So, for all the dogmatism about these elements, the reality is pretty simple—use whatever you want. The humans who read it won’t care, and the machines that read it (screen readers and search engines) don’t care either.

But where do these elements fit in HTML5?

I guess if you’re writing a spec, you have to try to make some sense of how these elements are used, with some emphasis (pun intended) on how they should be used. Here’s what the spec says (emphasis added):

HTML5doctor.com has an entire article on how this might work in theory (see http://html5doctor.com/i-b-em-strong-element/), but it’s really pure fiction. If you think people will actually mark up their documents in this way, I have 15 billion web pages I’d like to show you. And Ian Hickson himself likes to say this (www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/):

If the HTML5 spec documented actual behavior (that is, “paving cowpaths”), the spec would just say <b> and <strong> make text bold, <i> and <em> make text italic, and screen readers tend to ignore them altogether. That’s the reality. Everything else is fiction.

This may seem like small fry, but we’ve touched on a bigger philosophical question: how much of marking up a document in HTML is word processor–like formatting, and how much is marking up the meaning of the text? For most web authors—usually our clients using the content management systems we set up for them—it’s about word processor–like formatting, and that’s OK. We’ll return to this shortly.

Wrap Your Anchor Around This, and Other Bits and Pieces

Let’s do a quick roundup of some other features and elements available in HTML5.

<figure><img src="myphoto.jpg"><figcaption>Yup, this is my photo.</figcaption></figure>

<p>The Y2K bug destroyed civilization on <time>2000-01-01</time>.</p>

<p>The Y2K bug destroyed civilization at the <time datetime="2010-01-01"> beginning of this year</time>.</p>

<p>This Y2k article published on <time pubdate datetime="2000-01-01T01:42">Dec 31, 1999</time>.</p>

<details>
   <summary>Show/hide me</summary>
   <p>You can see this when expanded<p>
</details>

Should We Even Use These Obscure Little Tags?

If and when new functionality arrives in browsers or other agents (and not just the bowels of the HTML5 specification), sure, some of these elements may prove handy from time to time.

But let’s step back and consider the bigger picture of the purely “semantic” text-level elements. We’ve already touched on the question of simple word processor–style formatting versus marking up meaning when discussing <b> versus <strong> and <i> versus <em>. Now let’s consider the <address> element, for example. In November 2009, Jack Osborne wrote the following on HTML5doctor.com (http://html5doctor.com/the-address-element/):

Perhaps, after 15 years, it’s time for a rethink. What’s our aim here? Are we going to give it another 15 years? After 30 years, will the Web finally be using <address> correctly? And if it is, so what?

Fifteen years ago we may have assumed that “one day” someone will do something useful with our carefully marked-up pages. We now know better. It’s time to reevaluate. We’ve spent 15 years experimenting with HTML to see what works in terms of semantics and functionality. It’s time to take stock of the results.

If HTML5 were truly paving cowpaths here, it would open up the definition (instead of tightening it) for elements such as <address> and <cite> or, better still, make them obsolete altogether. We don’t need them. They don’t do anything. Micro-semantics on top of HTML make them obsolete. The search engines have demonstrated through  Schema.org (and earlier initiatives such as Rich Snippets) that they want micro-semantics, not redefined HTML elements. Authors have little use for them. So, why keep them?

This is the truth we need to acknowledge when it comes to these finer aspects of markup. HTML for documents has proven to be pretty lousy for anything but basic semantics that are explicitly tied to formatting (header, paragraph, list, link, and so on) and providing generic page structure (using <div>s, now with some ARIA roles sprinkled liberally), but that’s its beauty; it’s what makes it so universal and accessible.

Digging into the details of HTML5’s markup reveals yet another mixed bag, containing some interesting inclusions, some baffling ones, a lot of squabbling over some incredibly minor issues, and a lack of a coherent vision to really take markup, and the Web, forward.

Then again, criticism of HTML in this regard is hardly new. Here’s Clay Shirky in his piece “In Praise of Evolvable Systems” (www.shirky.com/writings/evolve.html) from—wait for it—1996:

And it was ever thus.