Navigation Block: Allow configuring behaviour of dropdowns.

[mtias]

It'd be nice to be able to toggle the behaviour of dropdown menus to open on click / tap vs focus / hover. This could be a setting in the inspector controls.

[retrofox]

Setting focus/hover as default.

[WunderBart]

Would it make sense to disable click (or convert to span) on submenu parent items when the click / tap option is on?

[mrwweb]

I'd offer up the USDWS basic header component as an excellent example of markup and behavior for a click-driven menu.

Notably, the submenu's parent menu item is a button, not a link. (Though when I implement this myself, I prefer to convert a functional link to a button with JS so the menu is functional with JS disabled.)

I would love to see this behavior become default for submenus!

[paaljoachim]

I am thinking that @aristath Ari might want to know about this issue.

[jasmussen]

Thanks for the example Mark! I'd definitely love to see click in addition to hover as the way to open submenus, perhaps even by default yes, and the USDWS example is a good one.

As you know, the big challenge here is how to handle the top level menu item, the "opener", so to speak. Should it be a separate block with a label that doesn't link anywhere and only opens a submenu? Should it be a split button with the pros and cons you list? Should toggling click instead of hover make the primary link become a linked subheading instead? I've been pondering a few options for how to make the classic WordPress menu building user experience also able to handle click-only menus, but would be happy to hear your thoughts.

[mrwweb]

@jasmussen Glad you found that article I wrote!

In classic WordPress I've flipped back and forth between using redundant links (duplicate of first submenu link) or href="#" for the parent item. When using a script that progressively enhances a link-only menu to use <button>s for the parent element, it still probably makes sense to use a real link for the parent element in the no-js version of the menu. That feels like the best possible suboptimal experience for when JS fails or is turned off.

Alternately, the subheading idea is really interesting. I'd love a non-hacky way to do that! It makes me wonder if there should be at least two non-link blocks available in a navigation menu, a toggle button and heading. (I now see this is much of #23745, so I'm heading down the same road.) If doing it that way, there's be no need for a click-vs-hover setting. Instead the decision about whether to use a link or toggle button for the parent would determine the behavior of the submenu. While not a good idea, I suppose this would let people combine the behaviors if they really wanted. The downside of this method is that if JS fails for any reason, the semantics of the menu are significantly worse.

[jasmussen]

The downside of this method is that if JS fails for any reason, the semantics of the menu are significantly worse.

I think that's an important point to consider.

So it seems there's this pros and cons. If we have a nav-level toggle for click or hover:

• You can't mix and match (almost certainly a good thing).
• We could potentially create a segmented control allowing you to choose between outputting a linked subheading, or showing a split button. TwentyTwentyOne does the latter (with mixed results in my opinion as it mixes hover and click).

The toggle would likely need to output the JS necessary for handling the split and/subheading options. The downside, almost certainly, would mean you can't edit the subheading label as it would be generated on the fly. But it'd be a neat user experience with just the toggle. I wonder if we could leverage one of the menu item link title for the subheading:

The other approach, a separate block, also as you outline, has downsides with regards to mix and match, having to handle yet another type of block to insert or convert to, but perhaps most importantly — since this would be a generic button it wouldn't know what to link to when the JS fails. That feels the most blocking to me, if you pardon the pun. The upside would be the markup, and the fact that we wouldn't need to worry about subheadings. It would be an entirely curated experience.

All that seems to suggest that the inspector toggle at this point in time looks like the best approach forward. But the feature would likely need to land in a "phase 2" of the block regardless, so there's time for further thought.

Thanks for sharing your thoughts!

[jasmussen]

Some draft mockups for choosing the behavior are being bounced around in #33775 (comment).

[jasmussen]

I took a look at dropdown menus across a slew of websites to see what the most common behaviors for opening on click or hover are. Overwhelmingly the behavior falls in two categories:

1. Hover: submenus open up on hover and the parent item links to a destination. For example, hover "Kids" and click "Sneakers" to go to /kids/sneakers, or just click "Kids" to go to /kids.
2. Click: submenus open on click (and often hover as well), but the parent item itself doesn't link anywhere. In these cases, the parent item would often not match a URL on the server, but serve more as a category, such as a "Services" link with no matching /services URL, but instead submenu items like "Printing Services" matching /printing-services.
   In other cases, the parent item would match a destination on the server, but to go there you'd have to select a submenu item. For example a menu item labelled "Blog", with an "All topics" link to /blog as part of the submenu.

From browsing a few of these sites, often with mega-menus associated with them, one quickly gets the feeling that the megamenu exists to save the effort of first clicking the "Products" page, waiting for it to load, and then reorienting yourself again: by just showing destinations in the megamenus, you can skip right on to Products → Shoes without the interim step.

I wasn't able to find any sites that had "split menu" behavior, where clicking the parent item took you to a destination, but a separate chevron opened a submenu on click.

Sites with menus that open on click

Sites with menus that open on hover, and where the parent item also links somewhere itself

[jasmussen]

Based on the research above, I took a look at a few designs that leverage an unambiguous click-only interface. The two primary benefits to this approach:

• Works the same across every platform
• There's no split button pattern to learn

The curated menu

In this example, the "Kids" menu item opens the submenu on click. If you want to go to /kids, you can click the "Go to Kids" item at the top of the menu:

The item could be an item you have to insert yourself, or it could be added by the submenu item automatically, and in both cases they'd be editable, and could have different default treatments, prefixes or suffices:

The modal menu

In this example, just like how the hamburger menu opens a modal dialog, a click on a menu item opens the submenu as a dialog. This has the benefit of trapping/looping tabs until you press Escape to close:

Similar to the curated version, the dialog could link to the parent menu item as a "permalink", and themes would be able to customize the appearance of the modal.

The click twice to go to parent menu

In this one, clicking the menu item opens the submenu, clicking again goes to the parent item destination. It's unclear whether this would be intuitive or semantically sound without a tweaked design, but felt worth including as an exploration:

If it behaved like a modal and with a visual treatment and animation to match, it might possibly work:

The WordPress challenge

Ultimately the curation aspect of the mockups shown boils down how WordPress has handled subpages for the longest time. This structure:

Instead of letting that structure fundamentally dictate how submenus should behave, blocks give us an opportunity to revisit this by embracing the ability for you to curate your menus entirely:

• You can have a flat structure (/new-arrivals, /back-to-school, /bestsellers) and still group those items together in a "Kids" submenu.
• You can keep your nested structure (/kids/new-arrivals, /kids/back-to-school, /kids/bestsellers) and group them together in a "Kids" submenu, and then choose whether or not to link to the /kids page at all.
• Through properties on menu item blocks, we can let you configure the behavior of the parent item link: whether or not to duplicate it or not, let you tweak any prefix or suffix, or even let you edit the duplicate link title itself.

A valid expectation users might have is that when using the Page Attributes panel, they affect the structure of menus as well:

This structure is valid even for users who might be leveraging the Page List block to keep menu item creation in sync with the navigation. As a solution to this fundamental structure, the duplicated menu item isn't the most elegant solution in the world. But combined with the right curation tools and good defaults, it might allow us to provide unambiguous click menus that can be tailored to fit expectations.

[tellthemachines]

I wasn't able to find any sites that had "split menu" behavior, where clicking the parent item took you to a destination, but a separate chevron opened a submenu on click.

It's a very common pattern on news websites, and to a lesser extent blogs, though most often it's shaped as an accordion-like structure. A few examples:

Inside a mega-menu:

This one opens on click and hover:

Some websites use it only on mobile:

These two open on hover and use arrow keys for keyboard navigation, which is... not super discoverable 😅

Based on the research above, I took a look at a few designs that leverage an unambiguous click-only interface.

Thanks for these explorations @jasmussen !

For the purposes of this discussion, I don't think it makes a huge difference whether the submenu opens in a dropdown or modal.

Clicking twice to go to the link destination would be extremely confusing for screen reader users, and keyboard and mouse users might not find it at all.

If I'm reading your examples correctly, that leaves us with repeating the parent item inside the submenu as the only alternative to the split button solution. Technically, it's doable: we can just remove the link from the parent item and duplicate it as the first submenu item. We can also make both of them editable, the parent as a simple text field and the link as a regular Navigation Link.

What happens if we provide hover as an option though? Do we still use the duplicated parent? The best solution for accessibility is having click behaviour for keyboard and screen reader, so how to we make that work with hover?

The advantage of split button in this scenario is that it works well as hover and click: for mouse users, it's a regular hover menu. For keyboard and screen reader users, it's pretty easy to understand what the toggle button does, and on mobile, it can take an accordion shape, which is also a well-known pattern.

(As a side note, we need to find a more scalable solution for responsive submenus than the current showing-everything-at-once, and that's essentially the same problem as this 😄 )

So, where can we go from here? #33775 proposes a split button solution with hover and click. I'm thinking we could merge that for starters, and then try out your parent duplication strategy as an alternative, click-only solution. We could have both of them coexist as options on the Navigation block, which is pretty much the initial proposal of this issue.

What do you think?

[jasmussen]

We could have both of them coexist as options on the Navigation block, which is pretty much the initial proposal of this issue.

I do think providing multiple options can be a good path forward, and it offers us to surface the best option as a default 👍

[talldan]

In this example, the "Kids" menu item opens the submenu on click. If you want to go to /kids, you can click the "Go to Kids" item at the top of the menu:
The item could be an item you have to insert yourself, or it could be added by the submenu item automatically, and in both cases they'd be editable, and could have different default treatments, prefixes or suffices:

I like this idea, but as an automatically added item it might limit the user's options for positioning the link in the submenu. It seems like it'd be easy enough to provide the user with the capability to create a hover menu without a link as the parent item, then the user can place this link in the submenu and name it as they desire.

[jasmussen]

I like this idea, but as an automatically added item it might limit the user's options for positioning the link in the submenu. It seems like it'd be easy enough to provide the user with the capability to create a hover menu without a link as the parent item, then the user can place this link in the submenu and name it as they desire.

Good thoughts. It inspires some options here, not sure they are good, but just talking through the flows might uncover better ideas.

• Add a Submenu block for use in Navigation #33775 creates a split button solution where the item itself links, and the dropdown chevron opens a submenu on click.
• That same branch in fact adds a new "Submenu" block, which works to open on click when the main item has no link. That in essence accomplishes the "curated click" solution outlined here, even if it appears to be unintended as it's lacking some styling.

Defining whether you get a split button or a click-only based purely on whether the parent item links doesn't seem intuitive, and if we did this you'd be able to create "mix and match" menus that included both behaviors, which likely isn't ideal. It also wouldn't easily work with the Page List block which simply outputs what's there.

I do agree that a completely curated and custom menu item as inserted if you'd like the behavior above can likely accomplish the best result. But I wish we had a path forward that let us define the click-only or split-menu behavior as a nav-block-global option with a single click. Something along these lines:

If parent items link when you toggle that option, those links would essentially be made void.

[mtias]

I think we should just have "Hover / Click" options, and then "show submenu indicators" would be the one that determines the split.

When not showing submenu indicators:

• Hover: should work just like wp-admin menus, where the dropdown can be tabbed into and enter would navigate to the top-level page. This seems one of the most common patterns on the web and it'd be a bit bizarre if we don't offer it.
• Click to open: this combination would make the top level inert. This would be a user choice and the simplest way to accomplish top-level items that are not themselves pages without overcomplicating things with extra blocks or a url-less link item.

When showing submenu indicators:

• Hover: on the link would do nothing; on the submenu indicator, it'd open the dropdown. We can consider also opening the dropdown when hovering the main link item, this is more of a UX detail. I don't have a strong opinion on it but lean on the first.
• Click to open: just a regular split button pattern here.

We could use help text on the "show submenu indicator" that explains some of the details when appropriate.

[mrwweb]

When showing submenu indicators: Click to open: just a regular split button pattern here.

I've never built a click-to-open menu that didn't have submenu indicators. They're a useful usability affordance for both hover and click menus. So that is to say that I don't think selecting a visual design option should change the behavior of the submenu. (I'm still not sold on including split buttons.)

If parent items link when you toggle that option, those links would essentially be made void.

I think that's probably the easiest path forward and users would likely figure it out. (If you have to click to open the submenu, then it can't be a link.) FWIW, I've built click-menus in WP using links as the parent item and converting them to buttons with JS and and it has a big upside: If you're progressively enhancing the menu so it can without JS, then defining what the parent item should link to when there's no JS is actually valuable for defining the fallback behavior.

you'd be able to create "mix and match" menus that included both behaviors, which likely isn't ideal

Definitely agree that mix-and-match is probably the worst possible outcome.

---

Thinking about theming, I wonder if the menu behavior should require theme support (or provide the ability to opt-out) so that it's easy for themes to define their own behavior instead of whatever comes in core. Again thinking back to the split-level buttons, I could see not including this in core but making sure it's easy to write your own script to define that if desired. One thing this ticket has surfaced is that there are a lot of ways to build menus and it's almost certainly impossible for core to support all or even most of them.

[tellthemachines]

That same branch in fact adds a new "Submenu" block, which works to open on click when the main item has no link. That in essence accomplishes the "curated click" solution outlined here, even if it appears to be unintended as it's lacking some styling.

That was actually the whole purpose of that PR; it started out as an alternative to #33351, in order to fix #18866 😅 What styling should be in place to make this clearer?

It also wouldn't easily work with the Page List block which simply outputs what's there.

Page List raises an interesting question, because it always outputs submenus with parents that are links. That means in my Submenus PR, they are always rendered as split buttons. What would happen to them in a hypothetical click-only menu?

But I wish we had a path forward that let us define the click-only or split-menu behavior as a nav-block-global option with a single click.

This (or a variation of this based on showing/hiding submenu indicators, or something else) won't be hard to implement on top of the Submenu block; but we have to answer the question above: what happens to parents defined as links when we're in click-only mode? For the Page List at least, because it's not editable, it feels wrong to just remove the link altogether without adding it somewhere else.

I think we should just have "Hover / Click" options, and then "show submenu indicators" would be the one that determines the split.

We can sort of work with this, but there is another variable to consider: whether the top level item is a link or a button. Users do want to have non-link top level items, and in classic menus they can do so (hackishly) by removing the url from the link.

Taking that into account, I think we have two main problems:

• Enforcing consistency in top-level items: either they are all links, or all buttons, but not a mix of both. Ideally, users should be able to explicitly choose between one or the other. The question is: is the choice between Hover (top-level links) and Click (top-level static items) explicit enough? I'm thinking it could work, but we might need to add a notice somewhere.

• Encouraging click instead of focus as the keyboard mechanism for opening submenus, when they are hoverable. This requires a split-button solution, which in turn requires submenu items to be present.

So, could we instead have:

• Open on hover with no submenu icons: same as we have now, with focus as the keyboard mechanism, and we can show a warning that this is not ideal for a11y. Top-level items are always links.

• Open on hover with submenu icons: very similar to what we have now, except we implement a sneaky split-button for keyboard interaction. Top-level items are always links.

• Open on click, with or without submenu icons: click is required to open submenus for both mouse and keyboard users. Top-level items cannot be links.

We'll still need to sort out what to do with Page List submenus in the context of the last option though 😅

This was a lot of thinking out loud, but hopefully it helps. What does everyone think?

[mtias]

I'm thinking it could work, but we might need to add a notice somewhere.

Yes, regardless of the combinations we end up supporting, contextual text would be needed to explain some of the details.

For the Page List at least, because it's not editable, it feels wrong to just remove the link altogether without adding it somewhere else.

I don't think this is wrong; it's not uncommon to create menus where the page that supports the children is mostly used as a breadcrumb and there's not much value (if any) in accessing it directly. For those cases, not having access to the parent page link on touch interfaces (for example) is actually one of the recommendations in "Don’t Use Split Buttons for Navigation Menus". Users, patterns, and themes would still be able to include the extra link within a mega-menu if desired.

We could in the future consider a setting for this in dropdowns, but we can take it one step at a time.

So, could we instead have [...]

This looks like a good target.

Not sure about the warning on accessibility for the hover/focus, though. It seems to me that if a menu is simple, with a single dropdown with 2 or 3 items, that the linear tabbing flow can be the best and least convoluted flow compared to the alternatives. So we'd need to be careful with including warnings that could be misleading in some situations.

[mtias]

Thinking about theming, I wonder if the menu behavior should require theme support (or provide the ability to opt-out) so that it's easy for themes to define their own behavior instead of whatever comes in core.

A theme would be able to specify through theme.json defaults and maybe settings it might want to remove. The latter is a bit more tricky because while useful for agencies, etc, we also want to avoid things working drastically different for users. Often being limited to the choices a theme made regarding how navigation works can be a deterrent from picking a theme even if everything else is spot on.

[jasmussen]

Per the conversation above, I've taken a stab at some refreshed mockups. Parsing through the suggested matrix left me with a structure where the segmented click/hover control combined with the "show submenu indicators" toggle offered 3 different interaction models.

Option 1: Hover & don't show submenu indicators:

• Hover or tab to focus menu items to dive through top and sublevels, like in WP-admin.
• Press Enter, or click to go to either item.
• Menus close when you tab out of, or move the cursor out of them.

 

Option 2: Hover & show indicators:

• Same as option 1, but keyboard users can open the submenu by focusing the separate submenu indicator.
• Hovering the main link may or may not show the submenu, to be decided.

 

Option 3: Click:

• Click, or focus and press enter, on the main menu item to open the submenu.
• You cannot navigate via click or enter to the main menu item, if need be you have to duplicate the menu item inside.
• Hover may or may not do anything here.
• Toggling the visibility of indicators is not possible.

 

Does that sound about right?

[tellthemachines]

Thanks @jasmussen , those look great! One question, though: shouldn't the submenu icon toggle also be available when Click is selected? It would just be a visual change, but some folks might prefer having the icon there.

I've implemented the click/hover toggle in #33775, and it's working as described above, but for now it's just a toggle like the others:

I'm happy to change it to a button set as per those mockups, but I'm thinking it might be best to do that as a separate PR together with the responsive menu toggle. Are those buttons based on an existing UI component, or will we have to create a new one?

[jasmussen]

One question, though: shouldn't the submenu icon toggle also be available when Click is selected? It would just be a visual change, but some folks might prefer having the icon there.

In the mockups, the intent I wanted to convey was that you can't toggle off the icon when it's set to click.

Are those buttons based on an existing UI component, or will we have to create a new one?

There's a new segmented control that's used for the Post Featured Image block that's used in the mockups. Since there are a lot of small tweaks for the navigation inspector, there's a separate issue for it in #30370.

[mtias]

@tellthemachines there's a component, it's called ToggleGroupControl now.

[tellthemachines]

With #33775 merged, is there anything still to do in this issue? The inspector toggles still need to be changed to ToggleGroupControl but that can be done as part of #30370.