Size Change: +3.66 kB (0%)

Total Size: 1.05 MB

_{compressed-size-action}

It's nice having the dropdown block in the inserter. For me it feels like it would be a clearer way to create a submenu compared to the current flow (particularly if the navigation block's quick inserter could be cleaned up to prioritise particular blocks). This makes it clear from the start what kind of an item I'm going to create, whereas adding a link and then converting to a submenu always felt like it took a bit of discovery and wasn't quite so direct.

I'd imagine navigation links could still retain the toolbar button for creating a submenu, but it'd result in a transform from the navigation link to a dropdown.

Not the most important part of this PR right now, but the name of this block is an interesting one. Dropdown implies a very specific style type of submenu. In the future, the navigation block might support other types of submenu (like an accordion), and I'm not sure whether that'd be the same block with a different style, or variation, or a different block entirely.

Coming back to this after a bit of AFK, thanks so much for the PR. Here's what I see:

Some of the rough edges aside (it's a draft PR), there are some interesting revelations in trying this, and forgive me for mostly echoing Dan above:

• While there would need to be a way to "convert" an existing menu item into a dropdown menu, the ability to explicitly insert a dropdown item like this seems like it has potential. It might even be great for patterns that are meant to suggest dropdown menu navigation.
• One potentially important benefit of this approach is that you can create truly click-only dropdown menus, which would be a big benefit for some particular designs, well explained in this post.
• The approach does challenge the menu item setup state as it exists, and the state would need to be tweaked in order to accommodate this item type. #30170 might benefit here, as might #33091.
• On a more general level, as we add more menu item types, #33048 is becoming increasingly important so themes won't have to refactor their CSS to target new CSS classes whenever a menu item type is added.
• It's possibly muscle memory and not necessarily the most ideal solution, but I find myself missing the "Add submenu item" button in the block toolbar, for creating dropdowns. It might be interesting to not only keep that button, but make it available even when the main navigation block is selected, and if clicked there, it just inserts the dropdown menu item.

As far as next steps, what are the smallest tweaks we need to make in order to find out if this is the best path forward?

Thanks for the feedback, folks!

I'd imagine navigation links could still retain the toolbar button for creating a submenu, but it'd result in a transform from the navigation link to a dropdown.

Oooh nice! That would be in addition to the transform option in the block name dropdown, right?

Dropdown implies a very specific style type of submenu. In the future, the navigation block might support other types of submenu (like an accordion), and I'm not sure whether that'd be the same block with a different style, or variation, or a different block entirely

Good question, I think that depends on whether we can use the same markup for both patterns, in which case it would make sense to have the same block with two styling options or variations, and call it Submenu. Or perhaps the block should be context-aware, as an accordion only makes sense within a certain layout. You'd expect it to be a slideout menu, or at least vertically oriented. It wouldn't make sense to have an accordion sitting next to a dropdown in a horizontal nav.

I think I went with Dropdown because at first I was considering if we'd want to use it outside the Nav block, but there's so much nav-specific behaviour in here that it's probably best to forget that 😅

The approach does challenge the menu item setup state as it exists, and the state would need to be tweaked in order to accommodate this item type

@jasmussen could you elaborate a bit more on this? I'm thinking the Navigation Link block could be just a menu item with no additional functionality apart from perhaps the ability to be transformed into a Dropdown.

#33048 is becoming increasingly important so themes won't have to refactor their CSS

Absolutely, and I'm now wondering if we should tackle that before moving on with this work. I'm happy to do a PR but we'll probably want to agree on the appropriate classnames beforehand 😄

As far as next steps, what are the smallest tweaks we need to make in order to find out if this is the best path forward?

I'm working on the open on click functionality, as that was a general requirement for submenus from the a11y feedback on the Navigation Heading PR. Then there's a bunch of styling issues that need to be fixed, but perhaps we should get #33048 done beforehand, as it will avoid some code duplication in this PR.

Really, the choice is between this PR and #33351 in terms of how we allow users to create submenus. I'm inclining towards this PR from a code perspective, and I like how obvious it is to have Dropdown as an option in the block inserter, but welcome more opinions on both fronts!

Oooh nice! That would be in addition to the transform option in the block name dropdown, right?

I'm missing a beat. In my testing this branch and trunk, I don't see any transform options for any menu items at the moment.

As I wrote the initial suggestion, I was thinking of the need for us to still support the existing use case of all the existing dropdown menus that only open on hover, and where the main opening item also links to its own page. But I'm now reminded of a conversation on the initial issue, #18395 (comment) about potentially avoiding this "mix and match". My comment there assumes that a JS-based click-only menu is ideally a progressive enhancement on the existing dropdown structure, but I'm happy to be corrected there.

could you elaborate a bit more on this? I'm thinking the Navigation Link block could be just a menu item with no additional functionality apart from perhaps the ability to be transformed into a Dropdown.

Currently when you insert a menu item, but don't choose a destination, it looks like this:

That state serves to indicate both that the menu item is in a draft state (and won't show up on the front-end), but also to indicate, just like grammar underlines, that you can click it to correct it:

The behavior exists also in part to accommodate highly opinionated patterns. That means unless the menu item has both a label and a URL, it will show up in this draft state. So if it needs to be able to transform into a destination-less click-only dropdown, the flow will probably not feel great as is.

Absolutely, and I'm now wondering if we should tackle that before moving on with this work. I'm happy to do a PR but we'll probably want to agree on the appropriate classnames beforehand 😄

The current classes targeted in the Navigation block structural CSS are these, as copied from #31879:

Menu item container:

• Page list: .wp-block-pages-list__item
• Menu items: .wp-block-navigation-link

Menu item link:

• Page list: .wp-block-pages-list__item__link
• Menu items: .wp-block-navigation-link__content

Submenu indicator:

• Page list: .wp-block-page-list__submenu-icon
• Menu items: .wp-block-navigation-link__submenu-icon

Submenu container:

• Page list: .submenu-container
• Menu items: .wp-block-navigation-link__container

The submenu indicators and submenu containers are specific to the Page List block and therefore mostly a separate issue that's less important. But both the menu item container and link containers are both used and targetted by all menu items. So, how about:

• Menu item container: .wp-block-navigation-item
• Menu item link: .wp-block-navigation-item__content

There's also a little conversation about it in #32677 (comment).

Really, the choice is between this PR and #33351 in terms of how we allow users to create submenus. I'm inclining towards this PR from a code perspective, and I like how obvious it is to have Dropdown as an option in the block inserter, but welcome more opinions on both fronts!

Thanks for that summary, makes a ton of sense. When approaching it from that angle, there's the added angle of "do we allow mix and match", and what does that mean for any JS we might need to output to ensure click-only behaviors?

To be fair, I have seen a number of mega-menu sites that do mix and match, and have click or even hover-only menu items where the opener itself doesn't link anywhere. But at the same time I could also see it being useful to have a single navigation-block-level toggle to choose whether dropdowns opened on click or on hover. There's some mostly out of date work in #18445 that explores the latter.

I'm missing a beat. In my testing this branch and trunk, I don't see any transform options for any menu items at the moment.

I haven't added them yet 😅 but am assuming we'd want to add them in the default location for block transforms.

there's the added angle of "do we allow mix and match", and what does that mean for any JS we might need to output to ensure click-only behaviors?

The accessibility feedback is that we should avoid having the dropdowns open on focus, and should instead open them on click when using the keyboard (and this solution also avoids having to tab through endless submenu items to reach the next top-level item). It's fine to have them open on both click and hover, like Twenty Twenty One does. Potentially we could flip the question in #18395 and allow hover to be the configurable behaviour: have open on click be the default, and an option to also open on hover.

That would mean the JS for open on click would always be output. I've just added that functionality in my latest commit, btw, and I left the open on hover working too, so we can have a play with this and see how it feels.

Cool, click is great. But it does come with some design challenges that are perhaps best explained in this post I can highly recommend, so we kind of have to decide where we land on that.

Potentially we could flip the question in #18395 and allow hover to be the configurable behaviour: have open on click be the default, and an option to also open on hover.

That makes a lot of sense to me, considering we probably have to keep the hover mechanism around, even just for cases where the JS fails or is blocked from loading, or as back compat for existing hover only themes. We can even add a yellow warning notice like we do for low contrast, when you choose the hover only option.

The challenge is, TwentyTwentyOne is designed around handling both hover and click, with a little "plus" icon being output for the click-only behavior. While I find it works well for that theme because it's designed around it, I'm skeptical it's a pattern we can roll out for every menu out there. Menus where the primary item links to its destination but also opens a submenu is like having the cake and eating it too — and it's not as obvious as the primary item performing only the single duty of opening the submenu. This is the part that needs the most flow-thought, I think.

Picture this structure:

Products [links to /products/]
	Jorts [links to /products/jorts/]
	Jeggings [links to /products/jeggings/]
	Jeans [links to /products/jeans]

If the entire menu, or just the menu item, was toggled to be click only, how would we handle the /products/ link? Doing double-duty with the split button feels like a plan B to me. Another option might be to move the products link inside the menu, and keep only the label. It would need to duplicate the label, but a design could potentialy work:

The other alternative, outside of the split menu, would be the Dropdown item approach, where the main item doesn't link anywhere:

Products [doesn't link anywhere]
	Jorts
	Jeggings
	Jeans

While a fine approach, it would allow the potentially confusing mix and match of hover-only menus and click-only menus, and it would also require the menu to be built in this way.

The challenge is, TwentyTwentyOne is designed around handling both hover and click, with a little "plus" icon being output for the click-only behavior. While I find it works well for that theme because it's designed around it, I'm skeptical it's a pattern we can roll out for every menu out there.

I'm thinking Twenty Twenty One is the best pattern to implement here, because it works just like a classic hover menu, and we only notice the open-on-click interaction when navigating with the keyboard. And when using the keyboard, it's frankly a relief not to have the submenus open as soon as we focus the parent element. The only obvious thing that we'd have to change in the Navigation block in order to implement that pattern is the submenu indicator could no longer be optional, as the click behaviour would need its own button whenever the parent element is a link, and we'd need the submenu indicator to signal the button's presence. But perhaps the indicator itself could be configurable, if a theme wanted to use a different icon.

What other issues do you anticipate with using the Twenty Twenty One pattern, @jasmussen ?

We can even add a yellow warning notice like we do for low contrast, when you choose the hover only option.

I meant having hover as optional in addition to click, not instead of it, otherwise the menu will be inaccessible. Unless the option is to have hover + open on focus instead of open on click only. But the accessibility folks seemed pretty keen on not using focus to open submenus at all.

The submenu indicators and submenu containers are specific to the Page List block and therefore mostly a separate issue that's less important. But both the menu item container and link containers are both used and targetted by all menu items. So, how about:

• Menu item container: .wp-block-navigation-item
• Menu item link: .wp-block-navigation-item__content

I've just made #33918 to address this issue. I'm thinking we'd better also add a classname for submenu containers, and perhaps for the indicators as well? That would help reduce (or even eliminate) the custom styles in this PR.

I'm thinking Twenty Twenty One is the best pattern to implement here, because it works just like a classic hover menu, and we only notice the open-on-click interaction when navigating with the keyboard.

Here's what I see in TT1:

• When using the mouse, the mixture of hover and click makes it tricky to select submenu items. I click the plus to open the submenu, but when hovering outside of the plus, that closes it.
• When using the keyboard alone, tab sets focus on the "opening" menu item, making it easy to follow that link. The next tab sets focus on the plus which then opens the submenu. However now I have to press tab again to enter the submenu, which doesn't match the visual order since the actual dropdown menu sits before the plus. My first instinct was shift-tab, or to use roving arrow-keys to navigate.

Moreover, the dropdown menu doesn't act as a modal in that it captures tab and closes on Escape, so it feels like it only adds limited value over the keyboard interaction compared to how the hover-only menu works with the keyboard:

Click is great, though, but click and hover I'm less sure about: it's an extra tab-stop, and it requires a very delicate design in order for the visual order to match the tab-order. I'm also worried about what this means for the existing WordPress themes that are designed assuming a hover-only design; if we were to enforce click by default, we'd have to output a split-button indicator like a plus or a chevron, I don't think we can be sure existing themes are ready for that.

Approaching this fresh, on the other hand, I think we have a great opportunity to make an excellent click-only experience by default, one which works out of the box, is carefully designed, and perhaps uses Micromodal like the burger menu for keyboard interactions (which could be extra useful in mega-menu cases). If combined with leaving the existing hover/basic tabbing behavior as an optional fallback, it might thread the needle.

Because this feels important to get right, I would hope we could get some wider input from some of our themers on this: @MaggieCabrera @melchoyce @critterverse @javierarce @kellychoffman — if you have time, thank you!

I've just made #33918 to address this issue. I'm thinking we'd better also add a classname for submenu containers, and perhaps for the indicators as well? That would help reduce (or even eliminate) the custom styles in this PR.

👏

A unification of all those classes sounds useful, absolutely, especially if it isn't too much work. One option might be to just let the existing classes for navigation items be intact (.wp-block-navigation-link__submenu-icon and .wp-block-navigation-link__container), and then copy those over to the Page List (which currently has .wp-block-page-list__submenu-icon, .submenu-container equivalents).

Here's what I see in TT1:

I agree the experience isn't great when clicking with a mouse, because we get a weird mix of click and hover behaviours, but both hover-only and click-only (using keyboard) is pretty nice:

Compared to the sub-optimal experience of opening on focus when there are large or multiple submenus:

So I wouldn't give up straightaway on a hover/click combination, but we can definitely work to improve the points you mentioned. Perhaps we could try:

• Aligning the submenus with the click button, so the focus order is visually obvious;
• Ignoring hover events if the submenu was opened with a click, and only closing it when focus is moved outside of it.

I was thinking that if we allow interaction on hover, the button icon could be positioned closer to the top-level element text, so that they don't seem to be separate elements? But that kind of makes open on click functionality less obvious for mouse users. I don't know, it's a complicated problem 😅

I'm not completely sold on the idea of moving the top-level link into the submenu, mainly because I suspect users may take exception to not being allowed to make that decision themselves, but generally I agree that having top-level items just be buttons that open submenus, instead of links, is nicer. But WP has had the top-level item be a link for such a long time that springing a completely new pattern on our users might be quite jarring. On the other hand, the Navigation block is completely new (and it's not released yet! So we still have room to change stuff around) so it might be a good place to make that change.

👋

When using the mouse, the mixture of hover and click makes it tricky to select submenu items. I click the plus to open the submenu, but when hovering outside of the plus, that closes it.

Oof. That seems like something that should be fixed in TT1.

In case you're curious, this is the thread where we discussed the current TT1 implementation: WordPress/twentytwentyone#263

The separate, click-to-expand submenu was put in place for two reasons: for more intuitive keyboard navigation, and to reinforce the "hover is not necessarily a reflection of intent" concept. We added hover back in after testing, since folks (like me 😄) really expect it these days.

So I wouldn't give up straightaway on a hover/click combination, but we can definitely work to improve the points you mentioned. Perhaps we could try:
...
• Ignoring hover events if the submenu was opened with a click, and only closing it when focus is moved outside of it.

This suggestion from @tellthemachines seems reasonable to me, and I think is worth a try.

Ideally, the nav menu would be able to support all three options from the w3 docs (https://www.w3.org/WAI/tutorials/menus/flyout/). I can then see the hover+click pattern being the default, as it is the most accessible. Another option to to have the nav block support only one of the w3 options, but is extensible in a way that a plugin could easily provide those options.

https://codepen.io/okia/pen/jXWrYL

I think that codepen above is a great example of how it should work. It combines keyboard navigation with hover in a really nice way. You can still have the parent item trigger a link but also use the spacebar or down arrow to navigate to it's children. Mouse interaction works on hover and feel natural.

Thanks for the added context. To be clear, my primary concern is with backwards compatibility with existing menus that rely on hover: the "plus" as a click affordance might mess with their layouts.

While the hover-only menu only provides basic accessibility, it is accessible, so I don't think there's any harm in existing menus retaining this behavior. Furthermore it's an opportunity to educate and warn in the interface, by providing a strong new default and warnings when choosing the legacy interface. Something like this, perhaps:

@getdave I've been keeping a PR up-to-date here that adds support for submenu in the nav editor - #34281

The key is to not have two different ways to accomplish the same, that will often cause confusion as to which way is the right/best way. In other words, if we bring back the submenu block, we should consider removing the button in the toolbar.

There's nothing wrong with having two ways of accomplishing something. This is a very similar situation to the Image to Cover transform: Cover is available as a block in the inserter, and it's possible to transform Image into Cover via the usual transforms menu, but the transform is additionally exposed in the Image toolbar as "Add text over image".

There doesn't have to be a single best way; if having two or more ways to do something makes it easier for users to accomplish what they want, I can't see any downsides 🙂

Thinking specifically of this case, due to the differences between hover and click, different flows are better suited to each option: transforming from a Link is more intuitive for the hover menu, but adding the Submenu directly makes more sense for the click menu.

Ultimately, some usability testing on this would help us confirm what is best.

The option not showing in the inserter would only be an issue when using the inline inserter; for the sidebar one the social links etc. are under a different section, so won't interfere with the visibility of the Submenu block. I'm not sure which inserter gets most use, but I doubt it would be a huge issue even for the inline one.

I wonder whether we ought to include the link text here if it's available rather than just Submenu. The block icon is enough to denote it's a submenu.

When adding dropdowns within dropdowns I found the teriary level sometimes appeared on top of the secondary level dropdown instead of to the side.

Thanks, fixed!

Nit: I noticed that when you expand / collapse the Submenu item in the list view the dropdown doesn't match in the Editor. I expected when I collapsed in the List View that the dropdown would disappear in the Editor.

Hmm, this also happens on trunk so it's either intended behaviour, or a bug that can be fixed separately 😅

Hover intent is a great idea! Again, it's not on trunk so we can do it separately.

Did some testing and I noticed in TT1 Blocks empty submenus are transparent (theme styles disabled):

The block behind also seems to be selectable so maybe it's more of a z-index thing. The same happens in standard Twenty Twenty One, but is harder to reproduce because there are bigger gaps between blocks, so it's harder to get a dropdown over the top of a trailing block.

Also, side note, #34281 should be ready for review now.

The way these options jump around doesn't feel good. It makes it really easy to click the wrong one.

The block behind also seems to be selectable so maybe it's more of a z-index thing.

It was; fixed now.

The way these options jump around doesn't feel good. It makes it really easy to click the wrong one.

I've moved them around so the disappearing one is at the bottom. In any case, there are plans to change some of these to buttons soon.

Thanks for the reviews, folks! I've fixed the pending issues.

In the meantime, there's the navigation editor update PR, #34281, that I'm going to review and test in a bit. Should that one be merged together with this one, or is it not a blocker for merging this?

There's also #34675 to update Page List block, but I think that one can be merged later.

We haven't formally reached an agreement on whether to show Submenu in the inserter or not 😄 but I'm inclined to show it, and then gather data on how it's being used.

The remaining thing is to investigate how/if we can deprecate submenus in Navigation Link. I'll look at that separately.

@tellthemachines All still looks good. I say go ahead and merge, and then it'd be good also merge #34281 straight after. I've addressed the feedback on that one.