Thoughts About HTML5 Structural Elements

Do you use the new HTML5 structural elements like header, aside, article, and footer? If so, do you do use them because of the added semantics they carry?


Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes

I started thinking about structural elements after reading a post by Jeremy Keith. One of Jeremy’s readers asked how he could convince colleagues to use the HTML5 structural tags. You can read Jeremy’s post for the details of his response.

The gist is not to agonize over using the new tags, though don’t be lazy and always settle for divs either. Sometimes the extra effort in deciding something should be an article instead of a div isn’t worth the time. Sometimes it is.

Jeremy talked about using h1-h6 headings and lists and paragraphs and how they help assistive technologies like screen readers. He said semantics are particularly beneficial with forms so you should use the right elements. However, these aren’t the new structural elements I’m talking about.

Reading the post made me think. A little more than three years ago I wrote a post about the new structural elements and their semantics. I even created a demo putting them to use. At the time I was very excited to use them in practice. I used them when I built this site and client sites of the time include them as well.

Fast forward to today and I rarely end up using them. I have to remind myself or they aren’t making it into my code. I’ve mostly gone back to using HTML like <div class="header"> instead of using <header>. It wasn’t so much a conscious choice to go back to my old ways. It happened little by little until I stopped using the new tags. I want to spend some time today thinking out loud about why that us.

Support for the new elements is great. Pretty much everything other than IE8 and below supports them. The main element isn’t supported everywhere, but the rest are. Browser support is not the reason I avoid the tags.

How Important is Semantic HTML?

I can already hear the arguments about the importance of semantics and no matter what I now say, someone will tell me how wrong I am. Welcome to the internet. The reason for semantic HTML is that it can communicate an extra layer of information to anyone or anything listening.

As far as rendering the page is concerned it doesn’t make a difference if you code something as an aside or as a div with a class of sidebar. The semantics won’t change how the page can be displayed in browsers. It only makes a difference to anything out there (human or machine) that’s understands the extra layer of communication and is going to do something with it

The natural question is who or what out there is currently listening and taking some meaning from the semantics of the structural tags? Do they make a difference to screen readers? Do search engines read them? Feed readers? Anyone?

I assume where screen readers are concerned they do, though I haven’t found anything concrete to confirm one way or the other. Does <header> communicate more to a screen reader than something like role=masthead? Is there a difference. Do screen readers understand both? One? Which?

If you know please leave a comment.

Based on what I could find, I don’t think much of anything is taking anything from the semantics of the structural tags. It always seems to be one of those things that will happen in a future that never comes.

I do think it makes sense to prepare for the future. Skate to where the puck is going and not where it is. Still, is it worth the extra effort if little or nothing is gleaning anything extra from the semantics? Maybe screen readers are more than I think and I apologize if they do. I should probably know, but I don’t.

Building Websites

Elements like divs and articles and spans and HTML elements in general are containers. You create a div, article, section and you put stuff inside it.

To build a site the semantics aren’t necessary. What I care about structurally are things like whether the element behaves as a block level element, an inline element, or both. I’ll want to know if it’s floated or positioned in some way.

I need to know those things so I can fit all the blocks together. In many ways building a website is like building a jigsaw puzzle, except you can change the size of the pieces to make them fit.

Whether you use a div, article, aside, section, doesn’t really matter. All can be made to behave the same way and can be located where you want and look how you want. None of the elements are limiting what you can do with them.

Any element that needs styling beyond its default will likely get a class. Styling the div element is usually too generic so I’ll usually add a class to any that needs styling or I’ll hook into an attribute inside the tag.

I suppose if one element becomes an article instead of div it’s more specific, because there will likely be fewer of them, but it’s still rather generic and I’m probably going to add a class before styling

The structural elements aren’t really making it easier to develop. I don’t see where header makes things easier than .header

None of this is meant to take away importance of semantics. The idea is that semantics aren’t needed structurally. My website doesn’t care about them. Your website doesn’t either. They display and render and work regardless of our use of articles over divs or divs over asides.

Who’s Actually Listening to Semantics?

One of the reasons I see mentioned in favor of semantics is they can make the structure and presentation of a site easier to understand when looking at the code.

I can’t say I find that to be true. Maybe it’s different for you, but for me I just want to see the structure and be able to find the CSS used on the element. I don’t particularly care what specific tag or class was used as long as I can match the structure to the presentation.

Usually when we’re talking about the semantics of code, it’s for machines that might read the code. It would seem choice in semantics should come down to who’s listening, what they can hear, what they understand, and what they’ll do with the information.

Add that up and decide if the effort is worth it. Will it help your site in some way? Will it help visitors navigate or consume content? Is it worth the effort or is your time better spent elsewhere?

I don’t know. When I try to search to find answers about who or what might be reading the semantics, I don’t find anything. Maybe I’m just searching in the wrong places. Mostly I see people talking about how important this will be in the future, but I don’t see much mentioned about anything listening now.

Future proofing is a valid argument, but I think of things like Microformats. We’ve been hearing how we should use them for years. Are they really in use? On some sites maybe. They never really gained traction from what I can tell. Why should this be any different?

How about search engines. They back schema.org. I can’t say I’ve looked through ever page on the schema.org site, but I haven’t found any mention of HTML5 structural tags or their semantics. Mostly I see a lot of extra stuff we should use to mark up content.

How about marking up an article? It seems like a logical place to include an article tag. Nope. Not a single mention on the schema.org page on articles. Check the example code at the bottom of the page (the microdata tab). I don’t see any article elements. I do see lots of divs and spans though.

I’m not saying we should get our coding practices from search engines, but Google and Bing and Yahoo and all the rest should be who we’re adding the semantics for. However, it doesn’t seem like any of them are listening for those semantics. So who are we writing the semantics for?

I come back to screen readers. ARIA includes the concept of an article with <div role="article">. Are screen readers dropping support for ARIA roles in favor of the new tags? Probably not. Are they also supporting <article>? Again, I couldn’t find confirmation one way or the other, though I assume they will if they aren’t yet.

Even as I’m saying all this it sounds wrong. It sounds wrong to think we shouldn’t use the new structural elements. I like the concept behind them and their reason for existing. I can envision a time when they are being read, but is that time now?

There’s Too Much Confusion, I Can’t Get No Relief

Honestly I think the main reason I stopped using the new structural elements is because I find them confusing to work with. They shouldn’t be that hard. They sound easy in theory but I find theyget confusing in practice.

For example to me there’s a single header and single footer on the page not however many you want. Every section is supposed to include header and footer according to the spec. Really? Seems a bit like overkill.

The section element is for thematically related content. What does that really mean? Every word in this article is thematically related. Does that mean using a section is better than using a article?

In fairness an article is supposed to be a special type of section where what’s inside is self contained content that can moved somewhere else and still make sense.

Does that mean this whole post is an article and each section in the article is a section? Sound good. The words match. I’ve definitely written sections within articles that could stand alone independent of everything else in the article, though. Are they articles inside articles?

Based on what I learned previously I wrapped each blog post on the main page of this blog in an article tag. The five most recent posts are each inside an <article></article>. Each has a title, some meta information, the first paragraph of the article, a link to read more, tags, and a category.

Are those small bits really independent? Could you remove one and have it make sense elsewhere? Technically maybe yes, but I don’t think so in all cases. It removes the continuity and context of specifically being here.

The main element is meant to replace something like div class=”main-content” Apparently if you have an article on the page it should be wrapped with a main tag. Isn’t that redundant? Isn’t that just adding a tag that’s unnecessary? If an <article> is already enclosing the main content does it also need to be wrapped inside a <main> element?

The nav element seems simple enough. It’s clearly for navigation, but not all navigation. It’s only for major navigation. Is a section menu major navigation or minor navigation? How about a set of utility links?

A lot of these questions probably don’t matter. In time it will come down to designers using the tags and standardizing their use through consistency.

In the spec the W3C offers an example. It contains two sidebars. One is structured as <section id="sidebar1"> and the other is structured as an <aside>. Why the difference? Without an explanation it adds to the confusion.

When I see examples like this it’s not clear to me why a certain element was used over another. It’s confusing when there’s no clear way to use the elements. Most examples, particularly those from W3C and people involved with spec tend to confuse me more than help me. There are explanations, but then a different explanation for something that seems to be the exact same thing.

It seems like there’s too much overlap in when you could use a section, aside, or article. I question then whether these elements are communicating consistently if we’re not using them consistently or using them at all.

I think part of the problem is that the people who write the specs like to change the accepted meaning of things. We all refer to something as one thing and they change the meaning for some technical reason. Too often the names they give things makes understanding those things more difficult, not less.

In the end I choose divs because I can make the decision quick and move on. I just want to know how the element behaves so I can control it through CSS.

Whenever I try to incorporate the new structural elements I have to stop everything and try to sort out any confusion. It’s one thing to build a site for me and another to build a client’s site. I have more time with my site.

It can take considerable time to use the new elements. It’s not necessarily time consuming to choose one element, but to figure out how all the elements will fit into the structure of your HTML can take a significant amount of time. Until I’m less confused and have more assurance something is reading the semantics I keep falling back to divs.

Closing Thoughts

Please don’t take anything here as me saying I don’t think we should ever use the new structural elements. It’s not exactly difficult to replace <div class="header"> with <header>. It’s just a matter of making it routine.

It makes sense to have our tags communicate more, even if no one is listening just yet. They probably will in the future. At least I hope so. The short history of the semantics on the web suggests otherwise, though.

Despite thinking they make sense I find that unless I force myself to use them they aren’t going to find their way into most of the sites I develop. There will be an aside here and an article there, but I don’t quite see myself using them all that frequently given everything I’ve said here.

Right now they’re an extra layer of communication, except that no one is listening to that communication. And perhaps the inconsistent way we might use them means they aren’t communicating the same thing from site to site (assuming something is out there paying attention to the semantics).

One positive outcome of dumping all these thoughts here is that it’s made me want to investigate a little more. Maybe after New Year’s I’ll take a more in-depth look at the tags and what they mean and especially how to use them.

I wouldn’t mind taking a look at structured data in general and include some more thoughts about Schema.org along the way. No promises, but my guess is I will take that in-depth look before long.

« »

Download a free sample from my book, Design Fundamentals.

16 comments

  1. I ask the same questions. My routine now includes the new elements but it often comes up, in my mind, to just use div everywhere for everything with an attached class and microformat (cause Google says it helps to do that). I often feel I’m preaching from the mountain top but no one is there to hear me.

  2. Your sentiment here echoes what I generally practice: get the broad semantics right (headings, forms) but don’t sweat the detail.

    I’ve never used the new structural elements precisely because of this confusion. It’s ambiguous, so requires extra thought, so makes something simple too complicated.

    I avoid them for a number of other reasons. One is that I still support IE7 and 8 for most projects (financial institutions) therefore requiring JS to style the basics doesn’t sit well with me. Another is the damned outlining algorithm.

    You’ll remember that the HTML5 outlining algorithm stated that each new sectioning element (section, article etc.) creates a new context at which you can begin headings from H1. This actually makes a lot of sense and improves code portability: imagine an HTML partial that contains a heading Hn that you re-use in different positions across a site. Previously you’d have to make sure that you passed a context to this partial to write out the correct heading number to maintain consecutive hierarchy. With HTML, wrap it in a section snd use an H1.

    However my understanding is that browsers and screenreaders have been both slow and inconsistent in implementing it, so the whole outlining algo concept is on the At Risk list to be dropped entirely.

    On a similar note, it’s my understanding that ARIA roles are analogous to the new elements. So a div with a role “main” is equivalent to the main element. Same semantics, interpreted the same by screen readers etc.

    With that in mind I simply use div elements with appropriate ARIA roles, and maintain the traditional H1-6 per page.

    • Good point about IE7 and IE8. The javascript isn’t much to make the new elements work in either, but it is still loading some javascript and I completely understand why you’d choose not to go that route.

      I do remember the outline algorithm. I wrote a post about it and while I thought there some interesting ideas there, I found the algorithm more confusing than it needed to be.

    • Thanks for the link. I wish I’d come across it before working on this post.

      You mentioned browsers being slow to adopt some things in your comment above. That’s what it seemed to me when I was researching. I don’t have the screenreader to test, but that’s the feeling I had reading.

      I don’t want to knock the new elements and suggest we shouldn’t use them. Even if I’m not using them as much as I though, I expect in time I will be using them.

  3. It would seem to me that these structural tags don’t mean much, specifically the role of context as it pertains to sections, when you introduce custom elements. The custom elements introduce context, easy styling, and portability (shadow DOM).

    It’s almost as if those structural tags were the prototypes of custom elements.

    • Thanks Steve. I appreciate the additional resources. I know I’ve been through a number of your articles in trying to sort this out for myself. I’m happy to have a few more to look through.

  4. There’s an eBook called “The Truth About HTML5” (http://www.truthabouthtml5.com/), whose entire premise is that the HTML5 sectioning elements are pointless. You can read the key chapter here: http://www.creativebloq.com/html5/truth-about-structuring-html5-page-9122842

    I agree with the main point of your blog post, but I think the concept you’re missing (through no fault of your own — it is terribly/inconsistently explained) is that the purpose of the sectioning elements are to serve the “document outline”. Once I understood that concept, the decisions about which elements to use became much clearer to me (although I don’t even bother with the “article” or “main” elements because they don’t make a lot of sense when you get down to it — it’s impossible to decipher the difference between an article and a section, and there’s no need for main because everything that’s not in a sectioning element is by default the “main” content).

    All that being said, few people understand this stuff and every tutorial and explanation out there is somewhat contradictory, so I think at the end of the day none of this will matter in the grand scheme of things because nobody is using them the way they were intended (which I think is a failing of the spec, *not* a failing of web designers).

    I think you sum it up best with your line “Right now they’re an extra layer of communication, except that no one is listening to that communication. And perhaps the inconsistent way we might use them means they aren’t communicating the same thing from site to site (assuming something is out there paying attention to the semantics).”

    Thanks for the great blog post!

    PS here’s another great blog post by Nicolas Gallagher about the over-use and mis-use of the term “semantic” when talking about HTML: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/

    • Thanks Jordan. I’m absolutely sure I’m missing something. I appreciate the links. I read the sample of the book and I think I want to read the rest. It looks interesting.

      I’ll revisit this topic again, though first I’ll put some effort into understanding the document outline. I looked at it a couple years ago. I understood the idea behind the outline, but I was definitely confused about it. I’ll look into it again.

      I do think the idea behind the new tags and the document outline is good. At the same time I wonder how useful any of them really are at the moment.

  5. As for me the masthead is a part of the header but most of the developers consider both as one. However, as for the structural data element concern, I will strongly recommend to add them with in your code, because the search engine are reading them quite efficiently and effectively, however, the time is not far when the browsers, mobile and tablet will start reading them and they will become a standard ranking factor in search engine as well as industry standard. BTW nice and very informative write-up.

    • Thanks Humayun. Are you sure search engines are reading them? As far as I can tell they aren’t. I doubt they would ever be much of a ranking factor.

      Search engines are interested in content. If we add more semantics to our code, search engines could use the semantics, but I wouldn’t expect it to be that important to ranking. I think the search engines would sooner present a page with great content and poor html than the other way around.

      You never know, though. Maybe they will put more importance on the html structure of web pages, or maybe it’ll be something like the semantics can give a small boost to a page or site.

      By the way I know what you mean about the masthead and the header. I think the masthead is technically just the title of a magazine or newspaper. For a website, I suppose a logo is really the closed thing to a masthead. Somehow it’s become the entire header though.

      • Hi, Steven and Humayun. Actually Humayun and I are colleagues, I have told him to not to put so much effort on these elements stuff, but he was not agreed. However, I am agreed with you Steven, you are absolutely right that SE only wants quality content and readable HTML document, thats it. We don’t have to be fanatic with our SEO.

        • Thanks Yunsey. I don’t think the new HTML5 elements are going to improve where your pages rank, but I did resist the topic and found some good reasons for using the new elements. I’ve had something of a change of opinion since writing this post.

Leave a Reply

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