HTML Structural Elements And The Document Outline

Do you use the new HTML5 structural elements like header, aside, article, and footer? I asked that question back in December when I recorded and posted some thoughts about the new HTML5 structural elements. My thoughts were mainly to wonder aloud if there was any reason to use the new elements.


When they were first introduced I was excited to use them, but I soon went back to simple and generic divs. It felt wrong to say that (and still does), but I wasn’t sure where the justification was for using the new tags.

Jordan left a comment on my post mentioning that the purpose of the new elements is to serve the HTML5 document outline and that understanding the outline makes working with the new elements less confusing. In my reply, I mentioned I might revisit the subject and here we are.

A Note About This Series

There was more to talk about than I initially thought, so I’ve turned the topic into a series. This first post in the series will mainly be prep work to get to the HTML5 outline and the new elements.

Today I want to look at the document outline in HTML 4 as a way to provide some additional context for where things were and what problems the HTML5 document outline was meant to solve. I also want ask whether or not we even need to consider the new outline as it’s not being used anywhere at the moment.

Next week I’ll get into the details of the HTML5 document outline before moving on to the new structural elements. I’ll close the series with a demo using the new elements and if we’re lucky, we’ll all come away with a better understanding for how to use header and section and article, etc.

The HTML 4 Document Outline

In HTML 4, the document outline is created through the use of h1-h6 tags. When a new heading appears a new section begins. You might place a heading inside a div and have the div wrap everything that belongs within the section, but you don’t have to and I don’t think most people do this.

More typical is something like the following:

<h1>Bob Dylan Albums</h1>
<p>Some text</p>
<h2>Blood on the Tracks</h2>
<p>Some text</p>
<h2>Highway 61 Revisited</h2>
<p>Some text</p>
<p>Some text</p>

On a real site there would probably be a div, maybe with a class of main or similar wrapping all the content, but divs probably wouldn’t be used to wrap each heading/paragraph section of content.

Note: You can use either of the outliners below to check the document outline for your HTML. I’ll be using the first one throughout the series.

Here’s the document outline produced by the HTML.

1. Bob Dylan Albums
   1.1 Blood on the Tracks
   1.2 Highway 61 Revisited

The outline is probably what you expected. An h1 at the top of the hierarchy with two h2s equal in the hierarchy and one level below the h1.

I think it’s safe to assume that a paragraph directly following a heading belongs to the same section, but what about the paragraphs that follow the first.

For example the very last paragraph in the example. Does it belong to the same section as the h2 that precedes it or does it belong to the h1 that starts the outline?

It could belong to either. Wrapping divs around the sections along with a little whitespace can help make it clearer.

  <h1>Bob Dylan Albums</h1>
  <p>Some text</p>

    <h2>Blood on the Tracks</h2>
    <p>Some text</p>

    <h2>Highway 61 Revisited</h2>
    <p>Some text</p>

  <p>Some text</p>

Here the last paragraph belongs to the section started by the h1 containing Bob Dylan Albums. It took a little more code to make it clear and it’s only clear when looking at the code.

The document outline is still the same.

1. Bob Dylan Albums
   1.1 Blood on the Tracks
   1.2 Highway 61 Revisited

The HTML 4 outline has some other issues.

There are no semantics to the divs. Semantics can be provided by adding classes or ids to the divs and giving them meaningful names, but a generic element like div offers no useful semantics on its own.

In HTML 4 every section becomes part of the outline. That’s not always what you want. There’s no way to include sections that don’t need to be part of the main outline. For example what if you wanted to add a short bio about Bob mixed in with the list of albums. The bio wouldn’t really be part of the main document, but it would be part of the document outline.

It’s also difficult to merge content that’s part of different outlines. This might be integrating the list of albums with reviews of each album from another page or site. The outlines of both pages may or may not work together and likely one or the other would need changing.

These are some of the problems the new sectioning elements in HTML5 along with the new document outline were meant to solve.

Is It Worth Learning the HTML5 Document Model?

Unfortunately nothing I’m going to tell you over the next few weeks about the HTML5 document outline is in use anywhere. At the moment, nothing supports it and based on what I’ve read, no one expects anything ever will.

So why look at the outline? Why try to gain some context from something that will probably never be used? It’s unlikely developers will use the new elements in the context of an algorithm that will never be supported. Why talk about the HTML5 document outline then?

I’m glad you asked.

The outline may never be supported, but it was assumed that it would be when the new elements were defined. The outline does provide context for the intent behind the elements. It can help us understand how the elements were meant to be used. Even if the algorithm for the HTML5 outline is never supported, we can support the intended semantics through consistency of use.

It’s also an excuse to look at the structure of HTML in general. The industry talks about structure mainly in connection with presentation. It’s HTML structure for the purpose of doing something with CSS. Here we can talk structure more for how it relates to the content.

While the HTML5 outline algorithm isn’t supported anywhere, Tim Berners-Lee talked about something similar to the HTML5 outline a long time ago, so maybe something like it will be supported in time.

Note: As Šime points out in the comments, screen readers do map the semantics of the new elements to ARIA roles. Screen readers have issues with the new document outline and it’s not recommended for use, but, since they do map the semantics of the elements to ARIA roles, it means there is a good reason to use the new elements. My bad for not knowing this when I started on this series.

I’ll do my best to incorporate this information into the rest of this series. Some of the series is already written so my apologies if I miss something I should correct. If you notice anything in this post or the remainder of the series, let me know and I’ll make any appropriate corrections

Falling Back for Older Browsers

One more thing I’ll add to prep us for next week. The last time I talked about the new elements they weren’t supported everywhere. Today browser support is very good and can’t be used as an excuse not to work with the new tags.

Opera mini doesn’t support the main element and IE8 and below don’t support any of the new elements. They work everywhere else. How much longer you want to support IE8 and lower is up to you. Browser statistics suggest IE8 is still used by roughly 5% of people.

It’s easy enough to add support where needed. The new elements should be block level so for every new structural element you want to use you would add the following to your CSS.

section, article, aside, footer, header, nav {
  display: block;

IE8 and below also need the tags to be created. You can do that with simple JavaScript and a conditional comment.

<!--[if lt IE 9]>
     document.createElement("header" );
     document.createElement("footer" );
     document.createElement("aside"  );
     document.createElement("nav"    );
  <noscript>Some message for browsers with JavaScript turned off</noscript>

That’s it. Add the JavaScript and CSS and older versions of Internet Explorer will render your layout as intended. If that’s still too much for you, you can include the html5shiv polyfill, which will do all the work for you.

Closing Thoughts

I hope you don’t mind the wait to get to the HTML5 document outline, but since the goal of this revisit is to understand the outline for the context it gives to the new elements, I thought it made sense to get some context from HTML 4.

I debated whether or not to post any of this given that the algorithm for the new HTML5 outline will probably never be used, but if you’ve read this far, you know how the debate with myself ended.

The algorithm may never be used, but it can still provide context for the intent of the new elements. The context can help us understand how the new structural elements were intended to be used and that is ultimately the goal of this series.

Next week we’ll take a look at how the HTML5 outline is supposed to work. In the weeks following I’ll walk you through the structural elements and then provide a demo in which I’ll attempt to use the new structural elements in practice.

« »

Download a free sample from my book, Design Fundamentals.


    • My bad if it came across that way. The outline isn’t the only purpose for the elements, but it’s the context in which the elements were defined. Learning more about outline can help us understand when to use the new elements. That’s why I’m looking at the outline.

      I don’t think screen readers are currently doing anything with the new elements. I think you’d want to use ARIA roles for screen readers regardless of whether you use the new elements or not.

    • Good question and I’m not entirely sure. If you can wait a few more weeks (3 I think), I’m working on a demo using all the new elements.

      It doesn’t currently have social network buttons, but I think that would be a good addition. I’ll add some and talk about why I used the element I used.

      I’m not sure which I’ll use. As I’m replying to your comment, I think any of three might work, so I’ll need to think a little more.

      Hope you don’t mind the wait.

Leave a Reply

Your email address will not be published.