Thanks for pursing this, it's a hard issue to solve.

With the proposed approach here, I see a number of issues:

• It's impossible to say float an element inside a container, the solution we used to apply for this is to insert a group inside a container and insert a left aligned block inside the centered group. How would you solve this kind of layouts and similar layouts (centered group inside a group)
• This is going to break existing sites relying on the current behavior, we should be careful about changing the default behaviors.
• the container class doesn't necessarily mean a group block that has a regular flow layout, while this is the only layout for now, introducing alternative layouts is planned see #33359, so for instance if I add a "navigation block" (or any block that could rely on a "flex layout"), it shouldn't be full width by default right?
• The main issue for me though is the inconsistency between blocks, some will be full width and others not and it can be confusing for users.

This is going to break existing sites relying on the current behavior, we should be careful about changing the default behaviors.

Since hasLayout is a brand new feature I'm not sure that's a concern here is it?

The addition class may seem superfluous but follows the alignment rules more specifically. The additional 'align full' class, I believe, is appropriate in the provided scenario. The intent is explicit.

An alternate is to not inherit the layout from the top-level group but exclusively from the post-content.

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
<!-- wp:post-content {"layout":{"inherit":true}} /-->
...

I could see either solution being appropriate for different scenarios. But I'm keen on the idea that the default behavior effects all contained blocks the same regardless of the container-ness of the contained block.

What I don't expect (noted in the originating blockbase issue) is that the two environments (editor/view) don't agree. So indeed there is still a problem to resolve, one way or the other!

I did not understand why needing to add the alignfull to the child is an issue.

One thing I just realized poking further is that while using the post/page editor there’s no knowledge of what alignment restrictions are imposed outside of the post-content block being edited. So the editor will always act as though there are no restrictions. This is why the behavior is different in the originating issue; alignment restrictions are imposed OUTSIDE of the editor and those only come into account when rendering the VIEW not the EDITOR.

While I'm not sure what the overarching fix for this situation should be I think that in the meantime it would simply be better practice to NOT impose any layout restrictions on blocks that contain the post-content block in the theme block-templates.

alignment restrictions are imposed OUTSIDE of the editor and those only come into account when rendering the VIEW not the EDITOR.

This is the reason there's a "layout" config in theme.json, that config applies to the post editor.

This is the reason there's a "layout" config in theme.json, that config applies to the post editor.

Ah! I see, and that also creates a similar problem.

Consider the theme.json defining layout parameters and in one block-template imposes that layout on the post-content block and on another does not (instead using perhaps a percentage value). The editor imposes the layout restrictions but the view does so differently; another discrepancy.

The alignment of the content in the post editor is based on assumption, not configuration. Which is what is happening in the originating issue: The editor ASSUMES that the content is the TOP LEVEL of any nested containers while the view calculates that layout situation differently.

Adding "alignfull" seems to mask the problem, causing the blocks to layout as expected in both environments, but is only necessary in ONE of the environments (the one that's already behaving correctly based on the rules its given [the view], not the one that's not following the rules [the editor]).

I did not understand why needing to add the alignfull to the child is an issue.

My issue with it is that it's not very intuitive. If I add a block with a default layout then I'll learn how it behaves from experimenting with it. Then if I add a child which also has default layout enabled, the behaviour of the child will be different from its parent. It wouldn't be clear to me as a user that the solution to this was to change the alignment of the child block.

the behaviour of the child will be different from its parent

But this is because the parent is acting upon ALL children the same be it another container, an image, or a block of text. Making an exception for "nested containers expressing layout" is what seems confusing to me. If I tell a container "constrain all of your children to 600px, except those who say they are WIDE or FULL width" then that is what I believe should happen.

I really think the whole issue at hand has stemmed from the block editor assuming the post-content would always be the top-level container, and always have 'inherit layout' defined. It was confusing in this use-case because the editor and view were doing different things for some of the blockbase templates because, in that case, the post-content was NOT the top-level "inherit layout" container.

So I DON'T believe the fix is to apply 'full width' to post-content in order to behave as we expect. While that is A way to fix it I believe it should be avoided if possible. I believe the fix is to ensure that UNTIL/UNLESS the block editor can discern and handle the layout configuration of the post-content more explicitly that we instead always ensure that the post-content block fits the editors expectations.

Is there a way to disable this whole feature without removing the theme.json from the theme? Exactly this case unfortunately breaks all my patterns...