The Final Off-Canvas Navigation?
Eight years ago I wrote a (then) modern guide to implementing off-canvas navigation for Smashing Magazine. My original demo is still online (links in the article are broken). It’s rather quaint by today’s standards.
nav element in IE. Between then and now I must have written over a hundred variations of this pattern improving it over time. I’ve often advised against it as it can encourage lazy information architecture.
The New Version
Check out my new demo on CodePen.
I think I’ve finally nailed it… well I am at least happy with the latest iteration but I’ll continue to tweak it. I’ve listed the key features on the demo page and expanded upon them below. It’s all built with accessibility and performance as a priority.
<nav> element at the end of the document. Sub-menus are accessible with the aid of
CSS Scroll Snap is the magic behind the sub-menus. The sub-menu
<ul> elements sit side-by-side with the parent overflow hiding all but the active menu. Each sub-menu link references their target to activate them, e.g.
Because the sub-menus use native browser scrolling, transitions back and forth are added with a single CSS declaration:
scroll-behavior: smooth. The
prefers-reduced-motion media query is used first to respect user preference.
I’ve taken care to use appropriate elements and ARIA attributes. To the best of my research and testing I’ve implemented this correctly. Feedback is very welcome @dbushell.
Focus State and Keyboard Navigation
I’m all about focus state and
focus-visible means no more weak “ugly design” excuses. Generally speaking, using a pointer — mouse, finger, etc — leaves no focus outline; keyboard navigation does. Ultimately it’s for the browser to decide. The “Escape” key can be used to close the menu. To trap and restore focus I’ve borrowed a technique from Kitty Giraudel’s fantastic A11y Dialog.
RTL styling is supported out of the box. CSS logical properties and values make this fairly trivial to provide. The document attribute
You could, of course, partially invert the design regardless of language direction. I feel like most LTR designs I see nowadays use a right-hand-side menu but it’s not a hard rule.
The demo features a bonus “sticky header” technique. That’s a common complimentary pattern and easy to do efficiently with an Intersection Observer.
No “plugin” I’m afraid. An MIT licensed CodePen demo is all I’m maintaining! The nuances are too varied to provide a configurable plugin. Doing so would bloat the code with more settings than actual functionality and make it less adaptable. I might work on a few design variations to show how flexible it can be.
Like I said I’m still working on this and constructive feedback is welcome @dbushell!