Boot package: A black area appears below the content when the sidebar height is greater than the page content height.

[shimotmk]

Description

Related:
#75339
#75231

This occurs on the Fonts and Connectors pages of the Boot package.

Step-by-step reproduction instructions

1. Go to Connectors page.
2. Narrow the browser height until the sidebar is hidden.
3. When you scroll the content, a black area appears below the content.

Screenshots, screen recording, code snippet

boot.mp4

Environment info

• WordPress 7.0-beta5

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[sandipmaurya2611]

Hi @shimotmk, I'd like to work on this issue. Could you please assign it to me? I'll start investigating and will update here.

[im3dabasia]

@sandipmaurya2611, thanks for your interest! Feel free to start working on it and open a PR referencing this issue. It will get automatically assigned once referenced, so you don’t have to wait for assignment.

[sandipmaurya2611]

Thanks @im3dabasia! I'll start working on it and open a PR soon.

[shimotmk]

The site editor has different scroll regions for the sidebar and the content.

When resolving this issue, I think it would be better to get feedback on whether to implement a different scrolling system or to make the sidebar scroll in conjunction with the content scroll.

Perhaps design feedback is needed.

For your reference, here's a screencast of the pattern page.

site-editor.mp4

[sandipmaurya2611]

Thanks for the feedback! I understand now that this is a design decision.

Hi design team (@jameskoster, @jasmussen, @mapk, @mikachan) – could you please provide your input? There are two approaches:

Implement a different scrolling system

Make the sidebar scroll with the content

Which one would be better from a user experience (UX) perspective? I'm happy to implement whichever approach is decided.

Thanks!

[jasmussen]

Ah yes, this brings me back to the last time we had this exact same issue. What we found there was that we cannot allow the left sidebar to scroll independently (at least in the current implementation), because it adds flyout menus on hover that would be cropped if overflow was applied.

How this has been solved in the past was to allow the html element to continue being scrolled, as is the case today, but employ fixed/sticky/full-height flex behaviors on the frame element, and allow it to scroll independently. The implementation here is important, I recall it being fiddly in the past, so be sure to check across every breakpoint to get it right!

[sandipmaurya2611]

Thanks @jasmussen for the detailed technical context! I really appreciate you explaining the history with flyout menus and why independent scrolling was avoided earlier.

I understand now that this needs careful implementation to avoid breaking the flyout menus. I'll wait for the final design decision from the team on which approach to take (different scrolling system vs making sidebar scroll with content).

Once the design direction is confirmed, I'm ready to implement it and test across all breakpoints as suggested.

Thanks everyone for your guidance!

[jasmussen]

Absent any other feedback from designers, feel free to take a stab with the directions I gave above: default scrolling for everything but what's inside the frame, which is then placed in a way that makes it always sit in the same space on the screen. 👍