I am available for freelance work - HIRE ME

How HTML5 Changes the Way We Think of Navigation

posted by Matt Ward on Feb 23, 2011.

The standard method of marking up site navigation and menus has pretty much unchanged for more than a decade now. With the arrival of HTML5, however, I believe that it is changing. In this article, we’re going to take a very brief look at the traditional way of coding menus, contrast it against what I believe to be the better HTML5 method, and even show you how to make it work in primarily-XHTML-based environments.

Update: There have been a number of comments that have already demonstrated a number of holes in what I’ve written below. Please be sure to read the comments as well. There are some excellent and valid points that rightfully challenge the ideas I’ve put forth here.

I think it’s safe to say that most people who keep up with what’s going on in the web development community are pretty excited about HTML5. Granted, there are some who would argue that HTML5 hasn’t really arrived yet, because we don’t have complete support in all browsers. While everything that I have heard and read suggests that IE9 will be the first iteration of Microsoft’s product to support HTML5, the other, current implementations do not. Fortunately, there are some tricks and techniques that we can use to bring a certain level of support, allowing us to follow numerous urgings and start using HTML5 today.

And that’s exactly what I have been doing!

Technically speaking, this version of the Echo Enduring Blog actually uses HTML5. Check out the DOCTYPE tag in the source code—pure HTML simplicity. However, I’m going to be honest here. The switch over to HTML5 actually came somewhat late in the development process, and if you actually examine the rest of the code, what you will find is that it really doesn’t make much use the numerous, new HTML5 tags and elements.

Fortunately, however, with a client project that I am currently working on, I had the opportunity to try a few new things and I decided to make it my first, full blown HTML5 development project. As I usually do, I coded up the design in flat HTML and CSS first, making use of the new <header>, <footer>, <aside>, <article> and <nav> tags as I went. Everything was going swimmingly, and I started to carve the HTML and CSS into a proper template for WordPress (that being my CMS of choice in this instance).

And Bang! I hit a snag. Specifically, I hit a snag having to do with the navigation. But before we get to that, let’s take a minute to talk about history and semantics.

There’s Semantics and Then There’s Semantics

As strange as it may seem, and in spite of everything we have come to expect (and even demand) from websites in the past fifteen years, until the arrival of HTML5 there has never really been a tag or series of tags that were actually dedicated to structural navigation. The <a> tag comes close, but it defines an individual elements, whereas navigation itself is more of a system.

So, using the logic of semantics, developers eventually came to the conclusion that a menu or other navigational tool closely resembles a collection or list of links. Given this, the most logical and semantic choice of the time was to use an unordered list, with each link placed within its own list item. So, if I wanted to code a menu, I would do something like this:

<ul>
   <li><a href="index.html">Home</a><li>
   <li><a href="about.html">About</a><li>
   <li><a href="services.html">Services</a><li>
   <li><a href="products.html">Products</a><li>
   <li><a href="contact.html">Contact</a><li>
</ul>

Over time, this (or some variation) pretty much became the accepted standard for creating navigation (specifically menus), and while I always thought that it was somewhat less than ideal as a solution, it was the best we had and it’s what I’ve been using for years now.

Then HTML5 hit the scene. I’m not sure how many people realize it, but this completely throws the traditional way of doing things on its head! This newest specification features a new tag called <nav>, and as you might suspect, it is used to define a navigational area. Okay, so what’s the problem? Can’t we just do something like this?

<nav>
   <ul>
      <li><a href="index.html">Home</a><li>
      <li><a href="about.html">About</a><li>
      <li><a href="services.html">Services</a><li>
      <li><a href="products.html">Products</a><li>
      <li><a href="contact.html">Contact</a><li>
   </ul>
</nav>

Absolutely. That’s entirely valid markup. But it’s not necessarily good markup. First, it’s redundant. Both the <nav> and <ul> tags are basically fulfilling the same role, acting as a wrapper. So, unless you have a very specific reason why you would need two wrapping elements, using both is simply redundant and ultimately unnecessary.

One option that some people might consider would be to take out the <ul> tags, but that strikes me as somewhat non-semantic—using list elements without a list. And semantics is the other issue that we need to consider. Semantic coding is about chosing the right tool for the job, but sometimes the term “right” should probably be replaced with the word “best”. There may be a number of equally valid options, and its up to us to chose the one that is the most appropriate.

As we have seen, previous to HTML5, using a list for navigation was the most appropriate and semantic decision. But, since HTML5 introduces a dedicated navigational tag, things change. Now, using a list for navigation is no longer the most semantic decision, because we have another option that is more appropriately suited to the task. And so, a menu coded like this would, in my opinion, but much better in HTML5.

<nav>
   <a href="index.html">Home</a>
   <a href="about.html">About</a>
   <a href="services.html">Services</a>
   <a href="products.html">Products</a>
   <a href="contact.html">Contact</a>
</nav>

As an added point of interest, if you check the W3C entry on the <nav> tag, this is pretty much exactly what they provide as their example of how to use the tag.

HTML5 Living in an XHTML World

Now, to bring this discussion back to my WordPress problem—the issue that I ran into stemmed from the fact that WordPress, as it currently stands, still uses the old list navigation method. Using the relatively new (but still totally awesome) custom menus tool that is now built right into WordPress, I created slightly different header and footer menus and deployed them in the custom theme that I was developing.

There, right in the middle of my semantic, well-coded HTML5, was a now-less-than-semantic, list-based navigation, aptly surrounded by a redundant <nav> tag! It was everything I didn’t want for my navigation, and it reminds us of a very simple but important truth: as much as HTML5 is a great new technology, and as much as we should push for its use here and now, the simple fact of the matter is that we are still living in an XHTML (or even HTML 4.01) world!

It’s kind of being left-handed (which I am). You’re part of the minority, and for the most part, you can get by in life without a hitch. Every once in a while though, you run up against something that is just so obviously built for right-handed people that it is all but impossible to use. It’s just a part of being left-handed in a world that is built for right-handed people.

I think that HTML5 is in a very similar situation, at least for the moment. For the most part, you can code freely and not run into a problem. With this navigation issue, however, I came to the point where I had an awesome system in WordPress, which was built on a particular assumption that was true for XHTML (and all its ancestors), but which I longer believe to be valid for HTML5, and while I tried looking for different options and preferences,  I couldn’t find any built-in way of moving from list-based navigation to purer <nav> based menus.

A Functional Solution

Fortunately, I did come up with theme-based solution, which involved writing a custom PHP function to manipulate the generated HTML. Basically, instead of just printing out the menu’s HTML, I wrote it to a variable, then passed that through a bit of processing before echoing (writing) my own, much simpler code. Here’s the function:

function custom_wp_nav_menu($menu,$menu_id){
   $custom_menu_html = wp_nav_menu( array(
      'container' => false,
      'echo' => false,
      'theme_location' => $menu
   ));
   $custom_menu_html = strip_tags($custom_menu_html, '<a>');
   if($menu_id == ""){
   echo "<nav>\n";
   }
   else{
      echo "<nav id=\"$menu_id\"gt;\n";
   }
   echo $custom_menu_html;
   echo "</nav>";
}

The logic here is really, really simple. First, we start by calling the wp_nav_menu WordPress tag, passing it a few key options. Setting the container property to false eliminates any default HTML elements used to wrap the menu, while setting the echo property allows us to return the HTML rather than immediately echoing it. Lastly, the theme_location property tells us which predefined menu we want to use, information which we pass into the custom function.

Then we use the PHP strip_tags function to strip out everything but the <a> tags, leaving us with a grouping of menu links saved to a variable. Then it’s just a matter of echoing the required tags to complete the transformation.

You’ll also notice that we have a second option in the function, which basically allows us to declare an id attribute for the surrounding <nav> element. This is useful for sites that declare multiple navigation areas, such as header and footer menus, which may be slightly different in terms of content and styling. You could also use this technique to pass in custom classes, or whatever else you may need.

Conclusion

Ultimately, it’s not the most ideal solution and it definitely feels a bit like a hack. However, until we make a fuller transition from XHTML list menus to purer HTML5 menus, it remains a relatively quick and easy workaround for those who continue to pioneer with emerging web technologies, as well as those who are just being introduced to them.

That being said, then, I hope this article has helped to introduce some readers to reality of certain semantic shifts that arise as a direct result of the new HTML specification, has helped illustrate the changes that are coming to the way we markup navigation, and (perhaps most importantly) provided a technique for deploying HTML5 in an XHTML world.

What do you think? Are you using HTML5 in your sites now? How are you coding your navigation and menus? Have you run into this or other, similar problems?

Post A Comment

Also from Echo Enduring Media:

An Unfolding Tale

About the Author

Matt Ward is a digital artist who lances freely under the moniker of Echo Enduring Media, and specializes in graphics design, illustration and writing. He is also the Creative Director for Highland Marketing, a creative direct marketing company based out of Waterloo, Ontario. You can follow Matt on Twitter

Like this post? Help Promote it!

Comments

Feb 23, 2011

Aaron James Young says:

Interesting thoughts. I appreciate the semantics of an unordered list of links, but brevity is attractive too. What do you think about marking-up multi-level navigation?

Feb 23, 2011

Russ Weakley says:

Apologies if this seems picky but…

1. The link you mention does NOT point to the W3C, it points to W3 Schools website – which is not in any way related to the W3C

2. If you look at the HTML5 spec, the two key examples given include the [nav] element followed by [ul] element.
http://dev.w3.org/html5/spec/Overview.html#the-nav-element

HTML5 spec example 1 (not sure how this markup is going to work in your comment box)

[nav]
[h1]Navigation[/h1]
[ul]
[li][a href="articles.html"]Index of all articles[/a][/li]
[li][a href="today.html"]Things sheeple need to wake up for today[/a][/li]
[li][a href="successes.html"]Sheeple we have managed to wake[/a][/li]
[/ul]
[/nav]

HTML5 spec example 2:

[nav]
[ul]
[li][a href="/"]Home[/a][/li]
[li][a href="/events"]Current Events[/a][/li]
…more…
[/ul]
[/nav]

Also, more here at the HTML5 Doctor – which also uses [ul] inside the [nav] element.
http://html5doctor.com/nav-element/

Having said all of this, the HTML5 spec does state that other types of markup could be used:

“A nav element doesn’t have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:”

to me, the most important point is that if you turn off CSS, the site should be meaningful to PEOPLE – first and formost!

If you place a series of [a] elements directly inside a [nav] element then you could have people seeing a bunch of totally unstructured links. This could make it much harder for people to distinguish them individually, let alone click on them.

I alway prefer to use the [nav] followed by a descriptive heading of some sort (such as an [h3]) followed by a [ul] and then the relevant [li] elements.

Years ago I did testing on screen reader users and found that headings used to describe navigation were very helpful for these users. The headings helped to describe the functionality of each page component.

More here
http://www.maxdesign.com.au/2006/01/17/about-structural-labels/

Thanks for listening :)
Russ

Feb 24, 2011

cghearn says:

Thanks for the heads up on this tag. Since HTML5 isn’t fully supported yet, I have been hesitant (at best) to implement new tags into current work. This is one that will be a huge help in the near future.

Feb 24, 2011

Louis says:

Hey, Matt. There are a couple of things to note about what you’ve said here:

First, there’s nothing wrong with wrapping a nav element around a list. Yes, it’s a bit redundant, but the semantic benefits outweigh that small drawback. Eventually, when HTML parsers and outlining algorithms are updated, the “nav” element will prove beneficial. Plus, if you need to use a list, that’s really the only way to do it. Which brings me to the second point…

You mentioned that the “W3C” used a list-less example. That website you linked to has nothing to do with the W3C. That’s “W3Schools” which has no connection to the W3C. They publish lots of info, and they appear very high in search results (because people often link to them, thinking they’re the W3C, as you did). But much of their content is very inaccurate.

See this website, launched recently:

http://w3fools.com/

The actual W3C spec uses nav to wrap a list, as you can see here:

http://dev.w3.org/html5/spec/Overview.html#the-nav-element

Anyhow, I’m sorry, I don’t mean to sound like a jerk or anything. Up until recently, I actually had the same impression about W3Schools, so it’s understandable. I would suggest you remove that link and not give them any more link juice than they already have. :)

Feb 24, 2011

Russell Bishop says:

I think I agree with using anchor inside of the nav and dropping the and ‘s, but aren’t we then in trouble when it comes to drop-down navigation (nested menus)?

Also, styling the nav will be more difficult without s, as they’re a good way of styling the nav without affecting the hit-areas of the anchors inside.

Will be interesting to hear your thoughts!

Feb 24, 2011

DESIGNfromWITHIN says:

Very interesting!
My first reacion is that it feel very strange to see a menu without items! But I must agree that this is the way it should be, very clean and nice.

But I think it will be some time before I will get away from the tags….

Feb 24, 2011

Russell Bishop says:

Ah, looks like my HTML was stripped from that comment.

“I think I agree with using anchors directly inside of the nav element and dropping the list items, but aren’t we then in trouble when it comes to drop-down navigation (nested menus)?

Also, styling the nav will be more difficult without list items, as they’re a good way of styling navigation without affecting the hit-areas of the anchors inside, and are crucial for revealing nested elements.

Will be interesting to hear your thoughts!”

Feb 24, 2011

RM says:

Whilst I agree that *should* be used without a <ul>, it seems a little anal to include a PHP hack to implement this in WordPress. Although I could now copy/paste your code, it’s still not a great use of my time on a client project! And if I explain what I’ve done, I’m just going to get blank faces!

Unfortunately I think this is one of those areas where we are just going to have to be patient whilst the rest of the world catches up.

Feb 24, 2011

Rares says:

What about all the special classes WP adds to the wrapping <li> tags?

There must be an easy way to move those to the anchor tags…

Feb 24, 2011

Matt Vaughan says:

What about hierarchical menus? With lists, you can define a new ul inside a li to get a new level. How would you do that using nav?

Feb 24, 2011

steve faulkner says:

“Both the and tags are basically fulfilling the same role, acting as a wrapper.”

This is not correct – The nav element semantic indicates these are links that point to other parts of this site. The unordered list provides a programmatic grouping which is conveyed to assitive technology users as a list with X items.

Feb 24, 2011

Brant says:

I think that (at least for the time being) using a nav->ul->li->a style markup is a good idea.

First, in terms of accessibility, I think that it will provide an easier transition for screen readers. Many of them deal fairly well with lists and the lists become fairly recognizable as navigation.

Secondly, there are many designs that often end up with the main navigational ul wrapped in a div or something anyway. So, in such a case, the div wrapper gets replaced by a semantic html5 nav wrapper, which still adds value.

Feb 24, 2011

Jeremy Carlson says:

I find it funny that HTML5, in this kind of example, has us clutter up the HTML we were trying to simplify. Kind of like ‘divititis’ on purpose.

This markup doesn’t bother me though. This is for semantic reasons. What bothers me is that definitions for when and where to use these tags were being changed. Like the ‘aside’ tag being used in a sidebar. Or when and where to use the ‘address’ tag. I dislike things like “You can/may use it here.” It’s less cut and dry. I know where to use the HTML4 tags, but saying you may, but not necessarily, use this tag here bugs the crap out of me. I don’t like the options like that. It should be plain English “use this tag right here, always!”

Luckily they have been defined better now, but I still see what I think is misuse of some HTML5 tags.

As to this type of thing though, I just look at tags like nav, section, article, aside, and footer as more semantic divs, some of which I don’t have to use id’s on anymore. I get your point, but I am not going to change the way I create a navigation because of an additional tag wrapped around it. Besides, a bunch of the menus I build need the ‘li’ tag for styling anyway. Or at least a second tag, and I would much prefer doing the list-item over a span or using css :before or :after until I can be sure non of the people viewing the sites I am building are not useing IE7 (or 6 for that matter).

Feb 24, 2011

Steve says:

I agree with Steve Faulkner this is totally wrong. I think where you’re coming from is something along the lines of:

“I used the [ul] for styling, so now i have a [nav] element that i can style I shouldn’t need the [ul].”

Like Steve said, the [ul] isn’t a wrapper, it’s not presentational mark-up, it’s part and parcel of displaying a list, of which I (and the W3C, the proper W3C not W3 Schools) consider to be a perfectly acceptable and semantic way of displaying groups of navigation links, wrapped in a [nav] or otherwise. http://www.w3.org/wiki/Html/Elements/nav

When using HTML5, you’ll often find you use more markup than perhaps you would in XHTML. Take a [header] element for example. According to the spec you should wrap [article] headers, [section] headers, etc in that tag too, and if you use multiple headers together (that are related) wrap those [h] tags in [hgroup] as well. Extra markup like this isn’t a bad thing if it makes the document more semantic and readable to assistive technologies.

Feb 24, 2011

Netraam says:

In order of semantics I always follow the usability of the website when all markup is turned off.

Having this said it comes in ease when navigational elements are prefixed with a dot and presented below eachother instead of becoming one horizontal line of text.

Leave a Comment

The comments are closed.

Copyright © Echo Enduring Media 2009-2014