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

Posted: 16 Mar 2015 05:30 AM PDT

As I mentioned last week, it’s one thing to learn how to use the new HTML5 structural elements and another to actually use them. In the past I’ve found using some of the HTML5 elements like aside seemingly easy to understand, but more difficult to use in practice.

So far in this series I’ve talked about the document outline we work with and the HTML5 outline that’s been proposed, but not used anywhere. I followed the outline talk with definitions for using the new sectioning elements and the new non-sectioning elements.

Last week I presented a demo that uses these new HTML elements and started to share my decisions and reasoning for using the elements I did and didn’t use. I talked briefly about the overall layout and then offered more details about both the header and main content areas.

Today I want to look at the other two parts of the layout, the sidebar and footer. I found both more confusing to structure mainly because the deeper I’ve looked at it the less I’ve understood what an aside really is. I’ll follow with some thoughts about how I used headings throughout.

Here’s the demo again in case you missed the link above and want to follow along.

The Sidebar

The sidebar turned out to be more confusing than I expected. My initial thought was to wrap an aside around the entire thing, but the more I thought about it, the more I disagreed with using an aside.

Is the whole sidebar related to the main document outline? If it is, it’s related in the same way the header and footer and all boilerplate content is related to the main document outline and should use an aside as well.

One question I kept asking is what does it really mean to be tangentially related to something? And related to what? Is it related to the main content of the page or the main document outline, which is the entire page.

The impression I originally got reading the spec is related means to the main document outline, but that starts with the body element. To me it makes more sense for an aside to be related to something a little nearer in the hierarchy. An aside in an article should be related to that article. An aside in a footer should be related to the main content in that footer.

Note: In looking again at the spec and the definition for an aside (after finishing the demo), the tangentially related part is clearer than I was thinking:

a section of a page that consists of content that is tangentially related to the content around the aside element

Unfortunately it’s something I had forgotten when working on the demo, though it is where my thinking was leading. Some of my confusion about asides is clearly of my own doing it seems. It’s a good argument for reviewing what you think you know from time to time.

It seemed more logical to me for the content inside the sidebar to be an aside, but the sidebar as a whole should probably be something else. I’m not sure that’s best, but it’s what seemed logical at the time.

I thought about using a section as the sidebar container, but there’s no reason why every block of content inside has to be related. How are the subscribe link, the category navigation, and social buttons related to each other? They’re related through their connection to the whole site, but so is everything on the page.

In the end I decided the wrapper is there solely to present what’s inside. It helps align elements within the layout. Since it’s for presentation only I went back to using a div and added the sidebar class for styling.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28

<div class="sidebar">    <aside role="complementary">      <a class="rss" href=""><img src="" alt=""> Subscribe</a>    </aside>      <nav>      <h3>Categories</h3>      <ul>        <li><a href="">CSS</a></li>        <li><a href="">Web Design</a></li>        <li><a href="">WordPress</a></li>        <li><a href="">Blogging</a></li>        <li><a href="">SEO</a></li>      </ul>    </nav>      <aside class="connect" role="complementary">      <h3>Connect</h3>      <ul>        <li><a href="" class="twitter"></a></li>        <li><a href="" class="google"></a></li>        <li><a href="" class="linkedin"></a></li>        <li><a href="" class="dribbble"></a></li>       <li><a href="" class="pinterest"></a></li>      </ul>    </aside>    </div>

I decided to wrap both the RSS information and the social buttons with an aside (along with a complementary role), though I still have some questions about relatedness. What’s the content around the asides here? Is it the other aside and a nav element? Is it the container?

When I used a div to wrap the entire sidebar I said the content inside wasn’t truly related to each other. In that case I shouldn’t be using an aside for the content inside. Either the content or the container would need to change to be consistent, but as you can see I opted for the inconsistency.

The buttons are a list of links to external sites. The external part says a nav element isn’t appropriate and so again I chose an aside.

The nav element made perfect sense for the category menu, however. I didn’t add a class like I did for the global navigation and opted for nested element selectors, though I probably would add a class in practice.

Other than structuring the category navigation inside a nav element, I have questions about most everything I did here. I could easily change my mind about everything by tomorrow.

My main question with asides is still to do with their relatedness. The spec is clearer than I originally thought about what an aside should be related to, but in practice I still find myself getting tripped up.

The problem is related and tangential are subjective words. Is a list of recent posts tangentially related to to the post that serves as the main content on the page? I don’t think so, but some would probably say it is. Both are related to the blog as a whole, but not to each other beside the general blog connection. Change recent posts to related posts and by definition they’d be related.

Perhaps I’m overthinking things. A simpler approach with the sidebar might have been to wrap everything with an aside and then structure the rss link and social buttons as sections.

In the end I think the question to decide is what is your definition of around the aside. Deciding the container should be an aside means you’re comparing it to the main content and other boilerplate on the page. Deciding the content in the sidebar is an aside means you’re comparing it to the content in the same container.

The Footer

The footer was another area of confusion for me, though much of the confusion was of my own doing. The content I placed inside the footer isn’t exactly indicative of the kind of content I would place in a typical fat footer.

In the original demo the three blocks of content on the dark gray background were not inside the footer element. They were inside a separate div with an id of footer. I was thinking of them as something unique to the page and not necessarily the whole site. This time around I decided to code this area as though it was a site footer and not for the page only.

Some of the content in the footer is page specific, though. Having a little of both site footer and unique page footer threw me off when I was making decisions about how to structure everything.

What probably makes more sense is to treat everything inside the gray background as another sidebar and structure it similar to the way I just described in the section about the sidebar. The footer would consist of the copyright and credit information only, which again is how I did it the last time.

Instead I chose a footer element (with contentinfo ARIA role) that includes both the gray background and the copyright information. Because I wanted the copyright outside the gray background, I wrapped everything inside the gray area in a div.

The background is presentational only and the content in each block isn’t related to the other blocks. For both reasons a div made more sense to me than a section.

1  2  3  4  5  6  7  8  9

<footer role="contentinfo">    <div>      <aside role="complementary"></aside>      <aside role="complementary"></aside>      <section  class="advertising"></section>    </div>      <p class="copyright"></p>  </footer>

Originally I structured each of the three blocks as an aside, though see my questions from the sidebar section about what’s related to what.

After reading the definition for the complementary ARIA role, I decided the ad block shouldn’t be an aside, since it can be completely removed from the main content. It doesn’t support the content and could easily placed on another page with different content without any loss in meaning.

Instead I wrapped the ad in a section. In the demo there’s a single ad, but it’s easy to imagine several ads here related to each other by being ads.

The other two blocks I left as asides, though again see my questions about what’s related to what. Some of my specific confusion here is the way I mixed page specific and site specific content in the footer, but much isn’t. I still haven’t answered the related questions for myself.

Inside each aside is a heading (h3), a paragraph, and a list of links. I didn’t wrap the links with a nav element. The example sites link to external sources, and the layouts aren’t really navigation as much as a few recommended links.

Headings

In this demo I opted to use headings as I always have. There’s a hierarchy of h1–h3 tags inside the article. Headings inside the sidebar and footer are all h3s. I don’t know if h3s are the best choice, but it was my choice

I’ve never settled on a best practice for headings outside of the hierarchy of the main content. I don’t use h1s outside of the main content. I sometimes use h2s, sometimes h3s, and occasionally h4s. My choice is usually based on what’s easier for me at the moment, which isn’t a good way to choose what level heading to use.

I decided not to use header elements around headings at the start of sections. After learning about the ARIA region role, a better choice would probably have been to use headers around headings in the article as each would likely be included in a table of contents for the article.

My reason for not using headers around headings was the extra markup. I would think there’s another way to communicate the same semantics to assistive devices and it’s something I’ll look for. The rationale for using headers makes sense to me if they help assistive devices, but I’m not sold on the implementation just yet.

In the end I stuck with the same old for how I used headings in the demo. I’ll consider the idea of using headers to help assistive devices or I’ll look for another way to communicate the same information. In other words I still have some things to work out where headings are concerned.

Closing Thoughts

The sidebar and footer were definitely the areas of this demo that were the hardest for me to structure. I went back and forth a number of times on both. The sidebar was both an aside and section before I ultimately decided to use a div. The footer went through similar changes.

Most of my confusion with both stems from questions about what we’re comparing when we decide if something is related. I suspect I’ll need to think a lot about the question before coming to any decision. The definition seems clear enough, but the definition suggests that asides only ever live inside the main content of a page even though typical sidebars are mentioned as a common use case.

I’m surprised, because prior to this series, an aside was one of the elements I thought I understood well. The deeper I look, the more confusion crept into my thoughts. It’s possible I’m overthinking their use.

Next week I want to finish talking about the demo and the series itself. I want to share what I learned working on this demo and from the posts that preceded it. I also want to share how I plan to work with all the new elements in the future. I’ll leave you with a few closing thoughts to wrap up the entire series as well.

Download a free sample from my book Design Fundamentals.

The post HTML5 Structural Elements — How I Built This Demo: Part 2 appeared first on Vanseo Design.