The <section> tag is among the most misused of all the new HTML5 elements.
I blame it on the name.
A section, it would seem, is just that: a discrete piece of content. The official specification provides corroborating evidence:
“The section element represents a generic section of a document or application.”
That sounds like a chunk of content. An awful lot like a <div>.
But wait, there’s more!
“A section, in this context, is a thematic grouping of content, typically with a heading.”
The spec goes on to provide examples, including chapters in a book (or long paper) and tabbed content within a set of tabs.
And that takes us to the critical difference between <div> and <section>. The former is a generic container, the contents of which may or may not be semantically similar. Its purpose is to impose structure, not add meaning.
A <section>, on the other hand, is a group of thematically-similar content. It adds structure and meaning.
Don’t be fooled. Sections do replace divs, but only in some contexts. Let’s see what Mozilla has to say about this:
“HTML5 removes the need for <div> elements from the outlining algorithm by introducing a new element, <section>, the HTML Section Element.”
In haste, we might surmise from this statement that we should replace all our <div> tags with <section> tags. But that means glossing over a critical phrase:
“from the outlining algorithm.”
In other words, <section> replaces <div> when we’re we’re establishing a “thematic grouping” based on the substance of the content, not just when we want to designate a region of a page to receive certain styling or positioning values.
Can we nest sections within one another? Absolutely. In fact, if you’re nesting sections, you’re probably using the element exactly as it’s intended, because you’re clarifying the outline of your document. Just like a book or term paper might have headings, sub headings, tertiary headings, and so on, so too might content on your pages. We could express this using, say, just a combination of <h*> and <p> tags. Or, we could add sections to this mix:
<h1>The Title of the Document</h1> <section> <h2>Chapter 1</h2> <p>One of many graphs</> <section> <h3>Part 1</h3> <p>Good things here,</p> </section> <section> And here. </section> </section>
What have we gained by adding sections? For one, we’ve made the structure of our document more concrete.
Another, less obvious advantage is more flexibility in how (and if) we implement headings.
A section may not have an explicit heading, but it probably will. At the very least, it should always feel natural to put a descriptive heading on a section, even if you don’t end up using one.
There’s something else important to know about how sections handle headings and nesting.
Here’s how Nicole Sullivan puts it:
The section element essentially reorders the heading tree so that whatever headings are used, if they are wrapped in a section element, they will be made to fit in with other content on the page. They need only be internally consistent within each section.
Let’s take a second look at the previous example. This time, we’ll make use of the section element’s ability to define our document outline:
<h1>The Title of the Document</h1> <section> <h1>Chapter 1</h1> <p>One of many graphs</> <section> <h1>Part 1</h1> <p>Good things here,</p> </section> <section> <h1>Part 2</h1> And here. </section> </section>
The difference is evident. Rather than specifying three heading levels, we can use <h1> all the way through. The relative importance of the headings is established by the structure provided by the <section> tags.
As the good (HTML5) doctor says, “<section> is not a wrapper.” If you find yourself adding a section so you can do something with CSS or jQuery, stop. You probably want a <div> instead.
If you’re not sure whether a <section> is the right tag in a given context, consider the following…
- Is the content you’re wrapping conceptually similar?
- Could you add an inclusive heading to describe it? This could be an <h*> element or a <header>.
- Will you be adding more than one section within a sequence? The spec doesn’t require this, but, in the light of the examples (chapters, tabs), it stands to reason that a section works best when it’s one of a set.
- Will you be adding the section(s) within an article? This isn’t necessary, but it makes sense that some articles will be long and benefit from multiple sections.
So, what about this pattern…
<body> <header></header> <section></section> <footer></footer> </body>
We don’t have enough context to know whether this is semantically correct, but there are some pointed questions we need to answer:
- Is all the content within the <section> semantically similar?
- Does the section have a heading? If not, is there at least a reasonable heading value we could use if we wanted to?
- Do we truly need just the one <section> tag, or do we need several?
- Are we not planning to put a class or ID on the section and use it primarily as a styling tool?
These questions are another way of asking “do we really want a <section> here, or would we be better off with a <div>?”
Bottom line: A well-structured HTML5 page will likely employ both sections and divs, along with articles, asides and the other new semantic elements.
It’s tempting to use <section> as a catch-all when other, more descriptive tags won’t work, but it’s designed to serve a more precise purpose.