The harsh truth about HTML5’s structural semantics (part 1)

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.

0 shares
  • jaystrab

    How about just working the way we’ve always worked and not worry about things like “asides” and “headers”. Do what you’re comfortable with and what fits your workflow.

  • http://www.testshoot.com/ TestShoot

    One of the issues I have always had with HTML is that you could just make up tags. Before really understanding classes, I foolishly created tags that I defined in a style sheet. Knowing that you could just create tags and then get them in the draft. what is to stop a “junk” or “thing” or “widget” tag from being created for wildcard items that maybe could become something just by existing?

    • http://taecilla.github.com/ Tae

      Oh… Thinking on make my own “HTML specification”…

  • Benjie

    If you check the title you’ll see that this article is “part 1″. There are another two parts which will be published over the next few days, delving into the issue in more depth.

    The ‘article’ you’re referring to on the .net site is an extract from Luke’s book which he’s currently promoting through our sister site MightyDeals.com (there’s a link to it above).

    • Jez

      Yep, looking forward to the next part!

      • Benjie

        Part two is available now :)

    • Xandor Schiefer

      Fair enough :)

  • M. David Green

    While it’s a little disturbing to read this story about how the new elements in HTML5 were defined and communicated, there is still a difference between grammar and semantics. The traditional way things have been done shouldn’t be the only consideration when developing and adopting a semantic approach to document structure.

  • http://www.javaexperience.com/ Java Experience

    HTML5 has been there for quite some time now but still the grammer and semantics hasn’t been standardized.

  • MarkupBox

    Very informative article. I really appreciate your post. You explained it very well. Insight information for HTML5 developers. Thanks for sharing!

  • Yvan Daneault

    Good insight. In the end however, customers who pay for their site care about its ranking. How will search engines -Google and Bing, namely- end up treating the html5 semantic elements? If they will put more “ranking weight” into , and , we can’t ignore them, can we?

    • http://twitter.com/lukestevens lukestevens

      The search engines don’t treat them any differently. I have a chapter on this in my book. Imagine, for a moment, that they did. They would be abused (as always) by unscrupulous SEOs, and any advantage would quickly be removed by the search engines. So, for SEO purposes, we certainly can ignore them :) Schema.org, on the other hand, is what the SEs want for result *display* (not ranking, for the same reason as above), as I discuss in Part 3: http://www.webdesignerdepot.com/2013/01/the-harsh-truth-about-html5s-structural-semantics-part-3/

  • http://twitter.com/stevefaulkner Steve Faulkner

    Luke, you talk about HTML5 as if it is set in stone, it is not there is the opportunity to participate via the W3C HTML working group to make course corrections on the authoring advice and requirements for the structural elements discussed here. HTML5/HTML5.1 http://www.w3.org/html/wg/drafts/html/master/ is no longer edited by hixie and the HTML WG is open to proposals based on use cases and data, to add/remove or modify features in HTML. I have worked on the introduction of a new structural element in HTML (the main element https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html ) which is moving through the standardisation process at the W3C and is being added to HTML5.1) It should also be noted that the outline algorithm is an at risk feature in HTML5 due to lack of implementation. Furthermore, modifying the author advice and requirements for currently implemented structural elements should be relatively easy (compared to getting stuff implemented in the first place). I urge you and others who have input on who structural elements should be defined in HTML to bring your arguments and evidence to the table.

    • http://twitter.com/lukestevens lukestevens

      Thanks for the info Steve! I’m happy for anyone to submit the appropriate chapters from my book to the W3C ;) However the competing W3C HTML5 and WHATWG “Living Standard” specs seems like one big can of worms at the moment. Though I take your point about author advice vs changing the spec, but still, the question of what is authoritative seems up for debate at the moment.

  • http://twitter.com/SinaBahram Sina Bahram

    Luke,

    Thank you for writing this post, and for sharing your
    thoughts. There are several things that come to mind as one reads, and so I’d
    like to go over those, if I may.

    First, a quick note on web accessibility, and this is
    perhaps a minor one and possibly not even under your control, but this little
    snippet on the current page:

    **

    **

    // *internal thought* I hope that above snippet doesn’t
    get filtered out

    Is inaccessible to individuals, such as myself, who use
    screen readers to access the web. The main reason being that the link has
    absolutely no textual equivalent, seeing as how the alt tag for the image is
    the empty string. Anyways, if that could be fixed, it would be most appreciated
    by this humble reader.

    Alright, so onto your post:

    One last thing before we get to substance, and that’s
    tone. I’ve been so guilty of this on technical topics I’m passionate about, and
    so I get it, and I’m also not suggesting the even more annoying and overly PC methodology
    of voting 25 times on 30 stupid and inane points of minutia while dancing together
    and singing happy HTML songs, but the post was a bit harsh, a bit ranty, and a
    bit bitter, man. Here’s the thing, it actually weakens the arguments you’ve got
    and the points you are making, which is why I bring it up. I was so distracted
    by wondering what the juicy story was about why you’re so mad at he who shall
    not be named, that I had to go back and read some passages more than once. Others
    might have simply given up or not bothered.

    I have to first strongly agree with Steve Faulkner’s
    comments RE HTML5 not being set in stone and echo his call for you and others
    to join the process and bring such arguments to the table.

    Regarding your discussion of the nav element and how the
    1 to 2% of IE8 users who have JavaScript turned off will lose out since the author
    decided to go with a nav rather than a div, this point is valid, but applicable
    to every other tag, and whilst you sure criticize the other tags for a myriad
    of reasons, this is not one of them, and so I’m left wondering why you are
    singling nav out for this special treatment? I’m biased of course, but frankly,
    nav and main are the two most helpful aspects of HTML5/Aria, and that 1% to 2%
    of IE8 folks who have JavaScript turned off is only going down each and every
    single hour of every single day, while the number of screen reader users and
    other user agents that take advantage of nav is going up (possibly more rapidly
    one might even argue). Are you really stating that legacy support for a provably
    diminishing group of folks is worth more than semantic support for an
    increasing group of users? Incidentally, even if styling is turned off for
    those folks, chances are that they will still be able to make use of those elements
    albeit them looking ugly/distorted/strange (sure, I understand sometimes
    functionality will actually be reduced e.g. overlaps or other things happening
    to cause them not to be useful), but the screen reader user, let’s just say, is
    “far more screwed” if I may use an arbitrary qualitative measurement.

    Moving on to some of your points with respect to the
    outlining algorithm, I find myself agreeing. I really do love the idea represented
    in the concept, especially for the early 90’s, and maybe if it had been implemented
    then, TBL and others would have caused us to move in a path of better authoring
    or what have you, but it didn’t happen, and the discussion you provide about h1
    being used all over the place is key, so I hope if readers get nothing else, they
    do understand what a miserably moronic idea it is to use h1’s all over the
    place (oh great, now I sound ranty … it’s contagious :P).

    Now, an overall point that I think you might agree with,
    but not in current implementation, maybe? I do think semantic tags are good. As
    a purest, which one can never afford to be with HTML, one might argue against
    all but a handful of tags, but as a pragmatist, which is the argument you seem
    to be making, I just want to state that I believe that semantic markup is a
    good thing. the benefits to folks like me using screen readers, as well as to automated
    processing and (one day before the heat death of the universe) truly semantic
    processing, are quite beneficial. In addition, these semantic tags have the
    ability to provide the impetus for developers to do things in a way that promulgates
    better design, easier transformations between content as a result of semantic
    separation, etc.

    So, how can we get there? The point you made about 100M
    out of the 1B pages examined being the only ones with classes really spoke to
    me. Do we feel that’s still the case today? Have folks done actual basic
    semantic processing on the classes of a lot of pages today? For example, just
    finding out what the various class names mean e.g. “menu” and
    “nav” and “navigation” all indicate a similar concept. This
    is trivial to do with a basic script and natural language processing (NLP)
    library, as long as one has the data.

    Anyways, I’d encourage you to bring these arguments into
    a forum in which they can be debated and acted upon, because otherwise, they’ll
    only have the satisfaction of being able to serve as justification for an empty
    “I not only told you so, but I told you so as you were doing it.”

  • http://twitter.com/lukestevens lukestevens

    Thanks for the comment Evert. I certainly know what you mean and I understand where you’re coming from. I’m just worried that everyone making up their own interpretation of these elements essentially “forks the spec”, so we have the “community spec” and the “actual spec”. It’s a messy situation! :)

  • http://twitter.com/gotofritz fritz

    Good article.

    The people who chose those elements must be related to those who spent years to come up with .name as TLDs…

    It seems obvious to anyone who actually builds websites (as opposed to index them) that there are candidates for semantic elements that come up over and over again – events, address, product description, price, map, widget, gallery, comment, article, logo, nav… it’s no more than about 15-20. Instead they gave us ‘aside’ and ‘article’, then you have endless discussions o whether blog comments should be ‘article’ or not

    Then you get ridiculous statements like in this HTML5 Doctor article, where they try to post-rationalize the ‘article’ tag to mean “an article of clothing”, i.e. a product
    http://html5doctor.com/lets-talk-about-semantics/

    Personally, I just use nav and boycott the rest