Customizer Widgets top chrome: scroll away and return on reverse scroll

[critterverse]

Hi all, this issue is for discussing the treatment of the top chrome within the Customizer Widgets editor. There are several bars along the top area that all have individual behaviors:

There have been various attempts to find a solution for how these top bars might behave in relation to one another in #31589 and #30912. I've opened a new bug fix issue in #32060 to address conflicts arising from the scroll behavior on the Customizer description container.

As a long-term solution, we could treat the editor top bar as a sticky bar that sits underneath the Customizer top bar. One way we could achieve this is by having the entire top chrome scroll away out of view, and then the Customizer top bar and editor top bar could come back into view on reverse scroll. (If you scroll all the way to the top, everything would come back as normal):

customizer-scroll.mov

This would resolve some of the issues we are running into currently with the Customizer top bar and longer block toolbars overlapping awkwardly. But this could be a bigger change as it would require revisiting the scroll behavior for the floating block toolbar, which anchors itself to the top of the scroll container while the selected block is passing in or out of view.

(Hat tip to @shaunandrews for helping brainstorm this solution!)

[kevin940726]

The scrollbar sits inside the sidebar content area, the customizer top bar is not a part of it. I can't picture how it will work when slowly scrolling down and hiding the customizer top bar. In my imagination it could be a little bit counter-intuitive 🤔.

[critterverse]

Thanks for taking a look at this @kevin940726! From a design standpoint, I don't think it would be problematic to move the Customizer top bar inside of the scrollable content area. This is how I’ve typically seen the “scroll up” header bar treatment work on desktop.

IMO, there are some drawbacks but this still seems like an improvement over the current overlapping behavior between the top bar and block toolbar.

We may also need to make a similar adjustment to the (very inconvenient) “recent autosave” notice that appears outside of the scrollable content container 🙃

Agree that imagination and Figma prototypes can only help so much here, so a PR will definitely help with proof of concept!

[kevin940726]

Sounds good to me! I'll make a prototype PR and play with it a little bit then 👍.

[kevin940726]

@critterverse This is what I have now:

Kapture.2021-06-04.at.21.41.18.mp4

It works great when scrolling down, but not so much when scrolling up. The issue of floating toolbar overlapping the editor top bar and the customizer top bar is still happening. Am I misunderstanding something here 🤔?

[critterverse]

This looks like a similar issue that we were running into with the initial explorations around this, which I believe has to do with modifying how the block toolbar anchors to the selected block while it is passing in or out of view at the upper boundary of the scroll container (sorry if I'm repeating things you are already taking a look at, it's hard to get a close read from video 😅 )

I think we may need a special provision for the way that the block toolbar is anchored when the two top bars reappear, i.e. an awareness that the “top edge” the toolbar gets anchored to is fluid (moving up and down). So the overlap you see at :16 and :19 when the top bars start to reappear from the top edge would look more like this:

Does that seem like something that could work?

[stokesman]

Howdy folks 👋 ,
I've made #32490 as a look at how we might get all these bars playing together nicely. It keeps the the customizer top bar as is and instead confines the floating toolbars to the editor/canvas. See that PR for a screen recording. Also it's testable with gutenberg.run if anyone would care to take it for a spin.

[kevin940726]

@stokesman That is awesome! My concern about that draft PR is probably that the block toolbar will stay visible even if we scroll down pass the block. This is not happening in the post editor, and could unfortunately be seen as a bug. I'm not strongly against it though if @critterverse think it's a better trade-off.

Does that seem like something that could work?

In theory I think it could work, but it probably requires adding/refactoring some internal code used in the <Popover> component, which is kind of a mess now and hard to maintain already.

There're some discussions about refactoring and changing the internal of the <Popover> component, but unfortunately it's a lot of work and nothing has been done lately. With that in mind though, I would suggest to not adding new features to that component or it will become harder and harder to maintain or migrate away from.

I'll do some experiments on how we can solve this using more "hackier" approaches and see where it goes. If anyone has any cool ideas, please share :)!

[critterverse]

Agree that the proposal from @stokesman is super interesting but I was spotting the same issue that you mentioned, @kevin940726 — I think it might be confusing to see the toolbar appear over other blocks after the selected block has scrolled out of view. Granted, this is how the fixed toolbar works — but the fixed toolbar is a bit more separate so it doesn’t seem like as much of an issue there.

I'll do some experiments on how we can solve this using more "hackier" approaches and see where it goes.

Totally on board with the "see where it goes" approach 😆 Thank you for exploring @kevin940726, and just let us know if you reach a point where the existing/known issues are making this proposal unworkable!

[stokesman]

Thanks @kevin940726 🙇

…probably requires adding/refactoring some internal code used in the component, which is kind of a mess now and hard to maintain already.

Agreed and it'd be rad to see you find an alternative. As a fallback, for a just the sticky top position offset, the changes to Popover can be pretty light. Merely plumbing it through BlockTools -> BlockPopover ends up the greater part of additions.

I'd be glad to take your branch for a spin so please ping me if you push it.

[kevin940726]

@critterverse After thinking and trying it for a bit more, I think the approach in this PR won't work, at least not perfectly 😅

Kapture.2021-06-10.at.15.11.41.mp4

Notice the very end of the video, when scrolling up, the customizer top bar and the editor top bar will appear first, meaning they will cover up the block toolbar. I think this is a smaller issue though and I think it could be considered acceptable? No matter how we do it, this issue is still gonna be there. TBH, I'm not even sure if there's a solution for this 😞.

[critterverse]

No worries @kevin940726 — thank you so much for investigating and trying to make it work 🙏

Left some notes over in #32490!

[kevin940726]

I wonder if we can just do something like this to dim the toolbar when it's out of view?

Kapture.2021-06-11.at.13.17.57.mp4

[critterverse]

There was also another approach (previously explored in #32062) where the block toolbar could go in front of the header bar rather than behind, as is happening currently with the footer controls at the bottom of the sidebar:

119018425-0f578d00-b96a-11eb-93d0-9da134d869ee.mov

toolbar-scroll-footer.mov

Would be good to see which of these approaches works better in combo with the sticky editor bar in #32490!

[noisysocks]

👋 @kevin940726 @critterverse: Where did we get to with this? Just doing some triage of the widgets issues and wondering if this is actionable or if we can close it.

[critterverse]

This one was a doozy but I think we landed on a pretty good solution in #32490. Would still love to see that approach implemented (although I can't recall if there were still any technical considerations to be worked out).

[noisysocks]

Cool. I'll link #32490 as closing this issue.

[jordesign]

Sounds like this one can be closed now 👍