HTML5 Structural Elements — Series Wrap Up

For the last month and a half I’ve been trying to better understand how to work with the new HTML5 structural elements with some degree of success as well as failure. Now that the series is done, what did I learn?

HTML5 Logo

I’ve talked about the document outline, the definitions of the new elements along with the definitions of the ARIA roles each maps to, and then I offered a demo and explained my choices for using and not using the new elements. If you missed any of the previous posts, here’s the entire series to this point.

This is the last post in the series. When I started the series I’d characterize myself as something of a hostile witness to these new elements. I didn’t expect to find any reason to use them beyond this series.

I was wrong and I thought I would conclude the series by sharing what I learned working on it and how I plan to incorporate the new sectioning and non-sectioning elements in my work.

Document Outline

When I finished the demo I thought why not check what the HTML5 document outline would be. I know it’s not in use anywhere, but I was curious and thought I’d take a look and see if I could learn anything. I ran my HTML through one of the outliners and here’s the outline that was returned along with the elements that create each new section.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1. Document<body>
    1. Section<section>
    2. Navigation<nav>
    3. Demo to explore html5 Structural Elements<article><h1>
        1. Section<section>
        2. Basic Structure<h2>
            1. CSS Presentation<h3>
        3. Thoughts About HTML5<h2>
        4. Section<section>
            1. About Steven Bradley<section><h3>
        5. 3 Comments<section><h2>
            1. Article<article>
            2. Article<article>
            3. Article<article>
    4. Sidebar<aside>
    5. Categories<nav><h3>
    6. Connect<aside><h3>
    7. Example Sites<aside><h3>
    8. CSS Layouts<aside><h3>
    9. Sponsored by<section><h3>

The outline shows I’ve set up each block of content inside the header, footer, and sidebar at an equal level in the hierarchy to the article.

I tend to think the main content of any page sits at a higher level in in the hierarchy than the boilerplate content, but that’s not how I structured my HTML according to the algorithm for the HTML5 document outline.

Again the algorithm that produced this outline isn’t in use, but it does make me want to think more about how we structure content as part of the hierarchy. Should information in a sidebar sit at the same level in the hierarchy as the main content?

I don’t know, but it’s a good question to ask and think about. If sidebar content should be at a lower level in the hierarchy, it suggests I should find a different way to markup sidebar content. For example changing div class=”sidebar” to aside class=”sidebar” places the sidebar container at the same level in the hierarchy as the article, but the content within the sidebar would be one level lower.

1
2
3
4
4.Sidebar<aside>
    1.Sidebar<aside>
    2.Categories<nav><h3>
    3.Connect<aside><h3>

I think you can make a case that this kind of outline makes more sense than the one I created with the structure I ultimately used. On any given page the content of the page should be seen as more important than boilerplate content. Of course, to follow through the rest of the boilerplate would need to be marked up with sectioning elements so header and footer elements wouldn’t make sense.

I’m not sure which is the better structure, but it’s worth thinking about in this context. One of the things I learned these last few weeks is it’s worth spending more time thinking about the structure of our HTML and what it communicates.

What I learned About HTML Writing This Series

I sometimes mention how many posts here come about from my wanting to learn something. This series didn’t start out that way. I began what I thought would be a single post about the HTML5 document outline after a comment Jordan left on a post about why I don’t use the new HTML5 structural elements in practice.

I may have thought it would be a single post, but something in the universe had other plans. The more I looked at the document outline and the new elements, the more confused I felt and the more research I did to try and clear the confusion.

Comments by Šime on the first post in this series let me know I’d missed something important about the new elements where assistive devices was concerned. I went back for more research and rewrote much of the series at that point.

All the research and revisions led to a lot of back and forth in how I feel about using the elements and how well I understand them. Both had me wondering if I would use the elements in practice once I concluded the series.

As I reworked the demo and continued to discover more information, particularly the ARIA role definitions, I had a few realizations.

  • There is a benefit to using the new elements, which is what they communicate to assistive devices.
  • Despite what I still think are somewhat confusing guidelines for their use, if we as an industry use the new elements consistently we’ll give them more standard definitions through our use.
  • The structural patterns I currently work with didn’t spring forth overnight. I’ve spent nearly a decade evolving these structures so why should I expect anything different with the new elements.
  • A large part of my confusion comes from lack of working with the elements I want to understand. More practice should lead to more understanding.

I know many of us like to think we’re always making objective decisions when we design and develop websites, but there’s a lot more subjectivity in our decisions than we might care to admit.

The structure we choose for our HTML is also subjective. There’s no single right way to structure the HTML for a web page. Different developers will make different decisions that work. Take navigation as an example. I build navigation with an unordered list. Others use ordered lists. Two more common patterns for navigation bars are inline-blocks and CSS tables.

Any of these approaches is fine. They each have a few tradeoffs that may or may not affect a specific project, but more likely each is used based on the personal preference of the developer.

It will be the same with new elements like section and aside. We’ll need to work with them awhile to develop the patterns we eventually use and there will likely be several common patterns in use across the industry.

Incorporating the New into the Old

I did gain a new appreciation for the value and use of the new elements and I would like to use them more. I had forgotten, but I did use the HTML5 elements when I developed this site’s current design.

I think the easiest way to use the new elements is to incorporate one or two at time into your work. A few of the new elements do replace a div and class combo you probably use and the new element is meant to work the same way.

We can start by making the following substitutions.

1
2
3
4
<div class="header">  -->  <header>
<div class="footer">  -->  <footer>
<div class="main">    -->  <main>
<div class="nav">     -->  <nav>

You barely have to alter your CSS practices with these changes. Instead of .header you’ll write header (with or without an additional class). Same for the other three elements. From here you can experiment.

With the header and footer elements you can decide if you only want to use them once each per page for site headers and footers or if you want to integrate them more through your document. Spend some time researching the use of headers wrapping h1–h6 headings at the start of any new section in the outline.

Do similar with the footer element. Do you think a footer is a good call for meta information inside an article? Put in some time thinking about it and decide for yourself. You can always change your mind later.

You can do the same with the other three elements. Enclosing your main content inside an article element is another painless switch. Whether to structure blog comments or forum posts as articles is a different question. Again, research, try, and think critically about the decisions you make.

I had a hard time sorting out how to interpret related and tangential making both asides and sections confusing at times. Some of my confusion was my misunderstanding of the spec’s definition of related to what.

It’s something I’ll continue to think about and I suspect as I gain more information and put more thought into the problem, I’ll come to a more confident decision about using asides and sections.

I know I wasn’t an expert in using divs and spans the first time I used CSS for a site layout. None of us was. It’s the same with these elements and the structural patterns we’ll eventually settle into.

One last thought for the future is to continue to check your document outline. Despite the lack of use for the HTML5 document outline algorithm, it can be a useful tool for seeing how you’ve structured your page and what you’re communicating with that structure.

Closing Thoughts

I learned a lot more than I expected when I started this series. I admit to going in as a hostile witness. I’ve come out the other side with a greater appreciation for and a greater desire to use the new elements more.

At the start I didn’t see any harm in using the new elements, but I wasn’t seeing any benefit either. That changed when I learned the new elements communicate to assistive devices.

If you’re still on the fence, I recommend coding a demo of your own. Develop one of your typical layouts for a web page and use the new elements when doing so. For each part of the document ask yourself what elements you might use and think about the pros and cons of each.

I was able to work through a lot of my confusion only when making real decisions about what element to use.

I’ll add one last reason for working with the new elements before closing. Sometimes it’s just good to shake up your routine. It’s easy to become too comfortable with a way of doing something. I found myself thinking about and questioning some of my common practices because I forced myself to change those practices with the new elements.

If you take only one thing away from this series, take the idea that critical thought about how you structure your HTML is worth the investment. The new HTML5 elements give you a perfect opportunity to do that, especially if you aren’t yet working with them.

I think many of us take the structure of our HTML for granted to some degree. We use the same patterns we’ve used for years and don’t consider if they could or even should be improved.

Change for the sake of change gets you to question your current practices and think about a lot of things you possibly take for granted. Think of it as a spring cleaning for your coding practices.

I hope you enjoyed this look at HTML structure. It’s been a few more weeks than I originally expected and I think it’s time to finally put this series to rest. Maybe I’ll report back after using the new elements more often in practice, but for now it’s time to move on to another topic.

Download a free sample from my book, Design Fundamentals.

7 comments

  1. hi steven, i really enjoyed the articles, they were very insightful! i am having a bit of a trouble on the aside issue though, maybe you can give me a hint or suggestion how you would mark up the following situation (main content and some modules with “related” content, were the modules can be reused on other pages as well):

    <article>
    <h1>Cars and Bikes
    <p>Main content about cars and bikes…

    <a>Some more specific information about A
    <a>Some more specific information about B
    </article>

    <aside>

    <section>
    <header><h2>Our Services
    <ul>
    <li>Service 1
    <li>Service 1
    <li>Service 1

    </ul>
    <a>See all our services
    </section>

    <section>
    <header><h2>Our Team
    <ul>
    <li>Marc Marco
    <li>Timmy Thomas
    <li>Maria Mara

    </ul>
    <a>See the whole team
    </section>


    …same for cars, bikes etc.

    </aside>

    this is how i applied it, but i am not 100% sure it is the right way of using aside, what do you think?

    • I was surprised, but asides ended up confusing me more as I ran through this series. They map to an ARIA role of complementary, which means they should be a supporting section of the document.

      Your example highlights what I was confused about. Your list of services and team members doesn’t strike me as supporting material for the article, but I could make the case that they’re related to the site as a whole.

      It looks like your using aside as a sidebar, which I think is common. If you saw my demo I chose to wrap the sidebar in a generic div, because in my mind I was only wrapping everything to make it easier to code the layout.

      An aside didn’t feel right to me, but I have a feeling most of the design community would disagree with me about this and use an aside exactly the way you did.

      I hope that helps.

      • thanks steven.

        we are not using aside as a sidebar, the content is on a vertical flow, and aside is at the bottom. also i went through the whole tutorial and examples. very well made! all nice explained. but i guess aside has to be treated individually according to the content and website structure every time.

        yeah, aside is pretty foggy…
        but i guess in our case it is the right way of using it, because the content IS related to the main article, as it is further information about the overall company etc.

        same idea applies probably with the content in the footer.
        here we have a section with all the countrywide storelocations, another one with the contact details, a separate one with the followus social icons and a last one with a footer navigation pointing to legal stuff, sitemap and faq… but i am not 100% sure if i should use aside here! i mean, if the overall team and services (see above) is inside an aside, so why shouldnt the footer stuff (contact details, the followus social icons and the footer navigation) not be as well?

        what do you think about those?

        it is always great to have more opinions, and as you write yourself, in a later stage we might change things as well.

        • Sorry for the late reply Dee.

          I think it still counts as a sidebar even if it’s not technically on the side. I still define them more by what content they hold than where they’re located

          I was surprised I came away from this with less confidence about when to use asides. I probably just need more time to play around with them and decide how I want to use them.

          I’m not sure what the best way to structure your footer is. I can hear myself asking the same questions you are. My ultimate conclusion to this series was that there probably isn’t a single right way to use any of these elements and we’re all going to have to find out own way the same as we did when we first learned HTML and CSS.

          We’ll try to structure something one way and think if there are better ways. Eventually we’ll settle on patterns we’ll reuse and hopefully continue to improve the patterns.

  2. crap… any idea how to fix my post?
    i forgot that html will get removed…
    should i repost and use html inside or or any other special formatting?

    ...sorry about that...

Leave a Reply

Your email address will not be published. Required fields are marked *