Style Navigation block differently for "mobile menu"

[getdave]

What problem does this address?

Currently any styles you apply to the Navigation block will also apply when it is in "mobile" mode. This is sometimes not desirable as the "mobile" menu may require different visual properties.

For example, if you align the navigation items to the right then the items in the mobile menu are also right aligned.

Screen.Capture.on.2022-03-01.at.16-35-20.mov

What is your proposed solution?

We could explore adding dedicated UI controls which only apply to the navigation when it is in mobile mode. That said, it might get complex if styles are not mutually exclusive so the mobile styles would have to take precedence.

Alternatively we could wait for a more robust responsive styling solution to land in Gutenberg which might allow blocks to define a standard means to style elements different based on viewport.

[jasmussen]

It's good to have a dedicated issue for this one, thank you, I definitely agree.

I touched a bit on the following concept in this comment as well, but the way I see it, the contents of your mobile overlay is a blank canvas, and you should be able to put any block there, including columns and non navigation blocks.

One idea here is to leverage the same concept of saving inner blocks to a custom post type, as the navigation block does for its menu items. That is, have an entirely separate CPT for the contents of the modal. Here's an early mockup:

One subgoal to accomplish here would be to ensure that the X to close the modal could sit exactly where the = menu item sits, so it feels like the same button. A root level padding solution (#35607) that is inherited by the modal (but user overridable) would be a good start for that.

Another idea that might help is, if the navigation block is used inside a Header template part, the entire template part is kept (duplicated) inside the modal overlay, with logo and open/close button. 
This would also let the burger icon transform into a close icon, which could be a nice touch.

[getdave]

Thanks for your excellent insight as always @jasmussen.

...the contents of your mobile overlay is a blank canvas, and you should be able to put any block there, including columns and non navigation blocks.

I think the idea of a wrapper into which you can place multiple Navigation blocks is a good idea. After all if the menus are drastically different them they shouldn't be the same <nav> anyway.

From a technical POV that's a challenge because it's going to require a separate "mobile overlay" block which has the ability to be populated differently in the editor canvas depending on the value of an inspector control toggle.

As a user I need to be able to switch between populating the "desktop" and "mobile" variations of the block. I have a video which explains how you can use x2 separate Navigation blocks and use CSS to show and hide them. It would be similar to this concept, except we'd need a design/UX solution for how users would interact with the block within the editor - that's the big challenge. How would you see that working?

[jasmussen]

It would be similar to this concept, except we'd need a design/UX solution for how users would interact with the block within the editor - that's the big challenge. How would you see that working?

Yes, that's definitely similar.

My instinct is always to start with as little as possible, the shortcomings always have a way of presenting themselves when you do that, so you can address them one by one.

In this case, I would lean towards the mockup above: if you toggle the mobile menu to "always" and click the burger icon in the canvas, the very act of clicking that item would open up the modal with a new blank canvas, with any saving or creation of a dedicated overlay slot happening transparently in the background.

Some questions immediately present themselves:

• Should we copy the navigation block you built before toggling "Always" into the overlay? Perhaps yes.
• Should you be able to have a dedicated overlay also when the "Mobile" option is toggled? Maybe, but could also wait?
• Is it enough to click the burger icon in the canvas to load the contents of the overlay in template isolation mode? Or should there also be a dedicated button in the inspector, "Edit overlay"?
• Do I need to be able to swap out the contents of one overlay with another if one such exists, just like the nav block itself? Sure maybe.

All of those feel solvable, even if it is legitimately a big and challenging project. From an UX perspective, the biggest challenge I see with the approach is how this is compatible with editing the contents of the navigation block in isolation (i.e. #37950) since the UI may end up being very similar. My hope is that in practice it'll be fine: when it's collapsed to a burger button, it loads the overlay, when it's not, it loads the innerblocks of the parent nav instead.

[scruffian]

We'd like to be able to style the overlay differently to the regular block, using theme.json. Unless we create a lot of extra properties in theme.json for the Navigation block, we're going to find it difficult to support all these different properties. However what if we made the overlay its own block? Then we can simply use the standard theme.json properties on that block...

[jasmussen]

You suggested here that the overlay could be a block. Here we are discussing something adjacent, total customization of the contents of an overlay. In both cases we'd need theme.json integration — are the two tasks complementary?

[scruffian]

Yeah I think they are basically the same thing!

[getdave]

I've been thinking about this as well and come to the same idea.

We could have some kind of wrapping block that allows you to toggle when the overlay is displayed (like the Nav block does today).

Then you could nest Nav blocks within that block. It could provide context to customise the behaviour.

[luisherranz]

I think this could be elegantly solved without any ad-hoc implementation if:

1. We add the ability to configure different layers/states using blocks.

   • How should we handle different layers/states for the same block in the editor? #38108

2. We allow any block to become a section capable of overwriting the global styles of their children.

   • Patterns as Sectioning Elements #39281
   • Implement the concept of sections #40317

[phil-sola]

This definitely needs reviving - the mobile menu is horrible out of the box and for a non-developer who may not know how to write CSS to style it any differently, that could be pretty offputting. I love the initial mockup and thought process from @jasmussen regarding a blank canvas to build out the overlay using blocks including columns, buttons, navigations.

Some really fantastic mobile overlay designs could be created directly in the block editor for everyone without needing to be a skilled developer to hack away at the current implementation.

[getdave]

@phil-sola I've previously recommended this as one of the features contributors should look to focus on.