Are you a member? Register or Login

HTML5: Semantic Changes (3 of 4)

In the last article, we looked at a number of new elements introduced in HTML5 and how to implement them properly. In this article, we’ll again be discussing a set of new elements but this time we’ll be examining only those HTML5 elements that represent a significant semantic change to the way you structure your sites. This article will cover how to use each of these new elements in a way that will bring much needed relief to the div-itus that plagues the structure of so many sites today.

The Ultimate Designer Toolkit: 2 Million+ Assets

Envato Elements gives you unlimited access to 2 million+ pro design resources, themes, templates, photos, graphics and more. Everything you'll ever need in your design resource toolkit.

Explore Envato Elements


Before we get started, you should know that by semantics I’m simply referring to using HTML tags and elements the way they were intended to be used. Unlike programming languages, which have to compile to run, HTML requires no compiler (the browser attempts all the interpretation) and therefore gives you a vast amount of freedom to use a given element any way you want. However, if you’re a new web designer you’re probably discovering that many people are semantic fanatics, and perhaps rightfully so. Using tables where they don’t belong or throwing around

tags every time you want to bold something might be convenient, but it makes for some incredibly messy and hard to read code. Therefore, we look to semantic, cross-browser, valid HTML practices to bring unity and consistency to sites all across the web. Many of the HTML5 elements we’ll be looking at will be easy enough to interpret simply by reading the name, but familiarizing yourself with the correct way to implement these elements is absolutely crucial if you want to create professional quality sites that function in a number of major browsers.

The Problem

Take a look at 100 different websites with nearly identical layouts and you will find 100 different structures and naming conventions in the underlying HTML. Even though any good web developer will name his/her

s in such a manner that they are easily understood, the vast possibilities can lead to confusion over the identification of relatively simple and uniform sections of code. For this reason, HTML5 gives us a number of elements that can be used to identify and target items that appear in almost every site on the web such as headers, footers and navigation menus. Furthermore, apart from inconsistent naming conventions, the current way of doing things can quickly lead to div structures that come with a lot of extra weight compared to simple, built-in HTML elements. To illustrate, let’s look at a simple structure you might find in HTML4.

You can see how this relatively simple piece of code is overrun by divs, which can take a long time to sort though due to all of the necessary fluff. The CSS to work with this HTML would contain the following selectors:

Though not as complicated as the HTML before it, this code isn’t as simple as it could be. Now let’s dive into how HTML5 helps us solve this problem.

The Solution

HTML5 allows us to take nearly all of the custom divs above and convert them to standard elements. Let’s look at the code necessary to accomplish the same thing in HTML5.

And the corresponding CSS:

There’s a lot to discuss about these examples so let’s start with the HTML. Notice that the chronic div-itus has disappeared and in its place are universally understood and easy to interpret elements. This vastly improves the readability of the code. One of my pet peeves when reading through someone else’s code is tracking down the correctly corresponding


tags. This can take a ridiculous amount of time if there are eight or ten stranded and unlabeled closing div tags. Using standard elements goes a long way towards eliminating this problem because the closing tag is more informational (it’s easier to find

than it is to locate a random

that belongs to


The CSS has been simplified as well. We can now just use identifiers without hash tags or periods in most cases because we are referring to natively supported elements instead of uniquely named divs. Notice that in our HTML this time around we were able to use the same tag for all header and footer elements (we tossed the “main” classification). This is because if we want to style headers within the container differently than the others we can just use “#container header” to target just the header elements within the container div (and we can be sure it will properly inherit the traits we want to keep). Now that we’ve gotten a glimpse of the new structural elements, let’s go over how to use each one individually.



You might initially assume that the header element refers to the one principal header on the page. However, it’s really just a generic element that can be used several times throughout your code. Here’s an example:

Again we’ve replaced what would’ve normally been a bunch of divs with simpler header tags. It’s important to note that since we can have multiple header tags in a single HTML file, you shouldn’t think of the header element as a replacement for

, which represents a unique div appearing only once, but rather for

, which represents an element that appears multiple times. This is an important distinction for semantic reasons as well as CSS styling and applies to several of the elements we’ll discuss.



Most of the things I just explained about the header element also apply to the footer element, meaning it is generic and can be placed multiple times throughout your code. Obviously, footers generally (though not always) go at the end of a section of code and contain information that is secondary in nature such as the publish date, author, copyright information, etc. However, what goes into the footer is largely up to you. Here’s a quick example that builds on what we saw with the header element:



The section element is a generic way to separate portions of your site. For instance, say an event website is divided up into “what”, “when”, and “where.” You could use

tags to make this division in your code (again, think “class” not “id”). Using our previous example, we could replace the “Tutslist” class with section elements.

Notice that sections frequently begin with a header element and end with a footer element, though this is by no means a necessity.



I briefly mentioned the article element in my last post, forgetting completely that I was saving it for this post. However, a commenter cleverly pointed out some bad information that we should straighten out. Despite the fact that w3schools states that the article element is strictly for external content, clearly states that its actual purpose is to identify a section of your site that is intended to be independently distributable. For example, a blog post like this one could stand on its own and is not dependent on the rest of the site’s content. Further, this post is something that we actually want other sites to discuss and link to. News stories, forum posts and tutorials are good examples of this type of content. Let’s apply this to our running example.

As you can see, this is really internal content that can be referenced externally, rather than vice versa like w3schools seems to suggest.


The nav element refers to sections of your HTML containing links for navigational purposes like that in a sidebar or strip of buttons along the top of a page. However, this does not apply to all groups of navigational links on your pages. Instead, reserve this element for the main sources of navigation on your site. gives the example of a series of links in a footer as a situation that would not merit a nav element. Again we’ll revise our example to include the new element.


The last element we’ll discuss is aside. This element is reserved for content that is related to, but distinctly separate from the rest of the content on the page. The aside element can be used for pull quotes, advertisements, nav elements, sidebars, etc. For instance, let’s say we wanted to take our navigation from the last example and place it into a sidebar:

Look Ma, No Divs!

The example above illustrates the exceptionally large amount of code that HTML5 allows us to execute using only standard elements! Every piece of this example is super easy to target in CSS, instantly understandable by any developer (at least any developer who is versed in HTML5), and incredibly concise compared to the amount of code this would require in HTML4. And there’s not a div in sight.


This article briefly described the concept and importance of semantic code and discussed the major semantic changes brought about by HTML5. We discovered how to properly use six incredibly helpful new HTML5 elements: header, footer, section, article, nav and aside. Finally, we learned how these new elements can be used to create neatly structured and easily readable code that avoids the excessive use of divs.

To prevent confusion (and to avoid a flurry of angry comments), I should make it clear that there is absolutely nothing wrong with divs. I personally use divs quite liberally throughout every site I create and find them to be among the most flexible and essential elements in HTML. However, the more you can replace uniquely named divs with universally named elements the more reliable and standards-accurate your code will become.

Looking Ahead: Three Down, One to Go!

The next article will be the final in our series on HTML5. As you probably know by this point, none of what I’ve showed you is ready to be integrated into websites for widespread public viewing. However, our next article will show you various tricks to start using HTML5 right away and discuss how you should be preparing your sites for the inevitable update!