Refactor the layout component to separate the UI from the content.

[youknowriad]

While working on #17838 I noticed that it's very hard to work on the Layout of the Editor.

The fact is there are so many things to think about:

• mobile
• fullscreen
• with or without sidebar
• WP admin header height changing
  ...

These create different constraints that are spread across different components in our code base and also mixed with a lot of unrelated items.

In this PR, I'm basically splitting the UI and the editor regions out of the Layout component. The idea is that the new EditorRegions takes care of how things are displayed on the screen (sidebar, main area, header, footer), gives a name and enable aria region navigation for these different areas and the Layout component fills the different regions for content.

A nice side effect here is that all these layouting constraints are now constraint in a single stylesheet making it very easy to maintain and reason about.

This change may have some impacts on classNames, zIndex, browsers so it needs to be tested properly but I'm hoping that it makes our code way more manageable.

The new EditorRegions component can also be easily made more flexible (allowing different names for the regions) and shared with other screens (Widgets...)

Thoughts?

[jasmussen]

This seems very solid. Works well for me in all horizontal breakpoints, with and without sidebar. However there are a couple of issues to solve, first one is easy:

Fullscreen has extra topmargin.

Another small one is the sidebar doesn't extend to the bottom:

The bigger issue is related to the navigation sidebar, and is visible in a number of situations:

1. If the user has a lot of plugins installed that add top level menus
2. If the user has a small screen (11 or 13 inch)
3. If the user prefers a not-so-high viewport

The left sidebar does not scroll.

This is a frustrating issue, because you'd think you could just add overflow: auto; to the navigation pane and let that scroll when necessary. Unfortunately this would prevent the flyout menus from working:

Which means there are only really two ways of fixing allowing the left menu to have flyouts, and scroll. One solution is in master currently, and it works by allowing you to scroll the html element naturally, and then overlaying the entire Gutenberg window with position: fixed;. This is what's causing the double scrollbars — the right most is for the HTML content, the innermost is for the sidebar or the editing canvas if the sidebar is toggled off:

This is not a very elegant solution, but the only other solution is to refactor the left navigation menu to not use flyouts, such as is proposed in https://core.trac.wordpress.org/ticket/47012.

[jasmussen]

The scrollbar issue seems to have been fixed!

One more issue, I'm seeing a z-index issue on the mobile breakpoints:

The content is above the editor bar. But the good news is, the viewport scrolls correctly on mobile! Well done.

I think this is ready for wider review.

[mtias]

This seems to be working well and generally makes sense to me. The set of structural dependencies looks a bit weird, though — should the sidebar, header, footer components be moved within editor-regions? Do we expect these components to ever be used outside of an editor regions wrapper?

I could imagine possibly making our exports reflect the dependency: EditorRegion.Header.

[youknowriad]

So yeah, right now the EditorRegions component is editor specific and contains the aria region names. Ideally, it becomes more flexible to allow it to be used outside the edit-post context (say edit-widgets...).

I think this PR is the first step in that direction, the API to make it more generic can be thought of separately.

[mtias]

Let's test this as soon as possible to detect any possible regressions.

[jasmussen]

I think this may have caused a small regression with TwentyTwenty, and other themes that use a different background color than white:

The div is no longer full-height:

I'll leave a couple of code comments that I think may be the cause.

[jasmussen]

This one could be the cause of #18044 (comment).

[jasmussen]

This CSS appears to fix the issue:

.edit-post-visual-editor {
	height: 100%;
}

But this div also happens to be editor-styles-wrapper, and I'm not sure any heights should be applied there?

[youknowriad]

This seems like a good fix to me, It was like that before so I don't see a reason for it to be a problem.

[jasmussen]

Want me to PR?

[jasmussen]

PR'ed: #18687

[youknowriad]

Thank you

[jasmussen]

I think this PR might have regressed the z-index location. It's now in the top left corner:

However #18732 might fix it.

[youknowriad]

It's already fixed in master

[aduth]

Is it necessary that className be applied on both the FocusReturnProvider and EditorRegions elements?

[youknowriad]

No, it's unintentional

[youknowriad]

#18967