The Group block's layout defaults break existing content

[kjellr]

The shift to using Gutenberg's layout controls is going to break a lot of content. Take this layout in Twenty Twenty-One for example:

This is how that looks when I switch the theme to Twenty Twenty-Two:

This is definitely unexpected, and looks very broken. The fix is to open up this post and set "Inherit default layout" to true, but I don't expect that users are going to know that.

Some suggestions:

• Consider turning "Inherit default layout" to true by default for blocks, as least in the post/page editor. (I know this is a major change)
• Consider some sort of fallback that helps prevent old content from breaking.

Related: #34589, #29983

[kjellr]

Here's sample code for anyone looking to recreate that:

<!-- wp:group {"align":"full","backgroundColor":"black","textColor":"white"} -->
<div class="wp-block-group alignfull has-white-color has-black-background-color has-text-color has-background"><!-- wp:heading -->
<h2 id="lorem-ipsum">Lorem Ipsum</h2>
<!-- /wp:heading -->

<!-- wp:image {"sizeSlug":"large","linkDestination":"none"} -->
<figure class="wp-block-image size-large"><img src="https://cldup.com/NCVsLRzaSd.png" alt=""/></figure>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam.</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

Basically the steps are:

1. Using a non-block theme, create a new post.
2. Add a full-width group block.
3. Add standard-width content inside of it.
4. Save the post.
5. Switch to a block theme, and view the post.
6. All your standard-width content will appear full-width.

[kjellr]

cc @youknowriad do you have any ideas for this one?

I wonder if it's feasible to (at least) enable "Inherit default layout" for anything inside of entry-content by default.

[youknowriad]

I gave this a try and I think there's no issues here, things are just working as expected. Let me explain:

• The "layout" support is opt-in because it's a breaking change, it's a change in how themes work, so content created for a theme without "layout" support is going to be a bit different in another one with layout support.
• Similarly, if you switch between classic themes, if you have content in a theme with wide/full align support, the output won't look similar in a theme without them, these classes are not styled... so content will look different.

[kjellr]

The "layout" support is opt-in because it's a breaking change, it's a change in how themes work, so content created for a theme without "layout" support is going to be a bit different in another one with layout support.

I understand your viewpoint here, but on a high level I'm concerned that users will switch to a block theme, see that big portions of their content is broken, and then just switch back.

I also don't think we should expect users to understand which themes have layout support and which don't. As one example: Twenty Twenty-One is a classic theme so it does not have layout support. TT1 Blocks does have layout support. Although the themes are generally identical on the surface, Group block content will appear drastically different by default in each theme. Users will think this is just a bug.

[youknowriad]

It's the same thing if you move from a theme with a layout with some content width defined to a theme without a default layout define or without content sizes. Themes don't have the same "content area" and that's going to make the content look different (especially alignments).

It's also the same reason why ideally block patterns shouldn't have alignments, alignments only make sense in the context of their wrapper and I don't see any solution to that to be honest. If I move a block that is wide aligned to a column, it's not going to be wide aligned anymore and that's fine, what you're doing here is the same thing, it's just feels different because these two themes do support wide alignments but in different ways (deprecated one and layout approach)

Regardless though, I don't see any solution for this. Applying "inherit: true" automatically creates a lot of issues:

• What I have a header as a full size banner and I use a columns block inside it to have the logo on the left and some navigation on the right, I don't want that columns block to be centered.
• Having the layout work differently depending on the context will become too confusing: A group block behaves differently than a group of a group (same for any container and any combination of containers, not just group blocks)

I guess what I'm saying is that I don't see any solution for this problem, I'd happy if someone tries something that works well without introducing problems, but I personally don't see any.

[mrwweb]

Definitely in favor of Inherit Layout on by default. My first two Classic theme's that use theme.json have needed this.

While I think I understand the concerns about changing the default (back compat, non-body block areas), I can't get over the fact that my expectation is that layout is inherited and "just works" when I insert a group block when creating a post. When inherit layout is not defaulted to on, it feels like I'm expected to act and make decisions every time I insert a group block. That is a lot of friction and mental overhead.

What I have a header as a full size banner and I use a columns block inside it to have the logo on the left and some navigation on the right, I don't want that columns block to be centered.

This actually feels like a good example of why the changing the default behavior would make sense. This is a specific situation where it would make sense to "break out" of the default layout, and so the editor would want to take action. Focusing on this type of specific use-case feels like it favors FSE template editing over writing in the editor, and that feels backwards to me.

When building templates, people are in a "click, make decision, click, make decision, click, make decision…" mindset. Conversely, when writing posts, the content should feel like it is flowing and you can focus on the text/media and not layout (as much).

Similarly, if you switch between classic themes, if you have content in a theme with wide/full align support, the output won't look similar in a theme without them, these classes are not styled... so content will look different.

This is technically true, but I think there is much less of a feeling that the content is actually "broken". (And I also think it's much less likely that people switch from themes with alignwide/full support to ones without.)

Related: #33374

[pattyok]

"Having the layout work differently depending on the context" is about 99% of the work that I am doing these days, in building out themes.

Most of my effort is in building out components that my clients can drop onto the page without thinking. That's is why they are paying me to build a custom theme. I bring guided flexibility to the table. They dont want to think about the width of a thing every time they put it on the page, and I dont want them to.

The primary example for me, the same as @kjellr -- a full width background with some content inside, that content could be wide or normal width, by default it is normal, in some cases we want it to be wide, my themes are set up to handle those scenarios... (or at least they were pre- theme.json)

I totally agree with @mrwweb that the example of a header, that would likely be built by someone who has a deeper knowledge of the whole ecosystem and will know how to set the widths correctly. But within the content of a page, we shouldn't make the user have to think so much.

[Mamaduka]

I'm removing this issue from WP 5.9 project board since RC1 was released last night.

We can add it to a minor release board once it's created.

[tellthemachines]

Since #42763 new Group blocks have content width on by default. After much back and forth, it was decided not to force content width on existing blocks because that would break back compat for all existing blocks that purposely don't have content width enabled. I'm going to go ahead and close this issue for now. Thanks everyone for contributing to the discussion here!