-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink and improve the 'None' alignment #64906
Comments
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. |
Yes there are some overlapping concepts here that originate from the WordPress history. Also, when a theme supports The concepts to communicate would be:
And then, the other ones, which are more understandable:
|
If I understand it right, this issue is about the naming in the UI, right? How about renaming None/Content to "Narrow"? 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". |
As Rich said already, I also think this is a bug and Wide should be removed from the inspector. |
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.
Yes and no. When the theme supports them and provides the widths value, these ar both widths and alignments. |
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. |
Now that #64891 has been merged, the UI with the widths input looks as in the screenshot below:
|
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 2
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. |
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 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. |
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. |
Doesn't this fall into the global vs local indicator discussion? Related: #37752 and #64670 |
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. |
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 widthwideSize
, 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
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Please confirm that you have tested with all plugins deactivated except Gutenberg.
The text was updated successfully, but these errors were encountered: