Friday 19 December 2014

Thoughts About HTML5 Structural Elements - Vanseo Design

Thoughts About HTML5 Structural Elements - Vanseo Design


Thoughts About HTML5 Structural Elements

Posted: 18 Dec 2014 05:30 AM PST

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.

The post Thoughts About HTML5 Structural Elements appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now