Hello,
finally find some time to start using and testing, and I have a huge problem using in the context of a CMS, or any dynamically generated content.

My menu is genereted dynamically too, with many informations on each entries, mostly via class names (but also data-attributes !). So on any "ul" and "li" there are class saying "this entry will point on an article/a category/an event/etc" or also "this entry is active, because it's part of the breadcrumb of the current page (like one of parent category)", etc.

Real life examples :

<ul class="menu-items" data-depth="1">
    <li class="menu-items__item menu-items__item_article menu-items__item_active">
        <a href="link to an article">

And all my themes will take all those classes and attributes in account to adjust styles, obviously.

But… this lib rewrite absolutely all top entries ! With own HTML and CSS classes, and only that, removing all the original ones (classes but also attributes). Sub-entries (when there is sub-menus, dropdown menus, etc) remain the sames, the rewriting is only for top entries.

The solution seems simple (I hope): the lib must never change the original code but only add its own classes, never removing which exist (any attributes).

There has been a request for 'sticky' items, and I'm trying to gauge if there is enough interest to warrant adding them.

Premise

The idea is that you would be able to 'stick' items to the end (possibly the beginning) of the visible navigation. These would not be part of the priority evaluation, and would remain no matter what.

Sticky items would provide a way of always including, for instance, 'Contact' in the navigation. Not only would it always be visible, but it would occupy its traditional space at the end of the nav.

Very rough demo:

If sticky items are added, it essentially allows for a 'squishy' middle part of the navigation:

Opposition

The biggest argument against the feature, other than increased complexity, is that if an item is 'high' priority, should it not just be promoted to higher up the list? The use-cases tend to be quite narrow, e.g. sticking 'Contact' to the far right. If the usefulness is so limited it might not be worth the extra size/complexity or dev time.

Adding the menu now to a project and noticed the readme has:

// Doesn't have to be SASS, just ensure the CSS is included.
@import "../node_modules/priority-nav/css/priority-plus";

Rather than node_modules/priority-plus/css/priority-plus;

Didn't see that in options list, so I make an enhancement request.

The default behavior for the More button is just to open/unfold an other menu containing hidden items. No change for that.

But some times, we want more complicated behavior, for example if we want to open a totally other menu than just the 2 or 3 hidden items, like a full sliding menu, or a fullscreen menu.

The simple way to allow that would be an option to pass a function which will overload the default handler. Like "buttonHandler" for ex, or "onToggleClick" to follow your current code.

The current "onToggleClick" could be rename as "onToggleClickDefault" and an option "onToggleClick" will wait a function, and trigger that if defined, else the default one.

Very simple, but one more customization possible! :)

To improve accessibility, the Plus/Menu button should use this aria attribute.

How to use: https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

Hey Jay 👋

Yesterday I was playing around with this lib (amazing job btw!) and I noticed that Vite was complaining about the .css import that you state in the README file. Affter looking at the package.json exports field I saw that there's no CSS dedicated export.
Maybe in the past it used to work before defining the exports field but once this is present it means anything not explicitly listed inside is not exposed I guess.

Vite's complaining error:

Thanks so much! Let me know if you need any extra info 🙂

First, thanks for this lib, it's super useful and amazing that it takes into account accessibility concerns.

Second, I'm working with a navigation layout that changes its orientation from horizontal (mobile) to vertical (desktop) based on viewport width.

Quick devtools prototyping on your demo page makes it seem like I can achieve this with some Flexbox customization, thanks to your use of IntersectionObserver.

I'm curious if you have any thoughts on this approach and figured I'd raise it as a possible feature request since it seems like a cool option to have.