We’ve written a bit about the Priority+ pattern here before. Here’s a bunch of real world examples. I needed to use it recently. I found Gijs Rogé’s priority-navigation. It’s pretty nice: no dependencies, clean code, fairly configurable and designable. It’s not particularly small though, and there is a good amount of it defining helper functions. I was in an environment that had all that stuff available and so I figured I’d take a crack at a version.
Technique: Test if Elements Have Wrapped
See the Pen Priority Nav via Wrapping/jQuery by Chris Coyier (@chriscoyier) on CodePen.
This version has jQuery (for DOM easiness) and Lodash (for debouncing) as dependencies. Those are far from insignificant, and you wouldn’t probably add them just for navigation, but my project had them available.
I also took a slightly different approach than I’ve seen in other takes. Rather than measure the available width and the width of each menu item to see if they will fit or not, I just let the menu items wrap. When the window is resized, I check the position of the elements and if I can tell by their position that they have wrapped, they go into the overflow. So you never really see any wrapping. (If your menu items can wrap, you probably don’t need Priority+.)
Of course there is work to be done. With the information about which items should be in the overflow, I needed to clone them over there. And be ready to do it all over again when the window resizes, but not too quickly (hence the debouncing).
Technique: Measure Widths
The technique I see more commonly is to measure widths and make choices based on those widths. Johan van Tongeren has a version of that:
See the Pen Responsive horizontal menu by Johan van Tongeren (@Dreamdealer) on CodePen.
The code is quite short. Measure the available space and space needed by the elements. If there isn’t enough space, pluck one off into the overflow and try again. It seems like a lot of calculation, especially the recursion and that it’s not debounced, but hey it seems to run pretty ok.
Luke Jacksonn has written a version in a simliar fashion:
See the Pen Greedy Navigation by lukejacksonn (@lukejacksonn) on CodePen.
Technique: Choose Overflow Items Ahead of Time
Michael Scharnagl has a demo that needs no JavaScript at all.
It uses the :target selector to hide/show a set of links. He uses alpha/beta/gamma classes on the links in conjunction with media queries to show more/less of them at different screen widths.
The Point
Uhm. I guess it’s that you can always snag someone else’s code to get something done. Very often that’s a good idea. But sometimes it’s fun to dig in a little and try to write it yourself and explore other possibilities. I’m not sure my version is any better (it’s not), but I learned about the problem and different possible approaches.
I like your approach Chris.
I’ve used a similar technique for an auto collapsing menu – less calculation / DOM querying for faster perf.
If we’re being super picky about performance we could always measure the height of a wrapping element to the containers – then we’re only querying a single element.
In many circumstances I think the priority navigation could work better than a traditional collapsable nav, as it’s been documented in various articles about burger icons are ignored / misunderstood.
One last point – you can do custom builds of Lodash to keep the filesize down https://lodash.com/custom-builds
This type of navigation came naturally to a client of mine, (or they observed it on another site) but not in an automated manner. He just has the last navigation link be a menu item that says “more”. (using the current tools available in the CMS)
The problem is that I have found the best style structure for navigation is flexbox, which scales and resizes beautifully on so many screens.
But automating this seems to require fixed width navigation, something I am not willing to trade flexbox for.
But perhaps one clever idea to take from this is adding the count to the “more” menu, even if it’s statically created.
Lastly, when any navigation goes to mobile, you have room for maybe one or two links at most with an automated system, and the rest are under a “more” link, which I can’t see as ever being ideal. So this is only useful for computer screens in a small window, or perhaps a tablet?
It seems many of these clever schemes are maybe ok for apps, but not websites? But then, you have functionality hidden and the problems that arise from this. But again, there’s always the unique situation…
I’ve got another take that puts the Prioritization in Priority Plus. Giving a little more control but without having to define manually define breakpoints to do it. Built with CMS integration in mind.
https://matthornsby.github.io/priority-navigation/