Nested blocks present many challenges. Any block can add as many nesting levels as they like. Tickets #17089 and #17088 have been created to improve the general tools to work with nesting layers.

However in some situations, you might want the benefits of child blocks — ability to insert and remove with generic tools, use movers and drag and drop to rearrange — but without the additional clunkiness of the block UI surrounding every single block. This concept is also somewhat related to, or can subsume, #7694.

The basic gist is inspired by the following idea from a conversation on the navigation menu block by @matias:

One idea I have for simplifying toolbar handling in nested contexts is to optionally allow an inner block container to say that it wants to absorb the toolbar of all the children. In those cases, selecting a child block within that area would change the toolbar content but it would be positioned at the level of the parent. This could be really useful for the navigation menu block, as selecting different items would remain coherent while offering specific tools for the right contexts.

Let's break that down:

• Blocks, when selected, have a border all around them, a block toolbar, and the mover tool.
• The benefit of using child blocks is that you are given these tools (inserting, deleting, rearranging) for "free"
• In some space-constrained contexts, much of that UI is clunky, heavy, and actually gets in the way.
• By allowing a child block container to absorb the UI of child blocks, block authors can provide a refined experience where appropariate.

In #16897, we are currently emulating this behavior:

That block adds some CSS to minimize the UI of child blocks, so the experience of customizing the list of social links can be as comfortable as it would be had it not used nesting, but still letting us maintain the benefits of child blocks. Specifically the CSS:

• Resets margins and paddings on innerblock containers and children.
• Hides the block outlines on the selected child block, and relies on the parent outline, currently a dashed border, to indicate which block group you are editing.
• Hides hover breadcrumbs.
• Hides the mover.

In practice this is working very well for the Social Links block, and I encourage anyone to try it as a good prototype for how this ticket could be addressed. However it is also hacky for each block to provide their own CSS to do this, when a prop could provide it in a generic way for any block that opts in.

A more generic approach would be to:

1. Make it so no margins or paddings (that are necessary for normal blocks to space themselves on the canvas) are applied, so no need to unset them.
2. In extension of 1, right now every [data-block] is born with intrinsic top and bottom margins. These would not be applied to an innerblock container with this prop.
3. No hover breadcrumbs would be output in the DOM.
4. The movers would be present in a design that is appropriate for child blocks. One idea for that is outlined here, and Navigation block: Add horizontal movers #16637 would also benefit this.

Blocks that could benefit from such a more minimal UI for child blocks include the Social Links block, the Navigation Menu block, potentially a Buttons block. Maybe even in situations like the Columns block, you might want to appy the prop to the top nesting level, so the child block UI for the immediate column block was less clunky.

Please share your thoughts.