The application’s primary navigation is a fixed-position column at the left of every screen for the main app pages and sections. Along with the header navigation, the left navigation should provide a consistent look and feel cross-product.
Navigation basics
Basic left navigation requires a parent nav element with the class .hc-app-nav and at least one section containing content.
The primary menus should sit inside of a wrapping section with class .hc-app-nav-primary. The expand/collapse toggle is recommended and should be contained in a section with class .hc-app-nav-toggle. These will automatically position themselves as justified-between.
The above boilerplate markup shows a basic representation of an application menu with active state and indicator count.
Each menu group should be wrapped in a menu element with class .hc-app-nav-menu. These menus take menu items using any element with class .hc-app-nav-menu-item. Menu items require an Icon, an .hc-label with the manu item’s label, and optionally an .hc-indicator-count if you’d like to include an indicator.
Applying the class .hc-active to .hc-app-nav-menu-item will automatically handle the active state changes.
Accessibility note
Make sure the navigation panels use <nav> as an element, and you can add role="navigation" to further specifiy the correct role (even though this is a bit redundant).
The bottom collapse/expand toggle must have tabindex="0" set on the label itself. This ensures that this clickable element is focusable. It should also have a label like aria-label="Toggle navigation width" for screen readers.
Expand/collapse handling
The Navigation component has a default 16rem width for desktop screens. Users should be able to collapse the Navigation with a familiar icon button fixed to the bottom of the component, reducing it to 4rem with the menu items in icon-only mode.
The CSS-only logic is handled by Honeycomb and just requires some specific markup before the </nav> end tag:
Important: please note that the markup above appends -2 to the input ID. This is only necessary for the examples on this page and should be removed in production; you can see the official markup in the first example at the top.
The button itself is actually a <label> that controls a hidden <checkbox> element. When the checkbox has a :checked state, the parent <nav> element sees this and adjusts its width and some other child element properties. The CSS for this looks like:
Because it looks at a checkbox’s :checked state, the Navigation component will stay collapsed or expanded regardless of other user interactions.
Class-based handling
Alternatively, you can apply the class .hc-app-nav--collapsed to the <nav> element to force the collapsed state. This is useful if you’d like to handle collapsing based on other conditions, to save the state with a cookie, or otherwise programmatically via JavaScript.
Note that you must manually remove this class when you want the Navigation component expanded again. The checkbox will not work with this manual class added.
Considerations
This checkbox-based approach will allow the collapsed state to “stick” during page refreshes. It will not, however, stick when the user navigates to another page. In this case, you could save the collapsed state to a cookie and add or remove the checked attribute to the checkbox by default depending on state.
Tooltips
You can add Tooltips on menu item hover when the Navigation component is collapsed with the same class hierarchy as a regular Tooltip.
Add the wrapper class, .hc-tooltip-group, to the .hc-app-nav-menu-item link itself and place the .hc-tooltip as a <span> as the last element within the link. Read more about this alternative HTML on the Tooltip component page.
Showing Tooltips all the time
The default behavior is to hide the Tooltip when the Navigation is in full/expanded mode, and to only show them when it’s collapsed.
To override this, add the class .hc-app-nav-menu--tooltips-always to the <menu> element.
Menu groups
In larger or more complex Navigation implementations it may make sense to group menu items together into logical sections.
Use separate <details> elements for groups along with the .hc-app-nav-menu-group class, and create toggleable titles at the top using a <summary> element that has both the .hc-app-nav-menu-group-toggle and .hc-app-nav-menu-item classes.
The markup is slightly different from the basic Navigation example. Each group must use a separate <details element with the <summary> at the top and the regular <menu> element and its items below that.
You must include the open attribute on the <details> element to expand the group by default. Removing this attribute will collapse the group, as will clicking the toggle.
Bottom actions
Sometimes it may be necessary to include actions or buttons at the bottom of the Navigation component, right above the collapse toggle. Simply add another <section> right before the toggle with class .hc-app-nav-footer.
Search and top actions
If the application requires actions at the top before the primary menu, like a search box or some other control, add another <section> before the primary menu section with a class of hc-app-nav-header.
Advanced menu items
Menu items can contain secondary information or actions, like an indicator count or a dropdown menu for more options. These should be wrapped in the last element within the hc-app-nav-menu-item.
Reference the Indicator and Dropdown components for the HTML. Basic examples are below.