I love the purpose of this PR. Outside of making the DOM simpler (which vastly simplifies block editor block styling), it solves numerous issues where the toolbar is cropped in nested contexts, or just weirdly offset to the right. This is not counting all the other benefits you mention.

If we could get the PR to a state where basically everything looks the same in the branch as it does in master, just with cleaner DOM, this would be great to ship.

Future improvements could inform efforts in #18667.

Right, I'll work on making everything look the same.

• I need to adjust Popover with some more positioning options.
• Make sure Popover repositions smoothly on scroll. Fixed
• Test on mobile and different screen sizes.
• Use Popover for the insertion points and buttons.

It does not necessarily need to be 100% accurate, and please let me know if you'd like me to do some of the heavy CSS lifting.

@jasmussen Thanks! I'm pretty sure I'll need your help to clean up the CSS. I'll let you know when it's otherwise done.

Nice! One possible benefit of this change is that it could make #7962 easier to fix.

Some things I've noticed on this branch (I know it's WIP; just posting to point them out):

• Drag-and-drop is broken.
• When scrolling, the block toolbar lags behind slightly. I'm not sure if there's any way to fix this without reducing performance, and it isn't really that important, but I do kind of miss the buttery smooth movement of the current toolbar.
• Similar to the previous issue: when changing selection from a block that has a short block inspector to another block that has an inspector tall enough to create a scroll bar, the block toolbar appears and then a moment later shifts to the left slightly due to the scroll bar shrinking the editor canvas slightly.

I fixed drag and drop of blocks.
The scrolling issues can be fixed.

What a journey!

First:

The only thing I'm not sure if I can get to work is drag and drop, because the drag handle is in a popover. If it were the block itself it would be easier.

... and then shortly after:

I fixed drag and drop of blocks.

You should get a medal. 🥇

@jasmussen Turned out one line was blocking drag 😅

There's a small remaining glitch with the toolbar that only happens in Chrome in some conditions. It happens when the content area is an odd number of pixels and as a result, in Chrome only, the reported block position and actual position have a difference of half a pixel, causing the toolbar position to be off by half a pixel.

Okay, I took everything for a last round of testing.

I ensured that:

• The toolbar is rendered and positioned correctly for:
  • All alignments (none, left, right, wide, and full)
  • Multi-selection
  • Nested blocks
  • Different screen sizes
  • RTL
  • Chrome, Safari, Firefox, Edge and IE11
• It doesn't affect the mobile block toolbar
• Moving blocks happens smoothly
• Scrolling is smooth
• Popovers anchored within the toolbar are positioned correctly
• Other popovers have no regressions
• You can drag and drop a block
• You can tab in and out of the toolbar
• Alt+F10 works

If I missed anything, I’ll fix it in a follow-up PR.

To recap, this PR puts the block controls (contextual toolbar and movers) in a popover.

• It fixes sticky positioning for multiple selected blocks.
• It reduces the amount of CSS needed to position the toolbar.
• It allows us to position the toolbar better for narrow blocks. I have not done this yet as the movers still visually appear at the side of the block.
• It’s a big step towards lightening the block DOM, which eventually will help theme authors, remove our alignment hacks, and could allow us to nest blocks that need a semantic relationship.

This PR introduces some unstable props on Popover, allowing us to figure out how to best stabilise this as the use of Popover grows. This PR has already brought many fixes to Popover benefitting all uses elsewhere.

Congrats on getting this merged in @ellatrix — super excited to see what kinds of improvements this unlocks! 👏

One of the unfortunate consequences of this change is that attempting to scroll the page while the cursor is atop the block toolbar will not scroll the block list. It's because the DOM hierarchy of the toolbar is no longer the same as the block list.

In others instances, it might be the sort of thing we could use pointer-events: none to allow the scroll event to occur on whatever is behind the element. However, this would of course conflict with how the cursor should interact with toolbar items.

If I recall correctly, this implementation had customized where the slot rendered in the page. Is that right? Is it the sort of thing where we can be more intentional with rendering it as part of the scrollable block list, in order to address the issue?

It's intentionally outside the scrollable container, so maybe in the future it can be unified with the top toolbar and so maybe the scrollable container can be iframed. Of course it's not nice that you cannot scroll while over a toolbar... :/ I can't immediately think of a solution.

Worth also noting that since the introduction of the first "popover" implementation, the accessibility team feedback pointed out it's a pattern that's far from ideal for accessibility.

We always pointed out that parts of the UI that "appear" after some user action should be in close proximity in the DOM with the control that was activated. For example: click a button, a menu opens, the menu should be immediately after the button in the DOM.

Keeping moving important UIs far, far, away in the DOM is far from ideal for accessibility, even if focus is programmatically handled.

Add to that this is also breaking a native, fundamental, browser feature like scrolling a page and it is pretty obvious any accessibility specialist can't support this change.