By Craig Buckler

Should Navigation Be Defined in Lists?

By Craig Buckler

An interesting article has been posted on Chris Coyer’s CSS-Tricks: Navigation in Lists: To Be or Not To Be. The article provoked a plethora of comments and debate. Here’s a summary…

When faced with creating a navigation menu, most web developers will implement code such as:

		<li><a href="#">Home</a></li>
		<li><a href="#">Products</a></li>
		<li><a href="#">Services</a></li>
		<li><a href="#">About Us</a></li>
		<li><a href="#">Contact Us</a></li>

Those who haven’t emigrated from HTML4 land will omit the <nav> and use <ul id="nav"> or similar.

The question: are list elements necessary?
Naked links are leaner and cleaner…

	<a href="#">Home</a>
	<a href="#">Products</a>
	<a href="#">Services</a>
	<a href="#">About Us</a>
	<a href="#">Contact Us</a>

Prior to HTML5, lists were required:

  • older browsers could struggle styling inline elements
  • adjacent links could cause accessibility issues in screen readers, and
  • you had to place navigation in something — lists were a good option.

These issues mostly disappear with the introduction of the HTML5 <nav> element. Superfluous list elements are unnecessary because the browser/screen readers understands that it’s a navigation block and can process links accordingly.

That said, there are a number of good reasons to retain lists:

  1. Hierarchical menus and sub-menus can be defined. There’s no reason why other elements couldn’t be used, although there are few benefits, e.g.
    	<h1>Main Menu</h1>
    	<a href="#">Home</a>
    	<a href="#">Products</a>
    		<h2>Product Menu</h2>
    		<a href="#">Product One</a>
    		<a href="#">Product Two</a>
    	<a href="#">Services</a>
  2. Lists provide additional elements for CSS hooks and styling.
  3. Lists are a widely adopted technique which developers know and expect.

Navigation lists have become ingrained as the definitive technique. Few of us consider listless navigation; it feels wrong — but is it? It will depend on the circumstances and it’s easy to get bogged down in semantic squabbles, but I suspect Chris is correct: lists are often unnecessary.

I’m going to attempt naked link navigation in my next project. Will you?

  • Jeff Seager

    Probably not. Your points are well taken, Craig, but I think backward compatibility is going to remain an issue for all of us for a little while. I see no DISadvantages to using an unordered list, really, and even the most complex UL navigation menu actually renders nicely for alternative user agents like text-only browsers. Accessibility is one of my biggest concerns, and I think naked links might be messy for user agents that are (or may be) programmed to seek navigation links in a structural context. I’d love to see this addressed by anyone truly knowledgeable about screen readers (JAWS, Window Eyes) … I work with some folks who use them, but I’m not that familiar with the details.

    It’s hard for me to imagine anyone choosing not to use a modern browser, and yet I DO own a perfectly capable and fully functional hand-me-down 1998 Mac Powerbook G3 (for which the most modern compatible browser is Classilla). Your average cellphone gives a better web experience these days, so I’ve found other uses for it! My point here is that some people for any number of reasons may not be browsing with optimal equipment OR browsers, and I (we?) need to make some allowances for that. Naked links seem like a step backward, from the accessibility standpoint.

    • I suspect lists will be the safest option for some time to come. Accessibility issues such as adjacent links remain the best reason to use them. But longer term, HTML5 appears to make them redundant.

      • Jeff Seager

        Interesting example given in the current HTML5 spec, still a work in progress by the W3C and not a final recommendation:

        “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:

        You are on my home page. To the north lies my
        , from whence the sounds of battle can be heard. To the east
        you can see a large mountain, upon which many school papers are littered. Far up thus mountain
        you can spy a little figure who appears to be me, desperately
        scribbling a thesis.
        To the west are several exits. One fun-looking exit is labeled “games”. Another more
        boring-looking exit is labeled ISP™.
        To the south lies a dark and dank contacts
        . Cobwebs cover its disused entrance, and at one point you
        see a rat run quickly out of the page.
        … ”

        I think the important consideration always will be context. Does the structure support the context, and is the navigation rendered on all devices in a way that makes sense to the end user? This navigation text from the W3C above is a neat idea that we can’t say is “wrong” if it’s understood by the user to be a nav tool.

      • Christian

        People are really missing the important point here although some are coming quite close. If you have a list of links then it is a list. A list is a list. It doesn’t matter if it’s surrounded by “” or “,” because it’s still a list. Now, if you have a paragraph which includes links, as in the example Jeff Seager just showed, then it is a paragraph which includes links whether it’s surrounded by “” or “.”

        So, no, using UL > LI > A is not mandated within a NAV element and that is because there is more than one way to present links. But the new presence of the NAV element doesn’t somehow mean that a list of links is somehow not a list anymore.

  • I’m still using lists for navigation, and judging by the pros and cons list, they’re fairly even and it comes down to a personal preference. Sometimes as a developer you just have to remember that as long as it works, 99% of your audience won’t really care how it works.

  • James

    I’ll be interested to read the comments on this one. I do feel like what we’re talking about IS a list. It’s a list of links to the pages of your site (or to functions). So I’ve always felt like it was simply ‘right’ to use lists for navigation. That said, I never felt totally comfortable with some of the CSS required just to make lists work as a horizontal nav-bar, so I’ll probably play with Naked Nav in private…

  • “I’m going to attempt naked link navigation in my next project. Will you?”

    After reading this article, I will certainly try naked navigation next time. Thanks for the tip!

    • Charles Ryder

      Enlightenment! I agree, and thanks Craig (and sitepoint) for the original post.

  • JoeFlash

    From what I have read the issue is with the loose adjacent provision of links. According to the accessibility requirements adjacent links require some form of markup or visual presentation to separate the items for a clear understanding of the content. When the CSS is removed these adjacent links loose a clearly comprehensible presentation of where one link ends and the next begins. The use of the unordered list was adopted to resolve this point of issue since each link gets rendered on it’s own line with a bullet point to mark the start of each.

    • Accessibility is/was the main reason for using lists. However, by definition, a nav element tells the browser/screen reader that one or more links are contained. It can render/read them appropriately.

      As far as I’m aware, some screen readers include list “text” when reading navigation, e.g. list item one: Home, list item two: Products, etc. If that’s the case, naked links may be more beneficial.

  • I would strongly recommend to not use a navigation without a list for accessibility and usability reasons. The discussion started at CSS-Tricks some days ago ( and they brought it to the point:

    • Interesting. Chris appears to have moved back to the opinion that lists are the ‘best’ option.

      That said, I suspect it’s closer to a draw. It’s difficult to quantify, but I doubt naked links actually cause serious accessibility issues — especially if the device is HTML5-aware.

  • When people looking for the new hatml,css and other versions to improve our development then those situations they can take several advantage of websites.

    • mister wales

      I couldn’t agree more. Absolutely brilliantly put. Yes.

  • Patrick

    I’m not sure why you frame this as a benefit of HTML5 – you could put anchors in a just as easily as in a . It’s got nothing to do with HTML4 vs HTML5, it’s about browser support for styling inline elements.

    The two techniques are more or less equivalent for simple navigation bars, but nested (hierarchical) navigation is much easier to achieve with lists. For that reason, I always use lists so that my markup and stylesheets are consistent, regardless of the type/depth of navigation I happen to be using.

    • HTML4 doesn’t have the nav element so the browser/screen reader cannot know a list contains navigation. Using a list is therefore the best/only option.

      • ralph.m


  • Chris Emerson

    A menu is a list of items to choose from or click. What better way is there to mark up a list, than marking it up as a list? Why the unnecessary drive to try and minimalise things and remove all semantics at the same time?

  • Kenny Landes

    Redundancy is not distinguished by whether or not markup is needed in order to style content to look the same. If it was, then we have passed the point of needing lists in navigation. Markup gives structural meaning to the content. Most navigation is in reality a list of links, regardless of how it is styles. So I think it makes better sense to code it semantically as a list wrapped in a nav tag to distinguish it from, say, a list of bullet points in an article, which would not be wrapped in or considered nav. There may come opportunities to do navigation in new and creative ways that would not require a list. Let’s start seeing them. Until the assertion made in the article is dubious.

    • Kenny Landes

      And excuse my bad editing!

  • Really interesting, this gives a lot to think about.. (actually I’ll implement this approach in my next project or at least I’ll try)

  • David

    While not a must, I always thought it was a nicer layout for the nav in case the CSS didn’t load at all.

    • That is a good point, especially when you’re stuck with Lynx!

  • I agree with James above. Navigation IS a list – a list of links – so a UL seems appropriate. My other comment is that most platforms for creating web sites are built around UL as navigation. Until that changes, I don’t see re-inventing the wheel.

    • OK, so why isn’t in an ordered list?! To be honest, any number of items can be defined as a ‘list’ so I’m not wholly convinced by that.

      • Christian

        It’s still a list. The fact that one might not know if a particular list should be ordered or unordered doesn’t make the list not a list. And the way to choose between a UL and an OL is if the order of the items is important. A grocery list is an example of a list where the order probably is not important. A recipe instruction list is an example where the order probably is. Actually recipes tend to have both kinds of lists:

  • I commented on Chris’s CSS-Tricks post on this subject as well…I still believe that most of the times a list for navigation is a good thing…

    In my mind a web site’s navigation links are akin to a table of contents….which could be thought of as a list of links…also links display nicely in vertical rows with out any CSS and if you have secondary navigation items in lists then those often show indented in browsers where the CSS has been turned off…giving a nice visual hierarchy to your navigation system without any CSS required…

    I fail to see other than the few extra keystrokes required for navigation list why some people feel that they are no longer a good thing or even needed….I am not saying that lists should always be used for navigation but for me I think I will use lists as the default unless their is a reason not use them…

  • Stevie D

    Until such time as support for HTML5 elements is widespread in browsers and assistive technology, and consistently interprets unseparated anchors that are direct children of blocks, I don’t think it’s sensible to say that we can eschew the st containers. You can’t just say “browsers can interpret this sensibly so they will”, because the real world just doesn’t work like that, and you’ll be leaving huge chunks of your potential audience out in the cold.

  • Robert Horowitz

    I am a beginner. I thought it strange to put nav links in a list because as a user. I just never thought of them that way, then I got it. Then I saw that any time you have more than one of something in the same place, it was a list eg blocks on a page, p in an article, pics in a gallery etc. I started putting everything in ul’s. Then I stopped because it got silly.

    I think that if you think it makes your code more readable to you/someone else or improves your visitor’s experience, do it. If not, skip it.

  • Thanks Craig for shearing views, most older browsers are having problem in dealing with the inline CSS. HTML5 introduce a great element called nav. It allows us to collect all links in a single frame. Thanks again.

  • My concern is how would older browsers display the tag and probably other semantic elements. HTML5 is a huge step forward for making websites better and more accessible but how would we go forward with all the new fangled stuff if old IE won’t show it right?

  • Although HTML5 is widely received, it is still yet to be completely adopted, correct? I wonder if there will ever be a point where it is. Matt x

  • Ran

    WordPress (for example) outputs list item by default. You can tweak it, but it’s not worth your time especially if you have an uptight client with a pressing deadline…

  • Personally, I’m going to stick to the way I do it now – as in your first code example, I wrap a NAV element around an ordered/unordered list. There are a few good reasons for sticking to this method:

    1. The semantics of a row of links are generally a list. For example, if you use a narrative style of navigation on your site (i.e.: links in the order they are meant to be visited), such as:

    [ Home | About | Sitemap | Search | Contact ]

    … you are effectively saying:

    [ Page 1 | Page 2 | Page 3 | Page 4 ]

    This is undoubtedly a ordered list.

    2. Even though you are right in saying that current browsers are capable of styling inline elements effectively, backwards compatibility is still an issue for me. Approx 10-15% of users in my logs are still using IE6 or 7. So, for the for the foreseeable future* at least, I’m sticking to lists.

    (* As long as MS Internet Explorer is on the face of the earth!)

  • Tony

    I am afraid that this discussion is quite academic to me, as I am still wrestling with the responsiveness of navigation systems. Now, before someone starts pasting in links to CSS-only nav systems, they are still clunky and imposing on mobile viewports–if not completely anachronistic.

    Granted, structuring them in HTML5 might make them a little more responsive– allow us to think outside the box, as it were. However, I believe that navigation systems need to be completely rethought in this age of mobi–new idioms and vernacular are still a decade away IMHO. Their existential purpose still takes up too much of my attention.

  • With something like Modernizr.js to pick up the slack, there could be some potential in this for sure. Otherwise, as many have said above, so long as older versions of IE are still out there it’s a risky move.

Get the latest in Front-end, once a week, for free.