-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Style Navigation block differently for "mobile menu" #39142
Comments
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. |
Thanks for your excellent insight as always @jasmussen.
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 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? |
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:
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. |
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... |
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? |
Yeah I think they are basically the same thing! |
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. |
I think this could be elegantly solved without any ad-hoc implementation if:
|
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. |
@phil-sola I've previously recommended this as one of the features contributors should look to focus on. |
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.
The text was updated successfully, but these errors were encountered: