Rethink and improve the 'None' alignment

[afercia]

Description

Splitting this out from #64842
See #64862
See #43468
See #51172
See #57318
See #52790

Blocks may support a number of alignments e.g. None, Wide, Full, Left, Center, Right. The actual nature of two of these alignments is a bit mixed, as they're more 'widths' than alignments.

To my understanding, the 'None' alignment may be also the value of the content width contentSize and the Wide alignment is the value of the wide width wideSize, if supported by the active theme.

Depending on theme support, the UI changes:

1
The theme supports both contentSize and wideSize.
In this case, the Style panel > Layout > DImensions shows both the 'Content' and 'Wide' inputs.
However, the block toolbar shows 'None' and 'Wide width'. It's a clear inconsistency in the name of the setting that doesn't help users understand what this 'None' is. The only hint is that the description below 'None' shows the value set in the 'Content' width. I would say the nature of this setting in this scenario is mixed, as it is at the same time both a width and an alignment none. Screenshot:

2
When the theme supports only wideSize, the UI in the Styles panel only shows the Wide width input. The Content width is gone. Notice the block toolbar setting is only called 'None' and doesn't show the value set any longer. In this case, this setting is actually only an 'alignment none' and looks correct. Screenshot:

3
When the theme does not support contentSize and wideSize, the UI in the Styles panel doesn't show any related input. The menu in the block toolbar only shows 'None' which is treated as an 'alignment none'. This looks correct to me. Screenshot:

Proposal

In terms of clarity of the UI, the first case is problematic to me. In that case, 'None' is actually the content width set in the Styles panel but it's named differently. As a user, I'd be very confused and I'm not sure I'd be able to understand they're the same thing.

I'd like to propose to conditionally name the 'None' item in the block toolbar menu. When the theme supports contentSize, this setting should be named 'Content width', which would be consistent with the item below: 'Wide width'.

Worth noting that #64842 proposes to clarify the labels and inputs in the Styles panel. The menu item in the block toolbar should be improved as well.

The Group block

The Group block is a special case, as it has its own setting for the Content width and Wide width. I'm not sure what the best option to improve things here would be but there's certainly something to improve. Open to feedback and suggestions.

A few findings:

1
The block settings panel shows the 'Content' and 'Wide' inputs. However, the alignment in the block toolbar menu, which is actually a width is called 'None'. I'd tend to think that also in this case it should be called 'Content width'. Screenshot:

2
When removing the theme support for contentSize, the Group block menu item is called 'None' and it doesn't show the width value any longer. However, the block settings panel still shows the 'Content' width input, which seems incorrect to me. Screenshot:

3
Similarly, when removing the theme support for wideSize, the Group block toolbar menu doesn't show the wide width any longer, which seems correct to me. However, the block settings still shows the 'Wide' input, which seems incorrect. Screenshot:

Step-by-step reproduction instructions

• Go to the Site editor.
• Select a block that supports all alignments e.g. a pagination block within a Group block.
• Open the Styles panel > Layout
• Observe the inputs in the Styles panel are named 'Content' and 'Wide'.
• Observe the settings in the block toolbar menu are named 'None' and 'Wide width'.
• Try to remove the theme support for contentSize and wideSize and reproduce the cases described above.
• Go to the post editor and select a Group block.
• Observe the inputs in the Block settings panel are named 'Content' and 'Wide'.
• Observe the settings in the block toolbar menu are named 'None' and 'Wide width'.
• Try to remove the theme support for contentSize and wideSize and reproduce the cases described above.

Screenshots, screen recording, code snippet

No response

Environment info

No response

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

[richtabor]

Yea, there's something here to improve for sure. I appreciate the thinking. There's a lot to unpack here.

Certainly seems "Wide" shouldn't be an option in the Inspector, if there is no support for wide width by the theme.

What's tricky about "None" and "Content" is that "None" is whatever the default is, which you can set in the Inspector as well. We do need a default, although "Content" is not quite as understandable.

I'm curious of other CMSs/builders and how they've approached this.

[afercia]

Yes there are some overlapping concepts here that originate from the WordPress history.
For ages, the concept of content_width has been familiar to theme developers. This terminology is now used in the editor for users but I'm not sure it's a terminology that makes sense for them. Rather, associating it with the concept of 'default' width would be more understandable, I think.

Also, when a theme supports contentSize and wideSize, these are both widths and alignments. Still, the UI places them in a dropdown menu labeled 'Align'.

The concepts to communicate would be:

• Alignment none with max content width as provided by the theme or customized by the user
• Wide alignment as provided by the theme or customized by the user

And then, the other ones, which are more understandable:

• Full width
• Left
• Center
• Right

[Marc-pi]

@afercia this issue is related also to yours #53771 : the dropdown selector states are difficult to understand and are non very intuitive, makes the user being crazy (click/unclick).

[hanneslsm]

If I understand it right, this issue is about the naming in the UI, right?
I agree, that the current implementation is confusing, especially if there is "None" and "Content" for (what looks to the average user as) the same thing. I also agree that it feels more like "widths settings" instead of "alignment".

How about renaming None/Content to "Narrow"?
Then we'd have "Narrow width" (being the default), "Wide width" and "Full width".

The toggle could be renamed to "Constrain width of inner blocks" (originally proposed in #51172 ) or "Enable width overwrite for inner blocks" or "Enable custom widths for inner blocks".

[hanneslsm]

3
Similarly, when removing the theme support for wideSize, the Group block toolbar menu doesn't show the wide width any longer, which seems correct to me. However, the block settings still shows the 'Wide' input, which seems incorrect.

As Rich said already, I also think this is a bug and Wide should be removed from the inspector.

[afercia]

Then we'd have "Narrow width" (being the default), "Wide width" and "Full width".

Yes that would be better. I'd consider to name the default... well, 'Default'. However, the UI should cleealry explain these widths are provided by the theme and can be customized in teh global styles.

it feels more like "widths settings" instead of "alignment".

Yes and no. When the theme supports them and provides the widths value, these ar both widths and alignments.
When the theme doesn't support the, 'None' is just an lignment and 'Wide' is not present.

[afercia]

As pointed out in #64891 (comment) the labels and help text / descriptions could be greatly improved, for both the Styles panel and the Group block settings panel.

[afercia]

Now that #64891 has been merged, the UI with the widths input looks as in the screenshot below:

• Left: Styles Panel > Layout
• Right: Group block settings panel

[rnrbrg]

Found #57318 and #52790. Both related to this issue. Maybe these could/should merged?

[afercia]

Thanks @rnrbrg I added those issues to the description of this issue as well.

I found some interesting suggestions about the wording for labels and descriptions on #36082 which is now closed as superseded by a broader discussion on #42385.

See mockup at #36082 (comment). However, it's not that simple. There are two more concepts to communicate:

1
Nested blocks: not all of them will honor these widths. For example, a nested Paragraph block dosn't even provide the Align dropdown menu. Also, its width doesn't honor the values set for nested blocks. More details at #65091. As such, the wording in the UI should clarify that these widths work for some nested blocks.

2
See this comment by @jameskoster

... 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

Yes. The point is that, depending on multiple factors, users may change these values and see no actual changes in the editor canvas. The key concept to communicate is that these values are maximum widths which are anyways constrained by the width of the parent. Otherwise, as a user, if I set the default block width to be 800px I would expect that the nested block has a 800px width even if its parent is 600px, as in: the nested block to actually honor the width value I set and expand beyond the parent boundaries. That's not the case though, and the UI should clarify these values are not widths. They are maximum widths.

[afercia]

In #65442, as a first step, I'm trying to rename these settings and improve the descriptions. Most notably, I'm renaming 'None' to 'Default width'.

However, I think there's a fundamental problem of clarity.

Basically, the 'global' widths and the 'local' widths for nested blocks are a different concept. The UI doesn't do a good job to communicate these different concepts. In the screenshot below, I'm showing the 'Align' menus of both a first level Group block and of a nested Group block.

• The active theme is Twenty Twenty-Four, which provides the global values 620 and 1280.
• I manually set the values for the nested blocks inside the Group block to 400 and 500.

The UI presents these settings in the same way. As a user, it's not clear to me the first ones are the 'global' values and the second one are the 'local' values. I'd tend to think these settings should be named differently.
@WordPress/gutenberg-design I'd appreciate any thoughts and suggestions.

[jameskoster]

I don't know that they're different concepts? It's the same concept, just with different values. I agree it's unclear where the values come from, but that's arguably true for both cases?

A random observation; we could eliminate the repetition of 'width' in each option by including a 'Width' label at the top of the menu.

[hanneslsm]

The UI presente these settings in the same way. As a user, it's not clear to me the first ones are the 'global' values and the second one are the 'local' values. I'd tend to think these settings should be named differently.

Doesn't this fall into the global vs local indicator discussion? Related: #37752 and #64670
Not sure if a different name or a (visual) indicator is a better solution here

[afercia]

Doesn't this fall into the global vs local indicator discussion?

In a way, these settings are 'global' and 'local'. However, the lcoal ones don't inherit. In this case, I'm not sure it would make sense for the local ones to inherit the global ones.

Worth noting that, when removing the 'local' widths from the parent, the nested block doesn't even show the 'Align' menu. It only shows the menu when the parent has some values set:

On top of that, not all the nested blocks support 'content' or 'width' and some blocks don't honor these values e.g. the paragraph inside a cover as reported on #65091

Overall, I think the UI is confusing for users and the functionality not working consistently adds even more confusion.