Blocks: Consider a "passthrough" supports for nested block wrappers

[aduth]

Related: #7234, #6895, #6459

With #7234, the Columns block will consist of individual Column blocks, wherein a user can add additional content blocks. The UX of this is such that a Column has some layers of interaction, despite currently not having any options of its own (though future options may surface, including width or coloring).

Proposed in #6895 (comment) and explored with summary at #7234 (comment), it may be worth exploring adding a new block supports passthrough, which omits most of the interaction points of a block if it is not intended to be mutated directly, instead serving only as an intermediary for nested block wrapping.

I think the general idea could be fairly "simple" but not "easy" to implement, where BlockListBlock's rendering has a shortcut condition to render only the contents of its BlockCrashBoundary when it's intended to be a passthrough. This is made complicated by various event handlings, ref assignment (e.g. focusTabbable), and styling considerations (e.g. expectation of a root div with data-type, className, etc).

This should not be considered a solution for general usability of deeply nested blocks, where it may be entirely expected that the user is expected to easily navigate through many layers of blocks. There have been some discussions and iterations of this previously, such as in #6459 and #5658.

[jorgefilipecosta]

The need for this kind of blocks also arises in layout blocks #7414.

One important feature of passthrough setting is that it should be possible to set the setting from the parent block.
E.g: Columns block can enable this mode in column block. But another block that needs for example 3 columns can set the setting for Columns block itself, so in the context of that block, both columns and column are invisible.

[westonruter]

This also seems related to the use case of allowing for blocks to be layered on top of each other (z-index). For example in ampproject/amp-wp#1215 we're looking at implementing blocks for the AMP Story format, and this consists of nested structure as follows:

An amp-story-page can contain any number of amp-story-grid-layer elements, and each of those elements are stacked on the z-index, not spatially on x/y coordinates like the pages and leaf elements are (like images and paragraphs). So we anticipate needing to have controls specifically for selecting the layer to edit to be located in the sidebar when selecting an amp-story-page block, and the normal controls for moving a block should be suppressed for the layers. The layers could instead be re-ordered via the sidebar, as @jwold is in the progress of designing as follows:

I understand that navigating multiple levels of nested blocks is also a current painpoint for Gutenberg, and that is also illustrated here. In order to select a layer we're currently thinking you would have to do so via the layer list in the sidebar when selecting an amp-story-page block, and upon selecting that layer only that layer would be shown so that you could edit the blocks inside of it.

I chatted with @mtias about this and he pointed out the nested block z-index layering as also being an important ability such as for creating a presentation slide layout.

[jasmussen]

@westonruter Very much digging the idea of a layer palette in the inspector. This is definitely a solid way to show a complex structure, and worth it for a number of of blocks notably the very advanced ones.

One of the challenges we still need to address, is making it easy and simple to select the quote containing element, in a quote block that has nested paragraphs and other blocks, as this seems like such a common use case. Having to use layers in the sidebar is fine for complex blocks, but seems overly complex for the simple ones.

So in addition to a layer palette, it would be good to still think about a really easy way to select just the parent, even if not all the way, of the block that has focus.

[getdave]

@aduth Just flagging that my Columns V Align PR requires that the individual Columns are selectable

#13899

It could make anything Column specific here redundant. Just wanted to let you know.

[gziolo]

I think this is exactly what we need as discussed in #15537 and #14961 when working on improvements around nested blocks interactions. /cc @jasmussen @kjellr

[aduth]

@aduth Just flagging that my Columns V Align PR requires that the individual Columns are selectable

#13899

It could make anything Column specific here redundant. Just wanted to let you know.

There was some feedback at #15499 (comment) which in turn motivated #15660, where resizing controls for individual Column blocks were proposed to still be managed by the Columns block. While I'm not sure it applies quite as nicely in the case of vertical alignment, there may be an option to explore there if there's a desire to avoid selectable Column.

[jasmussen]

In extension of Andrews comment, I would suggest that it's worth exploring making those vertical alignment buttons surfaced in a way similar to what Andrew is suggesting, i.e. in a way that does not require selecting the individual column blocks themselves.

The "clickthrough" PR (#15537) will mitigate the difficulty, but it feels like it would still have great value to avoid having to nest too deeply if we can.

[aduth]

In starting to consider an implementation here, a question occurs to me: For these "passthrough" blocks, would it be expected that we still render all of the same standard wrapping elements of a block in the editor, or should only the inner editable element of the block be rendered?

If it's the former, then probably isn't all that hard to implement, if we disable selection by virtue of the fact that a block only becomes selected by its div being a focusable fallback.

Here's a diff to demonstrate for the Column block. This alone achieves the behavior I assume we're expecting for a passthrough block, and could be extended to any other block in the same way.

https://gist.github.com/aduth/1123fe4e7f06bfd7e95742feeda29176

If it's the latter, and we don't render these wrapping elements, do we run any risk of breaking compatibility for plugins which rely on these elements to exist? For example, I expect it's a common pattern (even within Gutenberg itself) to apply styles based on a [data-type="core/..."] CSS selector. If we go this route, that element wouldn't exist.

@jasmussen Based on your comment at #15927 (comment) , I interpret it that you're expecting something more like the second option. Do you have any thoughts on this question, given the above considerations?

[jasmussen]

For these "passthrough" blocks, would it be expected that we still render all of the same standard wrapping elements of a block in the editor, or should only the inner editable element of the block be rendered?

IMO, the fewer elements/divs, the better.

If it's the latter, and we don't render these wrapping elements, do we run any risk of breaking compatibility for plugins which rely on these elements to exist? For example, I expect it's a common pattern (even within Gutenberg itself) to apply styles based on a [data-type="core/..."] CSS selector. If we go this route, that element wouldn't exist.

Yes, that's very likely.

Based on your comment at #15927 (comment) , I interpret it that you're expecting something more like the second option. Do you have any thoughts on this question, given the above considerations?

To be perfectly clear, all that in the end matters is the user experience. The divs do present some gnarly CSS challenges presently, it's very difficult to target specific elements and only those, and rather often you end up with very very long selectors, and/or intentional overrides, in order to accomplish what you need to do. So yes, the fewer elements the better, from a CSS implementation perspective.

And consider this example, a Table block that uses nesting. You can imagine that every piece of the markup, Table, Thead, TD, TR, would be a nesting container. The tree would be unwieldy to the point that the CSS necessary to make it actually look like a table is beyond reason.

At the same time, display: contents; is on the way. That may solve it. I'm not sure.

[aduth]

Here's a diff to demonstrate for the Column block. This alone achieves the behavior I assume we're expecting for a passthrough block, and could be extended to any other block in the same way.

https://gist.github.com/aduth/1123fe4e7f06bfd7e95742feeda29176

The implementation needed to change as a result of #15537, but I've proposed this as a pull request at #16024.

[draganescu]

Reviving this a bit because of #26101 @talldan suggested the same idea for solving an interaction weirdness in the new Widgets editor, where having a widget area as a block brings benefits such as a common root client id for all widgets, but we need a way to get rid of useless UI and interaction.

[apeatling]

Also +1 on this one because it would be useful for our Premium Content block where there are two levels of innerBlocks causing this middle block UI that is not useful:

[paaljoachim]

Buzzing Shaun here as well.
@shaunandrews