Navigation Block: Create Block Variant for a "Fullscreen" navigation menu

[shaunandrews]

Just like we have Horizontal and Vertical variations of the Navigation block, I think we could have a Fullscreen variation as well. With this variation, the Navigation block defaults to showing a Button block. The toolbar exposes a state selector, allowing you to toggle between the two states: Button and Menu.

[aristath]

The state-selector to allow switching between button & menu states is absolutely brilliant and definitely something we'll need.

But I do have some concerns... The main issue I have with this concept is specificity. I mean, why a fullscreen menu? Why not off-canvas-left, off-canvas-right, top, bottom, collapsible-in-place, slide-out, modal, vertical-icon-menu etc?
If we start adding specific use-cases (like fullscreen-navigation), then there's no end to that, we'll just keep adding more and more. I don't know if that's where we want to take things... We can either add all of them as we go, or none of them 😅

So an alternative suggestion: Maybe a more high-level approach would be preferable? Instead of "fullscreen", we can call it "collapsible" or something a bit more abstract, and then the states can be collapsed/expanded. That would cover most use-cases where the navigation has 2 states (collapsed/expanded), and allow for some freedom in themes. As long as the button & nav use valid markup with proper aria states etc, themes can then implement them however they want... All that will be needed is some CSS. Core can add the button, the aria states to that button, and the JS necessary to toggle these states on button-click.
If a theme supports collapsible menus they can add add_theme_support( 'collapsible-nav' ); or something similar, and then implement them however they want.

[shaunandrews]

Why not off-canvas-left, off-canvas-right, top, bottom, collapsible-in-place, slide-out, modal, vertical-icon-menu etc?

I actually think we (or themes and plugins) could offer any and all of these variants. In my mockups I explored displaying all of a blocks Variations, similar to Styles — one of the variants I was toying with was a "Sidebar":

If we start adding specific use-cases (like fullscreen-navigation), then there's no end to that

The "Fullscreen" design pattern is very common across the web today, and almost a standard on the mobile web. Its a good starting point to really flex the capabilities of the Navigation block and Gutenberg itself; There's currently no way to manage or edit the states of a block. This is a nice first step.

If we start adding too many variations, that would be a good problem. I'd expect WordPress Core would only offer the most basic and comment patterns, with themes and plugins expanding on those to offer more specific needs.

Instead of "fullscreen", we can call it "collapsible" or something a bit more abstract

I follow your thinking, but I believe you're coming at this purely from a theme developers point-of-view. I agree that the code/logic could be abstracted so that it could support any visual representation of a "collapsible" navigation menu.

However, when I'm inserting or adjusting this block, I wouldn't have any clear understanding of what a "collapsible" variant would actually do; Its not a descriptive enough label or concept.

[aristath]

I follow your thinking, but I believe you're coming at this purely from a theme developers point-of-view.

Can't argue with that assessment... That is indeed where I'm coming from and my perspective 😆

However, when I'm inserting or adjusting this block, I wouldn't have any clear understanding of what a "collapsible" variant would actually do; Its not a descriptive enough label or concept.

I hear you... What I want to avoid however is seeing 1000 websites, all looking the same. If fullscreen is available and maybe a couple other options, then that's what the majority will use.
What I want to avoid is limiting the imagination of authors, because if they have a couple decent patterns very few of them are going to bother creating new ones.

[mtias]

One other thought could be to have a general purpose "full-screen" block (or a version / attribute of group / cover). That would allow placing whatever block is required in the overlay, including navigation links. Just something to think about. You could transform an existing menu (or any set of blocks) into this special block. Maybe "Overlay"?

[MaggieCabrera]

Thanks for opening this issue, I think the discussion about the Navigation block is very important and I believe this is a critical block when it comes to theme building. The menu of a theme is usually the most complicated (and time-consuming) part of a theme's development and there are many variables involved. I'm sorry if I'm going to speak about things that are already being discussed elsewhere but I'm still getting a grasp of where we are right now :)

I think the block (be it the navigation block or a new one entirely) should provide a solid foundation for the theme developer/designer to expand upon.

I hear you... What I want to avoid however is seeing 1000 websites, all looking the same. If fullscreen is available and maybe a couple other options, then that's what the majority will use.

I agree this might be the case. I myself am more worried about the lack of tools that the block currently gives the themers for the most complicated part of their site. It is indeed complicated to know when to stop because the possibilities are also endless, but right now when building a block-based theme it feels like I can't really build a menu with the tools that I have available.

[mtias]

This is great! Do you think it should be a variation of the Navigation block or more generic like an "Overlay" block where you could just place whatever inside, including columns, cover, background images, etc?

[talldan]

This is great! Do you think it should be a variation of the Navigation block or more generic like an "Overlay" block where you could just place whatever inside, including columns, cover, background images, etc?

There was some separate discussion about a Dropdown block, so it seems a similar case—#23745

[andersnoren]

Big +1 to the ability to add blocks other than just the menu to the menu overlay. Most menu overlays these days have elements like social icons, search fields, language toggles, shopping carts, etc. in addition to the actual menu items.

Could there be a case made for being able to define an entire template part that the button can toggle, with a shortcut to that template part from the button in the editor? The template part would be easily accessible in the Site Editor and able to hold whatever blocks the user wants to add to it, in addition to a navigation block.

Modals/overlays for search forms, shopping carts, account menus etc. are all pretty common as well, so maybe at that point the button would be less a version of the navigation block and more of a "Overlay Button" block that can present any template part as an overlay. It would also enable multiple buttons to point to the same overlay.

[ramonjd]

Do you think it should be a variation of the Navigation block or more generic like an "Overlay" block where you could just place whatever inside, including columns, cover, background images, etc?

@andrewserong and I have spent some time thinking about this. It would be a useful general feature, if we can conceptualize the editor UX.

I imagine, as well as being able to add any inner block to the overlay, users would want to be able to attach events that trigger the overlay to buttons or other elements within the post.

Or even, in the case of navigation, trigger the overlay at certain viewport widths.

Modals/overlays for search forms, shopping carts, account menus etc. are all pretty common as well, so maybe at that point the button would be less a version of the navigation block and more of a "Overlay Button"

This sounds like it's worth devoting brain power to, if we can make the overlay button useful in the context of a webpage.

I was thinking of inline buttons or links that trigger overlays containing galleries, or contact forms etc. How would we insert these into the content flow in the editor 🤔 ?

An alternative is to focus on the navigation block and attempt to create a variation in order to gauge complexity, and learn lessons for when we genericize the overlay.

I'm happy to fork this conversation off to a separate issue.

Cheers!

[colorful-tones]

This is a neat endeavor. I believe off-screen, as opposed to fullscreen would be better terminology. This seems more common in my everyday (developing custom themes for clients), but would like to hear from others.

The original intent of this issue: "Navigation" is seemingly starting to diverge with the overlay conversation. While I encourage both conversations, and recognize that they're likely intertwined. I would encourage us to possibly consider spinning up another Issue to address overlay conversation. So as to not hold up progress on this Navigation-focused enhancement.

My biggest concern is proper accessibility (now talking to both: overlay and navigation contexts). Given that this conversation is starting to encompass larger contexts (beyond just navigation: expand/collapse) then accessibility becomes an even bigger concern. There is no single solution for all these contexts: carousel modal, off-screen menu, pop-up cart that affords some simple plugin-and-play aria.

I like the original proposal here, and would encourage the overlay block conversation be shifted elsewhere, or later down the line.

I vote K.I.S.S. (keep it simple stupid) for first iteration, and then continue to iterate.

What I want to avoid however is seeing 1000 websites, all looking the same. If fullscreen is available and maybe a couple other options, then that's what the majority will use.

I'm not too worried about this. Yes, it'll may/likely happen, but hopefully by the time that the everyday abuse hits peak then there will likely be iterations in the pipeline to add variants or revisit altogether. i.e. this is not large enough deterrent to not pursue the addition of this feature.

🕺 🥳

[colorful-tones]

Some consideration may need to be made on whether the off screen (sticking with my preferred terminology) should incorporate sub-menus?

If yes, then how will it play out: further off-screen (slide in), or toggle: expand/collapse?

If no, then why not? (Because eventually people will ask)

I would likely argue that an early, first iteration not allow for sub-menu items and only contain parent links. Then, second phase could include exploration of sub-menus.

[carolinan]

Do you think we can close this issue in favor of #43852, Navigation Overlay - reference as template part ?

[mtias]

Yes!