Structural SemanticsThe Importance Of HTML5 Sectioning Elements

Advertisement

Whatever you call them — blocks, boxes, areas, regions — we’ve been dividing our Web pages into visible sections for well over a decade. The problem is, we’ve never had the right tools to do so. While our interfaces look all the world like grids, the underlying structure has been cobbled together from numbered headings and unsemantic helper elements; an unbridled stream of content at odds with its own box-like appearance.

Because we can make our <div>s look but not behave like sections, the experience for assistive technology (AT) users and data-mining software is quite different from the experience enjoyed by those gifted with sight.

Now that HTML5 has finally made sectioning elements1 available, many of us greet them with great reluctance. Why? Partly, because we’re a community which is deceptively resistant to change, but also because of some perceived discrepancies regarding advice in the specification. In truth, the advice is sound and the algorithm for sectioning is actually easier to use than previous implementations. Some developers are just very married to their old workflow, and they think you should be too. There’s no good reason why.

Make no mistake: Sectioning elements help you improve document structure, and they’re in the spec’ to stay. Once and for all, I will be exploring the problems these elements solve, the opportunities they offer and their important but misunderstood contribution to the semantic Web. If you’re unfamiliar with the concept of the “semantic Web,” this video2 is a great introduction.

Making Websites

My introduction to Web design was via a university course module called something like “2.1: Dreamweaver,” and I recall my first website well. I remember my deliberately garish choice of Web-safe3 colors. I remember it looking right only in Netscape Navigator4. Most of all, I remember hours of frustration from tugging at the perimeter of a visual layout tool named “table.” I had no idea at the time that this layout tool represented a type of annotation called an HTML tag. Furthermore, no one told me that this annotation invited my patchwork of primary colors and compressed JPEGs to be computed as a sort of demented Excel spreadsheet. In other words, I had no idea I was doing it wrong.

A Dreamweaver table
*Bites tongue*

The fundamental failure of most graphic, product, architectural, and even urban design is its insistence on serving the God of Looking-Good rather than the God of Being-Good.

– Richard Saul Wurman

Macromedia’s Dreamweaver didn’t make the creation of valid documents impossible, but it was one of a number of emerging GUI editors that pandered to our desire for visual expression more than it encouraged informational clarity. Dreamweaver, and other editors classified under the misnomer “WYSIWYG,” helped transform a standardized information system into a home for graphic design and enabled a legion of insufferable Nathan Barleys5 to flypost the World Wide Web with their vapid eye candy. I was one of many.

Web Standards

By the time I made my first website, the Web standards movement, promoting compliance, uniformity and inclusion, was burgeoning. I just wasn’t aware of it until much later. I didn’t have to be: Agency-based Web design was still mainly graphic design with a reluctant programming department clumsily bolted on. If you’re doubtful of the grip that this culture has had on the World Wide Web, look no further than the fact it took until 2010 (2010!) for us to concede that Web browsers are not really made of paper6.

When I finally became familiar with Web standards and the practice of “doing things right,” it was as someone who still worked primarily as a visual designer. Inevitably, my first forays into standards-based design revolved around mastering “CSS layout,” the practice of visually arranging content without relying on the semantically incorrect <table> element. We’ve held up <div>-based layout as a mark of quality for a number of years now. You might even say that it has become a time-honored rite of passage for graphic designers who are moving into “proper” HTML coding.

As I shall demonstrate, the <div> is the ultimate Graphic Design tool. By affecting only appearance, it licenses poor document structure and overengineered interfaces; all without making your document technically invalid. As such, it sanctions the worst kind of hacks.

The Problem With <div>

Every day, thousands of Web developers invoke the almighty <div> to divide, partition and ring-fence their Web pages’ content. We use the <div> to police content, to prevent disparate chunks of information from collapsing into each other. In truth, the <div> has no such power.

Consider the following example:

Two column layout with sidebar encircled with dark border7

In this basic layout, I have included a body of text and an adjacent “sidebar.” To make it absolutely clear to the reader that the sidebar is tangential and does not belong to the main content, I’ve drawn a fat line around it using the border property. For those of you screaming, “That sidebar heading should be an <h3>!”, I’ll get to that shortly. All of my design decisions (the adjacent position, the border and the reduced font size) are facilitated by CSS alone. So, when I take the CSS away, I get this:

The same layout as before is now one column, no borders8

Not only is switching off CSS the quickest way to make a Web page responsive9, but it’s a great way to see how HTML4 documents (which lack sectioning elements) are actually computed. In this case, our so-called “sidebar” is revealed to be just another raft of information in the linear flow10 of the document.

Why Is This So?

The reason for this is that the <div> is, and always has been, a flow content11 element. No matter how thick the <div>’s borders or how dark its background color, it does not stand apart in the structure of the document. Neither, therefore, does its content. With the CSS removed, the faux sidebar’s heading of “Resources” now seems less a distinct component of the page and more a part of the main content. To a parser or screen reader, it would have seemed this way all along.

For reasons of clarity, let’s look at a further example using a snippet of HTML:

<div class="parent">
   <h2>Heading</h2>
   <p>Some content...</p>
      <div class="child">
         <h2>Another heading</h2>
         <p>Some other content...</p>
      </div>
   </div>

I’ve done something slightly different here by entering the two <div>s into a parent-child relationship: The div.child tag belongs to div.parent. We can certainly make it look that way with CSS, anyway. However, <div>s, to quote the specification, “have no special meaning.” Not only do they not mean anything semantically, but they have no impact on the computable structure of the page (sometimes called the “document outline12”). The <div>s we’ve used may as well be invisible; so, to get a meaningful map of the structure we’ve created, we should remove them completely. That leaves just four elements and reveals the parent-child relationship to be an illusion:

<h2>Heading</h2>
   <p>Some content...</p>
   <h2>Another heading</h2>
   <p>Some other content...</p>

As HTML coders interested in sound structure, we should be interested that the above reduction — which omits all meaningless elements — is what we’ve actually made, and it’s not what we set out to do: By not really belonging to “parent,” “child” has a different contextual status in the document than intended.

Heading Levels Don’t Really Help

It’s popular to believe that replacing the second <h2> with an <h3> would solve our problem. If we did so, we’d get the following, more dynamic outline:

  • A Heading (h2)
    • Another Heading (h3)

This solution certainly seems more purposeful, but is it the right decision? Should the second heading be a subheading within the same topic (an <h3>) or be the introduction of an entirely new topic (an <h2>, as we had in the first place)? Headings alone can only show where a piece of content starts, not where it ends, which makes it difficult to tell what belongs to what. We have to simulate belonging by choosing the correct heading level for the context. Just think about that for a second: We’re defining the content’s structural status by labeling it retroactively. It’s just begging to go wrong.

Lets have a look at the homepage13 of accessibility experts The Paciello Group. Naturally, it’s a highly accessible and pretty well organized site, but could the structure be improved with HTML5 sections? You’ll notice their use of a <div> to collectively wrap the three <h2>s, Software Developers, Website Owners and Mike Paciello. Since the <div> doesn’t computably contain these three blocks, the last <h2> and the following <h3> are allowed to pair off in this relationship:

  • Mike Paciello (h2)
    • Contact Us Now (h3)

Wait … so, “Contact Us Now” is a subtopic belonging to the larger theme of “Mike Paciello”. Can that be right? It certainly doesn’t look this way in the visual layout. It’s worth noting at this point that the <div> which fails to thematically group those three <h2> blocks has a class of class="region". Ironically, if this <div> had been a <section>, some screen readers would consider it a “region”. If a <section> had been used in place of the <div>, the observed relationship would not have emerged: The “region” would be self-contained. The class of “region”, however, is not taken into consideration in any meaningful way and does not affect the structure.

Okay, so that’s a weird one, but the situation only gets more confusing when we start to include items for which headings aren’t really even appropriate. Take this further example:

This layout has an h1, an h2 for content and an h3 sidebar with a footer div at the bottom14

In my HTML4 page, I have an <h1> to introduce the document, an <h2> for the main content and an <h3> to mark the start of my “sidebar” (which is just a wishy-washy <div>, as in previous examples). The page follows long-standing convention by having an untitled div#footer resting at the foot of the document for copyright information and other such necessary evils. (It has to be a <div> in HTML4, because the <footer> tag doesn’t exist yet.) The question is, to which heading does the footer belong?

Whose Footer Is This?

Most of us, based on appearances, would agree that the footer must belong to the document. That is what we’ve learned to expect. To the unsighted, it is a different story: Because there is no new introductory heading between the sidebar <h3> and the footer content, it could be extrapolated that these two components are as one (see image below left). By the same token, one could also argue that we’ve included the “sidebar” as a mere “break” from the flow of the main content, before returning to that flow at the advent of the footer (see image below right). This would make the <h2> the footer’s heading.

Red outlines show different interpretations of structure15

The only decent chance we have of understanding the intended structure of the page is by inferring it from a reading of the content. Remembering that the whole point of a “markup language” is to make the structure of information easier to follow, I may as well have chucked the HTML and written my Web page on the back of a napkin.

Some accessibility gurus would suggest that you use a remedial <h2> to head the #footer and bring it back in line, marking up the end of the sidebar like so:

  • h1 (page)
    • h2 (main)
      • h3 (sidebar)
    • h2 (footer)

This kind of works as a hack, but it’s not really sound. Do you really want to make a big announcement of the footer — an announcement as big and bold as the one used to summon the main content, not to mention bolder than the sidebar? No. If our Web page were a film, the footer wouldn’t be the titles — it would be the credits. In HTML5, the <footer> element16 “contains information about its section.” This is semantically superior: We don’t use footers to introduce topics; we use them to conclude them. Accordingly, footers — unlike their parent sections in HTML5 — do not require headings.

Tweet reads: Marking up lots of headings in a page significantly dilutes a screen reader user's ability to navigate between parts of a page efficiently17
Just because the nesting level of headings is correct doesn’t necessarily make a page easy to read.

The closest thing we have to a “system” for structuring documents properly in HTML4 is numbered headings. Not only does this lead to ambiguity, as explained, but in practice we don’t really even use headings to define structure. We use <div>s to define structure and throw in some apologetic headings for accessibility’s sake. To make matters even worse, advice regarding the deployment of numbered headings18 isn’t even clear on whether we should use them in order (h1-h6) or not.

The loose coupling between headings and <div>s is inadequate. Now, with the introduction of sectioning elements, we still use boxes, of sorts, but boxes that actually say something on their own. We are making a move from merely implying sections (by labeling them) to letting them define themselves. Simultaneously, sighted readers and unsighted parsers can experience content that one has effortlessly divided into clear, manageable portions.

The HTML4 spec is very imprecise on what is a section and how its scope is defined. Automatic generation of outlines is important, especially for assistive technology, that are likely to adapt the way they present information to the users according to the structure of the document. HTML5 removes the need for <div> elements from the outlining algorithm by introducing a new element, <section>, the HTML Section Element.

Sectioning

Aware of our desire for legitimate elements to create computable sections, HTML5 offers <section>, <article>, <aside> and <nav>. Like some sort of obnoxious holiday rep’, I’ll introduce the topic of practical sectioning using these elements with a quick quiz. Study the following diagram. How many sections do you count?

An HTML5 page with header, aside and footer20

Multiple-choice answers:

  1. 1
  2. 2
  3. 3
  4. 4

The correct answer is (b), 2. We have included just one of HTML5’s new sectioning elements in the form of an <aside>. Because <footer>s and <header>s are not sectioning elements, what does that leave us with? The <body> tag is the outermost element, making the document itself a kind of section (a supersection, to be precise). So, there you have it: We’ve been using “sectioning” since HTML 1.0, just not with any subsections to speak of.

Some of you may have missed the clue earlier in this article and thought that <header> and <footer> were sectioning elements. Don’t fret; it’s not your fault. Whenever developers like myself try to explain HTML5 page structure, they usually brandish a diagram like the one I used above. In these diagrams, the boxes marked “header,” “aside” and “footer” exist in the same visual paradigm and occupy a similar area. They seem alike, you might say. The other culprit for this endemic confusion is the way the specification is written. Believe it or not, the document structure of some pages in the specification that refer to document structure is structurally unclear! This sort of thing sometimes happens when a standard is constantly evolving. The navigation tree for “4.4 Sections” found in this draft21 is laid out like so:

  • 4.4 Sections
    • 4.4.1 body
    • 4.4.2 nav
    • 4.4.3 article
    • 4.4.4 aside
    • 4.4.5 h1, h2, h3, h4, h5 and h6
    • 4.4.6 hgroup
    • 4.4.7 header
    • 4.4.8 footer
    • 4.4.9 address

You’d be forgiven for thinking that anything in this list qualifies as a sectioning element, absurd as some of them (<address>?) may sound. It’s only when you navigate to 4.4 Sections > 4.4.8 Footer that you’re told that “the footer element is not sectioning content; it doesn’t introduce a new section.” Thanks!

Despite these ambiguities in the spec’ itself, as well as in the surrounding publicity for HTML5, sectioning in practice just works. The following three axioms are probably all you’ll need to understand the algorithm:

  1. <body> is the first section;
  2. <article>, <section>, <nav> and <aside> make subsections;
  3. Subsections may contain more sections (subsections)

Aside from a few trifling details, that’s it. In a little while I’ll cover the completely unnecessary worry that is had over headings combined with sections. For now, let’s take another look at that example from before about footer ownership. This time, I’ll make a few HTML5 substitutions:

The diagram clearly shows the footer in the context of the document22
Note the lack of illustrated headings. Wherever a section is opened, it assumes responsibility for nesting: The heading type is unimportant. More on this soon …

The outline for this example looks like this:

  • Document
    • Article
      • Aside

Now that we’ve implemented sections, the boundaries are clear. Our document contains an article, which, in turn, contains an aside. There are three sections, each belonging to the last, and the depth of each section is reflected in the outline. Importantly, because sectioning elements wrap their contents, we know perfectly well where they end, as well as where they begin. And yes — screen readers like JAWS actually announce the end of sections like these! We know what content belongs to what, which makes deducing the purpose of the footer much easier. Because it exists outside the bounds of both the <article> and its <aside>, it must be the document’s footer. Here’s the same diagram again, with subsections faded out:

The same diagram with subsections faded out23

The power of sectioning lies in its ability to prescribe clearly defined boundaries, resulting in a more modular document hierarchy. The footer unequivocally belongs within the immediate scope of the highest-level section, giving assistive technologies and indexing parsers a good idea of its scope, which helps to make sense of the page’s overall structure.

Headings And Accessibility

When Sir Tim Berners-Lee conceived the <section> element all the way back in 199124, he envisioned the obsolescence of ranked heading levels. The thrust of the idea was that headings should act as mere labels for blocks of content, and the nature (i.e. the importance, scope, etc.) of the content would be calculated automatically based on the content’s standing in the document.

I would in fact prefer, instead of <h1>, <h2> etc for headings [those come from the AAP DTD] to have a nestable <section>..</section> element, and a generic <h>..</h> which at any level within the sections would produce the required level of heading.

Why is this preferable? Determining heading level systemically, based on nesting level, is much more dependable because it removes a layer of decision-making: By “producing” the required heading level automatically, we no longer have to decide separately which numbered heading we should include. It effectively prevents us from choosing the wrong heading level, which would be bad for parsable structure. A subsection must be subject to its parent section. Because this relationship between sections determines “level,” numbered headings are made redundant — hence, the proposed <h>.

A lot of fuss over nothing

Now, this is the supposedly tricky part; the part that causes all the consternation and gnashing of teeth. This is the part that caused Luke Stevens to write this diatribe26, and prompted Roger Johansson into a state of uncharacteristic apoplexy, asking, “are you confused too?27”. Ready?

In the WHATWG specification (in the same place where <footer>s were ostensibly classified as sectioning elements!), we are “strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.” On first appearance, this seems contrary. Surely only one of these courses of action can possibly be right? What do you do? I’m thinking maybe the first option. Or the second. Who am I?

It certainly confused me, so I spoke with HTML Editor, Ian Hickson. He explained the outline to me in detail and I’m convinced it is perfectly robust. I’m going to do my best to explain it to you here.

Okay. As it turns out, we didn’t get the generic <h> element. This wouldn’t be backwards compatible because older browsers wouldn’t recognise it. However, headings that introduce sections are — regardless of their numbered level — treated as a generic <h>. Quite correctly, it is the section itself that takes responsibility for nesting in these situations — not the heading — and whenever you introduce a new section, you introduce a new nesting level without fail. What does this mean in practice? It means that we can introduce and benefit from the structural clarification offered by sections without abandoning heading levels. Take the following example:

<h4>Page heading</h4>
<p>Introductory paragraph...</p>
<section>
    <h3>Section heading</h3>
    <p>some content...</p>
    <h2>Subheading</h2>
    <p>content following subheading...</p>
    <section>
        <h1>Sub-subheading</h1>
        <p>content two levels deep...</p>
    </section>
</section>
<h5>Another heading</h5>
<p>Continued content...</p>

Our heading levels are all over the place. This is not recommended by the specification, but it helps demonstrate just how robust the HTML5 outlining algorithm really is. If we replace all the headings that open sections with a generic (“wildcard”, if you prefer) <h>, things become clearer:

<h>Page heading</h>
<p>Introductory paragraph...</p>
<section>
    <h>Section heading</h>
    <p>some content...</p>
    <h2>Subheading</h2>
    <p>content following subheading...</p>
    <section>
        <h>Sub-subheading</h>
        <p>content two levels deep...</p>
    </section>
</section>
<h5>Another heading</h5>
<p>Continued content...</p>

It’s important to note that the only errors revealed in the computed outline are ones relating to badly ordered numbered headings within the same section. In the original example, you’ll see that I’ve followed an <h3> with an <h2>. Because they are in the wrong order, the outline interprets them as being on the same level. Had I encapsulated the <h2> in <section>, this error would have been suppressed.

Well, how about that? If you’re not convinced, go ahead and paste my example into the test outliner28 and play around. It works just fine. In fact, it’s really difficult to break.

If you think there is a benefit to screen reader users, you may wish to adhere to the second of the two clauses from the specification and incorporate numbered headings that reflect nesting level. As demonstrated, this will have no effect on the outline, but since heading level (“Heading Level 2 – The Importance Of Sections”) is announced, it gives a clearer impression of structure to those who can’t see boxes inside boxes.

The assertation that heading levels are perpetually indispensable to screen reader users comes under pressure when you consider advancements being made by screen reader vendors. Screen readers like JAWS mark the territory of sections more clearly than headings, by announcing the beginnings and ends of sections and the thematic regions they represent (“Article End!”). From this perspective, using more than one <h1>s in your document might sometimes be applicable. You’ll come up against some accessibility experts who are keen on their “there can only be one [h1]!” mantra, but research shows29 that even in HTML4 or XHTML, this is not necessarily the case.

The approach you choose is yours to make; just employ some common sense and consistency. Bear in mind, though, that not all screen readers are able to announce the bounds of sectioned content. In these cases, there are measures you can take …

ARIA Enhancement

Transition to an HTML5 document structure is made smoother by incorporating some ARIA landmark roles30, which are both relatively well supported31 and somewhat analogous to the section-based navigation we should expect later. ARIA offers many more accessibility-specific features than baseline HTML5 could ever withstand; so, including “bolt-on” ARIA enhancements is certainly polite32. However, regarding ARIA roles as a substitute for semantic HTML would be a grave misconception.

Landmark roles, such as role="contentinfo" and role="banner", address accessibility only — not data mining — and each may be used only once per document. They are essentially shortcuts to parts of the page. HTML elements are more like building blocks, which are used in a repeated and modular fashion. So, while you can assist accessibility by placing role=”banner” into the <header> element closest to the document’s root, this does not preclude you from using <header> to introduce other sections:

The banner landmark role is used just once33

Are Sections The New <div>s?

This is a common misconception.

If it wasn’t clear already, it should be clear to you now that <div>s are semantically inert elements — elements that don’t really do or say anything. If this is clear, then it should also be clear that, when building a structured document, relying heavily on “an element of last resort34” makes for a very poor foundation.

If the new <section> element, for example, was just <div> with a new name, adopting it would be a straightforward matter of search and replace. It wouldn’t exactly be progress, though. The truth is, <div> still has a rightful place in the spec’; we’ve just given its organizational responsibilities to a team of elements that are better qualified. Sorry, <div>, old mate. What do we use <div>s for, then? Precisely what they were good at from the beginning: as a tool for “stylistic applications… when extant meaningful elements have exhausted their purpose35.”

For instance, you shouldn’t employ sections as box-model36 controlling measures like this…

<section class="outer">
      <section class="inner">
         <h1>Section title</h1>
      </section>
   </section>

… because there’s nothing that the outer section does that the inner section doesn’t. We’ve created two sections for one piece of content. A quick run through our outliner37 throws the “Untitled Section” warning:

  • [Untitled Section]
    • Section title

The brilliance of <div> in this context is that it refuses to affect the outline, which is why we can use it without fear of reprisal. This…

<section>
      <div>
         <h1&gtSection title</h1>
      </div>
   </section>

… averts disaster38 and results in this unsullied, if simplistic, outline:

  • Section title

Sections And Semantics

A lot of developers have trouble with the word “semantic.” You might even say that they don’t know what the word means, which (if you are familiar with the term) makes an interesting paradox. For instance, when Jeffrey Zeldman advocates39 for the “semantic” application of the id attribute, he’s kind of missing the point. The main purpose of semantic HTML is for the automated extraction of meaning from content. Applying a private, non-standard id to a <div> would not improve the semantics of the element one iota: Visitors can’t see it and parsers will ignore it. So much for the semantic Web40!

Sections are often characterized as the “semantic” equivalent of <div>. This is a half-truth at best, and I apologize for throwing the term “semantic” around so much — it’s become a bit of a shorthand. Some HTML elements are inherently semantic in that they prescribe specific meaning to their contents. The <address> element is a good example: When a parser reaches <address>, it knows that the contents should probably be interpreted as contact information. What it chooses to do with this knowledge is another matter, but it’s plausible that a screen reader could provide a shortcut to the address or a search engine could use it to refine its results pages.

Definition of syntax from Google search: The arrangement of words and phrases to create well-formed sentences in a language41

Sectioning elements are not so much semantic as syntactic. All <section> tells us is that it is a part of a whole. However, the syntactic contribution of sectioning elements to document structure is not unimportant. Consider the following sentence: If sections you don’t websites your are use obsolete. A lot of recognizable words are in there, but the lack of sensible syntax makes the sentence difficult to unpick. So it is with sectioning: You are not creating meaning so much as assembling it. Meaning isn’t always about the “thing”; it’s sometimes about what that thing’s role is amongst other things.

Microdata

Efficient, syntactically sound data structures are worthless if they are semantically lacking. Fortunately, HTML5 has both angles covered and provides a mechanism for attaching semantic meta data42, called “microdata43,” to our structured content. Using microdata, and by consulting schema.org44, you can define a page’s content as anything from a scholarly article to an exercise regimen. Unlike classes and IDs, this is information that can actually be interpreted usefully.

Google's structured data dashboard45
This microdata was found by Google and displayed in its “Structured Data Dashboard” for the WordPress theme Typical46.

Conclusion

HTML isn’t just an SDK or a Graphic Designer’s palette. It is a metalanguage, a language that tells you special information about information. Sometimes we — or, more precisely, the parsers we employ — benefit from added information about the subject, timing, origin or popularity of content. This is what APIs such as microdata and RDFa are for. Other times, the context, hierarchy, relative importance and codependence of the information are what need to be determined. This is where appropriate syntax, facilitated by sectioning elements, can be employed.

Some people will tell you not to bother with sectioning. They say that it’s hard work or that it doesn’t make sense. This is hokum. Sure, if you’re lazy, don’t bother with sectioning, but don’t pretend you’re doing it on principle. Using sections demonstrably enhances HTML structure without breaking accessibility. We’ve covered this.

Still, there will always be people who will attack this aspect of the specification. Perhaps we’ll enjoy some of these objections in the comments:

  1. They will point to bad implementations by specific vendors:
    These are bugs and bugs get fixed!
  2. They will cite the actions of large websites who don’t use sectioning elements:
    Just because large sites haven’t implemented sections doesn’t mean they wouldn’t like to. Since when does big mean ‘right’ anyway?
  3. They will flood you with examples of developers implementing sections badly:
    Some developers do stupid things and their misuse of HTML doesn’t stop at sections. I include myself here, by the way.
  4. They will present you with anecdotal evidence about user behavior within specific groups:
    It is expensive and impractical to address problems on a case-by-case basis. Fragmentation and complexity would also be inevitable: a loss for the majority of users.

I don’t think anyone would advocate making badly structured Web documents any more than they’d suggest building a house by stuffing a bag full of bricks and throwing it into a ravine. The case has been made and the specification bears it out: Sections aren’t just good for document structure — they finally make proper structure attainable. Some browsers and screen readers have some catching up to do, that’s for sure, but the situation is improving rapidly. Any kind of change is a little turbulent, but this kind is worth it.

Footnotes

  1. 1 http://www.w3.org/WAI/GL/wiki/Using_HTML5_section_elements
  2. 2 http://www.youtube.com/watch?gl=GB&hl=en-GB&v=OGg8A2zfWKg
  3. 3 http://en.wikipedia.org/wiki/Web_colors#Web-safe_colors
  4. 4 http://en.wikipedia.org/wiki/Netscape_Navigator
  5. 5 https://www.youtube.com/watch?v=ONaa4HxD-48&playnext=1&list=PL10DC9ABD97ED9957&feature=results_video
  6. 6 http://www.alistapart.com/articles/responsive-web-design/
  7. 7 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/drawing1/
  8. 8 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/drawing2/
  9. 9 http://www.smashingmagazine.com/tag/responsive-web-design/
  10. 10 http://webdesign.tutsplus.com/tutorials/htmlcss-tutorials/quick-tip-utilizing-normal-document-flow/
  11. 11 http://www.w3.org/TR/2011/WD-html5-20110525/content-models.html#flow-content-0
  12. 12 http://html5doctor.com/outlines/
  13. 13 http://paciellogroup.com/
  14. 14 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/drawing3/
  15. 15 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/leftandright-2/
  16. 16 http://dev.w3.org/html5/markup/footer.html
  17. 17 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/tweet/
  18. 18 http://www.w3.org/TR/WCAG-TECHS/H42.html
  19. 19 https://developer.mozilla.org/en-US/docs/Sections_and_Outlines_of_an_HTML5_document
  20. 20 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/sectioning1/
  21. 21 http://www.w3.org/TR/2011/WD-html5-20110525/sections.html
  22. 22 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/sectioning2/
  23. 23 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/sectioning3/
  24. 24 http://1997.webhistory.org/www.lists/www-talk.1991/0003.html
  25. 25 http://1997.webhistory.org/www.lists/www-talk.1991/0003.html
  26. 26 http://www.netmagazine.com/features/truth-about-structuring-html5-page
  27. 27 http://www.456bereastreet.com/archive/201103/html5_sectioning_elements_headings_and_document_outlines/
  28. 28 http://gsnedders.html5.org/outliner/
  29. 29 http://webaim.org/projects/screenreadersurvey3/#headings
  30. 30 http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/
  31. 31 http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-aria-landmark-support/
  32. 32 http://www.456bereastreet.com/archive/201004/built-in_or_bolt-on_accessibility_in_html5_how_about_a_bit_of_both/
  33. 33 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/banner/
  34. 34 http://www.w3.org/wiki/HTML/Elements/div
  35. 35 http://en.wikipedia.org/wiki/Span_and_div
  36. 36 http://www.w3.org/TR/CSS2/box.html
  37. 37 http://gsnedders.html5.org/outliner/
  38. 38 https://twitter.com/jvhellemond/status/257850976478842880
  39. 39 http://www.zeldman.com/2012/11/21/in-defense-of-descendant-selectors-and-id-elements/
  40. 40 http://en.wikipedia.org/wiki/Semantic_Web
  41. 41 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/syntax/
  42. 42 http://en.wikipedia.org/wiki/Metadata
  43. 43 http://googlewebmastercentral.blogspot.co.uk/2012/07/introducing-structured-data-dashboard.html
  44. 44 http://schema.org/docs/full.html
  45. 45 http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/typical/
  46. 46 http://typical-theme.heydonworks.com

↑ Back to topShare on Twitter

Heydon has a love/hate relationship with CSS and a lust/indifference relationship with javascript. He writes a lot and makes fonts.

Advertising
  1. 1

    Thank you for the detailed explanation! :-)

    0
  2. 2

    In the end, any structural semantics are only as relevant as their use. The problem is that the manner in which they were developed, and the clarity of the spec, are both very lacking. We can’t all ask Ian Hickson for clarification when his spec fails to answer the question.

    Here’s an eye-opening recent critique of the process that created sectioning in the first place:
    http://www.webdesignerdepot.com/2013/01/the-harsh-truth-about-html5s-structural-semantics-part-1/

    0
    • 3

      The manner in which sectioning elements were developed is not a “problem”. It is an anecdote. The many and variant ways in which natural languages develop cannot possibly be accounted for in their entirety and yet, here we are, communicating perfectly well.

      I read Luke’s article and alluded to it here. Whilst it is a fun read, it is highly emotive and focuses on the culture and attitudes surrounding this part of the specification. It is a critique of the process, not the resulting product. I’m not interested in the history but the application so I have, instead, focused on the intrinsic qualities of these elements and their impact on HTML. I think Smashing readers deserve such an explanation.

      I’m sure Hixie would not like to be inundated with questions from every developer in the world, which is why I approached him on your behalf. Cheers!

      0
      • 4

        But isn’t the process used as rationale for the nature of the product? The intrinsic qualities of these elements are dependent upon their regular and uniform usage, which was meant to be a natural outcome from ‘paving the cowpaths’. It was supposed to say what we were all already thinking.

        In reality, as a developer, I find it challenging and frustrating to read the docs and determine what that usage is. Without more clarity, I’m not confident that we’ll see any sort of widespread uniform usage. I love the concept of sectioning, but I’ve been discouraged by the confusing nature of the details. For me, the feeling is reinforced by the fact that an article of this detail required explanation by the editor outside the spec itself.

        0
        • 5

          I like the way these elements are specified, so we can’t all have been thinking the same thing. QED.

          It is indeed a shame that I had to write such a long article and consult Hixie to explain sectioning elements, but this is grounds for changing advise in the spec’ not the technical specification, surely?

          0
  3. 6

    Finally, a great article about sections. You’ve beaten W3C and HTML5Doctor. Thanks!

    0
  4. 7

    Looking forward to the mud wrestling on this one. I am as confused as ever, and not from a lack of clarity or eloquence on the writer’s part!

    0
    • 8

      Mud wrestling? What about foxy boxing?

      On a serious note, I’d be delighted to try and field any questions about it here.

      0
  5. 9

    Information has long overtaken natural selection as the driving force behind humanity’s continued survival. As this data that we rely on for our continued existence grows, we need it to be ever more structured, so that it may indeed be understood by the many – necessarily automated – processes for storing, sorting, and retrieving it. Beyond dubious use case studies and fashionable trends, it is the reader of the future that requires access to this information, and it’s more likely to be a machine than a human.

    So I guess my point is follow Mr Pickering’s advice, and mark up your stuff properly! :)

    0
    • 10

      Thanks for the – rather poetic – reply, Frank! You put it better than I did, and you’re right:

      It is the necessary involvement of automated parsers (which include AT-related interpreters) for which HTML and other metadata languages were conceived in the first place.

      Without structure, the Web isn’t the Web; it’s the Lump. This is as true for the relationships within documents as it is between them.

      0
  6. 11

    Thank you. This is by far the clearest explanation I have read for the purpose of the section element. Perhaps the biggest reaction to it is from those who have never bothered with trying to make their webpages accessible in the past… why would they start now?

    0
  7. 12

    The link to “ARIA landmark roles” in the first paragraph under the “ARIA ENHANCEMENT” header is broken.

    There is a space between the “-” and “roles” at the end of the link:

    http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark- roles/

    Other than that, a great read,

    Thanks :)

    0
  8. 14

    Wow, thanks for explaining.

    0
  9. 15

    In the section of your article on ARIA enhancements, you wrote “Landmark roles, such as role=”navigation” and role=”banner”, address accessibility only — not data mining — and each may be used only once per document.”

    However, my understanding from the W3C Role Model is that certain landmark roles can be used more than once. While the banner role definition states “Within any document or application, the author SHOULD mark no more than one element with the banner role,” the navigation role definition mentions no similar limitations.

    Overall, I really enjoyed your article. Thanks for the read!

    0
    • 16

      You’re right, Charlotte. I meant to say role=”contentinfo” and have amended the article accordingly. You may have more than one navigation block.

      0
  10. 17

    Nice article with lots of food for thought, thank you. I’m interested in sections and microdata within wordpress (combined with custom post-types and shortcodes) as reusable blocks of content. If we are future-proofing our sites, I think we should be boxing everything up neatly, so that articles can be sent to readers without taking the nav sections along with them, and so that contact cards and address sections can be sent to their own apps to parse without the article that was written.

    Nice!

    0
  11. 19

    http://gsnedders.html5.org/outliner/

    That tool will definitely come in handy – I ran a few of my websites through it and saw that I have much work to do in improving the sectioning.

    0
  12. 21

    Great explanation about sections. Website authoring conventions are important, and more of our kind should take them more to heart.

    0
  13. 22

    How come you guys don’t have share buttons on the articles?

    0
  14. 23

    Having read the multitude of very high level debates and arguments on this subject, and others akin to it, from both sides of the aisle I am ultimately left with the conclusion that in the grand scheme of things none of it really matters.

    Of all of the pages that exist on the world wide web probably fewer than 10% are actually built with the degree of uber-finess that is championed within these ‘academic circles’.

    I guess it’s all just analogous to university language courses and the relationship they have with people speaking in the street. None.

    We get up. We go to work. We design. We code. We try to do it well but when all said and done it has very little impact on the natural order of things. People build rubbish things and make lots of money. People build amazing things and make very little. People know very little and make a lot of noise. People know a great deal and are barely heard.

    That’s not to suggest that the inspired and enlightened do not deserve their platform, nor that their wisdom ultimately drives standards and marks the cutting edge but with something as richly complex and nuanced as design and language when all said and done there is no one right and no one wrong. It’s all just opinion of which there will always be a difference.

    0
  15. 24

    Where has this article been all my career?

    Thank you for clearing up the questions I’ve been having since HTML5 became a thing. We will be referencing this heavily in all the sites we build in the future.

    0
  16. 26

    Long story, short : Read the docs and learn from them. There’s no excuse for not reading the documentation. You can watch all the video-tutorials in the world and read every blog post on the Interwebs, nothing can explain a language/technology more accurate than it’s own documentation (except for the case in which the product and the documentation belongs/was written by Microsoft). Secondly, get your study-shoes on and start learning about ARIA ROLES. The rest, comes from passion, motivation, ambition and such !

    Great article, really well structured!

    0
  17. 28

    Great read. I recently converted a site from meaningless divs to proper sectioning elements. I ran into a bit of confusion regarding the importance (or lack of importance) of heading elements inside of section elements. It just didn’t feel “right” to go back to h1 in a new section, but your explanation makes it very clear why this is, in fact, correct. Thanks also for explaining that header and footer are not, in fact, sectioning elements but rather contextually relative to their parent element. That clarifies why they can be used again and again in sections.

    The fact that all screen readers do not yet understand sectioning elements yet is really not important if we are coding for the web that is emerging rather than the one that is dying. I know there are some out there who think code should work for every conceivable user environment, but this is exactly the fallacy that sectioning elements correct.

    Also, a big thanks for the link to HTML 5 Outliner. That will help streamline the process in future projects.

    0
  18. 29

    Heydon, do you know of any real site examples where these HTML5 elements are being done well? I saw your wordpress theme, but I’d love to see sites with lots of real data they organized . ..

    0
  19. 31

    You have written:

    Multiple-choice answers:
    a. 1
    b. 2
    c. 3
    d. 4
    The correct answer is (a), 2.
    a -> 1 ? Or 2?

    0
    • 32

      Sorry for the confusion, Alessandro. The answer is (b), 2. The proof reader misunderstood the question and changed it to (a) 1 because they thought I was only counting sectioning elements, not sections, which implicitly includes <body> as I go on to point out.

      Not the proof reader’s fault – it was a trick question!

      0
  20. 33

    Good article. One thing that I do find perplexing that I would love to hear your thoughts on, is the nav element. The nav element is defined as a section, and section elements sort of require a heading. Without an h tag you get an “untitled section” error. Typical usage of the nav element consists of an unordered list of links, and nothing more. An h tag or any labeling of the nav section doesn’t seem appropriate.

    0
    • 34

      My very long reply to Justin explains my position on untitled sections (I’m all for them in some circumstances).

      As for <nav>, I agree. The only reasonable case for deploying a heading in this case is for the benefit of screen reader users, which essentially make use of the heading as a label. For the same benefit you could use an actual label (via the aria-label attribute https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute).

      IMHO, headings for nav blocks are, like headings for footers, not a semantically good choice and only necessary for AT where aria-label="main navigation" would not be read.

      0
      • 35

        “…like headings for footers, not a semantically good…”
        How would you markup the headings of lists, that are used in big footers?

        Example from smashingmagazine.com:
        div id=”footer”
        h4Best of Design/h4
        ul

        0
  21. 36

    Thanks for the excellent explanation of sectioning.

    It cannot be stressed enough how important accessibility is becoming, and its interrelation with SEO.

    To follow onto Evan Payne’s comments, it is of paramount importance to incorporate this into CMS-driven sites, especially where many creators are involved.

    With the shift of more information to the Web, content strategy is essential–and where a good gameplan will go a long way to keeping things in a coherent structure…

    0
  22. 37

    Great article. One of the best I’ve seen in explaining the section tag.

    0
  23. 38

    Great article! I found this very informative and useful. Thanks!

    0
  24. 39

    One thing that really got under my skin while reading this article and seeing the outline for my own sites is the presence of an untitled section in an outline when you use .

    What do you do about this? It feels like adding a heading is pointless when you just used a semantic element to indicate the navigation. Or am I looking at this the wrong way?

    0
    • 40

      Good question, Justin.

      Steve Faulkner and others recently had a discussion to determine the efficacy of untitled sections at WHATWG. The example Steve used is for nested <article>s representing comments and comment replies at the end of a blog post.

      In my humble opinion, untitled <article>s are a great candidate for this markup task and I’ll tell you why:

      1) <article>s represent self-contained, independent pieces of content. This is apt in this case because comments are by independent authors.

      2) If someone writes a comment and someone replies to that comment, you might say that the reply comment is subject to the original. If the original commenter then replies again, you could say that this comment was subject to the 2 comments that that together preceded it. This structure starts to emerge:

      Untitled
          Untitled
              Untitled
      

      The beauty of using a sectioning element for this task is that a structure that is representative of the exchange that took place is possible without the use of headings which, as you point out, would not be appropriate (we don’t announce our presence everytime we contribute to a conversation!)

      When I was originally shown the example — which featured a conversation seven levels deep — I described this use of articles as “imbecilic”. Little did I know that the example was by Hixie, who made most of the HTML is the spec’ (!) Without doubt, Hixie knows precisely what he is doing, which is why I investigated further.

      Ultimately, it is only the subject of the original demo conversation — about narwhals eating bacon — that is silly. The deployment of nested sections does a good job of representing that exchange regardless.

      One last thing: A screen reader user that I talked to mentioned the irritating “noise” produced by hearing so many <article> beginnings and ends in this unusual case. I pointed out that, in my humble opinion, the experience of reading a long comment steam containing lots of overlapping conversations was a fragmented and “noisy” UX for sighted users so it should be the same for AT users. The <article>, by helping to better represent the jarring exchange, gives AT users “access” to the same (albeit unpleasant!) experience.

      For my feelings on “nav”, please see my reply to Jeff (I think no heading is applicable if you use aria-label in its place).

      0
      • 41

        @Heydon

        “One last thing: A screen reader user that I talked to mentioned the irritating “noise” produced by hearing so many beginnings and ends in this
        unusual case. I pointed out that, in my humble opinion, the experience of reading a long comment steam containing lots of overlapping conversations was
        a fragmented and “noisy” UX for sighted users so it should be the same for AT users. The , by helping to better represent the jarring exchange,
        gives AT users “access” to the same (albeit unpleasant!) experience.”

        I’m not sure I follow your logic. Are you saying that the experience of reading a thread of comments wrapped in article elements is equivalent to listening to the same thread? If so, how does the visual representation equate to the audio experience of hearing “Article start. Comment content. Article end.” over and over again?

        Your comment also seems to imply that a jarring experience is ok for anyone, providing the underlying semantics make sense. Hopefully I’ve misunderstood you here, but in case I haven’t – shouldn’t the tools we use to create UIs support good experiences?

        Questions aside, this was a useful article on a worthwhile topic. Thanks

        0
        • 42

          Thank you for your well-put questions, Léonie.

          To be clear, I don’t think that seeing and hearing websites is ever “equivalent”, unfortunately. If web pages were uniformly designed to look like the documents that they are underneath, then there would be some parity, but this is rarely the case.

          I was trying to make the point that multiple <article>s used to mark up multiple comments was not any less representative than one <article> used to markup just one comment: The tedium of the experience derives from the number of comments, not the way they are marked up. If we were to agree that <article> is suitable for one comment, then it must follow that it is suitable for each comment.

          I think that a jarring experience is okay for an AT user if – and only if – it is an unavoidably jarring experience for any other user. To read a conversation being had by two other people in a comment stream is never likely to be particularly edifying for anyone. Good structural semantics are about approximating relationships. The internal relationships of a conversation had in a crowded room are destined to be jarring and the use of <article> goes some way to approximate this. Any attempt at smoothing the edges of this exchange by employing unsemantic (unannounced) elements would be a deception.

          Thank you for reading.

          0
  25. 43

    @heydon

    I think this is a good explanation of the potential benefits of sections and the document outline if used correctly.

    I say ‘potential’ as no browser currently implements the outline algorithm or has shown an interest in doing so, which is why the outline algorithm is a feature at risk in HTML5. Until browser implement something it is nothing more than a fiction, unfortunately.

    I don’t see a good argument for the need for both section and article in this article.

    I also suggest that the outline algorithm, and the definitions of section and article are not fully baked yet and in need of some course correction in HTML 5.1.

    I find your statement, somewhat distasteful and shows a lack of understanding of the user experience for screen reader users.:

    the experience of reading a long comment steam containing lots of overlapping conversations was a fragmented and “noisy” UX for sighted users so it should be the same for AT users. The , by helping to better represent the jarring exchange, gives AT users “access” to the same (albeit unpleasant!) experience.

    This article and luke stevens article are opposite ends of a spectrum, I believe the truth lies somewhere in between and as such the authoring advice and requirments for new structural elements require further work, based on data gathered from real world usage, users and authors. HTML is a work in progress, so keep an eye on HTML 5.1!

    0
    • 44

      Thank you for your comment, Steve.

      When advocating for sectioning elements I’m often met with the objection (perhaps objection is too strong a word) that browsers have not “implemented” the outline algorithm. Perhaps you could explain what you mean by “implement”? Browsers such as Firefox are aware of section nesting, as evidenced by the way they introduce different font sizes to headings dependent on nesting level (http://jsbin.com/ijixib).

      I think that lack of current browser implementation is a bit of a red herring. As with any language construct, the outline exists as an agreement between those who choose to employ it, whoever or whatever they are. This agreement ensures better uniformity and should improve indexing and scraping tasks as well as maintenance and interoperability. The web browser, which is used merely to display discrete instances of information, is only one side of one coin. Any number of tools might be employed to preprocess and process HTML – tools to which browsers can remain largely agnostic or which work independently from browsers. The outline itself isn’t a fiction any more that the definition of the word “outline” is a fiction. It’s just abstract.

      On to my “distasteful” comment:

      As Steve Buell points out, the use of the article element does not make the experience magically alike between user types and I agree. However, we have to accept that differences between the visual and aural can never be precisely reconciled. I personally think that <article>s are more accurate than <div>s, even where correctly numbered headings are employed. Using <div>s would be fundamentally less verbose in a medium where verbosity is paramount. Less verbosity means less information as well as less information about that information. Am I really demonstrating a lack of understanding here? If I am, then it is not through ill intention. I think “distasteful” is rather unfair.

      I quite agree that there’s a lot of work to do in terms of refining the way sectioning elements are specified and explained. I’m not sure Luke’s unsolicited manadate that we should all simply stop using them because they’re “dead” (whatever that means) is particularly constructive.

      0
      • 45

        The implementation you speak of is merely a set of presentational suggestions for user agent CSS styles rules, which a conforming HTML5 user agent can happily ignore. A meaningful implementation that conveys semantics would be if the representation of headings in the DOM and/or accessibility tree were modified based on section nesting or the outline algorithm was implemented and the resulting outline exposed. Currently there is no implementation of such semantic information and as previously stated no implementers have shown any interest in doing so. Nothing meaningful can be robustly inferred by size of text alone. The section element as currently defined maps to a role region, this does not connote any of the required meaning for accessibility support of the outline algorithm. What would be required is properties that indicate level and setsize.

        0
        • 46

          What would be required is properties that indicate level and setsize.

          Surely these qualities could be inferred by nesting depth and attached to the sections automatically. If so, it’s something I’d love to see happen! As authored properties, we get no further than with the h1 -> h6 approach.

          Which do you mean? I could probably achieve (b) with some aria-labels and javascript…

          0
  26. 47

    Thank you A LOT for this very detailed explanation – it was the kind of info I had been looking for a long time.

    As I didnt have time to really dig into the HTML5 specification and informations about exactly this topic, content hierarchy and header nesting are either blunt, incomplete or straight up wrong on a lot of articles you’ll find, reading your explanation was a relief.

    You managed to explain extremely well how heading and secitoning is actually thought to work in HTML5, and gave me some crucial bits of information I didnt find anywhere before, which helped me now fully understand how I am supposed to structure my content. Thank you very much!

    0
  27. 48

    Very good explanation of of sectioning elements. It could *almost” substitute reading the specification.

    I only have two minor quibbles: one with the justification of using “article” to section comments in a thread and one with the equality of unpleasant experience encountered with nested article elements.

    First, the specification initially defines “article” as follows:
    “The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.” (http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element)

    One of these things is not like the others.

    I believe “article” is appropriate for a blog post, a column, a news item, etc. aka an “article.” Where I see article failing, when used for sectioning comments, is comments are contextual and derive their meaning only from the original topic.
    Were I to post a comment consisting of only “That’s just wrong!”, it *is* a self-contained composition, but it *is not* independently distributable or reusable without a loss of context.

    The specification continues defining the article element as:
    “When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry.”
    The use of the phrases “in principle” and “could represent” are imprecise and carry a certain level of ambiguity. I would prefer to see more definitive terms used in a specification.

    Second, to the point of an equally unpleasant experience for screen reader users, sighted users can quickly scan the first few words of each comment and determine whether they are interesting or junk.
    It is not a huge cognitive load because they are not actually investing much effort in sorting the wheat from the chaff. Screen reader users have to intellectually process more of the content to make such a value judgement.
    I sit beside a screen reader users every day at work and often hear the frustration they express while slogging through something I can visually process in minutes.
    It is not quite the same (albeit unpleasant!) experience.

    Sorry for the length of this comment, it was much shorter in my head.

    0
  28. 49

    After reading Luke Stevens’s The Truth About HTML5, I was convinced to not bother with the new sectioning tags. I’ll just use the old tags with aria roles for added meaning. No html5shiv for me, thanks.

    Now that you’ve eloquently explained why the new sectioning tags are actually useful AND how to use them in a consistent logical way, I guess it’s back to html5shiv-ing for me. At least I’ll be able to stop using that ugly hack when everyone stops using (…looks it up..) Internet Explorer 8?? Sweet Jebus, that will never happen!

    Have any suggestions for someone who wants to use the best web standards, and wants pages to work well enough for all users, but is tired of IE conditional comments proliferating all over our markup?

    0
  29. 50

    There are many good reasons to have an explicit section element with an h element. Just one of the things it could solve is that when you post a comment on a blog and want to include headings in the comment you don’t have to worry about which one of the available h1-h6 elements to use in order to get the right heading level in the structure of the blog.

    If HTML5 had introduced a heading element without an explicit level then the section element could have been useful. But it would also have created problems, if we used this element instead of the much more well established h1-h6 elements to markup headings it would no longer be recognized as headings in older user agents.

    So instead we have this technique to use section elements along with only h1 elements. And then the outline algorithm “fixes” them to become the right level. But there are many problems with this. In older user agents there would only be h1 elements, a lot of the hierarchical information about the document outline is lost. In order to style something like this there really needs to be an easy way to match the calculated level of headings in CSS (something like heading(n) where n is a calculated level) but there isn’t. Because of that when you try to style headings using the section+h1 technique it can become rather absurd just like Luke Stevens have demonstrated.

    There are already reports of problems with the implementation of the outline algorithm so even with the latest software it can produce strange results.

    Because of this, the same old best practice of using h1-h6 elements correctly is still applies in HTML5. This will work in all user agents more or less regardless of how old and outdated they are. And the section element should not be used at all to minimize the chance that the outline algorithm messes up your document.

    The hgroup element shares many issues with the section+h1 technique and should not be used either.

    0
    • 51

      Exactly my thoughts!
      Great respons to an awesome article

      0
    • 52

      So instead we have this technique to use section elements along with only h1 elements. And then the outline algorithm “fixes” them to become the right level.

      This is certainly true of JAWS, but should be considered a bug. I asked Hixie and he agrees.

      As I explain in the article, heading levels and sections are not mutually exclusive. Whenever a section is used with a heading, the heading gives responsibility of the nesting over to the section. Except for buggy implementations like JAWS, this means you can’t “double nest” items of content.

      You are free to use h1 for all your section headings, but I would advise not to. A moderate interpretation of the spec would use h1′s for the body and all top level sections within it (eg. body, body > article, body > aside.) and h2′s for subsections directly under these (eg. article > section.comments).

      Multiple h1′s are fine even in HTML4. The important thing is not how many headings of any number are used throughout the page, but to order numbered headings correctly when you use them. Eg. don’t skip straight from h1 to h3 or h2 to h5 as you go down the page.

      H1 – H6 will work in user agents old and new. Sectioning just adds further clarification of structure when and where their impact on the outline is supported. Here’s hoping the support problems you report are sorted out soon!

      0
      • 53

        “A moderate interpretation of the spec would use h1′s for the body and all top level sections within it (eg. body, body > article, body > aside.)”

        If you do that then you are implying that the H1′s in the ARTICLE’s and in the ASIDE’s have equal weight with the H1 for the BODY, which is contradictory. By this contradictory/arbitrary reasoning you are saying, “First you have my dad. Then you have me and I’m on the same level as my dad. But my children are my children but they’re also my father’s children and not his grandchildren.” The headers in any element that is a descendant of BODY are subordinate to the header for the BODY.

        0
  30. 54

    I’ve been working on the web since it was invented, and every few years a new group comes along and says that everything that was being done a few years earlier was crap and *this* [new approach] is the only logical way to do it. And lots of devs who want to seem au courant agree. Then a few years later another new group comes along, with a bunch of new “revolutionary insights”, and the nonsense starts all over again. This goes on for design trends (currently gray type on gray backgrounds, etc.) as well as for code (divs instead of table cells, sections instead of divs, wahoozies instead of sections…). Everybody wants to be revolutionary and disruptive and…

    What a load of pedantic rubbish. The problem with the web is that the content is 99.999% twaddle, not what flavor of tags devs use. And even the tiny bit that isn’t total twaddle is rarely amenable to semantic treatment. (And yes, I am a dev.)

    0
    • 55

      that comment belongs between the hind legs of a bull.

      0
    • 56

      Just to be clear, using tables to mark up document layouts was not superceded because we got bored of it and were in the market for something new and funky. We stopped using tables because it was lazy, invalid and not at all suitable.

      0
  31. 57

    I’m really disappointed that, after reading this article, and clicking “View page source”, have found that this website uses HTML5 sectioning elements. I was hoping for divs, dreaming for tables, so that I could have written a really mean comment about the irony of it. Damn!

    0
  32. 61

    Posting this on my wall:

    HTML isn’t just an SDK or a Graphic Designer’s palette. It is a metalanguage, a language that tells you special information about information.

    0
  33. 63

    There are many things which are imperfect with the current HTML5 schema but it is a good start.
    I have already found many people sliding back and forth between sections and divs and even nesting sections inside headers, around headers and so forth.

    The addition of the likes of microformats and now microdata attributes could lead us to more bloat than we have ever had before.

    The content editors aren’t being updated with these new elements, half of them still don’t encourage people to add title and alt attributes to images so getting somebody to section out an article is still very slim.

    0
  34. 64

    What are the impacts on SEO giving the fact that standard SEO rules dictate specific markup rules such as a single h1 element and using h2/h3 for specific headings or to show specific relevance to a section of the page… given that Google (most specifically) doesn’t appear to have change the algo for HTML5 valid markup…?

    0
  35. 65

    “If you’re doubtful of the grip that this culture has had on the World Wide Web, look no further than the fact it took until 2010 (2010!) for us to concede that Web browsers are not really made of paper.”

    I was telling people that in 2000.

    0
  36. 66

    “You’ll come up against some accessibility experts who are keen on their “there can only be one [h1]!” mantra, but research shows that even in HTML4 or XHTML, this is not necessarily the case”

    What the research shows is thousands of developers not knowing what they are doing. An H1 is the trunk and every other header level is branching out from that truck. The reason people used multiple H1′s is because they thought it have them “Google juice,” not because it made structural sense. It’s also because very, very, very few developers knew how to properly use H1 – H6 elements . . . at all. They would litter H1′s all over the place then run around shouting, “What do we do?! What do we do?!” So we now have a case of standards bending to the overall ineptitude of developers.

    An H1 can be seen as analogous to the title of a book or a magazine. No chapter of a book is given the same philosophical and structural weight as the title of the book itself. No magazine article is given the same philosophical and structural weight as the title of the magazine itself.

    0
  37. 67

    Hi All,

    Sorry to chime in negatively, especially with an early comment and because I am fairly new. That said, I am having a hard time understanding the need for the new HTML 5 “semantic” tags. Given the popularity of designer platforms like Bootstrap that simply use s I am not feeling it and a lot of others aren’t either. That said, I think accessibility is a big deal, so what to do? The last two sites I developed did use HTML 5 semantics….and I see little difference in the process and little difference in the result. I am open minded, but am not convinced HTML 5 is anywhere close to the final answer.

    0
  38. 68

    Nice one Heydon! Also the <main> element which will bring more structure into the HTML5 semantic.

    0
  39. 69

    I knew HTML 4.01 very well when I read the HTML5 spec from the beginning to the end a few years ago.

    And I jumped for joy!

    Because this sectioning elements in combination with footer/header solved exactly a problem I had often when marking up HTML documents. I always paid great attention to the outline of HTML 4.01 documents, but there are sometimes structures that can’t be marked up correctly with HTML 4.01. HTML5 solved this.

    For me the sectioning elements + the outline algorithm (including how footer and address “belong” to these sections) are the best thing in HTML5. All kinds of user-agents can benefit from this …

    … if we don’t use it wrong.

    So I’d have one advice: If you don’t understand/know how these sectioning elements work, don’t use them!

    It’s better to omit them (if you use headings as in HTML 4.01, you can get a correct outline most of the time) than to mis-use them. If many sites use section, article, aside and nav in the wrong way, all the great possibilites diminish.

    But, no excuses! This very article did a fantastic job of explaining why the outline is important and how it works.

    Really, Heydon, your article is great! Thanks to you for explaining this topic so well. I second every single statement (which happens rarely).

    0
    • 70

      Quite so, uo.

      You can construct an outline with just sections, just headings or a combination of both. It is advisable to have some sort of logical structure but the spec gives you some freedom as to how you approach it.

      The great thing about the way sections have been introduced is that they can be incorporated in a way that placates advanced parsers (that are able to read and understand a structure based on them) with heading schemas that can appease older user agents.

      Thanks for reading!

      0
  40. 71

    I’m glad Heydon is excited by the idea of sectioning in HTML5; unfortunately, as I’ve covered extensively both in my book The Truth About HTML5 and online; sectioning in HTML5 is (to borrow a phrase) a “fractal of bad design”.

    It’s worth distinguishing between the idea and implementation; of sectioning, as Heydon makes a great case for the idea, but as I’ve demonstrated extensively elsewhere, the implementation in HTML5 is hopelessly broken.

    There’s no point rehashing all my arguments and research here, so I suggest interested readers check out the following series “The harsh truth about HTML5′s structural semantics” (2, 3):

    The tl;dr version is:
    * The sectioning elements were drawn up on a whiteboard by Ian Hickson in late 2004, and added in the spec before any research was done into what web professionals actually used (or wanted), and were then specified and sold to the community in a deeply confusing way which has resulted in a huge mess of unusable, broken outlines that make the feature pretty much dead on arrival.
    * They serve no real purpose – Heydon vaguely refers to “data mining”, accessibility, and “structural clarification”; but Schema.org provides the structural data search engines want, accessibility is more easily solved with ARIA landmarks, and structural clarification is the opposite of what is achieved – having three elements in particular (section, article, aside) that all serve vague, overlapping, and at times nonsensical purposes is hardly “clarifying”.
    * You probably shouldn’t use them. With better ways to achieve their supposed benefits; the lack of any coherent design behind their implementation; and the mess of broken, inconsistent outlines already out there (it’s been 5 years since the first ALA article advocating their use) making any attempt to interpret them nigh-on impossible, these elements are better off ignored. The spec would be better off without them.

    0
    • 72

      I promised to approve your link-heavy comment, Luke, and I’m a man of my word.

      However, this doesn’t appear to be a comment. It appears to be a book pitch. In the interest of structural and semantic clarity I’m going to reply to it with a corresponding book review. If you’re going to use Smashing Magazine’s comment stream to sell your wares, it’s only fair!

      In his book The Truth About HTML5, Luke Stevens draws on hundreds of hours of research to reveal the astonishing truth that some aspects of the HTML specification are newer than others and are not as well established or implemented. He goes on to reveal that some other aspects of the specification were not immaculately conceived. Other earth-shattering revelations include the fact that some developers write rubbish HTML and the spec’ isn’t quite as clear as we’d like it to be.

      Joking aside, I like the way you write. I like the pace in particular, and I’m sure that your book makes for a great potted history. However, I’m not sure I’d personally pay for a book that gives instruction on not using something, curious as this premise is.

      I see that you find the inclusion of three elements (<article>, <section> and <aside>) confusing because of the conceptual overlap. That is, they all do different but similar things because they’re all sectioning elements. Well, I agree with you and think we should STOP USING THEM. I’ve noticed a similar conceptual overlap between <em>, <small> and <kbd>. Having more than one phrasing element is completely baffling, so let’s STOP USING THEM too. Advise on how to use sectioning elements isn’t crystal clear. Another good reason to STOP USING THEM. Advise on using h1 to h6 isn’t very clear either. Do I have to use them in order or can I have an <h2> for my top nav’ and follow it with an <h1> for my main doc’ title? I don’t know, so I’ll just STOP USING THEM. Wait a minute… some ARIA roles are for landmarks and some aren’t for landmarks. But which is which? I could look it up. No, I can’t be bothered. I’ll STOP USING THEM instead. Microdata and RDFa both exist at the same time, in the same space and do similar things. I should probably use just one, but which? I can’t decide. I’m going to STOP USING EITHER OF THEM.

      And now, without the sarcasm:

      *I’ve already started using sectioning elements correctly in my projects. With sectioning elements I’ve been able to make documents that are more logical and easier to maintain; documents with less bloat, less dependence on the help of classes and IDs and which are more conducive to organizing structured content. This has all been possible without maiming or psychologically damaging anyone to my knowledge.

      *It is immaterial how something is developed if the product that emerges is sound. If the specified outline algorithm were genuinely “broken” the story would be sensationally book-worthy. However, it’s not, as I demonstrate in this article.

      *If sectioning elements have no real purpose, then neither do h1 -> h6. Since you refer to h1 -> h6 as “old friends” I assume you are fully seized of the importance of syntactic structure. Sectioning elements are just better at it. You can use them without breaking accessibility if you are not an idiot. The readers here are not idiots; we’ve all just been acting on unclear advise. As I point out in the article, advise on h1 → h6 is also (fundamentally) unclear. Should we ban them too? No. We write better advise for both.

      *Just because some developers have trouble with sectioning elements doesn’t mean they are an inherently bad design or should be dropped from the spec’. If you see someone’s dog fouling the pavement, you don’t ban dogs. That’s madness. Besides, it doesn’t follow that someone else’s bad coding makes mine bad too. What sort of logic is that?

      *I never read the ALA article and I certainly would not have employed its HTML5-related advise as long as 5 years ago. Especially not without reading the spec’ too. Can you really attribute 5 years of bad HTML5 markup to this singular piece? If so, perhaps they could UPDATE IT.

      *The benefits aren’t “vague”, they’re broad. Any designer can see the implicit virtue of structure and uniformity. Meaning in any language must emerge – at least partly – from structure. The Web itself is largely only meaningful because of the structural relations afforded by hypertext. The future benefits for maintenance, parsing, indexing, editing, cross-pollinating and syndicating are likely to be considerable. You just need a bit of imagination and patience.

      0
      • 73

        Whoa, Heydon, you certainly know how to write a snarky reply. (All caps and bold, to make the same point six times? Wow.) Might want to tone things down in the future. If you ever actually want to engage on the issues though, let me know. Cheers.

        0
        • 74

          I’ll set the tone of my own comments without your advise thank you, Luke!

          You asked me to approve your comment, which was held in the queue due to the commercial content and I have.

          I’ve been fair and given you your platform, but I retain the right to mine.

          I do not need your advise on my language any more than I need it on my metalanguage and I will reply to comments in the comment stream of my article as I see fit.

          As for my readers? By publishing your comment they have access to your perspective, should they be interested in paying to read it.

          You’re welcome.

          Edit: P.S. I did, in fact, address the issues raised in your comments (marked with ‘*’)

          0
          • 75

            The only part of Stevens’ book that I found actually convincing was his point that IE users without Javascript (and therefore no access to Modernizr or HTML5 Shim) would lose the structure of the document all together, and therefore things could get pretty messy.

            I know this is a very, very small section of the population but do you think there is any way you can speak to that specific problem Heydon?

            Outstanding article, by the way. It’s rare to see things laid out so plainly and practically, so thanks for that.

            0
          • 76

            Hi Heydon,

            I wanted to point out a grammatical error, it is ‘advice’ not ‘advise’, (I assume you are not a native English speaker so easy one to miss).

            0
      • 77

        @Heydon – I’m with you on pretty much everything here. I particularly mourn the lack of a generic heading element and intend to start all my sections with h1 in protest. I find it strange, then, that I should have to take issue with you on question of ethics:

        “It is immaterial how something is developed if the product that emerges is sound”

        Really? I’d be delighted to debate this issue with you in public some time. Afterwards (and I think it won’t take long, however heroic your defence) I’ll buy you a pint. If you haven’t been torn limb from limb by anti-vivisectionists that is…

        0
        • 78

          Very good :-D

          I don’t, of course, mean “it is immaterial” in the sense that “the ends justify the means”. I simply mean that the story that leads to a products’s inception is not as important an object of criticism as the product itself.

          Still, very pithy!

          0
  41. 79

    Thanks Heydon for an excellent article. I begin to understand why I never could understand web designers with an technical background. Coming from traditional book making, I can see that what we see and what is the essence of content are ‘computed’ differently, also by human beings. Nice to see your explanation, if you strip down all non-structural info, you are left with the ‘section’ structure, which expands to a collections of files, collection of… like books in a library.
    You explanation is in fact the one I had to my authors (for print), I could not make the connection to HTML before … now I know why.

    0
    • 80

      Thank you for your thoughtful comment, Henk.

      I was talking to someone yesterday about a librarian who can’t stand pdf’s because they don’t expose their textual content for reformatting easily.

      You may already know that the term “markup” derives from “marks” (little bits of writing) made in the margins of printed or written documents to add commentary and clarification to the work.

      0
  42. 81

    Thanks very much Heydon for a thoughtful and interesting post. I agree though with Luke Stevens – and others who’ve commented – that a semantic document can be more effectively achieved through WAI-ARIA and Schema.org microdata. If our documents can’t be interpreted efficiently by search engines and accessibility software then the most finely crafted HTML5 markup in the world doesn’t matter a jot. The way to go is to keep the HTML tagset to a minimum and extend its meaning through appropriate interjection of WAI-ARIA and Schema.org classes: a much more elegant approach. I say that fully acknowledging that your article references both WAI-ARIA and Schema.

    Also, with respect I think it is rather unfair to suggest Luke’s contribution to this thread is commercially motivated. There’s no money to be made in self-publishing a rather exhaustively researched ebook on an esoteric topic of interest only to professional designers – quite the contrary given the time sacrificed that could have been spent on commercial projects. I’m always profoundly grateful to designers who put time aside to publish, and more than willing to pay something towards their efforts.

    0
    • 82

      Thank you, Justin.

      Just a few thoughts first:

      Neither WAI-ARIA or structural data address syntactics, as I point out in my article. Syntactics and semantics are both important for the organization of information and the manufacturing of meaning, but these attributions can be applied to any underlying structure “willy nilly”.

      Documents should be easy and efficient to parse and deconstruct by all parties: machines, authors (developer colleagues) and assistive technologies. Sectioning elements, which are designed to conform to certain syntactical rules, encourage us to be incisive and deliberate in document construction, whereas <div>s can be used indiscriminately. Because <div>s can be used indiscriminately, they frequently are. This leads to messy, bloated, illogical and inaccessible web pages.

      It is not the commercialism of Luke’s comment that I find distasteful on its own. He is also quite right in highlighting the importance of semantic attribution via microdata. However, his strongest argument for the exclusion of sectioning elements is that I – his reader and a developer – find them confusing. Not only is this audaciously presumptuous but it is completely unhelpful (hence the “snarkiness”). If I find an aspect of technical specification difficult to understand, I want it to be investigated and explained – not regaled with anecdotes pertaining to its origin or instructed to avoid it altogether. I want the facts, so I can make up my own mind.

      For instance, it is a hard fact that header and footer elements are not currently specified to affect the document outline. It is only something of a truth – in some cases – that developers have been confused over headers and footers as sections unto themselves. Only one of these pieces of information is clear, complete and unequivocally useful.

      It is for these reasons that I don’t think the book, in my humble opinion, is good value for money. I have a right to express this opinion and I will continue to do so, just as he has the right to continue to promote his own ideas and his book. I have not been an impediment to this end If you refer back to my original reply to Luke, you’ll find that I do, in fact, engage with him over the issues he addresses in his own remarks. I think he must have missed this.

      Thank you for reading. You are a more diplomatic gentleman than I :-)

      0
      • 83

        Thanks Heydon. The point about syntactics and semantics is noted, and something which I will need to explore more. I’m still not persuaded by the concept of significantly expanding the HTML tagset. That so many experienced designers have had difficulty interpreting the appropriate use of the sectioning elements is a sign that the new spec isn’t ideal in every respect. But of course the great thing about HTML5 is its flexibility: there’s room both for the approach you advocate – with greater clarity than I’ve read elsewhere thus far – and the scepticism of the likes of Roger Johansson and Luke Stevens.

        0
  43. 84

    Section heading some content… Subheading content following subheading…

    0
  44. 85

    Totally swiped that quote for an article I was writing. Thanks for the in-depth look at semantics, really helped out.

    0
  45. 86

    Where do I go to find out how far back browser support goes for sections? The references I’ve found don’t go as far back with IE as some peoples’ computers do.

    0
  46. 87

    Interestingly, when you run this page through the outliner, the tier one heading is “Related Articles” due to how the algorithm handles the first title in the initial section created by the body tag. In other words, “The Importance Of HTML5 Sectioning Elements” is in a sub-section created by the article tag. Clearly, the primary focus of this page is not “Related Articles.”

    This was explained in the article, I am sure this will be addressed when the CMS templates are overhauled.

    This will take time for me to wrap my head around. Practice and the outliner tool are going to be the only way to hammer the algorithm home! Great article, definitely worth the read.

    0
  47. 88

    Great in-depth cover for the idea and meaning of element!

    But even the article is pretty long, I thing that there should be at least 1, 2 sentences about the difference between sectioning elements, especially and which by me are often misunderstood.

    You have described the sections very well., let me add one thing :)

    According to the spec:

    “The element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributed or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.”

    0
  48. 89

    : HTTP Error 403: Forbidden

    http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fwikipedia.org

    Just thought perhaps you want to catch these kind of errors. Turns out I needed to use http://www.wikipedia.org.

    Thanks for an interesting article and a useful tool!

    0
  49. 90

    I’ve read Luke’s book. I’ve read this article several times. I’ve read the comments, particularly Luke and Heydon’s exchange. I’ve even commented before following my first read and since that time I’ve been away, learnt more, coded a few sites using the new elements, enhanced the semantic nature of my styling using Sass and more elegant cascades and sat back and marvelled at the largely wasted effort.

    Don’t get me wrong, there is pride to be taken in the intellectual pursuit of embracing modernity, clean, elegant, structured and semantically rich markup clothed in a compiled, minified and beautified stylesheet (see Hammer for Mac with Sass). I can even see some way to appreciating the ideology embodied in the elements, even if a more dramatic history to them was slotted in after the fact.

    I can even turn a blind eye to header and footer elements which are so egregiously NOT what a web designer would define them and hence can’t possibly be borne from the spirit of what went before.

    But my point is this. There is simply not sufficient value to any of the new elements as to warrant the time moving your head into a different space. Web designers are busy guys and gals. Over the years we have built a list of priorities which relate to how we markup a document, these are:

    Structuring for Ease of Layout / Styling
    Overcoming Browser Bugs / Compatibility
    Structuring for SEO
    Structuring for Accessibility

    More recently device agnostic development has moved more thought processes related to mobile into the mix but for the purpose of this argument we can keep those in the top bracket.

    The two areas where new structural elements can play a real part in our workflow are the last two, SEO and Accessibility, and at present the structural elements provide no value here – and indeed there is an argument to suggest they can destabilise what kind of works already. There is also the likelihood they will never play a role in this area.

    This only leaves document outlines as perhaps a reason for embracing the structural elements. Unfortunately most people don’t know what these are and nor do they have any relevance in the current web, and are probably not likely to.

    So of the list of four priorities above we must now add another to the bottom – intellectual pursuit. I can only conclude that by taking the time and effort to structure markup in a beautiful and spec evangelising way we are in fact meeting our own need to feel worthy of ‘modern web designer’ status.

    So my take is this. Use them if it makes you feel better. If you see sense in it. If it makes your work more maintainable, easier to read, easier to style, crikey if you’re client insists you do.

    If not, then don’t worry. Your code is no better or worse. You styles will not load faster. You pages will not rank better. Assuming you’re using ARIA roles and building with good accessibility in mind in the first instance, your pages will be no more accessible to blind or vision impaired people.

    The HTML5 structural element train is not leaving the station any time soon. You do not need to get on it. There will be plenty of seats in a year or so when everyone else starts getting off.

    PS – If anyone is interested I use section and article as I find these can be useful. The rest I’ve no interest in.

    0
  50. 91

    Great read, very revealing, clearing some fog around HTML5, thanks a ton.
    BUT the outline of this very document is confusing (at least to me)! It starts with “1. Related Articles” – why is that so?

    The outline shows as follows:
    1. Related Articles
    —1. Smashing MagazineSmashing Magazine
    —2. Untitled Section
    —3. Structural SemanticsThe Importance Of HTML5 Sectioning Elements
    ——1. Making Websites
    ———1. Web Standards
    ———2. The Problem With
    ——1. Why Is This So?


    —5. Conclusion
    4. The Semantic Grid System: Page Layout For Tomorrow
    5. HTML5 And The Document Outlining Algorithm
    6. Modern CSS Layouts The Essential Techniques


    Did I miss something important here?
    (or is the Smashing Magazine not living up to the explained ‘Standard’?)

    0
    • 92

      Yours is the second comment that indicates that the first item in the outline is “Related Articles”. I wonder which tool you are using to come to that conclusion. The very popular gsnedders.html5.org/outliner produces this result, but after much research, I have found that this tool does not produce a proper HTML5 document outline.

      If you use the HTML5 Outliner extension for Chrome (chrome.google.com/webstore/detail/html5-outliner/afoibpobokebhgfnknfndkgemglggomo), you will get a different (correct) outline that lists the beginning of the outline as:

      1. Footnotes:
      —-1. Smashing Magazine
      —-2. Untitled NAV
      —-3. Structural SemanticsThe Importance Of HTML5 Sectioning Elements
      ——–1. Making Websites
      ———–1. Web Standards
      ——–2. The Problem With
      ———–1. Why Is This So?
      ———–2. Heading Levels Don’t Really Help
      ———–3. Whose Footer Is This?
      ——–3. Sectioning
      ——–4. Headings And Accessibility
      ————1. A lot of fuss over nothing
      ————2. ARIA Enhancement
      ————3. Are Sections The New
      ————–s?
      ————4. Sections And Semantics
      ————5. Microdata
      ——–5. Conclusion
      2. Related Articles
      —-1. The Semantic Grid System: Page Layout For Tomorrow
      —-2. HTML5 And The Document Outlining Algorithm
      —-3. Modern CSS Layouts The Essential Techniques
      —- . . .

      0
  51. 93

    There are people who don’t know the difference between section and aside…. for example, there are some of my friends I work with that find it difficult to know…. although it might be the same , but its different because there is a capacity section can have that aside doesn’t …… nice article! :-)

    0
  52. 94

    Great Post. The point about syntactics and semantics is noted, and something which I will need to explore more. I’m still not persuaded by the concept of significantly expanding the HTML tagset.

    0
  53. 95

    Full Disclosure: I have read Luke Stevens’ “The Truth About HTML5″ (second edition) and I’ve also read countless online articles relating to the HTML5 sectioning elements and the HTML5 Document Outline. I’ve read the W3C spec, relating to this and I’ve got a stack of books that have been read as well.

    There is no doubt that this article explains sectioning in a way that many others don’t and there is a benefit to fully understanding how the sectioning elements should be used. But, I must say that Heydon Pickering seems (to me) to have as much of a bias “for” these elements as Luke Stevens has “against” them, with one important distinction and that is what I hope readers of this comment will focus on.

    I will do my best to explain as objectively and without injecting any “opinion”, but rather stick with facts as best as I can because after reading the back and forth comments between Stevens and Pickering, it is clear that there is *some* level of animosity there and that won’t help the rest of us build better web pages and applications.

    1. Heydon states that *why* and *how* these elements were initially created is not a material issue, but that is his opinion, not a fact. The fact is that understanding the history behind how we got these elements goes to the heart of the *intent* for their usage. Hixie intended to have elements that “paved the cow paths” in HTML5. Like them or hate them, the fact is that they do not do this — they create entirely new pavement that we are being asked to drive on. If a semantic web is the goal, as Heydon says it is, then *intent* for an element is literally the element’s semantics. After all, how many pages use the b element when strong was what Tim Berners-Lee would have intended for us to use? With these new sectioning elements, the intent doesn’t match the spec’s stated semantic meaning and that’s a problem for semantics.

    2. In reality, we must develop for the web we have, not the web we want. This simple paradigm is the basis for every work-around, hack, shim and polyfill that has ever been created. Heydon states that incorrect implementations of the document outline are bugs and “bugs get fixed”, so we should carry on with these elements under the guise that at some future point the web we get will line up with code we have today. This is a patently false assumption that has over 20 years of web history to prove that this is not how it works. We all know perfectly well that IE8 was released in 2009 – - that’s 5 years ago folks. We all also know that there are still enough IE8 users out there for us to worry about how to polyfill for it or gracefully degrade within it. Just ask why so many books, articles and blogs pound Remy Sharp’s IE8 shim into our brains. We cannot simply leave these users behind because they haven’t caught up to the web we wish we had. We must build for the user base we have today and progressively enhance pages for them to stay current with new technologies. Adding these elements in the hopes that technology will catch up to us is the very definition of “Feature Creep”.

    3. Heydon’s article does a fine job detailing how one might implement these elements, but as I read it, the only real case he makes for why they are better than the heading elements (that still contribute to document outlines) alone is that with heading elements, it’s hard to figure out where sections end. Frankly, that’s more opinion. We have 20 years of experience with heading elements and the vast majority of developers/designers I’ve interacted with consider them in the “101″ category of complexity. If you can make a Word document that is a report with headings and sub-headings, you understand headings in HTML.

    4. If you agree that the purpose for using these elements is better semantics, better accessibility for AT and better SEO, then you must determine their usefulness by how much they help us in those areas alone. You can’t say we like these elements because of “A” and then offer proof that relates to “B”.

    Is div id=”article” semantically better than article alone?
    The answer must unequivocally be “no”, since they both DO convey that they are each an article. Sure, you can say that article is shorter, but that’s not semantics, that’s “syntactic sugar” and there will never be a clear winner when it comes to debating purely stylistic coding decisions. By the way, if you consider that many HTML5 developers are nesting div elements inside these new sectioning elements for either fall-back purposes or for style hooks, then article isn’t less code, it’s more.

    Do these elements better serve us with AT?
    The answer is again, an unequivocal “no”, since many ATs either don’t use the HTML5 document outline or implement it incorrectly at this time. I freely admit that this *may* change in the future and, if so, we should give these elements another look. But, the possibility is also that this may not change in the future, in which case using these elements for AT is a red-herring.

    ARIA, on the other hand does work with AT and is well-supported. Why reinvent the wheel here?

    Do these elements help with SEO?
    No. There is no evidence to support that the use of these elements helps SEO or that the lack of their use hurts SEO. Google has not changed their ranking algorithm to account for HTML5 – that’s a fact.

    If we want semantics that can help with SEO, we have it today with Schema.org.

    5. Fully half of Heydon’s article is about how div is inadequate to truly section a document and that it is only CSS trickery that makes us believe that they do. And, he’s right. But that’s not news. What took him many paragraphs to say, I’ll say with all that needs to be said: the div element is semantically neutral (as is the span element, by the way). Does this make div useless? Certainly not! We need neutral elements as style hooks AND if we adorn them with ARIA, they magically do take on semantic meaning. With all that Heydon says drilling his point that div’s don’t create *actual* sections, what he glosses over is what I’ve already said – - we don’t need them to create the sections in the document outline, we use headings for that purpose. And, again, Heydon doesn’t prefer this because he finds it difficult to know where a section ends. That’s his opinion and he’s entitled to it, but it is not evidence for why sectioning element are, as a matter of *fact* better than headings.

    6. Heydon does not address, at all, how we are to style headings that are used within sections. This is a glaring omission. If a consistent look for all h1′s is desired, how am I to set up CSS to address the fact that some of my h1′s will be in the main section, some will be in an article or an aside, and still some will be in an aside, nested within an article that is nested within a section that is, itself, nested within another section? Am I to write CSS classes for all these possibilities? You might answer that this is a problem with a simple solution – create 6 CSS classes for the various heading elements and adorn each usage with the desired class. For some situations, this may be just fine. But, what if the content is coming from other content sources and I am just republishing it (such as a blog post or Twitter feed)? In those cases, I can’t modify the HTML to include these CSS adornments. So, now what?

    SUMMARY:

    1. These elements are a solution in search of a problem.

    2. Traditional headings (alone – without the new sectioning elements) still make valid HTML5 document outlines. And, these outlines are correctly implemented, TODAY, in all AT’s.

    3. These elements do not add any semantic value that we cannot already implement through ARIA and Schema.org.

    4. These elements do not affect SEO.

    5. These elements WILL cause untitled sections when headings are not present within them, which CREATES an AT problem that didn’t exist prior to their introduction.

    6. The “one distinction” between Heydon’s affection for these elements and Luke’s loathing of them that I made mention of at the beginning of this post is that Heydon doesn’t present anything other his opinion that sections (the old way) were hard (we’ve already dispelled the other incorrect notions about better semantics and better AT support). Luke provides real, testable and verifiable evidence for why using these elements (today anyway) is not a good idea.

    If you’ve read this far, I thank you for your attention. Again, I’ve tried very hard to stick to the facts here and not include any hyperbole or opinions. Everything I’ve stated is accurate and verifiable. But, I must conclude with this:

    When used correctly, with an understanding of how they work, you CAN use these sectioning elements and cover all your bases. That is a choice that we all must face, just as we do with any/all new technologies that come down the pike. My overall point here is that any argument for using them that includes anything but personal preference is a false-argument. Finally, all of this is true as of 3/11/14. When (not if) the landscape changes, I will adjust my practices accordingly. Just as we all should do with any new options.

    Thank you for your time and attention.

    Scott Marcus
    IT Educator for over 20 years.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top