This is impressive work. Thank you for doing this. For every div you remove, the closer we get to being able to make the table block use InnerBlocks :)

At a glance, this looks to behave the same as master does, even when it comes to floats:

I did notice an issue with embeds that have long captions, but this issue is present in master also, so not an issue with this branch:

However it seems like drag and drop broke. Master:

This branch:

Also noticed a few of the more complex blocks looking different. Columns in this branch:

In master:

Looks like the main difficulty here is the block movers, so we should either wait for them to be popovered or for them to move to the contextual toolbar.

The previous issues are now fixed!

Very excited for this PR! Great work.

I'm seeing a few small things:

Here's a cover image with a background:

Master:

It looks as though in this branch, the block borders are closer to the content itself (the text is centered).

Reusable blocks inside a cover seem to confirm that:

The issue looks to be the same inside columns:

So it looks like the remaining issue is related the the postion of block active borders in nested blocks. It sure would make things easier if the efforts in #18667 were closer, but until they are, I think we have to be careful to keep the current experience as is.

@jasmussen It looks like the lines I removed in 4df9d1e were causing the issue. These CSS rules seem outdated, as it mentions a hover line and setting menu. Do you think they are safe to remove? They are only applied to root blocks, so it would be good to make the experience more consistent.

It looks like the lines I removed in 4df9d1e were causing the issue. These CSS rules seem outdated, as it mentions a hover line and setting menu. Do you think they are safe to remove? They are only applied to root blocks, so it would be good to make the experience more consistent.

As a quick sanity check, yes, the branch now appears to work as it should! Nice work.

To your question — yes those rules are outdated and needs a fresh look. Can we remove them? It looks like things are working fine without them, so probably yes.

Back in earlier versions, the mover control on the left would appear on hover, even on an unselected block. The same would happen for the settings menu, the ellipsis button, which back then was not part of the block toolbar. In order to make these accessible when just on hovering the block, the block had to be widerto accommodate this. Since both of those controls are now available on click instead, this is no longer an issue.

I suppose the only thing to look for is the blue line that indicates where a block will be inserted when hovering in the block library:

And this blue line could use some love, it doesn't appear to work with nested blocks. But this is a non urgent separate issue that is not the result of this branch.

@jasmussen Ah, that blue line... 😅 I'll have a thorough look at that sometime soon. It's a bit related to the sibling/in-between inserters as it should have the same position. This is all certainly on my to-do list.

Don't take too much on your todo list! It's something we'll get to!

The branch should now be good. I tested all updated blocks, all blocks states and alignments.

I tried out the branch and everything seems to be working fine. 🙂

Thanks for the reviews and help!

I guess this could have some impact (probably good impact) on theming Gutenberg. I feel it deserves a dev note?

Definitely. Hopefully by that time there's more improvements to talk about as a whole.

A beginning draft of a dev note, which I expect you all to discard or correct 😄

In effort to make it easier to style blocks, efforts are underway to reduce the amount of HTML nodes in the DOM. #19010 removes the wrapper element labelled block-editor-block-list__block-edit, and more efforts will hopefully follow. With less HTML it should be easier to target the nodes you mean to, and make blocks look the same in the editor as in the frontend.