Navigation block: Make nested menus fully customizable (Megamenus)

[adamziel]

This is how the current dropdown/nested menu looks like:

The way it works is that the navigation link block supports nested navigation link blocks. This is fine for simple dropdowns like the one above, but does not support more advanced use cases like the ones below:

A good start would be supporting an arbitrary wrapper block such as columns, or even some kind of a "box" block that would be like columns with just one column. Supporting a drawer menu at some point would be nice too.

[adamziel]

cc @noisysocks @draganescu @tellthemachines @talldan @shaunandrews

[shaunandrews]

I've been toying with the idea of a Submenu block, which would offer customization options like width and color, along with acting like a specialized Group block that could contain blocks like Columns and Image. Here's a rough GIF to (hopefully) show how it could work:

There's also a clickable Figma prototype you can try.

[draganescu]

This has been discussed in Slack in the weekly navigation sync.

It's a bit unclear how does a submenu block differ from a group or columns block.

[tellthemachines]

I wonder if the Submenu block couldn't instead be a generic Dropdown block, that could also be used elsewhere outside Navigation? And perhaps we could also have a Slideout block, that could contain a Navigation block (or not, it could just contain a bunch of Buttons, or anything else really). The Slideout could just be a wrapper with a close button and <InnerBlocks>.

[jasmussen]

I wonder if the Submenu block couldn't instead be a generic Dropdown block, that could also be used elsewhere outside Navigation? And perhaps we could also have a Slideout block, that could contain a Navigation block (or not, it could just contain a bunch of Buttons, or anything else really). The Slideout could just be a wrapper with a close button and .

This is a great idea.

• The "Slideout" (which is really a better name than "Hamburger") could be a container block which showed a menu button on mobile breakpoints, and its contents on table or desktop breakpoints. Put a navigation block inside, or anything else, and you're golden.
• The Dropdown block could feature widths (contents width, main column width, wide, fullwide, fullscreen).
• Combined with the incoming "Page List" block, we could pre-create some delightful navigation block patterns which would give you excellent shortcuts to accomplishing this.

[talldan]

Decoupling the link block from its dropdown menu would be great from a code quality point of view as well.

Jumping into solution space a bit, the part that I'm wondering about is how the block hierarchy will look, especially when it comes to the toggle. Would it be something like:

Dropdown
    |— Dropdown toggle (only supports a single child block)
    |        |— Link / Button? / Text?
    |— Dropdown menu (supports multiple child blocks)
             |— Any block (potentially even another dropdown menu)

Alternatively, the Dropdown toggle could be a block without inner blocks, implemented using RichText. With that though there's a risk of losing consistency between how a link with a dropdown menu works compared to a link without a dropdown menu.

[tellthemachines]

Could creating a submenu mean that the Link block gets transformed into a Dropdown block, where the toggle content is editable but isn't a separate block, and all its inner blocks go inside the dropdown itself?

[talldan]

I think my concern would be about missing features in the Dropdown Block. Things like rel and title attributes would be lost. There has also been investigation into making Page Link dynamically update to changes in URL (e.g. permalink changes). Dropdown would also have to implement that.

But what you mention would at the moment be best for user experience.

For my suggestion to work there would need to be improvements to how inner blocks work (e.g. the 'passthrough' block idea)

[jasmussen]

I've been on an expedition to explore pragmatic next steps for this one. Specifically, I did the crazy thing and allowed the Heading and Columns blocks inside submenus. That's the easy part:

const ALLOWED_BLOCKS = [
	'core/navigation-link',
	'core/spacer',
	'core/heading',
	'core/columns',
];

Of course that's not going to work for us, but the experiment was nevertheless interesting:

A few immediate take-aways:

• The heading actually did work, but it's hard to know which heading level to use.
• Allowing the paragraph instead is arguably a better choice, but that changes the appender to the inline one, which we should avoid here.
• The columns block works, but it brings with it all the problems it already has — bulky placeholder, fiddly creation flow, yet another container.
• The columns block does not allow Page Link or any of the other navigation items. So even if we did want to allow a columns block inside submenus, it would come with additional work.
• The width of submenus is currently based on content — you can see it grow when I type in the heading. But this needs more control.
• The "Absorb toolbar" mechanism used by the navigation block shows its downsides here. We might want to turn it off again until we can revisit how the mover control can potentially be disconnected from the parent block toolbar, or otherwise make general improvements there.

But zooming out further, I feel like there are some more general observations we can make:

• Allowing just the paragraph (but without changing from the button plus appender) seems like a great way to allow subheadings or just arbitrary phrases. Seems like an easy win.
• Allowing you to set the width of submenus seems like a property we can set on the navigation block itself, like a sidebar toggle. There doesn't seem to be great value in allowing variable-width submenus on a per-dropdown basis.
• Showing multiple columns, the key bit of mega menus, is likely going to be the primary headache. It seems like it might be worth trying to start with the same approach the Gallery block uses, which is to say provide a number of columns slider in the navigation block sidebar, and then handling the complexity behind the scenes. If we combine this with a column-height value, you should be able to control how many items are in each column, by carefully using spacer blocks, and we'd avoid introducing a ton of nesting complexity in the process.

I'll try and explore this more in a mockup.

[shaunandrews]

Allowing just the paragraph (but without changing from the button plus appender) seems like a great way to allow subheadings or just arbitrary phrases. Seems like an easy win.

Love the flexibility this could provide.

There doesn't seem to be great value in allowing variable-width submenus on a per-dropdown basis.

I actually think a variable-width could be preferred, depending. I'd want to be able to select from some options, maybe [shrink|full-width|fix-width] — though that might be a bigger ask.

provide a number of columns slider in the navigation block sidebar, and then handling the complexity behind the scenes.

This setting, and the width setting, would "live" within the inspector for the parent link item?

[jasmussen]

To clarify: I meant that I'm not sure there's huge value in having drop-down menu 1 be full width, and drop-down menu 2 be automatic width, with both those dropdowns in the same navigation menu. By making the width a single toggle, it could live in the inspector for the navigation block itself.

The flip side, per drop-down controls, would need you to configure it on each item if you wanted full width for all drop-downs, and probably be harder to find as well.

[shaunandrews]

Ah, that makes more sense now. Thanks for the explanation.

[jasmussen]

Following up on the previous exploration, I took at whether we could implement basic megamenus. Turns out:

• Menus that span the width of the block navigation container is easy.
• Using CSS3 columns to provide a just-like-gallery column slider is also easy.

Codepen example.

CSS3 columns come with a few trade-offs, though, the primary one being that you have no control over which items go in which column. It's a sequence that's split by the browser. You could potentially mitigate some of these bits that with per-block margin controls, or spacers, but ultimately the design opportunities would be slightly limited by that.

The upside is not to be frowned at, though: it's fairly trivial to implement, and by avoiding nesting containers entirely, there would be no user experience overhead.

[paaljoachim]

That looks really nice Joen @jasmussen ! It makes me think of horizontal tabs. (Perhaps it can later on be the beginning of a tabs block.)

[jasmussen]

✨

I suppose if we were to enable click instead of hover to invoke submenus (#18395), you could put together a nice little tabbed section, though keep in mind it would be collapsed by default.

[tellthemachines]

I've been thinking about how we can build this in light of the changes in #30551. The semantics can be approached in the same way as that PR: make the dropdown container a div, and then iterate through its children on the server side and add list wrappers around the navigation links. What isn't clear is how the multi-column layout should be implemented: assuming users must be able to add items to any of the columns, much like in a columns block, we need to either enable multiple inner block areas as children of a single (Navigation Link) block, or some sort of passthrough block solution that allows us to add an invisible block for each column.

Also, looking at the examples above, mega menus aren't always limited to a bunch of columns. There are several different layouts that include header or footer areas inside the dropdown, and, to complicate matters, the same website might have slightly different layouts for each dropdown. For example, here are two from EdX:

We also can't assume that all dropdowns in a menu will be mega-sized:

I guess we can supply a bunch of settings that allow enough flexibility to build the most common patterns: choosing the number of columns and options to add a header and/or a footer area should cover most of them. For maximum flexibility, we should set those at a per-dropdown level, as well as the dropdown width.

[jasmussen]

Thanks for thinking about this 🚀

Also, looking at the examples above, mega menus aren't always limited to a bunch of columns. There are several different layouts that include header or footer areas inside the dropdown, and, to complicate matters, the same website might have slightly different layouts for each dropdown.

That question stands out to me, because I've been thinking of this as the submenu simply containing a Columns block. It can then have 1-6 columns, but perhaps default to 1. By leveraging the existing columns block (assuming possible), we'd get any benefits being built for that block, which includes using CSS grid, gap, and built-in responsivenes.

The following is a work in progress draft that simply puts some thoughts onto the canvas and is meant to be further refined:

But it shows the "Kids" section being selected, with that opening a dropdown menu that is full-width and which uses a 5 column Columns block with 4 filled out.

[tellthemachines]

By leveraging the existing columns block (assuming possible), we'd get any benefits being built for that block, which includes using CSS grid, gap, and built-in responsivenes.

This is a great point! Should it be presented to users as a block though (making the block selectable and all its controls available) or should we try for a passthrough block solution?

Also, in this scenario, if we wanted to add a header or footer area to the dropdown in addition the the Columns, we might look at using a Group block as a sibling of the Columns block. If we enabled horizontal layouts for Group (I think this has been brought up somewhere?) that would allow us to build pretty much any menu design out there.

[jasmussen]

This is a great point! Should it be presented to users as a block though (making the block selectable and all its controls available) or should we try for a passthrough block solution?

Ideally not, no, ideally you click a menu item, the megamenu opens, and ideally that's the columns block right there, without the ability to being deleted, or moved. It's a good question though, what would this look like?

I always thought of the Media & Text block that integrated an embed block directly on the left:

Turns out it's not an embed block, it's just the inner workings of it.

But the user experience is the same that could probably work well for navigation menus: it's integrated enough to feel a part of the block, even if the engine driving it is separate. Is it still a separate block, just tightly locked down? Do you select it when you select the dropdown menu? Is it hidden through the much-discussed "passthrough" mechanism from #7694 or something else?

Also, in this scenario, if we wanted to add a header or footer area to the dropdown in addition the the Columns, we might look at using a Group block as a sibling of the Columns block. If we enabled horizontal layouts for Group (I think this has been brought up somewhere?) that would allow us to build pretty much any menu design out there.

Yes, excellent problem to surface. I'll put on my todo to explore some mega-menu patterns in addition to mockups, so we have some idea of what combo of blocks we might want to insert.

[uniquesolution]

Why not provide just "Widget Area" insertable inside as submenu item. In this way we can create the whole mega menu how we like in a widget area and then just insert it in a menu just as a submenu item ?

[cfournel]

This is a great point! Should it be presented to users as a block though (making the block selectable and all its controls available) or should we try for a passthrough block solution?

Ideally not, no, ideally you click a menu item, the megamenu opens, and ideally that's the columns block right there, without the ability to being deleted, or moved. It's a good question though, what would this look like?

I always thought of the Media & Text block that integrated an embed block directly on the left:

Turns out it's not an embed block, it's just the inner workings of it.

But the user experience is the same that could probably work well for navigation menus: it's integrated enough to feel a part of the block, even if the engine driving it is separate. Is it still a separate block, just tightly locked down? Do you select it when you select the dropdown menu? Is it hidden through the much-discussed "passthrough" mechanism from #7694 or something else?

Also, in this scenario, if we wanted to add a header or footer area to the dropdown in addition the the Columns, we might look at using a Group block as a sibling of the Columns block. If we enabled horizontal layouts for Group (I think this has been brought up somewhere?) that would allow us to build pretty much any menu design out there.

Yes, excellent problem to surface. I'll put on my todo to explore some mega-menu patterns in addition to mockups, so we have some idea of what combo of blocks we might want to insert.

Thanks for thinking about this 🚀

Also, looking at the examples above, mega menus aren't always limited to a bunch of columns. There are several different layouts that include header or footer areas inside the dropdown, and, to complicate matters, the same website might have slightly different layouts for each dropdown.

That question stands out to me, because I've been thinking of this as the submenu simply containing a Columns block. It can then have 1-6 columns, but perhaps default to 1. By leveraging the existing columns block (assuming possible), we'd get any benefits being built for that block, which includes using CSS grid, gap, and built-in responsivenes.

The following is a work in progress draft that simply puts some thoughts onto the canvas and is meant to be further refined:

But it shows the "Kids" section being selected, with that opening a dropdown menu that is full-width and which uses a 5 column Columns block with 4 filled out.

hello, how can you achieve this in navigation block ? is it already available in wp 6 ? i m looking to develop a mega menu, with columns and images such as the example provided , thank you @jasmussen !

[draganescu]

@cfournel today the submenus of the navigation block are still limited to links and the ability to create "mega menus" is still not there. I think in the images we have design explorations not actual results of using Gutenberg.

[audunmb]

Got directed here from the Wordpress forums because I asked for more options. Building the navigation block into a full megamenu block seems to be overkill. Megamenu blocks should be left to plugins, it's not something every website needs.

Still, the Navigation block needs some more options. A footer menu where submenu items are shown (i.e. not a dropdown) like in the H&M example should be possible without a separate plugin. Not the only way to add a menu in FSE themes is the Navigation block, and you are forced to have a dropdown with it. An option to shown expanded can't be that hard to add.

Also, there are a few UX downsides to using a hamburger menu, forcing it as the default responsive option is bad. A short menu for smaller screens, optionally with hamburger button for full menu (like in the much used Astra theme) is a much better option for most websites. Though, this is general responsivity issue, the best would be the options to have separately designed headers and footers for different screens (again like Astra does).

[paaljoachim]

Here is an example from a site I am recreating with Twenty Twenty Two which has a lot of written material.
The submenu feels very crammed.

I assume I will need to use a bit of CSS to give the submenu more air.

[getdave]

Relaying some feedback from my YouTube channel:

The Block Editor must natively allow the creation of Mega Menus for the Navigation Block

It seems the demand for this feature is still strong.

[audunmb]

A simple workaround for those who want a menu to display without the dropdown is to override the CSS. This forces the Navigation block to display (and show, not hide behind a dropdown) submenu items below the parent item without dropdown.
This doesn't create a megamenu or anything, but it makes Navigation block useful for adding menus in the footer or other places where you don't want a dropdown.

Not the most elegant solution, but it works (at least with TwentyTwentyTwo). If someone can make a more elegant CSS solution, please tell me.

Add the class 'is-style-footer-menu' to the Navigation block (or create a block style for Footer Menu) and use this CSS:

`.is-style-footer-menu .wp-block-navigation__submenu-container {
color:inherit !important;
border: none !important;
background-color: initial !important;
}

.is-style-footer-menu ul.wp-block-navigation__submenu-container {
visibility: visible !important;
opacity: initial !important;
position: static !important;
width: auto !important;
height: auto !important;
min-width: 200px !important;
}

.is-style-footer-menu li.wp-block-navigation-item.has-child.wp-block-navigation-submenu{
display: block !important;
}`

[annezazu]

I wanted to follow up here to note that upcoming work in 6.5 helps folks get there. Here's a developer blog post on the topic: https://developer.wordpress.org/news/2024/02/29/an-introduction-to-block-based-mega-menus/

[paaljoachim]

It would be very helpful with an update.
Thanks!

[getdave]

My feeling is that it's highly unlikely that Core will provide a solution for this any time soon.

Whilst we recognise the user need here, Navigation has other more fundamental issues that need to be addressed first.

I'm currently working on reviewing all the Navigation Issues and relating them back to the Tracking Issue with a view to including Navigation work included in a future release.

The focus must necessarily be on improving the basic interactions as a priority before we can begin to tackle these far more complex tasks.

[paaljoachim]

Thank you for the update Dave @getdave