Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

jasmussen opened this issue Aug 30, 2019 · 6 comments


Copy link

commented Aug 30, 2019

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:

social links

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 #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.


This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2019

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



This comment has been minimized.

Copy link

commented Sep 3, 2019

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.


This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2019

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?


This comment has been minimized.

Copy link

commented Sep 7, 2019

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


This comment has been minimized.

Copy link

commented Oct 1, 2019

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

Navigation Block Child Block

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


This comment has been minimized.

Copy link

commented Oct 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.