Suggestion: Simplify the layout concept

[kjellr]

In the runup to 5.9, I've been thinking a lot about the Layout controls. These are going out to users soon, and I still find them to be hard to understand. I'd like to outline an idea for how we might simplify these controls in the near term.

This is not intended as a long-term solution, but I think it may simplify the rollout, and make these controls easier to grasp for users.

Background

Two statements to start:

1. The current Layout Controls are confusing. We’ve tried to come up with a better solution, but we haven’t landed on one yet. (Issue: Consider new label and copy for Layout controls #31950)

2. Currently, you can add custom values for individual instances of layout (like individual group blocks), but there’s no way to edit the “default layout” at all. I think on the whole, this is actually the main thing users want to adjust. You make one adjustment, and then it's all set across your entire site. (Issue: Allow users to edit the "default layout" in the Global Styles panel #35955)

3. We've had these layout controls for months, and I (as an advanced user) very rarely find myself needing to set a custom per-block content width. I think I did this once for a block pattern, but that was it. The vast majority of the time I use this control, it's just to click "Inherit default layout".

The idea

The idea to simplify this consists of just two parts:

• Remove or hide the "custom" controls for individual blocks.
• Add a Global Styles setting for adjusting the default layout.

Mockups

Here are the current per-block layout controls for reference:

I do not believe most users need the ability to add custom content widths per-block. So for all blocks that currently have a layout controls, we would remove those options:

Toggle Active	Toggle Off

This change would distill the Layout controls into a simple toggle. This makes it far less of a complicated thing to encounter, and makes the choice into a simple yes/no option for the user. It's low stress: If they click the toggle and it doesn't look like what they want, then they can undo it with a single click.

There is a segment of users who will miss the ability to set custom alignment controls per-block, but they're certainly advanced users. If we'd like, we could keep this functionality for now, but hide the controls unless theme/pattern authors specifically define a custom layout in template/pattern markup. (This aligns to how Gutenberg has handled "experimental" controls in the past).

Moving on to Global Styles: This is the only place most users would see these "Content" and "Wide" fields. As you'd expect, changing a setting here would apply globally — to all blocks that have "Limit the content width" active.

I may be missing some details, but I'm curious if this idea resonates with folks. Thanks!

cc @shaunandrews, @jameskoster, and @youknowriad, since you've all spent a lot of time thinking about these controls.

[MaggieCabrera]

I agree with you that not having controls in GS for the default layout is going to cause issues for users.

I haven't found myself needing to use the per-block controls as much but they do come in handy when in the early stages of theme development when we need to work on the whole template: there are a lot of cases where those come in handy to have and not require that I write the markup directly, but that may not be the use case that we are thinking here for end users. I'm ambivalent about hiding the group controls, so I'll let others decide on that matter.

[jffng]

I am very in favor of having some global controls over the default layout. I have a clarifying question that may be more technical:

there’s no way to edit the “default layout” at all.

Say there was a control in global styles for the "default layout", how would you identify which block to set "inherit: default" on? Templates could be structured in any number of ways, some more predictable than others.

An alternative is that this control just affects any new Group block added to a post is set to inherit the default layout. This wouldn't solve this issue though #36057

[kjellr]

Say there was a control in global styles for the "default layout", how would you identify which block to set "inherit: default" on? Templates could be structured in any number of ways, some more predictable than others.

I don't think that control would turn on or off the default layout anywhere — it would just allow you to modify the width values for all blocks that individually opt-in.

[scruffian]

This looks a great idea to me. I have never used these controls on a single block.

[jameskoster]

As block templates become more prevalent, these settings seem to make less sense to me.

Shouldn't the width of the content always be governed by the template rather than a single setting? This would be more flexible as it allows you to have contextual widths. For example my post template may have a sidebar and consequently suit a narrower content width. My portfolio entries may just consist of galleries and so make use of a wider content width. If I arrange my post archives in to columns, a wider area gives the content room to breath.

All that to say, could/should we remove these settings altogether?

[shaunandrews]

At the very least, I find the langue used in the UI to be very confusing. I think updating the language could help a lot:

Also, if this section made use of the toolsPanel we could likely remove the need for the switch entirely; That is, the ... menu would allow you to display the content width controls only when you want them.

[jameskoster]

That looks better for sure, but I wonder if it should be possible to change the "full width" value? Or should that be hard coded to 100%?

[jameskoster]

Also, thinking about the slider for the default width... how do you determine the maximum value there? Or what happens if I set the default block width to be 800px, but the container only renders at 600px 🤔

I suppose we could say it's a max-width. But I can't help but wonder if some kind of column system mightn't be more flexible.

[ellenbauer]

I think it's true that it would be helpful to have multiple width options per page template like @jameskoster suggested.

But as long as theme authors define a default layout width for content and wide blocks shouldn't it be possible for users to change these settings as well? I did have users ask about this.

For changing page template width: How would this work for users to change them in a single instance? Would there be an setting for page width? I like the idea to have flexible page width, but somehow I don't understand how this should or could work. Would love to hear more about it.

[annezazu]

This came up as part of the eleventh call for testing for the FSE Outreach Program as a point of confusion:

When testing the single post template, I had some trouble setting the styles for each block. When editing the template, I changed the width of each of the blocks to match the theme (~600px). After applying the template to my post, it didn’t look like those changes or settings were applied, since everything appeared at max width, and I wasn’t really sure of how or where to fix that.

Essentially, she was trying to set the overall width of all blocks within the template but couldn't find a place to do so. Here's a video showing the understandable confusion:

Template.Block.Settings.mp4

[paaljoachim]

@aaronrobertshaw and @andrewserong
I believe the both of you might want to know about this layout concept issue.

[andrewserong]

Thanks for the ping @paaljoachim — I've added this issue to the design tools overview, so it's tracked alongside some of the other Layout issues.

[Humanify-nl]

Just looking at this now again.

On statement 3:
This setting is only there for me to be allowed to actually set the widths on individual blocks (content/wide/full). Its become a can I please change widths? button for me. Which is an unnecessary question in itself; of course we do.

On statement 2:
Yes! We theme authors like to set our widths in theme.json as a value. Giving users the ability to break page widths with custom values is a game breaker when working with varying templates (like sidebars).

Let it be overridden (if it must be!) in the global site editor styles, but not on a per block level.

On the solution:

Just think about how many times you ticked this box instead of leaving it as is. Fullwidth content is almost never used.

• The default (off-state) should be : Content adheres to theme widths
• The on-state should be: Content is full width

[cbirdsong]

I hadn't extensively interacted with this bit of FSE until recently, and I found this setting to be pretty baffling until I set up a bunch group blocks with it enabled/disabled and compared how they acted. Once I understood what it does it didn't seem all that useful? It feels like it could use a total rethink.

[ndiego]

Now that layout support has been added to Column blocks with #39422, and it really should be added to other container blocks like Cover, I feel we need to earnestly revisit this UI for 13.1. It would clear up a lot of user confusion.

[eric-michel]

I found this issue when searching for other discussions related to issue #33374. There are a lot of really insightful comments in that thread, but I'll add my two cents here for visibility since this thread is tracked as part of #39336. My apologies for folks who are subbed to both threads and see my comments twice.

My users will not find the current functionality of these container layouts intuitive at all. Just like @cbirdsong, I found the concept so bewildering when testing out adding theme.json to our parent theme that I thought it was a bug with my CSS until I tested it in Twenty Twenty-Two and found the same thing to be happening.

For our users, the most common use-case for a group or cover block is setting that block as full width, applying a background color or background image, and filling it with content - most notably paragraph blocks. In the current version of Gutenberg, this causes paragraphs to be full width by default, which is a complete violation of a11y standards, not to mention perplexing for any user who is not super familiar with the editor.

My users will expect any blocks they add to a full width group or cover block to behave exactly the same as blocks added to the top level of the editor.

I support as much flexibility in the editor as is feasible, but with controls for theme authors to provide sensible defaults and limits for users who are not developers (or even technically-inclined).

The most intuitive option to add flexibility for layout in my mind is:

• Allow the addition of more alignment widths than just standard, wide, and full in theme.json. For instance, maybe I want narrow, standard, wide, extra wide, and full options.
• In containers with a constrained width (for instance, a group block set to wide alignment) limit any child blocks to alignment options that are the same size or smaller than the parent block. So in the example of a group block set to wide alignment, any child blocks would have narrow, standard, and wide available (and would be set to standard by default).
• From our perspective, having full available to all child blocks would be preferable as well, because we use full alignment in a child block to push it to the edge of its parent. We use width: calc(100% - var(--layout-spacer-x) * 2); for all blocks to create edge spacing, and full sets width: 100%. This is useful for setting, for instance, a group block within a group block to the same width as its parent. I realize this is a pretty opinionated bit of CSS, though, so maybe that's outside the scope of this conversation.

[SaxonF]

@eric-michel I'd love your thoughts on this proposal as it touches on a few of your ideas

[mtias]

Marking this as superseded by #42385.