More Block Tools and APIs for container blocks.

[youknowriad]

As we move forward with Full Site Editing, and explore adding customizations options to several blocks, we're starting to notice that the current APIs and interactions for container blocks are less than ideal. We might be missing some abstractions there to achieve several use-cases:

Layout

We have several blocks that are "flex containers". I'm thinking of columns, navigation, social icons, buttons. There are several common issues that are highlighted in these blocks:

• They are all styled almost similarly: A flex container with children blocks that stack inner blocks one after the other.
• Some of these blocks offer ways to define the "width" of their items.
• Most of these blocks need to disable "alignments" for their children.

Yet, all these shared properties are implemented in an Adhoc way. Styles are duplicated, width config is duplicated, ...

Alignments

This is particularly visible for FSE themes but it's a global issue. When you add a container (group block or a column block), sometimes the area is too narrow and you don't want the same alignments options available at the global level to apply. Also, if different areas of a page/template/content can have different kind of alignments (think sidebar, content area), how does a user "define" what alignments are available inside this area? How to avoid the "global alignments" styles to apply?

Nesting

This is another issue that is particularly visible in FSE but may exist elsewhere. Take a look at this screenshot.

On the side, you can see the hierarchy of the page. One thing that stands out is that there's a deep level of nesting where sometimes it might not be needed. Why the first column is not directly the "single post" template part and the second ne not the "sidebar" template part. Why do we need intermediary blocks (column) while a template part is a simple container just like column and could just replace it in some cases.

Customizations

This is another important use-case that we're starting to see as we add customization options.

• How do I change all the colors of the buttons in the "buttons" block at once? Why should I have to go to each block to apply the change? and should we store this at the leaf level or at the container level, or both?
• A lot of users are confused about alignments there, when they add a "buttons" block, the child "button" block gets selected and it's not obvious how to align the buttons (select the parent and then align).

This raises the question of surfacing common customization tools for children in the parent block and the opposite too, how to surface the parent options in the children (or if we should surface them).

--
These are some of the challenges we're facing now and solving them would improve the experience greatly.

Potential solutions

1- To solve the layout and alignment issues, I started introducing the "layout" prop to "InnerBlocks". For now, it's almost an empty bucket but the goal is that applying a given layout type to a container automatically adds the styling and the positionning and common options to their child blocks. For instance, if I set the "buttons" container as a "flex" layout, automatically, it will get a classname to style it properly and its children blocks will see the regular alignments being disabled and a "position" attribute added where you can customize the position of the child block in that particular context (for instance set a width). This same abstraction ("layout") could allow us to solve the FSE issue of defining alignments for given areas. For instance we could imagine a "grid" layout where could have ways to define "wide"/"full"/"center"/"side" alignments using grid configs and have these styles generated automatically for the containers and also available for the child blocks (saved in the "position" attribute).

2- For the solution to surface controls between parent and child blocks, we do have an experimental way of doing that but it's not ideal. I'd love some design explorations there before trying to come up with the best abstraction.

--
cc @WordPress/gutenberg-core @aristath @vindl @jameskoster @kjellr @scruffian

[scruffian]

How do I change all the colors of the buttons in the "buttons" block at once? Why should I have to go to each block to apply the change? and should we store this at the leaf level or at the container level, or both?

Or at the global level. One big concern I have with giving users so much control is that they are being empowered to make ugly sites by having slightly different settings for every block. It would be interesting to explore making the default interactions on a block modify the global styles for that block rather than the specific instance.

[jameskoster]

Why do we need intermediary blocks (column) while a template part is a simple container just like column and could just replace it in some cases

Just to note, I think the "in some cases" is quite important there. Sometimes those intermediary blocks are useful, indeed I would rely on them if I wanted to create a design like this:

[youknowriad]

@jameskoster

Just to note, I think the "in some cases" is quite important there. Sometimes those intermediary blocks are useful, indeed I would rely on them if I wanted to create a design like this:

The second column block in that screenshot is useless, why the "sidebar template part" doesn't represent that column.

[aristath]

For the layout & nesting issues, wouldn't a "grid" block as initially proposed in #18600 help? It could be used as a simple columns block, or it could take care of the whole layout from the screenshot above... If we had something like that, then it could easily accommodate most scenarios we may encounter now and in the future. A wrapper would be added only if there's multiple items in the same in the same area - in which case they'd need to be "grouped".
It can serve as an abstract block, and then the group block, columns block, and any other container-based blocks we have would extend that block. It would be a lot more consistent and we'd have a single source of truth for all these things.

It would be interesting to explore making the default interactions on a block modify the global styles for that block rather than the specific instance.

That would indeed be very interesting. It would bridge the gap the global-styles (which are only available in the site-editor) and the post-editor, and it would promote consistency. 👍

[jameskoster]

The second column block in that screenshot is useless, why the "sidebar template part" doesn't represent that column.

Fair, the second column is probably not needed, but some representation of the first column would be needed to add the different background color.

---

@aristath A richer grid block could help for sure. But I wonder if the grid/layout should be defined at the template/document level as well, perhaps via global styles? That way any block added to the document will always have some sense of consistent spacing, and creating layouts like the one above would just be a case of dragging those blocks in to position – no need for grid/column blocks.

I think @jasmussen has been looking at this.

[jasmussen]

Great ticket.

On the side, you can see the hierarchy of the page. One thing that stands out is that there's a deep level of nesting where sometimes it might not be needed. Why the first column is not directly the "single post" template part and the second ne not the "sidebar" template part. Why do we need intermediary blocks (column) while a template part is a simple container just like column and could just replace it in some cases.

Beautiful articulation, and I strongly agree — the more containers we can "abstract away" or make invisible, the better. While it's important to improve the select-parent flow, simply removing parents is a sure-fire way of improving this. I recall discussing how to build a better Table block with @talldan recently, and he had some great ideas on that.

This raises the question of surfacing common customization tools for children in the parent block and the opposite too, how to surface the parent options in the children (or if we should surface them).

There's a separate ticket for exploring improvements to selecting the parent block in #26313, and I shared some initial work in a comment #26313 (comment):

Those two mockups target the canvas experience at a high level.

With regards to showing child sidebar(s) when a parent is selected, vs. showing parent sidebars when a child is seleced, this is really tricky as you might have, well in a gnarly case, tens of different child blocks inside a group, and showing them all is tricky. But to get the ball rolling, here's a mockup showing a Cover block with a Paragraph inside, and how you might use the sidebar to go back and forth between them:

I'm not 100% feeling it, but I think it might serve to enable better ideas. The problem is, I don't think we can ever show all the sidebars stacked on top of each other — we have to collapse either the parent or the child, and at that point we might just as well select the parent and/or child when expanding them.

I took a little bit of inspiration from Figma on this, where selecting the parent you can see the "styles" of child elements:

See also how when there are more than n children, some of them are collapsed.

Also note, some of the sidebar work here is inspired by #27331.

[overclokk]

Inner containers is a problem I also highlighted here #29228

[luisherranz]

How do I change all the colors of the buttons in the "buttons" block at once? Why should I have to go to each block to apply the change? and should we store this at the leaf level or at the container level, or both?

I was thinking that if we allow any block to become a section capable of overwriting the global styles of their children (as described in #39281), then the question of how to apply the same style to all the button blocks at once pretty much disappears (issues like this or this). Actually, draging and dropping a button block from one set of buttons to another will automatically change its style (it will match its new siblings).

[mtias]

Yep, it could have a series of neat cascading effects.

[mtias]

@youknowriad do you think we can close this? It seems other issue are more relevant these days.

[youknowriad]

Yes, I'm going to close this. Personally I think the missing thing is the "unification" of the position attribute. I've expanded here though. So let's close in favor of this one #8288 (comment)