For a long time, HTML5 had no element to demarcate the main content of a page. Within the body of a web page, this would be the element that contains the main block of content.

At first, it was argued that the content that wasn't inside one of the other new semantic HTML5 elements would, by negation, be the main content. Thankfully, the spec changed and we now have a more declarative way to group the main content; the aptly named <main> tag.

Whether you're wrapping the main content of a page or the main section of a web-based application, the main element is what you should be grouping it all with. Here's a particularly useful line from the specification:

It's also worth noting that there shouldn't be more than one main on each page (after all, you can't have two main pieces of content) and it shouldn't be used as a descendent as some of the other semantic HTML5 elements such as article, aside, header, footer, nav, or header. They can live within a main element however.

The <section> element is used to define a generic section of a document or application. For example, you may choose to create sections round your content; one section for contact information, another section for news feeds, and so on. It's important to understand that it isn't intended for styling purposes. If you need to wrap an element merely to style it, you should continue to use a div as you would have before.

When working on web-based applications I tend to use section as the wrapping element for visual components. It provides a simple way to see the beginning and end of components in the markup.

You can also qualify for yourself whether you should be using a section based upon whether the content you are sectioning has a natural heading within it (for example an h1). If it doesn't, it's likely you'd be better off opting for a div.

The <nav> element is used to wrap major navigational links to other pages or parts within the same page. It isn't strictly intended for use in footers (although it can be) and the like, where groups of links to other pages are common.

If you usually markup your navigational elements with an un-ordered list (<ul>) and a bunch of list tags (li), you may be better served with a nav and a number of nested a tags instead.

The <article> element, alongside <section> can easily lead to confusion. I certainly had to read and re-read the specifications of each before it sank in. Here's my re-iteration of the specification. The <article> element is used to wrap a self-contained piece of content. When structuring a page, ask whether the content you're intending to use within a <article> tag could be taken as a whole lump and pasted onto a different site and still make complete sense? Another way to think about it is, would the content that you are considering wrapping in an <article> actually constitute a separate article in a RSS feed? Obvious examples of content that should be wrapped with an <article> element would be blog posts or news stories. Be aware that if nesting <article> elements, it is presumed that the nested <article> elements are principally related to the outer article.

The <aside> element is used for content that is tangentially related to the content around it. In practical terms, I often use it for sidebars (when it contains suitable content). It's also considered suitable for pull quotes, advertising, and groups of navigation elements. Basically anything not directly related to the main content would work well in an aside. If it was an e-commerce site, I'd consider areas like 'customers who bought this also bought' as prime candidates for an <aside>.

The specification relates that the figure element:

Here's how we could use it to revise a portion of markup from the first chapter:

<figure class="MoneyShot">
  <img class="MoneyShotImg" src="img/scones.jpg" alt="Incredible scones" />
  <figcaption class="ImageCaption">Incredible scones, picture from Wikipedia</figcaption>
</figure>

You can see that the <figure> element is used to wrap this little self-contained block. Inside, the <figcaption> is used to provide a caption for the parent <figure> element.

It's perfect when images or code need a little caption alongside (that wouldn't be suitable in the main text of the content).

How many times have you wanted to create a simple open and close 'widget' on your page? A piece of summary text that when clicked, opens a panel with additional information. HTML5 facilitates this pattern with the details and summary elements. Consider this markup (you can open example3.html from this chapter's code to play with it for yourself):

<details>
    <summary>I ate 15 scones in one day</summary>
    <p>Of course I didn't. It would probably kill me if I did. What a way to go. Mmmmmm, scones!</p>
</details>

Opening this in Chrome, with no added styling, shows only the summary text by default:

Clicking anywhere on the summary text opens the panel. Clicking it again toggles it shut. If you want the panel open by default you can add the open attribute to the details element:

<details open>
    <summary>I ate 15 scones in one day</summary>
    <p>Of course I didn't. It would probably kill me if I did. What a way to go. Mmmmmm, scones!</p>
</details>

Supporting browsers typically add some default styling to indicate the panel can be opened. Here in Chrome (and also Safari) that's a dark disclosure triangle. To disable this, you need to use a WebKit specific proprietary pseudo selector:

summary::-webkit-details-marker {
  display: none;
}

You can of course use that same selector to style the marker differently.

Currently, there is no way of animating the open and close. Neither is there a (non JavaScript) way of toggling other details panels closed (at the same level) when a different one is open. I'm not sure either of these desires will (or should) ever be addressed. You should think of it more as a way to facilitate what you would have done with a display: none; toggle with the help of JavaScript.

Sadly, as I write this (mid 2015), there is no support for this element in Firefox or Internet Explorer (they just render the two elements as inline elements). Polyfills exist (https://mathiasbynens.be/notes/html5-details-jquery) and hopefully will be fully implemented soon.

Practically, the <header> element can be used for the "masthead" area of a site's header. It can also be used as an introduction to other content such as a section within an <article> element. You can use it as many times on the same page as needed (you could have a <header> inside every <section> on your page for example).

The <footer> element should be used to contain information about the section it sits within. It might contain links to other documents or copyright information for example. Like the <header> it can be used multiple times withina page if needed. For example, it could be used for the footer of a blog but also a footer section within a blog post article. However, the specification explains that contact information for the author of a blog post should instead be wrapped by an <address> element.

The <address> element is to be used explicitly for marking up contact information for its nearest <article> or <body> ancestor. To confuse matters, keep in mind that it isn't to be used for postal addresses and the like (unless they are indeed the contact addresses for the content in question). Instead postal addresses and other arbitrary contact information should be wrapped in good ol' <p> tags.

I'm not a fan of the <address> element as in my experience it would be far more useful to markup a physical address in its own element, but that's a personal gripe. Hopefully it makes more sense to you.

Something that I hadn't realized until very recently is that using h1-h6 tags to markup headings and sub-headings is discouraged. I'm talking about this kind of thing:

<h1>Scones:</h1>
<h2>The most resplendent of snacks</h2>

Here's a quote from the HTML5 specification:

h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection.

That's certainly one of the less ambiguous sentences in the specification! Ooops!

So, how should we author such eventualities? The specification actually has a whole section, (http://www.w3.org/TR/html5/common-idioms.html#common-idioms) dedicated to this. Personally, I preferred the old <hgroup> element but sadly that ship has sailed (more information in the Obsolete HTML features section). So, to follow the advice of the specification, our prior example could be rewritten as:

<h1>Scones:</h1>
<p>The most resplendent of snacks</p>