Some legacy widgets don't fit in the customizer block editor

[draganescu]

Description

Some widgets, such as most of the ones provided by the Site Origin bundle, don't fit in the thin sidebar of the customizer block editor. Previously, before we had a block editor these widgets would show their edit form in the Customizer's drawer.

Block widgets

[draganescu]

There are three ideas "floating" around how to solve this problem:

1. add the ability to resize the sidebar by dragging it
2. add an expand button that just places a large modal on top of everything with the contents of the sidebar in it
3. add a toggle that alternates the ratio between sidebar and preview

All three have +/- arguments going for them. I am here to argue talk about (3) because I think it's a quick solution that:

• solves the problem
• does not imply changing the customzier behavior in general
• is quick and possible to implement
• keeps the original UX, without introducing new modes

[critterverse]

Hey all, I think there may be a simpler approach that won’t require new UI or major reconfigurations the Customizer sidebar — we could follow the same logic as the block toolbar overhang approach, and let wider legacy widgets overlap the preview area:

wide-legacy-widgets.mov

Extra large widgets work in a somewhat similar way on the legacy Widgets screen, so hopefully this will feel familiar to users:

Notes:

• The oversized legacy widgets can be in their own scrolling container, separate from the legacy widget block container.
• There could be a max height for the oversized container of about 50% of the visible editing canvas (the height of the actual block container behind it is somewhat arbitrary but maybe 50% of the larger container height).
• I think we should consider putting a 10% opacity black overlay over the preview area when editing one of the larger legacy widgets and use the default “popover” shadow to help it stand out against the preview window.
• If the legacy widget is edited from a position lower in the viewport window, the sidebar contents could scroll to create space for the height of the container.
• Also wondering if the legacy widget should change from editing mode to preview mode for any scroll that happens on the sidebar itself

For narrow viewport sizes/mobile browsers (could use a gut check/confirmation of the expected behavior here):

• If legacy widgets have been built responsively, they will respond down to an appropriate mobile layout at this screen size (Is this correct? For example, the SiteOrigin widgets)
• Legacy widgets that don't scale nicely may need to be able to scroll horizontally on small screen sizes

[noisysocks]

Worth noting that widgets already have an is_wide attribute which is set during registration. We can have it so that the overhang in #31194 (comment) only happens when is_wide is set.

[kevin940726]

@critterverse Very cool! A few questions:

1. What happens if we scroll the block editor when the legacy widget is active? I would assume that it would follow along with the block, but then we have to decide the z-index of the "popup", should it be above or beneath the section title for instance.
2. 50% of the height seems reasonable, but I think maybe we should also have a min-height so that small screens can still have enough spaces to edit the legacy widget.
3. What's the accessibility story of it? I think it's pretty much like a modal, so maybe follow most if not all requirements of a modal? e.g. Focus trap, closing upon pressing esc. We probably don't want to block scrolling for the parent element though.

[critterverse]

These are great questions, thanks @kevin940726!

What happens if we scroll the block editor when the legacy widget is active?

I wonder if we should flip the legacy widget back over from editing mode to preview mode for any scroll activity that happens within the editor. Might need to play around with this in the PR but I think this would feel ok!

What's the accessibility story of it? I think it's pretty much like a modal, so maybe follow most if not all requirements of a modal?

The modal treatment sounds good:

• Let's try it with the focus trap
• We probably don't want to block scrolling for the parent element though — agree, let’s not do this

Thinking outloud about pressing Esc to close in the context of the Customizer (relevant to editing mode for all legacy widgets, including the oversized ones):

• Normally in the block editor, pressing Esc will activate Select mode. But the default behavior for pressing Esc in the Customizer is to back out one level to the previous screen/menu
• For legacy widgets, Esc switches to Select mode and switches the widget from editing mode to preview mode (implemented in Implement Legacy Widget design iterations #30889)
• Currently in the Customizer, the Esc key is trying to do all of the above when editing a legacy widget — could we make it so that pressing Esc activates Select mode and switches to the widget preview, but doesn't take you back a screen?
• We might need to make a similar adjustment for pressing Enter when trying to switch back from the editor Select mode to Edit mode

Maybe more generally, the behavior could be...

• If you have a block selected, Esc and Enter toggles between Select and Edit mode (default editor behavior)
• If you don’t have a block selected, Esc and Enter takes you back a screen (default Customizer behavior)

Am I missing any other considerations here? Some of this keyboard behavior goes beyond the scope of this issue — let me know if a separate one would be better 😅

[tellthemachines]

The modal treatment sounds good:
Let's try it with the focus trap

I'm not sure about this. In the old customizer widget section, tabbing through an oversized widget takes us out and into the next widget, and opening the next widget closes the previous one. A focus trap will completely change that behaviour, and the overhanging widget doesn't look much like a modal so it won't be expected that it behave like one.

On the other hand, testing with keyboard in the new customizer widgets with one of the SiteOrigin widgets that embeds a tinymce editor, I can't get from inside tinymce to the rest of the widget controls, or from there to the next block, so there's definitely some improvement needed in that area 😅

Some of this keyboard behavior goes beyond the scope of this issue

Esc key behaviour sounds like a good candidate for a new issue. In any case, thanks for thinking it through @critterverse !

[critterverse]

In the old customizer widget section, tabbing through an oversized widget takes us out and into the next widget and opening the next widget closes the previous one.

This is a helpful reference, thanks @tellthemachines. I'm having troubling imagining exactly how this would feel on the new screen (which has a few extra variables like the toggle between Editing/Preview modes and having blocks interspersed throughout). But I might be overcomplicating it — I think it's worth trying your suggestion to see how it feels 😁

Also opened a new issue to look at Esc and Enter behavior in #31730!