Expanding and simplifying layout

[SaxonF]

What problem does this address?

When making a decision around how to implement a particular layout, multiple blocks need to be considered. There is group, columns, layout grid, row and stack, not to mention more specific blocks like cover and gallery. The tools within those blocks also limit what's possible, particularly when looking at inner block sizes and alignment

What is your proposed solution?

This proposal consists of a few changes revolving around creating a single container block that can handle both fluid and grid based layouts, as well as extending layout/size controls.

A single container block

As a user, I can currently implement a two column layout using either the Columns, Layout Grid or Row blocks. They each behave slightly different but they also overlap slightly in what you can accomplish. It's worth exploring whether we can accomplish all behaviours using a single intuitive block.

POC

I have built a little proof of concept that I would recommend playing with https://s75qk3.csb.app

You can also see a quick demo below:

layout-demo.mp4

• By default columns snap to a 12 column grid
• Columns are either in a "fill" state (take up remaining space) or have a set column width
• In the POC if you hold cmd while dragging a column you break out of the grid
• Snap to grid resizes columns to the nearest column size

The block

What would this look like in the block inspector?

The container block would have the following global layout settings:

• Direction [horizontal, vertical]
• Gap/Block Spacing which is driven by spacing scale in theme.json
• Alignment which is a combination of the existing justification controls + the opposite axis e.g. align-items when set to row. The grid is arguably a more intuitive way of justification/alignment content within a container.

All child blocks of a container block have size properties accessible to them, starting with width but also including padding and margin.

An important point to note is that there should be a global token called size/layout/width which is an array or object of width values. wide and content (default) would be two options, but you should be able to create as many as you like.

Layout and size controls will change depending on the direction of the container block.

Horizontal

Container

Containers set to horizontal direction also have an inner block width setting which contains a snap to grid toggle and wrap items toggle. The snap to grid toggle performs the same function as seen in the POC above.

Child

• Width can be set to
  • Fill which is basically flex grow 1
  • Fit which is flex grow 0
  • Fixed which sets a fixed width depending on the unit type selected
    • Columns which is only accessible when "snap to grid" is enabled. If a fixed width is set on a child block, the parent block snap to grid is toggled off. If toggled back on, all child blocks scale to their nearest column value.
    • Theme which pulls width values from a size/width/layout scale set in global settings (see above note)
    • px/%/etc which are just hard coded values
• Height which lets the child either fill the height of the row (alignItems: stretch) or fit (default) its contents

Vertical

Container
When a container block is set to vertical orientation it behaves like the existing group block by default. The only change here is that we are removing the existing (and somewhat confusing) Inner blocks use full width setting and relying on smart defaults. If a container block is wider than the content width/layout size, then inner block widths should be set to the content width, if its smaller than they should be set to "fill". The size controls should be accessible to all inner blocks however.

Alternatively, we can introduce an default inner block width setting which uses the same interactions as the width setting of any other block. The only thing you can't accomplish with this interaction is setting the "wide" size of child blocks but I'd argue this should be set on the child anyway.

Child
A child within a vertical direction container block has its width set to fill by default, unless the container block is wider than the content width. It also has its horizontal padding set to the global padding setting. If a user wanted an image to span the full width of the container, they just need to remove the padding (or could be margin).

The width setting has an extra full option which is essentially 100vw.

These settings should be able to be applied on any container block, including blocks like PostContent. This gives the theme builder more flexibility when designing unique templates.

For added flexibility we should also consider adopting a negative margin property that also uses global spacing values.

[SaxonF]

This issue touches on some of the concepts discussed in #36082 and #35607 and #42085

[jameskoster]

Big +1 from me on the idea of abstracting layout as a concept versus dedicated blocks like row/columns/group. I'm curious about the relationship with semantic blocks that require layout... things like navigation, social links, gallery. My assumption is that they would just 'support' layout, and users would find the same panel when working with those blocks.

How do you see fixed columns working on nested containers?

I appreciate most of the examples here are to demonstrate full capabilities, but it could be good to ideate on the smart defaults and determine the minimum number of controls to expose by default so that we might avoid an overwhelming initial experience.

Nice work. This is very comprehensive :)

[andrewserong]

Fascinating exploration, thanks for sharing the great interactive demo, too!

This proposal consists of a few changes revolving around creating a single container block

For a bit of context surrounding the Group, Row, and Stack blocks — they're all the one Group block, but use the block variations API to be exposed as different conceptual blocks in the editor, based on their layout settings. At the moment the Group block appears to be the canonical container block in the editor, and it gets registered as such when the editor boots up.

So, (at least in API terms), we already have a Layout concept that's abstracted away from the block type itself, where different features of Layout can be opted-into at the block.json level. The Group block opts-in to (nearly) everything, and the variations can be thought of as a kind of preset for Layout settings. For example, if you take a Row block and switch the orientation to vertical it looks like it transforms it to a Stack block, but really it's still just a group block with a particular Layout setting. Here's how the Stack variation exists when serialized to markup:

<!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap","orientation":"vertical"}} -->
<div class="wp-block-group"></div>
<!-- /wp:group -->

With that in mind, it sounds like there are a few different parts to this proposal: 1) The changes to controls and which ones appear in the Layout panel, 2) the introduction of a Grid layout type, that is different to the existing flow and flex layout types, and 3) the ability to resize children of the Grid layout type to determine a particular grid layout?

To achieve this, if there was an additional Grid layout type, it could then be exposed in the editor as a Grid variation of the Group block, too. That way, users could switch a Group block from a default flow layout to Grid or back, either via the existing Variations toggles, a new UI for switching between Layout types, or by adjusting Layout settings?

When it comes to the existing conceptual blocks like Group and Row, some of the benefits of keeping some semantic difference in block naming within the editor (even if behind-the-scenes they're still a Group block) include:

• A user who wants two or more blocks to be on the same row, but otherwise isn't concerned with layout per-se — e.g. I've got a site title and a site logo that I want to put into a header, so I reach for the "Row" block. Or, I "group" them, and then switch the Group to a Row.
• A user who wants to group together two or more blocks within a blog post as a call-out or aside — e.g. I've got a bit of explanatory text, so I'll highlight a header plus a couple of paragraphs, click the Group button, then add a border and a background colour so it looks more like a callout.

All child blocks of a container block have size properties accessible to them, starting with width but also including padding and margin.

I really like the idea of the child blocks being able to set their width or column span — one of the things that'd be very cool, is if it could also be supported in the Gallery block, so that users could set a grid of images, and then select particular images to span multiple columns, to have a customisable mosaic kind of layout.

Width can be set to
Fill which is basically flex grow 1
Fit which is flex grow 0

For these kinds of layout options, did you have in mind that the layout controls are defining a flexbox layout or CSS grid approach?

[tellthemachines]

Thanks for sharing these thoughts!

One thing we need to account for is responsive behaviour. In the current Columns block, that manifests as a “Stack on mobile” setting, but also in the ability to set fixed widths in px units, and unset width altogether so that a column can take up the remaining space. This allows us, for example, to build classic fixed sidebar/responsive content area layouts.

By default columns snap to a 12 column grid
Columns are either in a "fill" state (take up remaining space) or have a set column width

I’m curious about how the 12-col underlying grid would work in a mixed fixed/variable column width context. Is the grid always 12-col regardless of screen size? Do fixed px width columns ignore it?

[eric-michel]

This is a very cool demonstration! I love the sandbox to allow for testing of the features!

One thing we need to account for is responsive behaviour. In the current Columns block, that manifests as a “Stack on mobile” setting, but also in the ability to set fixed widths in px units, and unset width altogether so that a column can take up the remaining space. This allows us, for example, to build classic fixed sidebar/responsive content area layouts.

This is what I'm immediately curious about as well. Right now, Gutenberg doesn't really have a lot of options for controlling how things will shift when the screen size shrinks. In any case where I want something even remotely complex (like 3 column shifting to 2/1 instead of 1/1/1) I usually swap to a row block and work up some custom CSS.

[SaxonF]

I've spent more time thinking this through and have iterated on the above to get to the point below.

Consistent layout and dimension settings for all container blocks (e.g. Group or even Query) and child blocks. We infer whether a block is flex, grid or auto based on its settings, and in some cases its children's settings. We also infer the "inner block width" toggle based on child width setting and hide the complex wide/content width setting unless it's needed.

[jasmussen]

I always appreciate how deep you immerse yourself in the UI/UX challenges, Saxon. Nice work.

I am having a bit of a hard time extracting the Layout pieces on their own from the component and inspector changes you made. I understand why the compression of said componentry might have played a role in your decisions, but it can still make it a little trickier to compare with what's shipping, since the visual delta is bigger.

Two riffs on your mockup, just to see if I understand this right:

[SaxonF]

@jasmussen that looks about right. There is an experimental branch in motion here which we will use to play with some of these changes.

[jasmussen]

Nice, I took the branch for a spin and left some comments there.

[richtabor]

I explored a little on this front too, mostly figuring a way to fuse what we have today with a bit more simplicity - but also flexibility.

CleanShot.2023-05-10.at.10.50.33.mp4

Align/Justify Matrix

Like @jameskoster explored in #49448, I think we could potentially condense a bit, while adding more flexibility, with a matrix control like what Figma uses.

Justify (Distribute) Select

A way to set values for how the blocks are distributed within the layout. I.e. Space between, around and evenly. We only support between at the moment, but using a select lets us flex this without making the UI more complicated.

I'm not 100% on the label—could be "Distribution" or "Distribute" or "Space" (though we do have Block Spacing elsewhere).

Nested width

A way to condense the current layout content controls that exist within the Group block.

• Instead of always showing the content/wide input fields, leverage the existing settings icon pattern to reveal additional controls.
• Uses a ToggleGroup to name the options, instead of a toggle to turn on one of the modes (which is confusing).
• Use relative help text based on the value.
• If there are custom content/wide input values, the layout attribute is set to "constrained".
• This proposes layout constraining for the Stack block, as the Group block is basically a less malleable Stack block—but the Stack currently lacks support for the width, so you have to use the Group if you need that. This would pave the way for using the Stack consistently instead of having to decide if you need a Group or Stack.
• Also not 100% on the label, but it could work.

[richtabor]

There's also room for adding an "Items" select, for setting the items in the layout to align-items: stretch, or other.

[richtabor]

And I explored using a checkmark/minus (reset) for Wrap as well. Perhaps a "wrap" icon would work better than a checkmark?

[jasmussen]

Will this this work for other blocks with flex layout, such as Buttons or Navigation?

Right, valid point to bring up. But the fact that we have both the transforms at the top, and now additional icons that do the same inside the layout panel, regardless of the solution, still suggest we need an iteration here. Whether that's removing the icons at the top, and go with more generic layout icons, or even removing the direction control from the layout. Perhaps there's even a third option?

[SaxonF]

Providing an update here with some further iterations @richtabor and I have been exploring.

There are two options, both of which add the following:

• Move padding and margin in to layout panel
• Move dimensions panel under layout
• Use matrix for alignment
• space between is accessible via more menu within gap (or alignment if that makes more sense)
• Width and height are always visible and follow the rules listed
• When using vertical direction, child blocks are set to fill (stretch) by default

Option 1: Merge Group with Stack
This is an iteration on what's already been done as we are still merging stack and group by adding an additional "content width" property. We actually already have this on the POC branch except we are adding several changes listed above. In this scenario other container blocks like Buttons and Navigation would adopt the same layout changes.

Option 2: Keep Group
The second option is to leave the Group block as is for now and focus on updating Stack and Row initially. In this scenario we'd likely just keep the direction control on other blocks like Buttons and Navigation edit: or move layout selection in to layers panel.

Moving variation selection in to layers panel

[tellthemachines]

In this scenario we'd likely just keep the direction control on other blocks like Buttons and Navigation.

I'm concerned that changing the layout tools without testing on all blocks with layout will lead us down the wrong path. Controls should be the same across different block types, so we need to make sure they work for all different block types.

[SaxonF]

I agree with you @tellthemachines . An alternative for option 2 is to move the block variation selection (group, row, stack, grid) into the layers panel so that it's accessible to all blocks (I think @richtabor was playing with this idea). Perhaps this is a better starting point as its consistent with option 1 just without the content width control. We can then decide to remove group variation in favour of a content width property or keep it there.

[jasmussen]

Great progress. The use of the generic block icons feels like a big step forward, and in general moving them out from the top "descriptive" area works well here. I wonder if that translates well to other places where we are showing those transforms? Maybe not, but perhaps this suggests those other places may not be the right approach after all (example: #46195).

The "Wrap" yes/no is too prominent for taking up a whole row like that. It was added because it allowed some responsive nuance that was useful, but it still seems like we can have a default and then a much more hidden option to toggle it. Perhaps it can live inside an ellipsis menu?

It's pretty important we be intentional about our terms, and "Block Spacing" instead of "Gap" was chosen as a more obvious alternative to "Gap". I know this is something @mtias feels strongly about too. I realize the length of that term makes it hard to fit in the space, but to that end the slider doesn't feel as successful to me in the stacked version regardless, and we may end up with translations becoming an issue here regardless, where a worst case German translation could be "Zwischenraum".

Finally it may be worth keeping padding and margin separate from the layout panel at least for the first iterations. I see the argument to unify them with a layout panel, but if we're going to move them from Dimensions to Layout, maybe it has to happen across all such panels at once?

[jameskoster]

I like moving the variation selection to the layout panel. It's easy to see this working for all container blocks. IE allow Buttons to be arranged in a grid.

The Gap control looks a little strange, I don't think there's a vertical configuration of input + range elsewhere. Are there other options?

[mtias]

I don't like moving variations to the layout panel very much because it breaks the hierarchy and consistency they aim to provide—changing the layout is also changing the block variation, which is represented in the block icon and is relevant outside of the appearance sub panel. Variations render at a higher level, given they can also be accessed directly in the block inserter and block transformations. Moving them into an attribute palette breaks that mental model which I think is pretty important.

[tellthemachines]

I don't like moving variations to the layout panel very much because it breaks the hierarchy and consistency they aim to provide

There's only one block (Group) that uses variations to switch between orientations, whereas there are multiple blocks that depend on the layout tools for that. For blocks such as Buttons and Social Icons it feels like overkill to make orientation switch a block variation, and we also need to consider third party blocks already using layout: removing the orientation switch in the layout panel will break back compatibility for those.

Tbh I'm not fully convinced that it makes sense for different layouts of Group to be variations; it seems to indicate we have different types of containers, when what we actually have is the one container with different ways of organising its contents.

[richtabor]

it seems to indicate we have different types of containers, when what we actually have is the one container with different ways of organising its contents.

Yea, though the notion that you can start with the intent to add a row, or a stack, of blocks is beneficial — i.e. via the inserter.

[tellthemachines]

start with the intent to add a row, or a stack, of blocks is beneficial — i.e. via the inserter.

Hmm yeah that must have been the reason to make Row and Stack variations in the first place.

I guess regarding the orientation controls, we have two options:

• Keep them in the layout panel for all blocks and remove the block variation controls for Group to avoid duplication; or
• Add a property to layout to hide the orientation controls, and use that property to hide them just for Group, while leaving the block variation controls as they are.

The second option has the downside of introducing inconsistency in the layout tools, but that could be mitigated by using the same icons for horizontal/vertical/grid orientation as we use for the Group variations, so the controls would look similar even if they are in a different place.

[hanneslsm]

Minor feedback: Can we switch width & height? Since we read the layout from top to bottom and left to right, let's got with horizontal first and vertical second - as for padding, margin and image aspect ratio (just seen it's inconsistent between image and featured image)

Other questions and notes:

• Padding / Margins are not displayed in the "Dimension" section anymore. Is this on purpose?
• I am not sure if moving the dimensions from the "Styles" Tab to the "Settings" Tab. I prefer having control over background color, padding and border all at once.
• I am using a theme with custom spacing presets (like here), therefore I'd also prefer if "Gap" would be full width. Supports also the argument with long translations.
• I am often grouping blocks via the list view and then change them to row or stack. Especially if this will be implemented I'd prefer if the variations will not be moved to the layout panel - on top they rather function as "quick links" for transforming the block.

[mtias]

@tellthemachines it's ok to reflect orientation as a layout attribute, what I mean is it should not imply relocating the variation functions into layout as well. Variations are higher level for group(s) block. We use them for transforms; in multi-select; in list view; we expose them in the inserter. They offer a direct mental model to things you can express with layout without understanding the intricacies of layout properties. I consider this an important user-focused design principle. Other blocks leveraging the layout tools (buttons, social icons, navigation) are fine to just rely on orientation since the mental model and context is a bit different there.

[SaxonF]

it's ok to reflect orientation as a layout attribute, what I mean is it should not imply relocating the variation functions into layout as well

@mtias Could you clarify what you mean here in terms of what sort of experience you expect? It sounds like you're fine with option #2 @tellthemachines mentioned above. The fact that we currently have an orientation control that changes the group variation also breaks hierarchy in a way (from a users perspective).

Other blocks leveraging the layout tools (buttons, social icons, navigation) are fine to just rely on orientation since the mental model and context is a bit different there.

I don't think our mental model as developers would match that of end users. I doubt majority of users even know what a block variation is. If we were to go with this approach I'd expect variation icons and orientation/direction icons to be the same.

[richtabor]

I am not sure if moving the dimensions from the "Styles" Tab to the "Settings" Tab. I prefer having control over background color, padding and border all at once.
I am using a theme with custom spacing presets (like #52827), therefore I'd also prefer if "Gap" would be full width. Supports also the argument with long translations.

Just explorations; many more bits to iron out. :)

[mtias]

@SaxonF the main experience I expect is to preserve the mental model afforded by blocks more than the mental model of properties. I think the latter is the developer and systematic thinking in us more than what users would intuitively understand. So I want us to balance improving design tools with the value of blocks as the primary user-facing abstraction. In a nutshell, I rather normal users learn one thing—blocks—than a whole set of layout tools.

Another example: the Cover block can be seen as just a group block with a given set of properties. However, a user would have a much easier time discovering a Cover in the inserter than figuring out a Group can do all the things they need it to do to replicate a cover. It doesn't matter if we end up with Cover being just a variation of Group, what matters is users recognize and interact with it through all our major interfaces (inserter, transforms, list view). The block encapsulates an intention and communicates it much more rapidly than properties.

Block variations were designed to allow us to have both things—a consistent set of malleable properties that allows us to reduce duplication and consolidate tools without letting go of the more direct aspect of the block mental model. I don't mind layout orientation existing as a property, what I mind is burying blocks within it and eliminating the higher level concept of quick variations from the inserter.

So in terms of the proposals above I'm actually fine with orientation existing in layout tools with the arrows and for group blocks to also see that reflected in the variations. Which I guess is what we have now.

The fact that we currently have an orientation control that changes the group variation also breaks hierarchy in a way (from a users perspective)

I don't think it does. We have blocks where a given combination of attributes would match a variation and the variation become enabled. Variations can be seen as a shortcut for a combination of attributes but it's not a requirement that a user understands this. If anything, I think changing layout orientation and seeing my Stack became a Row helps me understand things better.

[SaxonF]

An update here is that we have a second prototype branch here. I'd recommend trying it by attempting to reproduce common pattern layouts etc. If you're used to the existing layout controls it takes a bit to adjust but I personally find it a little easier to understand conceptually and the addition of predictable height/width controls goes a long way.

This obviously wont make it for 6.4 but I'm hoping to put together a few tests to send out to different groups of people to collect feedback and iterate before 6.5.

[tellisbethel]

Howdy! It was recommended I share a recent scenario where I ran into some difficulties helping a user with a layout request:

A user wanted to have a “Welcome to our team” Cover block banner show Full width above their footer on their About Us page, while maintaining the rest of their page content at Wide width. (The Content block in their Page template was already set to be Wide width.)

With lots of help, I almost nailed the request: I ended up with a Full width banner, but narrow, instead of wide, width content. We settled on suggesting the user try the Content block's Layout > Content width setting to let them set their ideal content width manually.

Even though I have a much better grasp thanks to help from colleagues and my experimentation, it felt like a lot of effort for a simple request: place a full width banner beneath wide width content. Understanding where to apply the "Inner blocks use content width" setting is also tough, especially with several layers of nesting. That said, I do appreciate the power of FSE!