HTML5 And The Document Outlining Algorithm


By now, we all know that we should be using HTML51 to build websites. The discussion now is moving on to how to use HTML5 correctly. One important part of HTML5 that is still not widely understood is sectioning content: section, article, aside and nav. To understand sectioning content, we need to grasp the document outlining algorithm.

Understanding the document outlining algorithm can be a challenge, but the rewards are well worth it. No longer will you agonize over whether to use a section or div element — you will know straight away. Moreover, you will know why these elements are used, and this knowledge of semantics is the biggest benefit of learning how the algorithm works.


What Is The Document Outlining Algorithm?

The document outlining algorithm is a mechanism for producing outline summaries of Web pages based on how they are marked up. Every Web page has an outline, and checking it is easy using a really simple free online tool, which we’ll cover shortly.

So, let’s start with a sample outline. Imagine you have built a website for a horse breeder, and he wants a page to advertise horses that he is selling. The structure of the page might look something like this:

  1. Horses for sale
    1. Mares
      1. Pink Diva
      2. Ring a Rosies
      3. Chelsea’s Fancy
    2. Stallions
      1. Korah’s Fury
      2. Sea Pioneer
      3. Brown Biscuit

Figure 1: How a page about horses for sale might be structured.

That’s all it is: a nice, clean, easy-to-follow list of headings, displayed in a hierarchy — much like a table of contents.

To make things even simpler, only two things in your mark-up affect the outline of a Web page:

Obviously, the sectioning of content is the new HTML5 way to create outlines. But before we get into that, let’s go back to HTML 101 and review how we should all be using headings.

Creating Outlines With Heading Content

To create a structure for the horses page outlined in figure 1, we could use mark-up like the following:

   <h1>Horses for sale</h1>


   <h3>Pink Diva</h3>
   <p>Pink Diva has given birth to three Grand National winners.</p>

   <h3>Ring a Rosies</h3>
   <p>Ring a Rosies has won the Derby three times.</p>

   <h3>Chelsea’s Fancy</h3>
   <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>


   <h3>Korah’s Fury</h3>
   <p>Korah’s Fury has fathered three champion race horses.</p>

   <h3>Sea Pioneer</h3>
   <p>Sea Pioneer has won The Oaks three times.</p>

   <h3>Brown Biscuit</h3>
   <p>Brown Biscuit has fathered nothing of any note.</p>

   <p>All our horses come with full paperwork and a family tree.</p>

Figure 2: Our “Horses for sale” page, marked up using headings.

It’s as simple as that. The outline in figure 1 is created by the levels of the headings.

Just so you know that I’m not making this up, you should copy and paste the code above into Geoffrey Sneddon5’s excellent outlining tool6. Click the big “Outline this” button, et voila!

An outline created with heading content this way is said to consist of implicit, or implied, sections. Each heading creates its own implicit section, and any subsequent heading of a lower level starts another layer, of implicit sub-section, within it.

An implicit section is ended by a heading of the same level or higher. In our example, the “Mares” section is ended by the beginning of the “Stallions” section, and each section that contains details of an individual horse is ended by the beginning of the next one.

Figure 3 below is an example of an implicit section that ends with a heading of the same level. And figure 4 is an implicit section that ends with a heading of a higher level.

<h3>Sea Pioneer</h3><!-- start of implicit section -->
<p>Sea Pioneer has won The Oaks three times.</p>
<h3>Brown Biscuit</h3><!-- This heading starts a new implicit section,
so the previous Sea Pioneer section is closed -->

Figure 3: An implicit section being closed by a heading of the same level

<h3>Chelsea’s Fancy</h3><!-- start of implicit section -->
<p>Chelsea’s Fancy has given birth to 3 Gold Cup winners.</p>
<h2>Stallions</h2><!-- this heading starts a new implicit section
using a higher level heading, so Chelsea’s Fancy is now closed -->

Figure 4: An implicit section being closed by a heading of a higher level.

Creating Outlines With Sectioning Content

Now that we know how heading content works in creating an outline, let’s mark up our horses page using some new HTML5 structural elements:

   <h6>Horses for sale</h6>

         <h1>Pink Diva</h1>
         <p>Pink Diva has given birth to three Grand National winners.</p>
         <h5>Ring a Rosies</h5>
         <p>Ring a Rosies has won the Derby three times.</p>
         <h2>Chelsea’s Fancy</h2>
         <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>


         <h3>Korah’s Fury</h3>
         <p>Korah’s Fury has fathered three champion race horses.</p>
         <h3>Sea Pioneer</h3>
         <p>Sea Pioneer has won The Oaks three times.</p>

         <h1>Brown Biscuit</h1>
         <p>Brown Biscuit has fathered nothing of any note.</p>

   <p>All our horses come with full paperwork and a family tree.</p>

Figure 5: The horses page, marked up with some new HTML5 structural elements.

Now, I know what you’re thinking, but I haven’t taken leave of my senses with these crazy headings. I am making a very important point, which is that the outline is created by the sectioning content, not the headings.

Go ahead and copy and paste that code into the outliner7, and you will see that the heading levels have absolutely no effect on the outline where sectioning content is used.

The section, article, aside and nav elements are what create the outline, and this time the sections are called explicit sections.

One of the most talked about features of HTML5 is that multiple h1 elements are allowed, and this is why. It’s not an open invitation to mark up every heading on the page as h1; rather, it’s an acknowledgement that where sectioning content is used, it creates the outline, and that each explicit section has its own heading structure.

The part of the HTML5 spec8 that deals with headings and sections makes this clear:

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

I would strongly advise that until browsers — and, more critically, screen readers — understand that sectioning content introduces a sub-section, using multiple h1 elements is less safe than using a heading structure that reflects the level of each heading in the document, as shown in figure 6 below.

This means that user agents that haven’t implemented the outlining algorithm can use implicit sectioning, and those that have implemented it can effectively ignore the heading levels and use sectioning content to create the outline.

At the time of this writing, no browsers or screen readers have implemented the outlining algorithm, which is why we need third-party testing tools such as the outliner. The latest versions of Chrome and Firefox style h1 elements in nested sections differently, but that is very different from actually implementing the algorithm.

When most user agents finally do support it, using an h1 in every explicit section will be the preferred option. It will allow syndication tools to handle articles without needing to reformat any heading levels in the original content.

      <h1>Horses for sale</h1>


            <h3>Pink Diva</h3>
            <p>Pink Diva has given birth to three Grand National winners.</p>

            <h3>Ring a Rosies</h3>
            <p>Ring a Rosies has won the Derby three times.</p>

            <h3>Chelsea’s Fancy</h3>
            <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>


            <h3>Korah’s Fury</h3>
            <p>Korah’s Fury has fathered three champion race horses.</p>

            <h3>Sea Pioneer</h3>
            <p>Sea Pioneer has won The Oaks three times.</p>

            <h3>Brown Biscuit</h3>
            <p>Brown Biscuit has fathered nothing of any note.</p>

      <p>All our horses come with full paperwork and a family tree.</p>

Figure 6: Our horses page, marked up sensibly.

One other point worth noting here is the position of the paragraph “All our horses come with full paperwork and a family tree.” In the example that used headings to create the outline (figure 2), this paragraph is part of the implicit section created by the “Brown Biscuit” heading. Human readers will clearly see that this text applies to the whole document, not just Brown Biscuit.

Sectioning content solves this problem quite easily, moving it back up to the top level, headed by “Horses for sale.”

Mixing It Up

So, what happens when implicit sections and explicit sections are combined? As long as you remember that implicit sections can go inside explicit sections, but not the other way round, you will be fine. For example, the following works well and is perfectly valid:

<h1>Horses for sale</h1>


      <h3>Pink Diva</h3>
      <p>Pink Diva has given birth to three Grand National winners.</p>

      <h3>Ring a Rosies</h3>
      <p>Ring a Rosies has won the Derby three times.</p>

      <h3>Chelsea’s Fancy</h3>
      <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>

And it creates a sensible hierarchical outline:

  1. Horses for sale
    1. Mares
      1. Pink Diva
      2. Ring a Rosies
      3. Chelsea’s Fancy

Figure 7: Implicit sections created by headings inside an explicit section.

However, if you hope to achieve the same outline by nesting an explicit section inside an implicit section, it won’t work. The sectioning element will simply close the implicit section created by the heading and create a very different outline, as shown below:

<h1>Horses for sale</h1>


      <h3>Pink Diva</h3>
      <p>Pink Diva has given birth to three Grand National winners.</p>

      <h3>Ring a Rosies</h3>
      <p>Ring a Rosies has won the Derby three times.</p>
      <h3>Chelsea’s Fancy</h3>
      <p>Chelsea’s Fancy has given birth to three Gold Cup winners.</p>

This would produce the following outline:

  1. Horses for sale
    1. Mares
    2. Pink Diva
    3. Ring a Rosies
    4. Chelsea’s Fancy

Figure 8: Explicit sections can’t go inside implicit sections.

There is no way to make the explicit sections created by the article elements become sub-sections of the Mare’s implicit section.

You can use headings to split up the content of sectioning elements, but not the other way round.

Things To Watch Out For

Untitled Sections

Until now we haven’t really looked at nav and aside, but they work exactly the same as section and article. If you have secondary content that is generally related to your website — say, horse-training tips and industry news — you would mark it up as an aside, which creates an explicit section in the document outline. Similarly, major navigation would be marked up as nav, again creating an explicit section.

There is no requirement to use headings for aside and nav, so they can appear in the outline as untitled sections. Go ahead and try the following code in the outliner:

         <li><a href="/">home</a></li>
         <li><a href="/about.html">about us</a></li>
         <li><a href="/horses.html">horses for sale</a></li>

   <h1>Horses for sale</h1>



Figure 9: An untitled <nav>.

The nav appears as an untitled section. Now, this generally wouldn’t be a problem and is not considered bad HTML5 code, although in his recent HTML5 Doctor article9 on outlining, Mike Robinson10 recommends using headings for all sectioning content in order to increase accessibility.

Untitled section and article elements, on the other hand, are generally to be avoided. In fact, if you’re unsure whether to use a section or article, a good rule of thumb is to see whether the content has a natural, logical heading. If it doesn’t, then you will more than likely be wiser to use a good old div.

Now, the spec doesn’t actually require section elements to have a title. It says:

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.

Your interpretation of this probably hinges on your understanding of the word “typically.” I take it to mean that you need a damn good reason not to use headings with section elements. I do not take it to mean that you can ignore it whenever you feel the urge to use a new HTML5 element.

Where the article element is specified11, the spec goes even further by showing an example of blog comments marked up as untitled articles, so there are exceptions. However, if you see an untitled section or article in the outline, make sure you have a good reason for not giving it a title.

If you are unsure whether your untitled section is a nav, aside, section or article, a very handy Opera extension12 will let you know which type of sectioning content you have left untitled. The tool will also let you view the outline without leaving the page, which can be hugely beneficial when you’re debugging sections.

Sectioning Root

The eagle-eyed among you will have noticed that when I said that sectioning content cannot create a sub-section of an implicit section, there was an h1 (“Horses for sale”) not in sectioning content immediately followed by a section (“Mares”), and that the sectioning content did actually create a sub-section of the h1.

The reason for this is sectioning root. As the spec says13, sectioning elements create sub-sections of their nearest ancestor sectioning root or sectioning content.

Sectioning content2414 elements are always considered subsections of their nearest ancestor sectioning root15 or their nearest ancestor element of sectioning content16, whichever is nearest, regardless of what implied sections other headings may have created.

The body element is sectioning root. So, if you paste the code from figure 7 into the outliner, the h1 would be the sectioning root heading, and the section element would be a sub-section of the body sectioning root.

The body element is not the only one that acts as sectioning root. There are five others:

  1. blockquote
  2. details
  3. fieldset
  4. figure
  5. td

The status of these elements as sectioning root has two implications. First, each can have its own outline. Secondly, the outline of nested sectioning root does not appear in, nor does it have an effect on, the outline of its parent sectioning root.

In practice, this means that headings inside any of the five sectioning root elements listed above do not affect the outline of the document that they are a part of.

The final thing (you’ll be glad to hear) that I’ll say about sectioning root is that the first heading in the document that is not inside sectioning content is considered to be the document title.

Try the following code in the outliner to see what happens:

   <h1>this is an h1</h1>

<h6>this h6 comes first in the source</h6>

<h1>this h1 comes last in the source</h1>

Figure 10: How heading levels at the root level affect the outline.

I won’t try to explain this to you because it will probably only confuse both of us, so I’ll let you play with it in the outliner. Hint: try using different heading levels for the implicit sections to see how the outline is affected; for example, h3 and h4, or two h5s.

Untitled Documents

If no heading is at the root level of the document (i.e. not inside sectioning content), then the document itself will be untitled. This is a pretty serious problem, and it can occur either through carelessness or, paradoxically, by thinking carefully about how sectioning content should be used.

Roger Johansson17 addresses this issue in his excellent article on document outlines and HTML518 and the follow-up article19.

Johansson asks how a proper document outline is supposed to be created for a blog post or other news-type item using HTML5. If you subscribe to the belief that your logo or website name should not be in an h1 element, you could mark up your blog post along the lines of the following:

      <h1>Blog post title</h1>

      <p>Blog post content</p>

The document is untitled. Somewhat reluctantly, Johansson settles on marking up the website’s title in h1 and using another h1 to mark up the article’s title. This is a sensible solution and is backed up by the results of the WebAIM screenreader user survey20, in which the majority of respondents stated a preference for two top-level headings in exactly this format.

This same approach is also widely used on static pages that are built with HTML5 structural elements, and it could be very useful indeed for screen reader users. Imagine that you are using a screen reader to find a decent recipe for chicken pie, and you have a handful of recipe websites open for comparison. Being able to quickly find out which website you are on using the shortcut key for headings would be much more useful than seeing only “chicken pie” on each one.

Not too far behind two top-level headings in the screen reader user survey was one top-level heading for the document. This is probably my preferred option in most cases; but as we have already seen, it creates an untitled body, which is undesirable.

In my opinion, there is an easy way around this problem: don’t use article as a wrapper for single-blog posts, news items or static page main content. Remember that article is sectioning content: it creates a sub-section of the document. But in these cases, the document is the content, and the content is the document. Setting aside the name of the element, why would we want to create a sub-section of a document before it has even begun?

Remember, you can still use div21!


This is the final item in the list of things to watch out for, and it’s very easy to understand. The hgroup element can contain only headings (h1 to h6), and its purpose is to remove all but the highest-level heading it contains from the outline.

It has been and continues to be the subject of controversy, and its inclusion in the specification is by no means a given. However, for now, it does exactly what it says on the tin: it groups headings into one, as far as the outlining algorithm is concerned.

In Conclusion

The logic behind the document outlining algorithm can be hard to grasp, and the spec can sometimes feel like physics: understandable as you’re reading it, but when you try to confirm your understanding, it dissolves and you find yourself re-reading it again and again.

But if you remember the basics — that section, article, aside and nav create sub-sections on Web pages — then you are 90% of the way there. Get used to marking up content with sectioning elements and to checking your pages in the outliner, because the more you practice creating well-outlined documents, the sooner you will grasp the algorithm.

I promise, you will have it cracked after only a handful of times, and you will never look back. And from that moment on, every Web page you create will be structured, semantic, robust, well-outlined content.

Other Resources



  1. 1
  2. 2
  3. 3
  4. 4
  5. 5!/gsnedders
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10!/akamike
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28

↑ Back to topShare on Twitter

Derek builds websites at WebsiteNI and helps curate the HTML5 Gallery, where he gets particularly hung up about document outlines. His favourite place in the world is the Mourne Mountains but you are more likely to find him lurking on Twitter.


Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    “By now, we all know that we should be using HTML5 to build websites.”

    I’ll quote this the next time one of my clients, that has 250+ PCs running Internet Explorer 7, wonders why the marketing department can’t view their lovely new website correctly.

    Until older browsers are finished, done with and dead, statements like that will continue to boil my blood.

    As a very learned web developer once commented on this very website. A developer who ignores certain browsers, is a bad developer.

    However, a very informative piece after that.

    • 2

      I think there is a solution to your problem — it is called javascript… ;)

      • 3

        The thing is: there’s just still not enough full support for HTML 5 in the average browser use. yet every litte blogger keeps on yelling about why to USE HTML5 NOW and WHY and THIS and THAT!

        Why would i STILL build my website in HTML 5 and then jump through javascript hoops to make them work in de main used browsers of the visitors the site is targeted for? Because someone says it in an online article?

        Very very wrong. All those articles like this and on all the other blogs are realy great, but people tend to forget that there is a big change the writer of the article is even a bigger newbie than the one who’s reading it. SO it’s for readers best not to believe things just because they are written in a blog post or article.

        Obviously, if one (even in these times) says that everyone should be using html5 by now, they clearly are no professional in the business OR either only working on more experimental projects OR even more for webbased apps or for mobile devices supporting html5. But in anyway not for the more commercial goals.

        Wanta professional’s opinion? : Do stay up to date with HTML5, but don’t force yourself into using it and keep your audience in mind while choosing to do so.

        Please keep in mind that i still DO like this article. It’s nicely written and very clear. So thx for that!

        • 4

          We can s t a r t to use html5 today with html5shiv, modernizr or other compatibility tool, for exapmle. And the first one, from what I know, doesn’t require enourmous resources.

          • 5

            Indeed… if an HTML5 website works fine with javascripts such as Modernizr, Selectivizr, etc… why not use it? You just can’t use HTML5 to it’s full potential yet, but you can still use the basics. That way you and the product are prepared for the future.

            Of course if you’re dealing with a client who still uses IE6/IE7 at the office and has customers who do the same… it’s not really smart to use HTML5 or javascript at all.

      • 6

        You solution is to add even more work/time/code? And since calling HTML5 tags in CSS won’t work on any but the newest browsers, you usually have to wrap in XHTML. I love HTML5, but it’s not 100% viable right now. If anything, using it to much kinda makes you have to do more work.

        • 7

          well html5 is there to make your website more interactive than before, even though not every browser can benefit from it, it doesn’t stop you to help people that are more capable and enhance their mobile experience also.
          What I like is that it makes everything semantically correct, and I think it does help a lot for seo (not too sure though)

      • 8

        Nice one…lol

    • 9

      “By now, we all know that we should be using HTML5 to build websites.”

      A sweeping statement for sure. I think though, that any developer worth their salt knows that the use of HTML5 is based on the target audience or demographic of the site. Developing a site for older browsers (corporate intranet or whatever) then you will want to think hard about whether HTML5 is a good option. Targeting smart phone users; HTML5 is your friend.

    • 10

      “A developer who ignores certain browsers, is a bad developer.”

      A developer who says “A developer who ignores certain browsers, is a bad developer.”, is a bad developer.

      • 11

        Neither of the above statements are related to “bad developer”. A bad developer is a developer that doesn’t push himself to constantly improve. complacency is our enemy.

        “By now, we all know that we should be using HTML5 to build websites.”
        It depends on your audience obviously, most of my clients are still using ie7/8 and some of the account managers, unfortunately we have to deal with it. I personally don’t like adding extra code to a page when its not 100% needed, so adding shims hurts me a bit…

    • 12
    • 13

      Brandon Barringer

      August 16, 2011 5:56 am

      It is this school of thought that has some developers still using tables. HTML5 is a very realistic way to code right now, with all the shims and polyfills available almost all sites can be coded with HTML5. Even if JS is not available to some users a simple display:block css code will get you moving on the layout.

    • 14

      Abbas what will you do when the marketing chief will ask you why your website that was build several months ago already uses old technologies from ten years ago? Will you tell them that you have ignored webstats telling you that most browser can handle html5?

      Will you tell them that users that complain that the website can be viewed on their tablet, that you didnt use media queries and now want more time or money to create a special tablet version of the website?

      We all know we cant ignore ie7 users until the stats show us that they dropped below 1 percent. But there is a trick, build a html5 and ensure it degrades gracefully, there are lots of tools out there that will help you.

      Maybe you will have used flash and probably your website will lack lot of modern features that other marketing teams have used to build their website.

      Even worse, maybe your website will lack usability because it hasnt the modern html5 enhancements or isnt semantically less usefull for search engines which will result in bad SEO and therefore your website will always show up behind your opponents website in the results.

      In my opinion every dev that builds a website today and doesnt ensure it is at least html5 ready is a bad developper!

      • 15

        I almost laughed out loud when I read this, a marketing manager wouldn’t even know how to phrase the question, he wouldn’t have clue. He probably wouldn’t even realise that the site uses new/old technologies unless your really crap at your job i.e. things aren’t working. Sorry, but the fact is most of people in the world just don’t have a technological clue how they get their websites. People still get flash websites done, despite being warned about the limitations. HTML 5 is worth adopting but your opening line is not a good way to go about convincing anyone to use it.

        • 16


          I disagree. I’m a marketing manager and I’m most definitely interested in the quality of a developer’s code. As someone who’s hired programmers, designers and developers, I have a duty to understand at least the fundamentals of Web technology.

          If I look at a developer’s code and see table layouts, I’m without a doubt not hiring that developer.

          On a deeper level, the line between developer and marketer is getting grayer. As marketers, we have to be fully aware of Web developments as they’re increasingly vital to our success. Clean code, versatile design, rich data structure, and lightweight operation is essential for us as they drive our ability to provide a good experience to customers – and therefore encourage customer engagement.

      • 17

        This situation will never occur. No “marketing chief” will be discting the source of a website, or keeping up to date with the latest bleeding-edge web tech that’s nowhere near fully supported yet. If the website works, is valid, and makes money, nobody cares what’s running under the hood. In fact, writing everything in a way that excludes a large percentage of browsers is not only ignorant, but any professional web developer doing that should consider a change in careers.

        Web development isn’t a hobby to some of us.

      • 18

        If a website doesn’t work on the computer that is sat on the marketing “chief’s” desk then, for them, it doesn’t work full stop.

        Thankfully, it doesn’t happen on every project. In fact, i’d say 80-90% of the clients that I’ve worked with are more than willing to embrace new technologies. But there is always the other 10%.

        If I’ve already built a website for a particular client then the technology/browser discussion will already have been had, and in some detail. So if they then decide to come back in eight months time and complain it’s not inline with the latest technologies then I’m afraid extra time will be needed to make that particular person happy.

        I’ve been in plenty of meetings, armed with plenty of stats, but until you appease the person signing the cheques everybody else has to wait.

        We have to service our clients first, and our egos second.

        I’ll ignore the Flash comment.

    • 19

      Use (for example) to serve older versions of IEs!

      There is NO REASON at all to use div instead of semantic containers. No matter if you have to support old IEs or not.

      If you think, supporting different browsers by refusing to use actual techniques is a lot of work, you should learn some more things about HTML5 and how to implement things. And if you really try to make sites, which will work in all kind of user agents (and not just browsers) HTML5 is a big help!

      • 20

        What I meant:

        If you think, supporting different browsers by refusing to use actual techniques is a good idea and causes less work,

    • 21

      If you build a website with only 250 PCs on a single browser in mind I think you should focus your learning on the definition of the internet.

      If you believe your clients marketing department are only satisfied with an output that meets their own internal requirements you have misinterpreted their role within the business.

      To assume working in HTML5 means you ignore browser versions as recent as 7 is naive.

      If you had said: “I am comfortable delivering quality websites in XHTML and believe I can do this for my client effectively and efficiently so see no need to change my current working habits.” This would have left me respecting your, and other tribute bands, opinion but you have not said that.

      As I have said before, no other industry waits for technologies to disappear before moving forward, their advancements drive the market, not the other way round (E.G. Video to DVD to Blu-Ray for example) . The benefit of our industry, however, is that we can still produce sites that deliver to the older technologies whilst using the advanced ones.

      Furthermore I would like to dispel the myth that the experts and peers that provide us with these great articles somehow have magical clients that ask for experimental sites. The notion that there are whacky clients asking hip developers in lab coats to do bizarre things like code in HTML5 and use CSS3 is frankly misplaced. They have normal clients, they just do cool stuff because they choose to and manage to position themselves as the experts, educate and enthusing their clients to want the best.

      Opting to stick to XHTML because your client has IE7 is like standing on a melting icecap in an ocean of ‘crazy’ and ‘modern’ things that end in numbers higher than 1.

    • 22

      I love how you say ” A developer who ignores certain browsers, is a bad developer”. This tells me that you haven’t been developing professionally for very long.

      I’ve been developing professionally for over 10 years and I can tell you for certain your explanation needs to be expanded to provide more information because as the comments towards you have shown your statement as it stands is quite invalid.

      Web development is so much more then just using HTML5 and just making sure your code displays correctly on all browsers, there are compromises that sometimes have to be made during all development work.

    • 23

      I can see where you’re coming from, to ensure that your projects are as cross browser compatible as possible, but HTML5 ensures that your sites will work in the future, and still be cross browser. I feel that developers who get caught up trying to make things work in older browsers hinder progress.

      I am fairly new to working in the industry, but I’ve been in the technology game for a while now. I always thought it was more important to look at who the market is for what it is you’re making (thats kind of a no brainer). There are more benefits to starting a project in HTML5 as opposed to keeping your work in older technologies to ensure browser compatibility. Those browsers will disappear eventually, and in instances where it sticks around, the mass of people who can, and are taking advantage of these new technologies like HTML5 and CSS3, out weigh the users of older less standard browsers.
      Development is about progress, and creating great user experience, having to stifle what technologies I use because of older browsers isn’t progress (I know we all know the frustrations that come with the evils of IE6/7), but browsers are encouraging updates regularly, look at mozilla, i haven’t had to give permission for an update in the last 4 or 5 versions, and Firefox still has the largest share:

      I guess my point is, this shouldn’t boil your blood, it should encourage you? Technology is all about moving forward, and I know we don’t want to cut any users out, but theres still a cost – benefit analysis you should make, and I feel now, most projects, developers should be using HTML5. Existing projects should be evaluated, especially if they weren’t built using standards of the time.


    • 24

      I often face the problem of clients using older browsers such as IE7. But I don’t let it stop me using HTML5.

      Firstly, I educate the client. Let them know that the browser they are using is not secure and support for it is fading. I then suggest they update to chrome or firefox.

      Secondly, I ensure that all websites I make have the correct fall backs in place to deal with the stone age browsers. I believe that a website doesn’t need to work identical on both chrome and older browsers. I believe that a website should degrade well.

      I can’t play Xbox 360 games on the original Xbox. I would have to buy (upgrade to) a new console. The same applies to websites. If a user wants the full experience they will have to upgrade. If not, then they will have to stick with the degraded less featured version.

      The web is changing. Less and less support is around for people in the stone age.

    • 25

      I work in a corporation where users have either Internet Explorer 7 or Internet Explorer 8 on their desktop machines. Many employees have iPads and iPhones that they use to view intranet resources and applications. In my last development project I did use HTML5 and CSS3 with graceful degradation where necessary. IE won’t get all of the bells and whistles, but the experience in IE is not broken by any means. Yes, I did have to include a small .js (the html5 shiv) file so that IE could understand the new elements, but it is was a small price to pay.

      I understand your sentiment… many of the blog posts you find online promoting HTML5 are likely not written by developers who work in corporate environments or deal much with legacy browsers (as a core requirement of any project)… but I would encourage you to take HTML5 for a test drive and see for yourself what it can and cannot provide in your environment. As for me, I plan to leverage it as much as I can.

    • 26

      Older browsers are a security risk, are they not?

      It is now 2013

  2. 27

    Pardon me if this is a newbie question, but I skimmed your source docs and did a little Googling and I’m not finding an answer: what do older browsers (read: IE 8, 7, 6) do with these elements? How do they display them? Is there some kind of workaround? What’s the benefit to using “article” or “section” instead of a div?

    • 28

      Workarounds are available but you will need to figure out which is best for you.

      Personally I use Remy Sharps HTMLShim which can be added to your HTML5 document header in a set of conditional comments like so:

      Other’s who delve more into CSS3 and other HTML attributes like Modenizr for its ability to combine the above shim with a bunch of other features. For me though I don’t find myself needing all that it can offer, and even with their “build your own” script I find myself being better off with the Shim.

      As for the benefits of using sections and articles, I am not experienced enough in using them to say. :-)

      • 29

        It didn’t show the code, but search for Remy Sharps HTML Shim and you will find it. Google provides a hosted option too.

    • 30

      Oh, older browsers break as they don’t understand the basic styling of these elements as blocks. You will need to add some styling for those particular items. Many HTML5 CSS Resets are available now and that seems to do the trick.

      They tend to look something like:

      article, aside, dialog, figure, footer, header, hgroup, nav, section { display: block }

    • 31
  3. 32

    This was one those things that I had to study hard to understand when I first started using HTML5. Now I never start a project without considering using at the very least structural tags like the header, nav, aside, or footer.

    I have been mainly designing static websites so haven’t really had a chance to to start sectioning articles like blog posts but I intend to start soon.

    Great article though, hopefully it will encourage some of my local designers to start using HTML5.

  4. 33

    Nice article! How about search engines? Does sectioning content with HTML5 have a positive influence on SEO?

    • 34

      As far as I know using sectioning content has no major effect on SEO either way.

      • 35

        I think it WILL make a differences, if not already. Using semantic containers gives the SE interesting informations about the content of a site and the importance of certain sections.

    • 36

      Derek Johnson mentioned that there is “no major effect on SEO either way,” and he’s right — for the time being. In the future, it’s very possible that search engines will take advantage of site structure and HTML document outlines, but only as long as we all decide to stick to good code and write to a semantic standard.

  5. 37

    Also, don’t forget each can have a and a . or can be used if the article has multiple headers. is pretty useful for meta information (“0 comments | Published on 15 August 2011 | Category: Monkey Business”).

  6. 38

    In figure 5, isn’t the whole thing an article and each piece of content referring to a different horse a section of that article?

    • 39

      It could be John, depending on its context. I used div in the example so as not to create an untitled section when pasted into the outliner, but if there was another part of the page detailing donkeys for sale it could very well be enclosed in an article or section.

  7. 40

    While the html5 debate starts to boil up again; is there anyone who knows or recommend a good book about html 5 ?

    I though it might be nice to have things clear in a book rather that 100 different sites

    • 41

      There are very good online courses on I’ll recommend “Structure, Syntacs and Semantics” by James Williamson.

    • 42

      HTML5 & CSS3 by Brian Hogan from Pragmatic Programmers is pretty good.

    • 43

      Two reliable books on the topic I’m familiar with are HTML5 For Web Designers by Jeremy Keith or if you want coverage on CSS3 too there’s HTML5 & CSS3 for the Real World by the guys over at Sitepoint.

  8. 44

    If you have been building html for a long time, the transition to html5 is simple, you’ll have been building page frameworks with ID’s of header, footer, nav et al for years before somebody shouted loudly ‘DONT USE ID’ so then you will have changed it it to CLASS.

    For many it’s just a few less characters to write.

    Where it really becomes interesting is in the mechanics behind it – or what in theory it should/will do.

    There is going to be far more intelligence within the document for a browser to analyse and interact with. But it isn’t there yet.

    Put it in now because it really isn’t going to ‘break’ anything as somebody wrote.

    I’m thinking of it like an appendix. we’ve all got one but they don’t work haven’t for a couple of thousand years. But! when the apocalypse comes, we’ll all be using them.

    HTML5 is the apocalypse appendix

  9. 45

    Still the examples are always a simple blog structure or a list of text items. I would like the ‘experts’ to show how to use these tags on a more complex structure, like web applications with different forms on the same page, or different layouts.

  10. 46

    Lyndas series is really helpful and all the smashing mag articles too.

  11. 47

    I believe the ‘article’ and ‘section’ are reversed in the first image. At least according to the examples given in the rest of this post, ‘article’ goes inside a ‘section’ and not the other way around.

    • 48

      Both ways are “correct” if you check the spec. But yes, they should explain better those details.

    • 49

      There’s nothing to say article can’t be nested in another article, or section sit inside article. Similarly section can (and often is) nested in section.

      It depends on the content contained in the element, not its parent.

  12. 50

    The first image was replaced. Thanks for the feedback, guys!

  13. 51

    I have to disagree with not using the article tag to wrap a single blog post. It’s structurally necessary. The blog post isn’t the page, but a part of the page. Your page footer, navigation, and sidebar are not part of the post. But like the post, they are also part of the page.

    In fact, a blog article has it’s own header and footer, and can even have asides. These are completely separate and so must all be wrapped in the article section tag. In this way, the entire piece can be republished on another page without altering the structure.

    • 52

      You make a very good point Jeff about republishing, and I alluded to that in the article. However that is only clean if you are putting your site title/logo in an h1, which itself isn’t totally clean.

      I really don’t like the idea of an untitled document and I don’t think it is structurally necessary to create a sub-section of the document in this way. Jeremy Keith’s journal entries are a good example of not using article for single posts.

      It is a difficult one though, and there is no perfect solution. Do we forego sectioning content and do without header, footer and aside where perhaps semantics suggest their inclusion; do we create an untitled document; or do we put the site title in an h1 and give each document in the blog the same title?

      I guess the answer is, as with everything else in web development, “It depends.”

  14. 53

    Great article, i really enjoyed reading this. Thank you.

  15. 54

    And that right there makes writing it 100% worthwhile. Thank you Abogado.

  16. 55

    There are still some users/clients who are using IE6 (major clients), what about them? It’s not the case that they are unaware of new browsers, it’s just they don’t want to change.

    It’s quite strange but true that we should kill older browser first and then start talking about HTML 5.

    Thanks for the article. Nice one.

    • 56

      Yes! I used to have a 45 mnutie commute (one way) when I was attending community college. And given the fact that all science professors think their students ought to be ready to learn at 8am, that meant I had to leave my house 6:30! I still can’t believe I did that for two years straight before moving closer to school. And that was before I started drinking coffee! How’d I do it?! Now I’m lucky to be living only 15 mnuties away from my job!

  17. 57

    I’m sorry but today it’s not time to start to build the sites in HTML5… It’s like in 1999 the people that said was time to build the sites with DIVs and not tables… Remember IE3 or Netscape? Come on, use it for develop APPS for Android or iphone or experimental websites, but not for common sites :)

  18. 58

    I agree with this 100% but you do have to judge how much html5 you use depending on the client.

    If anyone is having problems selling this into their clients have a read of this “Dear Clients, The Web Has Changed. It’s Time To Use CSS3 and HTML5 Now.” published in the code area of this site.

  19. 59

    So I am a bit new, but I create a web page in html and then use CSS and have a wrapper with a header, main content, sidebar and footer at the bottom … all divs. Does HTML 5 take away the use of that CSS frame work?


  20. 60

    Maybe YOU should be using HTML 5 to build YOUR website… or maybe, you don’t build website by 10 years, so, you ignore that most of your customers won’t be so happy with their IE 6! (I swear!!)

    And, just to rember, the client is always right. Use HTML 5 when the client is YOU, for sperimantation or for fun, wait your chance of building a VERY USEFUL HTML 5 website.

  21. 61

    Huh. How’s that outline generated, I wonder? Probably a finite list of well-defined instructions. That would be an effective method.

  22. 62

    Derek, I’m a bit confused. :/

    You say no browsers or screenreaders (and later, no search engines) use the document outlining algorithm. Because of this, you recommend against using the nested h1 structure that is foundational to the outlining algorithm.

    So.. why the article then? What is the practical result in refining your document outline?

    • 63

      Personally Paul, when I got a grasp of the outlining algorithm I created documents with better structure, the penny dropped with when to use sectioning content, and the semantic meaning of sectioning content became a lot clearer.

      I read dozens of articles, blog posts and resources about section, article, aside and to a lesser extent nav, and just didn’t get it until I understood the algorithm.

      I see it that way round: learn how the algorithm works then learn how to use new HTML5 elements.

      Developers with this knowledge won’t do find/replace on div/section, won’t use section or article as a generic wrapper, and won’t use <section style="clear:both"></section>, all of which I’ve seen in sites submitted to the HTML5 Gallery.

      Creating outlines just for a tool that reads outlines would be at best pretty anal, but arming one’s self with the knowledge required for when users agents do implement the algorithm, and maintaining a practical outlook on the situation right now is worthwhile in my opinion.

  23. 65
  24. 66

    This part of HTML5, the more semantic side dealing with section, article, aside and nav, is kind of flawed in my mind.

    A couple of things I’ve noticed which make it really hard as a designer/developer to adopt these particular HTML5 tags:

    1. Tags are more difficult to understand, learn and implement correctly.
    2. Additional semantics adds more markup than the previous model.
    3. H2-H6 tags are “almost irrelevant” in the new model (not such a big deal)
    4. New doc outline model relies even more heavily on human input than previous models.

    At this point, machines should be adapting to us, not the other way round. Search engines like Google should be able to, and I assume already do, organically discern document outlines and correct semantics for webpages.

    Realistically, what is the benefit of these added semantics? Will our search results be improved because of the new doc outline model? Remember, the end user doesn’t see any difference, developers are forced to add more markup to pages and learn what seems to be a complex and bloated model so that search engines can more easily discern semantic markup? Is this what we’re talking about? Surely Google’s search algorithms are sophisticated enough to organically discern the existing doc model.

    The one area I can see the new semantic tags making more sense in the future could possibly be for web-based applications where content might be complicated enough to require these tags. Also, the nav tag seems like a logical addition. Ideally though, we should be reducing the number of tags and letting the system organically do the work.

  25. 67

    i would say this every project is different, you should know whats best for your targeted users,
    when you know your users you will end up knowing if you should or shouldnt use html5 or css3
    or anything , however there is some hml5 features you can use in every project with very little fallback

    always ENHANCE

    at last i think this a great article

  26. 68

    Christian Krammer

    August 29, 2011 5:13 am

    Great article! Although I have read about this topic again and yet again (and sometimes I already thought I understood everything) it made things clearer a little bit more. Hope that I better get it this time. ;) All that really is a tough topic.

  27. 69

    I’m not reading anyone addressing the question of types of web pages that simply DO NOT FIT into this model of nav, section, article.

    For example, a single page site announcing a book being released. Should I shoe horn the book tile and call to action button into a section/article? And then put the background info on the book into ANOTHER “article”? Should both “articles” be in a “section”?

    I guess the book title and download button could be a “free-standing” article, but really, it seems to me like html5 is turning the language of the web into the model of blogs and blog posts. And not every web page fits into that model. IMHO.

  28. 70

    Doc Outline Algorithm? Don’t worry about browser support.

    Because in a year no SEARCH ENGINE will be using it. Doc outline is all relative, and will be exploited/over-used. Just like ‘meta-tag=keyword’ was 10 years ago. Once this hits the ‘bush leagues’ Google won’t care about your doc outline.

    The same site you reference: states the ‘mircodata’ helps search engines, does not affect rank. Microfromats are pre HTML5, far more descriptive, far more accessible, but search bots don’t care. Google even says to help you search rank WRITE VALID, CROSS BROWSER ACCESSIBLE HTML
    I code close to the HTML5 doc outline now, mainly to get in the habit.
    However, any enterprise level site/slash offshore dev team… forget it. I like to use W3’s unicorn on Conference Calls to prove the back messed up the front with crazy iframes, inline styles, open tags etc. You can’t play the standards card with HTML5.

    Just wait a year, see what happens, unless your Client is Small and or Progressive.

  29. 71

    So… what if my outline is messy? Will my users care? Will they see the content correctly? Will google care?

  30. 72

    Would it be acceptable to place h tags where they are needed for the document outline and then hide them?

  31. 73

    Excuse me, i’m want to ask if this is right.

    At the description on, they say:
    “In HTML4, every section is part of the document outline. But documents are often not that linear. A document can have special sections containing information that is not part of, though it is related to, the main flow, like an advertisement block or an explanation box. HTML5 introduces the element allowing such sections to not be part of the main outline.”

    Then why on the outline tools, the element shows up as part of the outline?
    Sorry I’m new in this html5.

  32. 74

    still the best write up on the internet of the document outlining algorithm. And your reply to Mr. Irish is spot on. Thanks for the work.

  33. 75

    For me, this is the best written article about the HTML5 outline. It’s written so that this, that I have found very hard to understand, suddenly is quite easy to grasp. Thanks!

  34. 76

    What a detailed explanation of the use of outline algorithm , thanks for such a great and informative article

  35. 77

    Hi Derek,

    Thank you for the wonderful article, it really helped me alot, but I still have one question :
    What should be my Document Outline ? 1). the Website Title or 2). The Page Title ?

    In case#1, the Document outline stays same for all the pages, because its the Website title, which will be same throughout.
    1. My Website
    – 1. My Portfolio
    – – 1. project#1
    – – 2.project#2

    Or I shall change Document outline starting from My Portfolio ?
    1. My Portfolio
    – 1. project#1
    – 2.project#2

↑ Back to top