Please leave your sense of logic at the door, thanks!

<section> is not just a “semantic <div>”

by James Graham in Elements, Tutorials

HTML 5 introduces new elements like <section>, <article> and <footer> for structuring the content in your webpages. They can be employed in many situations where <div> is used today and should help you make more readable, maintainable, HTML source. But if you just go through your document and blindly replace all the <div>s with <section>s you are doing it wrong.

This is not just semantic nit-picking, there is a practical reason to use these elements correctly.

In HTML 5, there is an algorithm for constructing an outline view of documents. This can be used, for example by AT, to help a user navigate through a document. And <section> and friends are an important part of this algorithm. Each time you nest a <section>, you increase the outline depth by 1 (in case you are wondering what the advantages of this model are compared to the traditional <h1>-<h6> model, consider a web based feedreader that wants to integrate the document structure of the syndicated content with that of the surrounding site. In HTML 4 this means parsing all the content and renumbering all the headings. In HTML5 the headings end up at the right depth for free). So a document like the following:

  <h1>This is the main header</h1>
    <h1>This is a subheader</h1>
      <h1>This is a subsubheader</h1>
    <h1>This is a second subheader</h1>

has an outline like:

This is the main header
+--This is a subheader
    +--This is a subsubheader
+--This is a second subheader

If you just blindly convert all the <div>s on your pages to <sections> it's pretty unlikely your page will have the outline you expected. And, apart from being a semantic faux-pas, this will confuse the hell out of people who rely on headings for navigation.

Hopefully, in time, we will get tools that make this kind of mistake obvious and CSS support for selecting headings based on depth. Until then remember <section> is not just a semantic <div>

24 Responses to “<section> is not just a “semantic <div>””

  1. I only discovered that a couple months ago while experimenting with my implementation of HTML5 so this post is helpful. It might prove useful to go through an equally simple explanation using and with the elements and so on.

  2. Makes sense… sort of.

    What about when [section] and numbered [h1…6] elements are used in a mix match?

    [h1]This is the main header[/h1]
    [h2]This is a subheader[/h2]
    [h2]This is a subheader[/h2]
    [h3]This is a subsubheader[/h3]
    [h3]This is what, then?[/h3]

    Is that example simply an abuse of semantics, or are UA’s going to be expected to treat both [h3] elements as “subsubheaders”? Or would the last [h3] element be treated only as a “subheader” because [h2] is missing?

    (Angle brackets have been replaced with square brackets to make sure the markup example shows up in this comment)

  3. So a <SECTION> is not a <DIV> huh? – that’s not very difficult to grasp 😉
    But what’s with that nonsence of not letting an <H1> continue to be a document level level one header instead of redefining it as a poor substitute for the more generic <H> of XHTML2 (and excluding <H> at the same time) ?

    Leave your sense of logic at the door?


  4. What about the Web Content Accessibility Guidelines? H42: Using h1-h6 to identify headings Aren’t we now totally ignoring this or can you dictate per your headings? I am running a weblog and every entry has a tag, so when validating this it will fail because there isn’t any distinction between them (latest article versus oldest). Will this or solve this?

  5. Vincent, that technique is based on the more limited heading markup available in HTML4. The important thing is that heading hierarchies are conveyed to the user. In HTML4, that can only be done with h1 to h6. The sectioning elements in HTML5 extend this with new ways to convey the heading hierarchy to the user.

  6. Nathanael:

    That looks like a fine way of marking up the document per HTML 5. The idea is that one can use <h1>-<h6> in the usual way for compatibility with tools that expect those elements, and move to just using <h1> incrementally as older tools are replaced with newer ones that have support for the HTML 5 <section> semantics.

  7. People don’t care about readability of code. They care about a website looks in their browser.

    Developers in general don’t care about whether section is different from div or not. They care whether they can create a visually appealing layout without all the insane amounts of hackery they require to do now and in the forseeable future.

    And WHATWG and W3C seem to be totally out of touch with reality…

  8. Dmitrii:

    Constructive criticism is very much welcome, but I’m not sure what to take from your comments. If you have specific things that you thing could be improved in HTML 5 please speak up. The whatwg or public-html mailing lists are the most obvious avenues for feedback, but you can also make use of the WHATWG forums. Or blog your thoughts. Here even (this blog is open to everyone, although only administrators can actually hit “publish” to protect from spam). Alternatively come and join #whatwg on freenode irc and chat about the changes that you would like.

    It sounds like your problem might be more to do with CSS than HTML and to some extent I agree that CSS is both optimized for the wrong problem (it deals better with document layout than the kind of document-application hybrid layout that is common on the web) and not as open to external influence as I would like. But even then you can post to www-style to engage the working group members.

  9. So do you encourage a full set of subheadings within sections, or do you encourage one heading per section (and lots of sections)?

    My opinion is still that a generic section element really only makes sense if you also include a generic heading element.

    I really don’t follow the WG’s logic that it’s acceptable to create a whole new system that requires a whole new outline algorithm to be useful… then suddenly insist on using a stack of H1 elements that won’t degrade to a meaning that’s anything like the new outline.

    To put it another way, an HTML4 UA will still get something significantly semantically different from an HTML5 UA. Backwards compatibility is not served, all this approach does is remove the most obvious implementation benefit of the section element.

  10. IF you care about HTML 4 UAs you can always use <h1>-<h6> instead of, or in combination with, <section> et. al. It is only when there is wide support for HTML 5 semantics that using <section> with <h1> alone is appropriate. I should have made this more clear in the article.

    Adding an additionnal <h> element wouldn’t have made this transition any easier, indeed it would have made it harder since we would have to have the same algorithm as today but with a <h> element that has exactly the same semantics as <h1> but is not recognised as a heading in any existing UAs. Since many sites that use headings at all use them badly, it is likely that having headings that are present but appear to all be at the same level is a better back-compat. story than having no headings recognized at all in legacy UAs.

  11. “but with a element that has exactly the same semantics as ”

    No, ‘h1’ implies that the use of further headings within the section would be appropriate. The correct use would be a one to one relationship between ‘h’ and ‘section’. The continued allowance of h1…h6 is really a leftover from previous versions of HTML which is being embraced by people who don’t look forward to semantically outlining their documents properly with nested ‘section’ tags.

    If you leave in h1…h6, then you leave in a confusing tool for people who don’t choose semantics and are already bucking the system. If you leave out ‘h’, then you remove the only tool that symantically makes sense, pretty much destroying an otherwise elegant system for semantically defining parts of a document.

    If that doesn’t make sense to you, think of it like this: we want HTML and CSS to provide very fundamental building blocks with which we can build anything. Limiting us to h1…h6 means there’s a limitation. Instead of allowing the number to grow to infinity, look at every other html element: they don’t have numbers, why in the world would it make sense to keep numbers in heading tags? Why should heading tags have numbers if we don’t do li1…li6 within ol tags?

    Seriously, I can’t stress enough how this completely shatters what otherwise is shaping up to me a very semantic, very usable, very understandable version of HTML.

  12. […] HTML5 has started to see real use in the wild, but unfortunately there’s already some misunderstandings concerning some parts of the draft – most notably the <section> element. People seem to have missed the purpose of this element – it is not just a “semantic <div>”. […]

  13. Everyone seems to be looking at this is way too black-and-white. My interpretation is that <section> merely allows better organization of content.

    Most commonly the <h1> element is reserved for the page title, but consider scenarios such as a blog homepage with several posts on one page. Semantically, each is a separate entity unified only by existing on the same site. Using <section>, each post title could be an <h1>, which is more semantically correct. (<article> should actually be used rather than <section>, probably, but I wanted to make a point).

    However, you don’t *have* to use <section> with every new heading. Each section, obviously could use all six levels of headings.

  14. They added section article footer…I would have expected a tag like for main content. It is the one thing all pages on the internet have, no matter how many sidebars, footer, columns…etc. This would have allowed us to give up the [a href=”#content”]Skip to content[/a] thing…And it sure is semantic

  15. @Dave I can’t agree u more.

    Use so many H1 make me puzzled, shouldn’t we keep the principle that One Page One H1, which also should be same with Title tag.