Nested Blocks: Provide container block prop to absorb child block UI

[jasmussen]

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.

[jasmussen]

Here's a quick doodle on how it could look when the parent block absorbed the child block UI for Social Links:

[chrisvanpatten]

I love this, with the caveat of course that it does depend on block developers to provide ample visual evidence of a "selected" state on child blocks, which is likely a concern for accessibility. One advantage of the 'standard' approach is that the visuals of the selected state (the border) are handled by the editor itself, and not up to the developer.

[jasmussen]

That's a great observation Chris. It seems like for starters it's worth exploring visually how it might look if the editor still provided a "selected block" style. We want to make sure that it's a design that does not require paddings and margins like the current selected block style does, but within those boundaries it should be possible?

[karmatosed]

I really like this and would encourage exploring the selected block style too.

[shaunandrews]

Yes, please. I've stolen this for the work on the Navigation block in #17544

I did change the selected state for child blocks, opting to use a single pixel border similar to a standard selected block.

[pablohoneyhoney]

If enough visual evidence/feedback with the interaction, maybe we don't need to move/slide the toolbar at all, keeping more consistency of the block UI per se.

[mtias]

Somewhat related to this, making it easier to spot a child block vs the parent, and letting users select the parent from the toolbar flow:

[ZebulanStanphill]

@mtias That mockup looks cool, but the purpose of the floating button seems rather ambiguous; if you didn't tell me it was the button to select the parent block, I'd be confused.

[mtias]

Yes, this is something that I'm curious to see in practice because previous attempts have not quite hit the mark. Some aspects that are crucial for this interface element to work:

• Needs to reflect one-level hierarchy.
• Needs to build on the block type as an anchor.
• Needs to be close by to the child block type icon for selection.
• Needs to feel an extension of the toolbar while not interfering with what belongs to the child block.

For example, the navigation block could combine this with the docked toolbar to always give easy access to the parent:

[paaljoachim]

Regarding nesting.
When going into a child/nested block a new icon can show up that gives the signal that one is in a nested block.

I have made a wireframe where I switched out the existing toolbar and placed a paragraph block toolbar (took a screenshot of the visuals of the new toolbar I found). I am still keeping the border around the block as it shows the boundaries of the area one is working within. Having a border also gives a constraint showing the user what is being affected.

I added an icon bottom left of the block to give an obvious visual signal that this is a nested block one is working within. NB. The icon is not there when the parent is selected. As it only shows up when within a nested block.

By clicking the icon one goes upward one step and will end up back at the parent block. Btw clicking outside a nested block should also automatically select the parent block.

[ZebulanStanphill]

@mtias Now that I've seen the slide-out G2 movers in action in #20056, your mockup has grown on me quite a bit. One issue I see with the design, however, is how it would work for keyboard users. What is the tab order?

@paaljoachim

Btw clicking outside a nested block should also automatically select the parent block.

I disagree. Clicking outside a nested block should put your focus... well, wherever you clicked.

I also think a button to select the immediate parent of the selected block should be placed somewhere in the block toolbar. The ellipsis (and movers in G2) were moved there for a reason. Having it placed on the left or right block borders would complicate the UI again.

[paaljoachim]

@ZebulanStanphill

I also think a button to select the immediate parent of the selected block should be placed somewhere in the block toolbar.

We could place it beside the mover icons, so that the mover and select parent icon show up on hover.

[ZebulanStanphill]

@paaljoachim That's more or less what the mockup by @mtias depicts. I was not initially a fan of that mockup, but it's grown on me lately. I think from both a visual and DOM order standpoint, it probably makes more sense to put that control there than it does to put the sibling inserter there (which is the current behavior in master). In other words, you would shift-tab from the movers to get to the select-parent button. Unlike the current hidden hidden tabbable above-block inserter, however, the select-parent button would appear the same way as the movers; it would appear when hovering/focusing the block icon or the movers.

As for the hidden inserter that's currently there, I think it should be overhauled and moved to a different location. See #13571.

[shaunandrews]

Took a first pass at the parent selector over here: #21056

[jasmussen]

As far as I can tell, this ticket can actually be closed because the navigation block now uses this prop.

We can reopen if this was closed in error!