HTML5 Structural Elements — How I Built This Demo: Part 1

It’s one thing to learn how the new HTML5 structural elements are supposed to be used. It’s another to actually use them in practice.

Screenshot of the top of the demo

For a few weeks I’ve been looking at the new sectioning and non-sectioning elements in HTML5. Before that I walked through the existing document outline as well as the proposed HTML5 outline. I talked about the different elements and how each is defined in the spec. I also looked to the ARIA role each element maps to for additional definitions and use cases.

Several times in the series I promised a demo. Here is it. You may recognize it’s similarity to a demo I built a few years ago when I first talked about the HTML5 structural elements. The new demo is a reworking of the older one.

If you’re interested in comparing then and now, here’s the older demo and the two posts that described the choices I made at the time.

I went into this new demo (the whole series really) expecting to not like or want to use any of the new elements beyond these posts. After working my way through this demo, I have a different feeling.

I now have a better understanding for how to use a few of the HTML5 elements, despite some new and lingering confusion. I also came away from this series with reasons for why it’s a good idea to use the new elements along with a plan for how to incorporate them into my work.

The key to my change was working on the demo and having to explain my choices. Having to think critical about the elements led to a deeper understanding.

It’s going to take a few weeks to get through the demo and my reasons for using one element over another. Today I’ll share how I approached the demo and then consider the overall layout, the header area, and the main content area.

Next week I’ll look at the sidebar and footer, which were the parts of the layout that I found most difficult. I’ll also discuss how used hx headings throughout. The week after I’ll share what I learned writing this series and my planned approach for incorporating the new HTML5 elements into my work.

How I Approached This Demo

My goal was to find a balance where I would use the new elements, but not in a way that didn’t make sense to me. Ideally I wanted to walk away having figured out how I want to use the elements in practice.

I opened the previous demo in a browser and without looking at the code, developed a new HTML structure, referring to the posts in this series for guidance here and there.

I did borrow some code from the older demo. For example I didn’t want to type out the specifics of the comments again so I lifted the code. However, I only did so after I had set up the structure with the new elements.

With the HTML in place I added the CSS. In some places that meant having to rethink the HTML. Should I add a class or would a different choice of elements make more sense? I did borrow some of the older CSS so I could skip figuring out what colors and font sizes I used.

If you look at both demos you can see I made a few tweaks. The biggest is the addition of the social buttons, which I lifted from the footer of this site. Alvaro asked in a comment how I might mark up social buttons, so I added them to the demo.

I make no claims the way I structured the HTML is how you should structure it too. This demo isn’t meant to be the one way to use these elements. It’s simply how I decided to use them at this point in time.

My choices aren’t necessarily the right or best choices. My hope is by sharing my choices and especially my reasoning, it will help you make similar decisions about using or not using these elements in your work.

The Overall Layout

I divided the overall layout into four parts. A header at the top that includes everything above the thin gray line. The line is a border-bottom on the header.

There’s a footer at the bottom that includes everything inside the dark gray background as well as the copyright and credit below it.

In between there’s a column on the left for the main content and a narrower column on the right that serves as sidebar. It’s a pretty standard 2-column layout. Here’s the code I used for the basic structure.

[code type=html]
<div class="wrapper">
<header role="banner"></header>
<main role="main"></main>
<div class="sidebar"></div>
<footer role="contentinfo"></footer>

The wrapper is there to center the overall page. Since it exists for presentation only, a div made the most sense. For three of the four major areas of the page I used one of the new elements along with the ARIA role each maps to as recommended.

However, I decided to use an ordinary div and class for the sidebar. I went back and forth on this and could easily change my mind again. I’ll offer more details when I talk about the sidebar next week, but in the end I felt like the sidebar container was presentational and a div made the most sense.

The Header

The header was the easiest part of the demo for me. I replaced what I usually code as <div class="header"> with a header element. One definition for the element includes what we all think of as a page header so it wasn’t a hard decision.

My issues with the header element are when they’re used for something that isn’t the main page or site header, though I am reconsidering my opposition.

Because the header element (when used as a page header) maps to the ARIA role banner, I added the role to the header element for any browser or tool that doesn’t yet map the element to the role.

[code type=html]
<header role="banner">
<section class="logo">
<img src="images/html5-logo.png" />
<p>HTML5 Web Design</p>
<p class="tagline">Building your website for the future</p>

<nav class="global" role="navigation">
<li><a href="">Home</a></li>
<li><a href="">About</a></li>
<li><a href="">Blog</a></li>
<li><a href="">Contact</a></li>

The logo is comprised of an image and a couple of one line paragraphs. I wrapped all three with a section. I debated using an article or aside, but I don’t like the idea of using the former too often and I think using the latter would give justification for using asides for most everything in the boilerplate design. Since, the image and paragraphs are clearly related so a section element made the most sense to me.

The navigation is the usual list of links and here I wrapped it with the nav element. It is global navigation and is exactly what belongs inside a nav element.

As you can see, using the new elements doesn’t remove the need for classes. To style the navigation I originally used descendent combinator selectors (header nav a). Adding the class reduced depth of applicability by one (.global a).

One question I asked myself was how necessary the nav element is if I’m adding the class. I don’t need the extra markup to structure the navigation. Adding semantics for assistive devices is something we should all do, but I’m not sure if that requires the nav element. I may decide to use role=”navigation” as well as the class name on the ul element in the future.

The header isn’t much different than what I would have done had I not used the new elements. I can easily get behind these changes despite a question or two.

The Main Content

Here’s the adbridged version of my code for the main section of the page. I’ll talk about headings next week and the rest of what I’m not showing was the usual paragraphs and lists and things you’ve likely seen hundreds of times before.

[code type=html]
<main role="main">
<article role="article">
<section class="meta" role="contentinfo"></section>
<!– rest of written article here –>

<section class="meta archives" role="contentinfo"></section>

<section class="comments"></section

Inside the main element is an article element that wraps everything. That raised the question of how necessary the main element is here, but it’s not hard to see where you could have something outside the article and inside the main element even if I don’t in this demo.

The article contains meta information at both the top and bottom. The spec suggests using a footer element for both, but that doesn’t make sense to me. I’m still in the one footer per page camp. I decided on a section because the information is related.

I gave each a class of meta as well as a role of contentinfo. The role is for meta information and it’s also the role a footer element (when used as a page or site footer) maps to by default. I may not be using a footer here, but I do want my HTML to communicate to assistive technologies that the information is meta information. The additional class of archives on the second section was so I could style the two meta sections differently.

I wrapped all the comments in a section, since I think it’s fair to say they’re all related. The comments class is for presentation. Here’s what’s inside the section.

[code type=html]
<section class="comments">
<h2>3 Comments</h2>

<article class="comment">
<div class="comment-meta" id="comment-1"></div>
<div class="comment-body"></div>

<article class="comment">
<div class="comment-meta" id="comment-2"></div>
<div class="comment-body"></div>

<article class="comment">
<div class="comment-meta" id="comment-3"></div>
<div class="comment-body"></div>

<p class="closed">Comments are currently closed.</p>

I went with the an article for each comment, not because it’s what I think best, but because I wanted to follow the spec and see how I felt after.

I still question how independent a comment is and my guess is in practice I would more likely wrap each comment in a section as opposed to using an article. I gave each comment a class of comment, but I could have used .comments > article as a selector instead as it isn’t overly specific.

In the end I failed to convince myself to use articles for comments and in practice I think I’ll sooner choose a section. I just don’t like the article of clothing definition.

Closing Thoughts

The header and main content area of the layout were the easy parts for me. Other than a preference for one article per page and some questions about the necessity of the nav element, I can easily seem myself using the HTML5 elements I used in these two areas of the layout.

Again, please don’t see this demo as the one true way to use these elements. Don’t see it as my recommendation either. If I rebuild this demo a few months from now, it would probably end up with a different structure.

The things to pay attention to are my choices and reasoning. You don’t have to agree with either, but hopefully seeing my decisions and rationale will help you make similar decisions when faced with them.

Next week I’ll get to the two parts of this demo I found most difficult to structure. I went back and forth on a number of things with both the sidebar and footer and I’ll share what and why in part 2 of this demo.

« »

Download a free sample from my book, Design Fundamentals.


  1. Two thoughts:
    1. Do we still need a “wrapper” DIV? Applying those styles to the BODY element seems to work fine.
    2. With the more meaningful NAV element, do we still need to wrap the links inside a UL? The list elements don’t seem to contribute anything, AFAICT.
    — Cordially, David

    • True about the body element. I’ve always placed another container inside, though I’ll be the first to admit you can have the body be that container and think of the html element as filling up the screen.

      My question with the nav element is that it serves as a container for something that’s already a container. The ul contains all the list items.

      To style the navigation I’m adding a class here on the nav element, but I could just as easily have added the class to the ul and styled it the same way. One or the other seems redundant as far as presenting the navigation.

      It makes me question whether or not to use the nav element.

      Wouldn’t this be enough?

      <ul class=”global” role=”navigation”>

      • Actually, I was questioning the need for the list. I would have thought the NAV would be enough to wrap the links. no?

        • Sorry I didn’t reply sooner David. I understand now. You could wrap the links in the nav element. You’d need different CSS for the same look, but you don’t need the list.

          I prefer using a list though. It makes sense to me that a menu is a list of links.

      • Umm. I don’t see where we disagree, Adam. The only element that wraps the entire page in your example is the `body` element, no? In contrast, with Steven’s example, both the `body` element and the `div.wrapper` wrap the entire page.

        Calling something a wrapper does not make it so. 🙂

        • I am not sure I follow.

          I would like to know if it is possible to re-create my codepen layout above, without the use of a wrapping div. I would be interested to see how you would do it.

          • I think you and David might be talking about different things. David was asking about the way I used the wrapper class here.

            I tend not to add any CSS to the HTML element. I treat the body as the outermost element and the use a wrapper div inside. A lot of people don’t use the wrapper div. They use the body the way I use the wrapper and use the html element the way I would use the body.

            I took a look at your codepen and it looks like you’re using the wrapper in a different way than I am here and in the way David was asking about.

Leave a Reply

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