HTML’s structural elements — article, section, nav and aside — are, at first glance, some of the easiest parts of the HTML5 specification to understand and implement. However, they’re actually some of the most poorly specified, poorly understood, and poorly implemented parts of HTML5.

Created arbitrarily; they attempt to introduce a whole new way of structuring web pages; they violate HTML’s own design principles; they harm accessibility for some users; and you shouldn’t use them.

Yes, I’m coming out guns-blazing against this specific part of HTML5, but please don’t assume I’m ‘anti-HTML5’. I've written a book about HTML5, I love the open web, I love good web standards, and I love the fact that after working through a decade of stagnation, innovation in web technologies is now happening at an utterly blistering speed. That, however, doesn’t mean we have to accept everything we’re given. We don’t have to eat everything on the HTML5 plate, even if we find parts of the dish rather tasty indeed. Some parts probably need to be sent back to the chef.

There are good and bad parts to the quite enormous HTML5 specification, and we’re going to think critically about one very specific part of the specification: the sectioning, or ‘structural’ elements HTML5 introduces. So let’s put our detective hats on and look at where these new elements really came from, how they are supposed to be used, and how we, the web design community, have fundamentally misunderstood them, essentially forking the spec. We’ll question the very basis for these elements, and bust a few myths about them along the way.

Where did HTML5's structural elements come from?

Let’s bust one myth that’s been repeated ad nauseum about these elements: the idea that they are based on research into how we, the web community, were marking up our documents. It’s a myth that’s been repeated in books, blogs, and talks for years now, and it’s just not true. How do I know? I asked.

When I was researching the origins of these elements, I decided to ask the editor of the HTML5 specification, Ian Hickson, where these elements came from. He replied:

Me and other WHATWG contributors [added them], [in] 2004ish, because they were obvious elements to add after seeing how authors used HTML4. We later (late 2005 early 2006) did some objective research to find out what the top ten HTML classes were and it turned out that they basically exactly matched the elements we had added, which was convenient.

Let’s break this down: first, Hickson and the WHATWG members added these elements before any research was done. You can dive into the WHATWG’s (thankfully public) mailing list archives and discover early discussions about these elements for yourself. For example, you can see Hickson discussing them in November 2004, with comments such as this one:

Yes, I intend to include stuff like [semantic elements] in Web Apps. The whiteboard in my office currently has a list of elements under the heading "HTML5 BLOCK LEVEL ELEMENTS", and I'm trying to work out how to make them work well (the elements in question are currently mentioned in the draft, but the draft doesn't handle headers at all well). I haven't looked at inline markup yet, but that's on the cards too.

That is, it seems, how the HTML5 structural semantics came to be: one man, one whiteboard, and some input from other WHATWG members. (The WHATWG, or Web Hypertext Application Technology Working Group, was formed by browser representatives in response to the W3C’s abandonment of HTML for the utopian ideal of XHTML 2.0).

The elements used by millions of documents that we’ve been discussing and debating were, it seems, created arbitrarily on a whim of the HTML5 editor in 2004. (And were met with an astute critique and some sadly accurate predictions almost immediately.)

Collective behinds

Tantek has been insisting on research-before-specifying-new formats for a long time in the microformats context, and finally the WHATWG specifications will similarly be designed with actual data, instead of us pulling stuff out of our collective behinds. – Ian Hickson

That brings us to the second point. In December 2005—a year or so after coming up with these new elements—Hickson (an employee of Google) did some research into how documents were authored using Google’s vast document database. The research was ‘an analysis of a sample of slightly over a billion documents, extracting information about popular class names, elements, attributes, and related metadata.’ IDs were not included in the research. The findings were published by Google as Web Authoring Statistics (2005).

The critical part of the research, as far as HTML’s structural elements were concerned, were the classes findings, which, despite using a sample where ~900 million of the 1 billion documents apparently had no classes at all, contained some common classes I’m sure we’ve all used in our projects before: footer, menu, title, small, text, content, header, nav, copyright, button, main, and so on.

Hickson then provides his spin on the data, suggesting that these classes ‘actually [map] very well to the elements that are being proposed in HTML5’ and provides a table comparing the findings of the research, and the new elements in HTML5: a footer class is in the research, a footer element is in HTML5; a header class is in the research, a header element is in HTML5; the classes text, content, main, body are in the research, and, err... article is in HTML5 which, as we’ll see, doesn’t match at all; section isn’t to be found at all, which is also worth noting.

Taken at face value, this is all reasonable enough. I use footer, you use footer, footer is in HTML5. What’s the problem?

The problem is, if you read the actual HTML5 specification, the elements in HTML5 are defined in a way that has little to do with how we have traditionally used them.

On the one hand, Hickson has introduced a whole new concept of structuring a web page in HTML5 with sectioning elements. On the other, Hickson is comparing his HTML5 sectioning elements to classes used in the wild with no understanding of what those classes were actually used for. A classic example is ‘header’, which most of us would use for the area at the top of the page, but the HTML5 spec, suggests you can use it for the header of every comment on a page. Really. Just because classes in the research and elements in HTML5 have the same name does not mean their uses are the same.

Now, if it was communicated clearly that new elements were introduced with a new purpose, and a clear rationale, then that wouldn’t be so bad. But that’s not what we’ve been told.

Here’s Hickson in 2009, responding to a question about the purpose of section, nav, article, aside and others:

They are, more or less, filling the most common requests from Web developers based on what the most common class="" attribute values are. Their main purpose is to simplify authoring and styling.

Unfortunately, this seems to be a case where the HTML5 editor, for all his good work in pulling the spec together, has (let’s be generous) forgotten why he added these elements to what is essentially his spec. Perhaps it’s the time difference between 2009 and 2004, who knows. But we do know this: the HTML5 sectioning elements were not added to fill ‘the most common requests from web developers’ at all. How do we know? We can just look at the list, and see the most fundamental elements added, such as the section element (and the related article and aside elements), do not appear in the common class attributes research whatsoever.

Though Hickson may have forgotten why these elements were added, we can still thankfully read the spec that documents their purpose.

But what happens when you tell web designers and developers not to worry, these elements just replace what you’re already doing, and then specify these elements in a way that is most certainly not what web designers and developers were doing? You put them on a one-way trip to confusion city.

This is the worst kind of research: a lazy interpretation of data done to justify decisions that were already made. An oft-repeated design principle of HTML5 is to ‘pave the cowpaths’, that is ‘When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.’ And so it would seem with these new structural elements: section, article, nav, and aside (and header and footer)—surely these are just ‘paving the cowpaths’?

That’s the impression many of us have got, as that’s what we’ve been told they are.

In fact, nearly five years ago when we first got a preview of HTML5, it looked as though these elements could simply replace the ‘unsemantic’ divs that we were used to using. What was div id="header" at the top of the page could now just become header; div id="footer" could now just become footer, and our div could just be article. Simple, right?

We forked the spec

Unfortunately, despite doing what we were told (i.e. just swap one out for the other), we have actually implemented these elements in a way that isn’t reflected in the HTML5 spec. That is, when it comes to HTML5 structure, we’ve essentially forked the spec. There’s currently two methods of HTML5 structure out there — the community interpretation, which is reflected in the 2007 A List Apart article (and countless others); and the actual HTML5 specification, which introduces a whole new way of structuring a web page called outlining.

This is the contradiction at the heart of HTML’s structural semantics. On the one hand we have the editor telling us the new elements are based on the research about what we were already doing, and are therefore intended to just make authoring a bit easier; and on the other hand we have what the editor actually created in the HTML5 specification, which is a new way of structuring a web page in a way that generates a document outline using sectioning elements.

There was a clear choice to be made here. Break with the HTML5 design principles and introduce something new, or simply follow real authoring practices and specify elements in a way that reflects web design practice. Hickson tried to do the former and call it the latter, and we now have one big mess on our hands.

Hungry for more? Part two of this article is now available and Luke's book "The Truth About HTML5" is available for a limited time through our sister site MightyDeals.com at an amazing 50% off.

Do you work with HTML5 structural elements? Do you find them helpful, or a hindrance? Let us know in the comments.

Featured image/thumbnail, uses structure image via Shutterstock.