Flex Layout Iterations

[youknowriad]

In #33359 we added the possibility for blocks to support multiple layouts: the default "flow" layout and the new "Flex" layout. In the future, we'll be also introducing other layouts like "Grid" or "Absolute positioning container"...

What is a layout?

A layout is a configuration you apply to a container block that changes how its inner blocks are aligned, and also impacts the behavior of these inner blocks (enable/disable some customization options). Right now, we have two types of "layouts" we can apply to container blocks:

• Flow layout: This is the default behavior in HTML, meaning if you apply this to a container block, its children are rendered one after the other vertically without any specific CSS styles (it works just like adding divs inside divs). Blocks inside a flow container can be left/right aligned (float) and in this type of layout, you have the possibility to define a "content size" and a "wide size", by defining these, the inner blocks get centered by default inside the "content size" area and they receive new alignments options (full/wide alignments)

• Flex layout: This is a layout where the container receives a display: flex style. Right now it's opinionated, meaning the inner blocks are positioned horizontally one after the other with a small gap between each block. No alignment options are available for inner blocks inside a "flex container". That said, it is likely that we'll be introducing a number of customizations for this kind of layout. For instance, we could add a config to choose whether the blocks are horizontal or vertical (some argued that flex should be only used for horizontal alignments but it's something we should discuss more). Another option could be the "gap" size, align-items could also be a config option for the layout itself. For the children of this particular layout, we could potentially explore adding positioning tools (like align-self and such).

Layout switching

Generic container blocks like the group are most likely going to require a layout switcher UI to allow users to switch layouts and configure its specific options.

Right now, the initial prototype from #33359 contains a very basic undesigned layout switcher that you can enable by replacing this line with:

"__experimentalLayout": {
	"allowSwitching": true
}

You'll get something like:

This area is going to require a better design/wording...

Refactoring blocks to use declarative layouts

Historically, we've added a number of flex horizontal container blocks over time like: Social Links, Buttons, Columns and Navigation blocks. But we did so in a very ad-hoc way, meaning we just added custom CSS and custom customization options to these blocks. Now that we introduced the "layout" config and the "flex layouts", we should consider refactoring some of these blocks to be more declarative and remove the specific treatment we have right now for these blocks.

One technical issue that needs solving though to do that is that right now, the layout block support renders styles in the editor by using the __experimentalLayout prop of the userInnerBlocksProps call, but in frontend it relies on the layout block attribute. For the editor, the current APIs should be enough but for the frontend, these blocks might not allow users to tweak their "layout", meaning the layout attribute might or might not be necessary. We need to find a declarative way in block.json to define the "default layout" of a container block.

Todo List

In terms of design, we need a couple of explorations:

• Design a good layout switcher.
• What customization options are going to be needed for the Flex layout. Design the flex container config panel.
• Should we allow align-self positioning tools for children of flex containers? How to surface these?

In terms of architecture:

• Refactoring existing horizontal blocks to use the new flex layout.
• Write some architecture documentation for contributors about the layout and layout types.

[mtias]

Do we need to establish some criteria for when Flex is better over Grid?

[youknowriad]

I didn't think much about the Grid layout yet but it seems that "Flex" is easier/simpler when it comes to basic vertical blocks (social icons, navigation, buttons) but Grid would be a better choice for "page layouts", so an option on a generic container/group block (or variation) that you apply at the top level of your template.

I think what we're missing right now to start exploring Grid, is better understanding/exploration on what needs to be configured at the container level and what alignment/config options to expose on the child blocks. Maybe @jasmussen could help with that a bit. I think we could use a separate issue about the Grid layout to answer these questions:

• When I apply a "grid" layout to a block, what config options can I have on that block?
• What config options I have on its children?
• How does a "grid" layout impact the UI and possible interactions on the inner blocks?
• Potentially some design mockups about the questions above.

[mtias]

I think the important aspect is that it's not just a different layout property and it's more about who has more control, the parent block or the child blocks when laying things out. And that's something we should take into account early on since it can dictate the kind of tools that get exposed and where (in the container toolbar/inspector or the children toolbar/inspector). Also relevant.

[ghost]

I really like where this is going. From a UX perspective, I think that Webflow does an excellent job with their Grid/Flex layout interfaces.

[richtabor]

I riffed on some ideas as part of a big-picture proposal for the Group block's layout panel. Thoughts? #34558

[mtias]

@youknowriad where do you think we stand with this one after the latest work on Row, Stack and the transforms menu like #40036 ?

[youknowriad]

I think in terms of features for the flex layout itself, we're mostly there. Maybe the only potential addition could be this:

Should we allow align-self positioning tools for children of flex containers? How to surface these?

Similar to how "alignments" appear when you chose a "flex" layout for the container, specific flex alignment options could appear in child blocks when you select "flex" as their container.

That said there are a number of issues in terms of "architecture". Right now, some blocks have "align" block support which only works if container is "flow" and it works by adding an "align" attribute to the block. There are several things we should improve here:

• "align" is not a reserved attribute name and the framework (block-editor) don't really know anything about it. Some blocks might implement the same behavior using a different attribute.
• "align" is also not something that translates well in all kind of layouts, I'd love for that attribute to be named something like "position" (or maybe "_position" to avoid collisions with existing third-party attributes) and be understood by the framework. The attribute could store the "alignment" in case of a "flow" parent, and when you move the block to another container that is "flex", it should reset itself. In other words, the "position" attribute only make sense in the context of a given layout container. I hope that makes sense. That said It's also fine to track this separately as it's a tangent here.

[jasmussen]

One small addition is to consider a matrix-grid like alignment tool, a la what the Cover block has already, for flex containers that allow both vertical and horizontal alignments. Probably worth its own separte issue?

[mtias]

For self-positioning?

[jasmussen]

Row now has both horizontal and vertical alignments for children in the block toolbar, but not in the inspector:

We could potentially use the same interface the Cover block has for aligning. Instead of setting horizontal and vertical separately, it can be a single 9-cell matrix.

[youknowriad]

@jasmussen I'm not sure that interface make sense. What's "center": "justify center" or "space between"?

[jasmussen]

This is how Figma handles it:

I recognize the dropdown to choose between "packed" and "space between" isn't the most intuitive. Mostly it's the discrepancy between the vertical tools being available in the block toolbar, but not in the inspector, and if we add them to the inspector as well, we should try to avoid this:

One alternative is to also have dropdowns in the inspector:

That just doesn't feel quite as natural as the behavior that exists for Cover, though. 🤔

[mtias]

I was talking about self-align, though — so you can place something at the top of a cover, something else at the bottom, etc, which is not possible with the matrix control on the parent.

[jasmussen]

Depending on how many of the flex properties we want to support, it can quickly become a lot. Two options:

[youknowriad]

@jasmussen orientation doesn't make sense for individual blocks inside a container, justify might not make sense either.

[jasmussen]

Right of course, so potentially this; layout container:

Inner block, with justification shown or hidden depending on the block:

Something like that for a start?

[youknowriad]

Yes, I also wonder if it should be on the toolbar. Conceptually it's the alternative to "align left/right/wide/full" that we have for children of "flow" layouts.

[jasmussen]

Good point, and it illustrates a challenge with the iconography. When the justification icons are used both for inner blocks, and for self, it becomes unclear what they apply to.

I don't like the following icons, consider them placeholders to illustrate how "align self" icons might need to be different from "justify content" icons. Potentially we keep the group block toolbar simple:

And then you're suggesting some new align-self options in inspector and block toolbar for inner groups, right? Perhaps something like this:

[mtias]

@youknowriad do you see anything pending here? I think maybe some of the self-align options, which also overlap with the matrix control, but I think it'd be better to extract that into a separate issue. I feel the core work is done here.

[youknowriad]

@mtias 👍 Let's close and do a separate one about self align.