NavigationMenu - add ability to disable hover behaviour

[AlexJMohr]

I'd like the ability to disable opening submenus on hover, i.e. require the user to click the trigger.

I could use MenuBar, but I think it wouldn't be semantically correct (it's not a <nav>)

[huntabyte]

Will look into this!

[huntabyte]

So if we were to expose a prop called openOnHover which would default to true, what is the expectation for how the menu behaves when the pointer leaves?

In my mind, if I open via hover, when the pointer goes outside of the trigger and not towards the content, it would close (the current behavior today). However, if I open via "click" (with hover disabled), I would expect it to stay open until I explicitly close via escape, outside click, etc.

[huntabyte]

Investigating the submenu viewport as we speak

[AlexJMohr]

EDIT: side note: openOnHover feels like it belongs on the Content to me, not Trigger, since that's where other "similar" props are, like interactOutsideBehavior and escapeKeydownBehavior. Maybe it could be called openOnTriggerHover or hoverBehavior?

Unfortunately, this wouldn't work in a scenario like this which is common for svelte transitions:

<NavigationMenu.Item>
	<NavigationMenu.Trigger />
	{#if someCondition}
		<NavigationMenu.Content openOnHover>
		</NavigationMenu.Content>
	{/if}
</NavigationMenu.Item>

Since the NavigationMenu.Content wouldn't be mounted (we don't know that prop) until the trigger is already being hovered.

For svelte transitions, doesn't the if go inside the Content's child snippet?

<NavigationMenu.Content>
    {#snippet child({props})}
        {#if someCondition}
            <div {...props} transition:slide></div>
        {/if}
    {/snippet}
</NavigationMenu.Content>

[huntabyte]

For svelte transitions, doesn't the if go inside the Content's child snippet?

Yes that is correct, but regardless, the content doesn't determine how the menu opens, only how it closes when it is already open if that makes sense.

We place it on the <NavigationMenu.Item> as it provides context to everything within the item (trigger and content), so we can control how the trigger responds to pointer events, and how the content closes (pointer leave vs explicit).

I hate going from bottom up unless I absolutely have to because it's difficult to predict what users will attempt to do, especially around conditionals, conditionally swapping content components out given certain conditions, etc.

[huntabyte]

CleanShot.2025-02-21.at.12.29.09.mp4

Is this about what you're looking to do @AlexJMohr ?

[AlexJMohr]

@huntabyte Yes that looks right. How will it work with keyboard navigation with the submenus? is focused locked inside expanded submenus? Do arrow keys work, or just tab? (not sure how it's supposed to work, just curious)

[brandonp-ais]

Similar question in the other direction:

Is it possible to add optional hover trigger to DropdownMenu?

Currently, it only triggers by a click-like action.

[huntabyte]

It's on the list of things I want to add 😁 will require some lifts internally to make it happen though as hover open behavior changes the expected way the menu should close.