Entity nav list
Following the bootstrap naming convention - this describes navigation that generally appears like a vertical list. Commonly used in secondary navigation.
Here's a pattern that I've been seeing a lot and wondering about: The component name describes the visual semantics (its rendered form - i.e. bar vs. list ) -- since the navigation list is something that repeats a lot. But, it will be handy to have a class that describes it's information hierarchy (i.e. navmain vs. navsecondary) -- such that when translating from a full page layout to a mobile layout -- navigation is something that often needs to change in form but will stay consistent in terms of information hierarchy. The info-hierarchy (Primary and Secondary navigation) will remain stable across responsive -- but many times the form (bar or list style navigation) will shift to a springboard or some other form. So, I can see a need to decouple the two: hierarchy and form.
An important note about the HTML5 entity nav. A point was brought up that we may not be able to always neatly organize our entities by the html5 entities. Buttons was one case brought up -- and here, navigation will be another. When we get into more tertiary types of navigation like "pagination" ... we'll see this issue arise. From a patterns perspective it will be a form of navigation - but it won't be marked up in the same way that major navigation will.
According to the html5 definition for the nav element ( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ):
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.
User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.
Research on the html5 Nav entity brings up a lot of debate on which lists of links qualifies as "nav" and which should just be marked up a lists w/o the nav wrapper. It seems like many people are arguing for the following for nav: primary navigation, secondary navigation, search, in-page navigation (in a long article) The ones that don't seem to make the cut are: fat footer links, blog tags/categories, tertiary navigation, pagination See section on nav: http://html5doctor.com/avoiding-common-html5-mistakes/
I created a first draft of the prototype. It was essentially a duplicate of Eric's work on Nav/Main with a few changes that I hoped we could discuss:
Expand-Collapse Functionality
I added an optional nav.expandable class, which would indicate that the framework should hide sub-menus and only show the parent menu items. If a list element has an .active class, then the sub-menu contained within that list item element should be visible.
Toggle Element
Continuing with the expand-collapse functionality trend, I added a "toggle" button. (This may be unnecessary, read last section below)
Navigation Headers
I added a nav-header class. You would generally use this with a span to indicate a navigation item that is not a link, but a mid-menu header (ala Twitter Bootstrap's navigation headers). So, for example:
<nav class="secondary list">
<ul>
<li><span class="nav-header">Fruit</span></li>
<li><a href="apple.html">Apple</a></li>
<li><a href="orange.html">Orange</a></li>
<li><span class="nav-header">Vegetable</span></li>
<li><a href="carrot.html">Carrot</a></li>
<li><a href="broccoli.html">Broccoli</a></li>
</ul>
</nav>
This is similar to Twitter Bootstrap's style, although it would probably be more semantic as:
<nav class="secondary list">
<ul>
<li>
<span class="nav-header">Fruit</span>
<ul>
<li><a href="apple.html">Apple</a></li>
<li><a href="orange.html">Orange</a></li>
</ul>
</li>
<li>
<span class="nav-header">Vegetable</span>
<ul>
<li><a href="carrot.html">Carrot</a></li>
<li><a href="broccoli.html">Broccoli</a></li>
</ul>
</li>
</ul>
</nav>
We could enforce the second version, or we could simply support both (although enforcing the second version would allow for the developer to flip expand/collapse off and on more easily).
Interaction Between nav.expandable And Navigation Headers/Parent Links
Here's the part where it gets a little confusing and I may be overthinking it: if a list is set to be a expand-collapse list, should a parent list item's link always serve as a toggle control for a child sub-menu? Or should we allow for an option (a separate "toggle" button) where the User can still use the parent item's link as a link and use the separate toggle control to expand-collapse the sub-menu?
For example:
<nav class="secondary list exapndable">
<ul>
<li>
<a href="fruit.html">Fruit</span>
<button class="toggle">Toggle</button>
<ul>
<li><a href="apple.html">Apple</a></li>
<li><a href="orange.html">Orange</a></li>
</ul>
</li>
</ul>
</nav>
In this case, the User can still visit "Fruit.html", or they can expand the sub-menu and visit the sub-links. This kind of seems like a bad idea to me at first glance, but I suppose I could see the potential use cases. If this case is possible, then we would need to provide some mechanism to indicate that a parent link is or is not a toggle control for a submenu.
RE: the toggle option. Perhaps we need to clarify the use of the nav list:
- if/when the nav list is used for the (hidden) submenu of a primary (main) nav {drop-down menu style)
- or if it is used for a secondary nav {i.e. "local navigation" as in what people have commonly called left navigation}
In the first case supporting the full options for the expanding menus could make sense. In the second, it would seem like a potential usability problem.
Mega-menu style drop-down menus are executed both ways (parent name on-click leads to a child page with a separate toggle arrow on-click that reveals a submenu) & (parent name on-click opens submenu only) -- with the latter being more common these days. Google.com's "More" was an example of the first style ... and recently switched to the second style.
For "local navigation" (a.k.a. secondary navigation) -- sub-menus are generally hard to execute in a usable way. The ones that work well tend to be simple:
- Just a disclosure drawer (accordion) that expands to show children on click (aka mobile style.
- Or a flyout-style megamenu that expands on hover or click (amazon.com "Shop by Department").
I don't commonly see the split child-page link with separate toogle on local navigation lists. My feeling is this just may be too complicated for local nav lists, when these tend to have more categories than main nav bars and visually busier already?
RE: 2 options for entity markup Can you explain more about the second set (the one with the extra level of ul) -- at first glance this looks more complicated than your first option. But you mention this would be a more semantic choice?
Another note RE headings for navigation. When we got out site reviewed for Accessibility by DCP, the recommendation we received then was to make sure that our nav headings were marked up as h2 elements; the other acceptable tactic is to use the ARIA roles (which is how the gateway template handles it). See this source: http://www.456bereastreet.com/archive/200911/headings_and_document_structure_conclusions/
Thanks for the awesome feedback!
I committed an updated template with a README that explains all of the new features. As for the list semantics, I would still argue for the second form for two reasons:
Semantics
Consider this image:
The left list is the first form ("flat"), while the right list is the second form ("hierarchical"). I would argue the right list is more semantic as it is clear from the structure of the list that "Apple" and "Orange" are children of "Fruit."
Practicality
Having the extra list element also provides a hook for certain effects (the ul can serve as a wrapper for delineating the area around an accordion/flyout section).
If the developer/designer is adding just a flat list with no effects, as far as I can tell the current template provides them with the ability to create the list either way, so I don't think it will be too much of an issue.