Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Nested Blocks: Provide container block prop to absorb child block UI #17267
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:
Let's break that down:
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:
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:
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.
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.
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?