Blocks in Widget Customizer: Block toolbar not visible at small screen sizes.

[talldan]

Description

This sounds like the same issue as experienced in the navigation editor (#28875), the new widget experience is missing the 'fixed' version of the toolbar.

For this screen, we may want the fixed toolbar to appear just under the fixed customizer options (cc @critterverse):

Step-by-step reproduction instructions

1. Enable the blocks in widget customizer experiment
2. Select a block in a widget area
3. Make your browser viewport small or use the responsive dev tools

Expected behaviour

The block toolbar is still visible

Actual behaviour

The block toolbar is not present

[critterverse]

Here's my take on this! I think the fixed position toolbar could appear underneath the editor "top bar" (where we have the undo/redo and inserter buttons):

Because it needs to work on narrow viewport sizes and the block toolbar “overhang” solution won’t work in this scenario, I think the most ideal approach would be to figure out a way to collapse longer block toolbars. This collapsed version could then be the default anytime there’s a fixed toolbar regardless of viewport size (including when the "View → Top toolbar" setting has been selected via the ellipses menu next to the Publish button).

What I'm thinking:

^ Anytime there's a discrete section in a toolbar with more than 2 items, that section could be collapsed down to show only the first icon and a "more" carrot. This way most toolbars will fit in a narrow viewport without having to scroll horizontally. (Still need to take a look at how the selection behavior could work when selecting "more" but one idea is that the carrot could just cycle through the available tools for that section.)

I'm also wondering if on scroll, both the editor top bar and the toolbar could act as sticky elements — meaning the Customizer navigation area could scroll as normal and disappear out of view, while the editor top bar and toolbar would lock into position underneath the Customizer top bar:

scroll.mov

Ideally, the editor top bar could behave this way in general, whether there's a fixed toolbar or not. Happy to make a new issue for the scrolling behavior if everything is making sense in this context.

[talldan]

Thanks for the awesome feedback, @critterverse.

Because it needs to work on narrow viewport sizes and the block toolbar “overhang” solution won’t work in this scenario, I think the most ideal approach would be to figure out a way to collapse longer block toolbars. This collapsed version could then be the default anytime there’s a fixed toolbar regardless of viewport size (including when the "View → Top toolbar" setting has been selected via the ellipses menu next to the Publish button).

I think there have been some prior work on making sections of the toolbar collapsible. Did some digging and there's #9075 that covers some previous work, but there might also be other issues. (cc @jasmussen)

I'm not sure on the technical feasibility, but @youknowriad recently worked on some changes to block toolbars to divide them up into logical sections, so this might be more possible now? A challenge is that plugins can add items to those parts of the toolbar, and there's no guarantee those items can be made to work both as a standalone icon button, or as an item in a dropdown.

I'm also wondering if on scroll, both the editor top bar and the toolbar could act as sticky elements — meaning the Customizer navigation area could scroll as normal and disappear out of view, while the editor top bar and toolbar would lock into position underneath the Customizer top bar:

Sounds good 👍

Ideally, the editor top bar could behave this way in general, whether there's a fixed toolbar or not. Happy to make a new issue for the scrolling behavior if everything is making sense in this context.

A separate issue would good, I think there are a few styling adjustments to make to the editor top bar as well, so I think it could be tackled as a separate restyling task.

[jasmussen]

Yep, we've been a bit back and forth on this. Both the top toolbar and the "breaking out of the box" toolbar have pros and cons, and both ultimately speak to the fact that the block editor was designed to be the canvas itself, not to be this abstracted copy shown in a sidebar.

I would agree that general efforts making the sidebar able to scale down further and collapse sections would benefit the mobile viewport as well, where while things work reasonably at the moment, if you add plugins that expand the width of the toolbars, some blocks that have already wide toolbars (like lists) become rather unwieldy. The toolbar does scroll horizontally to reveal any elided controls, but it's not ideal. So general efforts to allow the toolbar to scale, not just in context of the widget editor, definitely make sense. It's a difficult technical challenge that has been tried many times, which is why it's not solved yet, but nevertheless worth looking at. (On that note, I'm almost certain there are existing and open tickets about toolbar size/scaling).

Until the toolbar is able to collapse better, though, I'd recommend against docking the toolbar to the top in the widgets editor. Doing so causes a horizontal scrollbar, which while working reasonably on mobile due to the more natural touch/swiping gestures, does not work very well at all on the desktop.

[critterverse]

Thanks so much for these notes, @talldan and @jasmussen! This is definitely a tricky one.

Just thinking out loud but even with the floating version of the toolbar, we’ll need to account for the possibility of horizontal scrolling in a narrow viewport window, yes? Rather than trying to collapse the toolbar, I wonder if it’s worth taking a look at how to better improve the scrolling behavior since we know that's likely to occur in some instances.

Here’s how the fixed toolbar scrolls horizontally within a narrow viewport in the post editor:

Maybe there’s an opportunity to use something like a button/arrow that sits at the edges of the toolbar instead:

^ I wasn't able to find existing explorations around this on GH, although it seems likely that this discussion may have come up at some point!

Could this approach or something similar make the docked toolbar more feasible in the Customizer as a solution for narrow viewports? The overhang approach that's being implemented on the floating toolbar feels like it may be hard to solve for in this context without having the entire sidebar scroll horizontally.

[jasmussen]

The horizontal scrollbar is definitely pretty terrible for desktop interfaces. But it feels okay on mobile, in that you can grab and slide more easily than pressing/holding an arrow. The arrow could be a good idea, but notably on physical mobile devices it should probably not replace the scrolling feature. But the arrow would benefit both mobile devices and desktops with small viewports in that it would make clear there was more stuff to be seen.

An alternate discussion, way back, was an overflow menu, where items pop off into a menu, like Google Docs:

That has its own downsides, and has proven very difficult to implement.

The overhang approach that's being implemented on the floating toolbar feels like it may be hard to solve for in this context without having the entire sidebar scroll horizontally.

Can you clarify? Last I tested it worked without the need to scroll anything horizontally.

To be clear, I'm not necessarily advocating for the overhang approach (great term 👍 👍) being that elegant a solution. I'm mainly advocating for it as being the best we have at the moment, and a good holdover on the path to greater things.

[tellthemachines]

Looks like the main issue of the toolbar not showing at all on mobile is fixed in #31134. Not sure if the remaining styling issues will be fully resolved over there though, so leaving this one open for now.