Keep width settings when transforming to container blocks (row, stack, group)

[annezazu]

Description

When transforming blocks with width controls to a container block, the width options are not retained. This was found during the 6.0 walkthrough.

Step-by-step reproduction instructions

1. Add a few cover blocks.
2. Select all of them.
3. Use the options in the block toolbar to switch between group, row, or stack.
4. Update the post after transforming.
5. Notice the width shrinks and notice the front end now looks different than the editor.

Screenshots, screen recording, code snippet

stack.block.mov

Environment info

• WordPress 5.9.3
• Gutenberg nightly 13.0.20220404
• TT2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[carolinan]

The cover blocks keeps the alignfull CSS class on the front when transformed, even though stack and row does not support "inherit layout" .
-The CSS for alignfull is applied
-There is no way to change the inner block width using the UI after transforming.

For rows, I think the expectation is for the inner block to no longer be full width, and for the "allow to wrap to multiple lines" to be toggled off. Otherwise the blocks do not display in a row.

For stack, if I remove the align-items: flex-start; from the container group block on the front, the cover is full width.

[andrewserong]

Notice the width shrinks

I'm not too sure what the ideal fix is here, but for a bit more context, it looks like the style that's adding padding in the editor is coming from the Twenty Twenty Two theme:

I think the solution might be related to the issue described in: #35607, which @glendaviesnz has been looking into in #39871, and @tellthemachines has been doing related work in: #39926

[tellthemachines]

This seems to be a theme styles issue, because I can't reproduce it testing with Empty Theme on trunk:

@andrewserong you're right that this is related to #35607, in that if we fix that issue, themes will no longer need to add the styles that are causing breakage here. Ideally the logic to display blocks full width would be handled by Core.

[ndiego]

This seems like this might be a theme styling issue? Can anyone confirm? If so, I will remove from the 6.0 Project Board. Thanks!

[ndiego]

I have confirmed all these issues are related to custom styling in Twenty Twenty-Two. I have not tested with the updated version coming with 6.0, just the version in the repo.

@jffng are you still working on Twenty Twenty-Two? If so, I just wanted to make sure you were aware of this issue. Thanks!

[youknowriad]

Hi there! this is not really a new bug but more of an unsolved conceptual issue. (I touched upon this on other issues)

Basically, when you transform blocks or just move blocks between different containers, the "align" attribute might not make sense anymore. It's the container that defines the available alignments for its children, so if I move from a container that supports "wide" alignment to one that doesn't, we should probably remove the "wide" alignment from that block. The same happens when you move a block from a "flow" container to a "flex" container.

Also, while the issue right now only happens for "align" attribute, it's going to start happening for other kind of alignments, for instance we're considering adding some alignments for child blocks of "flex" container (self alignment), and these attributes will have the same issue.

In a previous issue #27324 I propose the following:

• Introduce a "position" attribute that is basically something each block has and that depends on the parent
• the position attribute meaning depends on the current parent, for instance it can replace the "align" attribute for children of flow containers and can support other kind of positioning for children of other layouts (think align-self for grid, and more complex stuff for grid...)
• Have some logic in place in the "block-editor" reducer that everytime a block moves to another container, we compare the "layout" of these two containers (previous and new container of the block) and keep or reset the "position" attribute of the moved block accordingly.

It's going to be a complex problem to solve, and I don't really think we can solve it properly in 6.0

[jffng]

Thanks for the ping, ideally we remove the offending padding CSS in TT2. As others have said, we can do that once #35607 is solved. A solution is close to landing but not in 6.0, and I think the theme should continue to ship with the alignment CSS until it does.

[NoHopeRadio]

Just want to note a few other other related issues to this at least from the .com side, as I've run into issues with alignment settings in nested blocks relatively regularly since the first time I saw an issue in February.

Automattic/wp-calypso#61473

In this case, it was copying a block with alignment settings into a pre-FSE widget area that resulted in the strange behavior with alignment, and since the option to edit the alignment was not available, it couldn't be changed except by copying the block into the regular editor and fixing it there, or one thing I've taken to doing for this issue, copying the blocks to a text editor and deleting the alignment settings there. I'm excited to hear that the code view will be more available after 6.0!

Automattic/wp-calypso#60996
Automattic/themes#5636

These two open issues are more about the general case, and I was looking for an issue about one more issue about template parts, this was the closest I found:

Automattic/wp-calypso#35387

But this issue or something very similar also seems to be present while editing an individual template part. I believe something may treat the template part taxonomy the same way as a group block, so alignment settings aren't present for the elements within.

[donalirl]

I encountered a confusing issue related to this as well, with the following steps:

1. Insert a Columns block with text inside
2. Set the Columns to full-width alignment
3. Then put the Columns block inside a Group block
4. Set the Group block to full alignment
5. Insert another Paragraph inside another Column inside another Group block, but this time don't set full width alignment on the Columns block, only the Group block

This resulted in two different alignments, with no option to adjust because of the way the Group block removes the option to set a full-width alignment on the nested blocks:

In the inspector, the block still retains the alignfull class:

but the Columns block no longer has the setting to unset the full width alignment. The only way I found to resolve it was to ungroup those columns, unset the full-width alignment on the columns, then group them again.

I recorded a video to demonstrate this flow visually:

Screen.Recording.2022-07-12.at.01.44.03.95.PM.mp4

This was on the Blank Canvas theme with the 13.6 version of Gutenberg.