HTML5 Structural Elements — Series Wrap Up

Posted: 23 Mar 2015 05:30 AM PDT

For the last month and a half I’ve been trying to better understand how to work with the new HTML5 structural elements with some degree of success as well as failure. Now that the series is done, what did I learn?

I’ve talked about the document outline, the definitions of the new elements along with the definitions of the ARIA roles each maps to, and then I offered a demo and explained my choices for using and not using the new elements. If you missed any of the previous posts, here’s the entire series to this point.

This is the last post in the series. When I started the series I’d characterize myself as something of a hostile witness to these new elements. I didn’t expect to find any reason to use them beyond this series.

I was wrong and I thought I would conclude the series by sharing what I learned working on it and how I plan to incorporate the new sectioning and non-sectioning elements in my work.

Document Outline

When I finished the demo I thought why not check what the HTML5 document outline would be. I know it’s not in use anywhere, but I was curious and thought I’d take a look and see if I could learn anything. I ran my HTML through one of the outliners and here’s the outline that was returned along with the elements that create each new section.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20

1. Document<body>      1. Section<section>      2. Navigation<nav>      3. Demo to explore html5 Structural Elements<article><h1>          1. Section<section>          2. Basic Structure<h2>              1. CSS Presentation<h3>          3. Thoughts About HTML5<h2>          4. Section<section>              1. About Steven Bradley<section><h3>          5. 3 Comments<section><h2>              1. Article<article>              2. Article<article>              3. Article<article>      4. Sidebar<aside>      5. Categories<nav><h3>      6. Connect<aside><h3>      7. Example Sites<aside><h3>      8. CSS Layouts<aside><h3>      9. Sponsored by<section><h3>

The outline shows I’ve set up each block of content inside the header, footer, and sidebar at an equal level in the hierarchy to the article.

I tend to think the main content of any page sits at a higher level in in the hierarchy than the boilerplate content, but that’s not how I structured my HTML according to the algorithm for the HTML5 document outline.

Again the algorithm that produced this outline isn’t in use, but it does make me want to think more about how we structure content as part of the hierarchy. Should information in a sidebar sit at the same level in the hierarchy as the main content?

I don’t know, but it’s a good question to ask and think about. If sidebar content should be at a lower level in the hierarchy, it suggests I should find a different way to markup sidebar content. For example changing div class=”sidebar” to aside class=”sidebar” places the sidebar container at the same level in the hierarchy as the article, but the content within the sidebar would be one level lower.

1  2  3  4

4.Sidebar<aside>      1.Sidebar<aside>      2.Categories<nav><h3>      3.Connect<aside><h3>

I think you can make a case that this kind of outline makes more sense than the one I created with the structure I ultimately used. On any given page the content of the page should be seen as more important than boilerplate content. Of course, to follow through the rest of the boilerplate would need to be marked up with sectioning elements so header and footer elements wouldn’t make sense.

I’m not sure which is the better structure, but it’s worth thinking about in this context. One of the things I learned these last few weeks is it’s worth spending more time thinking about the structure of our HTML and what it communicates.

What I learned About HTML Writing This Series

I sometimes mention how many posts here come about from my wanting to learn something. This series didn’t start out that way. I began what I thought would be a single post about the HTML5 document outline after a comment Jordan left on a post about why I don’t use the new HTML5 structural elements in practice.

I may have thought it would be a single post, but something in the universe had other plans. The more I looked at the document outline and the new elements, the more confused I felt and the more research I did to try and clear the confusion.

Comments by Šime on the first post in this series let me know I’d missed something important about the new elements where assistive devices was concerned. I went back for more research and rewrote much of the series at that point.

All the research and revisions led to a lot of back and forth in how I feel about using the elements and how well I understand them. Both had me wondering if I would use the elements in practice once I concluded the series.

As I reworked the demo and continued to discover more information, particularly the ARIA role definitions, I had a few realizations.

There is a benefit to using the new elements, which is what they communicate to assistive devices.
Despite what I still think are somewhat confusing guidelines for their use, if we as an industry use the new elements consistently we’ll give them more standard definitions through our use.
The structural patterns I currently work with didn’t spring forth overnight. I’ve spent nearly a decade evolving these structures so why should I expect anything different with the new elements.
A large part of my confusion comes from lack of working with the elements I want to understand. More practice should lead to more understanding.

I know many of us like to think we’re always making objective decisions when we design and develop websites, but there’s a lot more subjectivity in our decisions than we might care to admit.

The structure we choose for our HTML is also subjective. There’s no single right way to structure the HTML for a web page. Different developers will make different decisions that work. Take navigation as an example. I build navigation with an unordered list. Others use ordered lists. Two more common patterns for navigation bars are inline-blocks and CSS tables.

Any of these approaches is fine. They each have a few tradeoffs that may or may not affect a specific project, but more likely each is used based on the personal preference of the developer.

It will be the same with new elements like section and aside. We’ll need to work with them awhile to develop the patterns we eventually use and there will likely be several common patterns in use across the industry.

Incorporating the New into the Old

I did gain a new appreciation for the value and use of the new elements and I would like to use them more. I had forgotten, but I did use the HTML5 elements when I developed this site’s current design.

I think the easiest way to use the new elements is to incorporate one or two at time into your work. A few of the new elements do replace a div and class combo you probably use and the new element is meant to work the same way.

We can start by making the following substitutions.

1  2  3  4

<div class="header">  -->  <header>  <div class="footer">  -->  <footer>  <div class="main">    -->  <main>  <div class="nav">     -->  <nav>

You barely have to alter your CSS practices with these changes. Instead of .header you’ll write header (with or without an additional class). Same for the other three elements. From here you can experiment.

With the header and footer elements you can decide if you only want to use them once each per page for site headers and footers or if you want to integrate them more through your document. Spend some time researching the use of headers wrapping h1–h6 headings at the start of any new section in the outline.

Do similar with the footer element. Do you think a footer is a good call for meta information inside an article? Put in some time thinking about it and decide for yourself. You can always change your mind later.

You can do the same with the other three elements. Enclosing your main content inside an article element is another painless switch. Whether to structure blog comments or forum posts as articles is a different question. Again, research, try, and think critically about the decisions you make.

I had a hard time sorting out how to interpret related and tangential making both asides and sections confusing at times. Some of my confusion was my misunderstanding of the spec’s definition of related to what.

It’s something I’ll continue to think about and I suspect as I gain more information and put more thought into the problem, I’ll come to a more confident decision about using asides and sections.

I know I wasn’t an expert in using divs and spans the first time I used CSS for a site layout. None of us was. It’s the same with these elements and the structural patterns we’ll eventually settle into.

One last thought for the future is to continue to check your document outline. Despite the lack of use for the HTML5 document outline algorithm, it can be a useful tool for seeing how you’ve structured your page and what you’re communicating with that structure.

Closing Thoughts

I learned a lot more than I expected when I started this series. I admit to going in as a hostile witness. I’ve come out the other side with a greater appreciation for and a greater desire to use the new elements more.

At the start I didn’t see any harm in using the new elements, but I wasn’t seeing any benefit either. That changed when I learned the new elements communicate to assistive devices.

If you’re still on the fence, I recommend coding a demo of your own. Develop one of your typical layouts for a web page and use the new elements when doing so. For each part of the document ask yourself what elements you might use and think about the pros and cons of each.

I was able to work through a lot of my confusion only when making real decisions about what element to use.

I’ll add one last reason for working with the new elements before closing. Sometimes it’s just good to shake up your routine. It’s easy to become too comfortable with a way of doing something. I found myself thinking about and questioning some of my common practices because I forced myself to change those practices with the new elements.

If you take only one thing away from this series, take the idea that critical thought about how you structure your HTML is worth the investment. The new HTML5 elements give you a perfect opportunity to do that, especially if you aren’t yet working with them.

I think many of us take the structure of our HTML for granted to some degree. We use the same patterns we’ve used for years and don’t consider if they could or even should be improved.

Change for the sake of change gets you to question your current practices and think about a lot of things you possibly take for granted. Think of it as a spring cleaning for your coding practices.

I hope you enjoyed this look at HTML structure. It’s been a few more weeks than I originally expected and I think it’s time to finally put this series to rest. Maybe I’ll report back after using the new elements more often in practice, but for now it’s time to move on to another topic.

Download a free sample from my book Design Fundamentals.

The post HTML5 Structural Elements — Series Wrap Up appeared first on Vanseo Design.