Responsive layout behaviour for Navigation block

[getdave]

This discussion is specifically about the layout behaviours of the Navigation block at different viewports.

Current State

The block currently hardcodes a breakpoint at 782px at which point the block switches to "mobile" layout. This is only viable for the simplest of navigations - just try creating a Navigation with long labels or many items and it quickly breaks down.

It's generally agreed that a better solution is needed.

Requirements

The block editor aspires to the principles of intrinsic design whereby the design system adapts automatically whatever viewport it is displayed within. For this reason contributors aim to avoid media queries where possible and instead rely on more intrinsic solutions such as container queries, flex/grid layout algorithms...etc.

Therefore we should avoid any solution which:

• adds new media queries (e.g. "tablet", "desktop"...etc)
• allows the user / developer to specify their own break point

The rationale behind this is that once we add these solutions we would need to support them indefinitely. This means should a better solution become available then implementing it would become much more complex.

Moreover, such approaches require the user/developer to micro-manage the breakpoint which quickly breaks down in the face of changing numbers of menu items and their respective title lengths.

As a result, I propose that any solution we implement should meet the following requirements:

• automatically adapts whatever screensize it is displayed upon.
• automatically adapts based on quantity/length of menu items added.
• avoids hardcoded values.

In user story form:

As a user I expect my Navigation to automatically adapt itself visually when there is no longer room for the menu items to display.

Avenues for exploration

Container Queries

Container Queries are supported by all major browsers and allow a developer to query the size of a container (as opposed to the entire viewport) and alter the CSS accordingly.

The major failing of this approach is that we would still need to query a specific container for a specific size and adjust the layout. That would therefore require a hardcoded value (relative or otherwise) to dictate the size at which the Navigation should adapt to "mobile" layout. This leaves us with the same problem at the current solution - namely that WordPress would need to pick an arbitrary breakpoint.

As a result I don't see this as viable.

JavaScript "Measuring"

The actual requirement is that the Navigation should adapt to "mobile" view based on a heuristic which combines:

• Size of the Navigation's own contents (i.e. the number of items in the navigation and the "size" of each item)
• The space available on the main flex axis within a given container/viewport.

I.e: where there is no longer sufficient space on the main flex axis to display all of the Navigation items, switch to mobile layout.

The only solution that would seem to be viable for this would be JavaScript based. Two options spring to mind:

1. Measure the total "size" (dimensions) of the navigation items on the main flex axis and determine if they can fit within the space available to the Navigation block itself within it's container. Switch in/out of "mobile" layout based on this calculation.
2. Get the height of the Navigation block and see if any of the individual items have "overflowed" that height. If so then assume there is insufficient space on the main flex axis and adjust layout to "mobile".

Both options seem complex and would require significant exploration.

Request for Feedback

Contributors to the Navigation block would greatly appreciate feedback and input on the following:

• Do you agree that, in an effort to adhere to intrinsic design principles, we should avoid exposing responsive "break point" controls on the Navigation block.
• Do you agree the scope of the problem and the requirements indicated above are accurate? If not, why?
• Are you aware of any CSS-only solutions that would address the key requirements?
• Do you believe a JavaScript solution is suitable and if so do any of the ideas outlined above sound like they would be suitable?

[MaggieCabrera]

So, to see if I understand correctly, the problem we want to solve is when we are swapping from the desktop menu to the mobile one, or are we solving something else? Because another request that I've heard plenty of was a way to tag some blocks as mobile or desktop only since it's widespread that some elements are needed on only one of the versions of the menu.

[richtabor]

Because another request that I've heard plenty of was a way to tag some blocks as mobile or desktop only since it's widespread that some elements are needed on only one of the versions of the menu.

I don’t think that’s related. For an advanced mobile menu we should lean into the mobile template part concepts (where you design a mobile menu experience entirely).

[getdave]

@richtabor is correct. This is solely about the more "simple" use case of a single menu which adapts automatically based on its context.

[MaggieCabrera]

Of the two options you shared (and I don't think there's a CSS only alternative available), we best go with JS and probably option 1. Option 2 would require for the items to actually wrap for a second before the change to the burger menu is triggered.

[draganescu]

What exactly is the limiting factor of the current system? The menu collapses into a hamburger too soon? Or what? Do we still want to keep this overlay behavior or do we want a menu that just makes room for itself?

[richtabor]

The menu collapses into a hamburger too soon?

Or too late, if there are more items in it than horizontal space provided.

[getdave]

The limiting factor(s) is that we have a hard coded media query that doesn't account for:

• the number of items in the Nav
• how much content is used in the label for each Nav item
• the space available in the container on the Nav block

As a result the switch to "mobile" layout either happens too late or too early. If we're not going to allow users to control the specific breakpoint then the automated behaviour needs to be much more refined.

Try it out and you'll see what I mean. I will try and post a video to illustrate as I didn't do a great job on that part.

[draganescu]

Has anyone seen an example that magically behaves like we describe here? As far as I've seen all website authors manually tweak these menus and they break when new stuff appears without prep. I am unsure intrinsic is smart enough. Navigation usually:

• is placed in crammed places - so it's always constrained by some neighbouring content
• serves a decorative purpose too - so it's important how it changes, we can't just count on content reflow
• can vary from list of links to complicated trees therefore we can only employ simple solutions with as little edge cases as possible

I think as long as users can disable the mobile behavior of collapsing into a burger kebap then they're free to design whatever they want.

The fact that people ask for applying different layout and styles for breakpoints also points out to how intrinsic responsiveness is great for content but not so great for layout and decoration.

[getdave]

What would be your suggested approach?

[draganescu]

I would love control over media queries and settings that apply to specific breakpoints. Not for everything, but for some things where it makes sense to have such control. I also would think we should support both container and media queries.

[JosVelasco]

As much as I’d like everything to be automated, I think defining a field to override the breakpoint in which the block switches to mobile would be the easiest method without using javascript.
This field could appear in the advanced options of the navigation block, following the same logic as the CSS editor to hide it a little bit.
Most of the time, when you have to adjust this breakpoint is because items that were added to the navigation break it, and usually, they won’t be removed. Even if they do, having an early mobile navigation is not a big deal.

[getdave]

Thanks @JosVelasco. Do you thinking this should be using a container query rather than a media (viewport-based) query?

[JosVelasco]

Level 1: In the global styles, it could be cool to override the viewport-based query for all blocks, not just the navigation ones. For most sites, this global styles override would be enough.

Level 2: This value could be adjusted for the navigation block global styles, also view-port based.

Level 3: In the specific navigation block settings where you insert an instance, that could override the previous two values. Here we could have users select if they prefer view-port or container query.

Actually, I think offering both options, container, and media, could be a good way to introduce the concept of container queries.

[getdave]

I have had the additional thought that we need to consider the future of multi-lingual WordPress. This is stage 4 of the Gutenberg Roadmap after collaboration.

A Navigation might work well at 700px breakpoint (container or viewport query) in English but be totally broken in another more verbose language. You could make the argument that in which case you'd set an artificially low breakpoint and just allow the English site to collapse to mobile layout "earlier", but that doesn't seem ideal.

Something to consider.

[MaggieCabrera]

Agree 100%, Spanish is about 20% longer than English :D. I'm also not a great fan of magic numbers in general. Also, since we are thinking about surfacing the breakpoint value to the end user (as opposed to a solution catered to plugin/theme devs), it wouldn't make sense to add a control like that without a way they can test it within the editor. We can't assume that they are going to know how to use the browser inspector or something like that. How will they know what that magic number is for them?

[draganescu]

We'd have had html.en <specific css> as a solution with code. Without code we can try and put this in the UI or attempt to use intrinsic responsiveness that covers all possible cases. I think the first would be a better and less frustrating - albeit a tad more cumbersome experience.

[JosVelasco]

To help the user establish the magic number, we could calculate in the editor the viewport width in which the layout breaks, maybe when they save the post to avoid JS on the front end.

This approach could consider other languages, either by having a max width defined by the longest strings or a custom setting by language. The user could edit the value in the advanced settings.

We don't have the full breakpoints available, but there is a preview for small screens.

[tresorama]

It is impossibile to anticipate and so automate the "perfect" breakpoint.
The decision is up to the person who decide the menu items, and also its visual preference.
So this decision IMO require an additional attribute to the block.

Also because a template can have multiple navigation blocks, with different position in the page and different number of nav items. Because of that they potentially need different breakpoint as well. Every instance of the block need their custom value to indicate "when" to switch to mobile or desktop layout.

For the type of the attributes i think "string" in the code side, and in the UX side my idea is that the user can type:

• any number without unit , like 876, and the system assume that its a min width in pixel, min-width: 876px
• any valid CSS media condition, like max-width: 56rem , so web designer can be creative

[tresorama]

If multiple instances of a navigation block are on the same page, their base string value would be the same because the calculation could be based on the template width in which they would be displayed, leaving the option to override this value manually.

Could you re explain this?

[JosVelasco]

Why should a user input a single numeric value?
We could provide a way to determine the kind of metric the user wants to choose in a similar way in which we can select units for font sizes.

I like the idea of having a draggable preview.

What I meant for the multiple instances of a navigation block on the same page is that we could calculate the best breakpoint to suggest the user automatically, even if we insert the block in a template part. This could work for most cases as a better starting point than what we currently offer.

[tresorama]

Merging my idea with your "magic" value calculated by Wordpress is something like this interactive demo:
https://codesandbox.io/s/test-wordpress-navigation-custom-responsive-breakopint-n22l4g

Magic

Custom - Simple Number in Min-WIdth (for regular user when auto is not enough)

Custom - Free media condition (for web dev/designer)

---

Interactive DEmo

[MaggieCabrera]

We might have multiple nav blocks on the same page, but I doubt they all will have the burger menu on mobile selected for them. The majority of the time, we are looking at one burger menu per page.

[tresorama]

Yeah the majority of usage will be to have only one Navigation with the mobile layout.
But I think that bind properties to instance instead that forcing to have only a global value is more future proof.

If a site want multiple header at disposal (so different template parts) and on every page template he pick one of them , is not good having the same responsive behavior in place for every Navigation. Maybe one of the header template part contains different other block that are not Navigation that will dictate the Navigation responsive behavior to be different from an other header template part.

To give a unique identifier we can calculate a CSS class on the fly and add to the wrapper.

[scruffian]

I had a go at creating a solution that relies only on CSS: https://codepen.io/scruffian/pen/ExOzByR

This works for the most part, but the problem is that the navigation creates a horizontal scrollbar when it collapses. Maybe someone can find a way around that too...

[JosVelasco]

For a theme like Twenty Twenty Three, I just switch to a mobile hamburger with something like this. I forgot where I found the code:

@media screen and (max-width: 991px) {
/* hamburger button */
.wp-block-navigation__responsive-container-open {
display: block !important;
}

/* full menu */
.wp-block-navigation__responsive-container:not(.is-menu-open.has-modal-open) {
display: none !important;
}

} /* ends 991*/