Multiple blocks: Make the added padding when there is a background color optional #50813
Conversation
|
Size Change: -418 B (-0.02%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
carolinan
added
[Type] Discussion
|
There is still something affecting the padding of the heading block with the background color. Some styles may be from Core or were not built properly in my test. |
|
@WordPress/block-themers What are your thoughts about making the padding which is added when a block has a background color optional, through I think the default padding is especially bad on the heading block. |
|
Flaky tests detected in d241948. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9168571703
|
|
While I see the benefit of additional padding from an intrinsic design philosophy, providing a more "designed" experience by default, The additional padding often causes large inconsistencies between elements and makes creating complicated layouts more difficult. I hope to see this merged. |
|
I agree with the statement from @philhoyt. It would be useful to be able to customize / configure the default spacing that gets applied to an element when a background is added. Kind of with more context aware global styles. But in it's current form the default padding that is arbitrary and doesn't abide by the spacing presets / design tokens is always a hurdle and causes a lot of issues. |
|
I'm in favour of making the padding optional through |
|
It is great to see this PR on it's way. There is a jump that happens when adding or removing background color which in a sense feels like a bug. Automatically adding or removing padding based on adding/removing background color just seems weird. When a user adds a background color they can see the result and then choose to add the padding they need. |
|
Any additional thoughts? |
I concur. |
|
Seems reasonable to me 👍 |
|
Another option that I think it worth considering is to add the padding as a setting at the same time as adding the background color. That way it gets set, which is probably what most users want, but it can be removed using the padding tool, if its not what you need. |
This seems like the most reasonable option, but maybe not the easiest |
|
Let's see if I get this correct.... I initially gave it a thumbs up but need to go through the logic.
A user adds a background color and padding are automatically added. User wonders why padding is added and if they happen to look in the sidebar settings they will see that padding values have been added. Based on this I would likely report a bug with the title: Adding background color padding is automatically added. It is better to have the flow like so. Going through the above flow I would then suggest this: |
|
Since we already add a padding when a background color is added it seems reasonable to assume that this is the behaviour most users would expect. |
|
It is tricky. The suggestion is better than what we have now without the PR. |
|
When an user adds one behavior it is not beneficial for Gutenberg to add another behavior not directly added by the user themselves. We can not assume what the user wants. It is up to us to make the Gutenberg experience as smooth as possible based on the actions the user decides to take. When an additional behavior is added not directly controlled by the user then Gutenberg needs to alert the user. Letting them know that something else also happened even though the user did not add it themselves. |
|
I think the most confusing part of the auto padding isn't even related to the added padding itself, but that there are no indicators of the amount of padding on the padding sliders because they dont show the actual state. Right now you have to engage with the slider at zero wiggling it a bit to apply your own padding. A lot of people won't even bother trying to engage with the sliders if they're showing zero thinking that this isn't the place to change it. The lack of state on sliders is a severe UX glitch which should have priority over this one because it drags other experiences down which may even be good ideas. Also how about a toggle like global content width but for a global padding value? |
|
No options show the value from theme.json and I agree this is a problem. |
The range controls are most egregious, but this is a pretty widespread issue: #43082 |
|
Wow it seems to be a big problem @jameskoster If it can't get fixed soon I think a introductory design guide could be helpful where users are made aware that they can overwrite stuff despite the handles/sliders showing no state. E.g. a small link in the right sidebar "learn how to design with blocks" or something. Users shouldn't be expected to figure it out themselves. Maybe start the guide right away saying that it's still a work in progress and making users aware of the things that don't work yet perfectly right away. This document could evolve over time as things progress. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @philhoyt, @Ren2049. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
What?
Some blocks add default padding when the background color is enabled. This can be unexpected for users, as expressed in #36586 and #30725
It affects:
By moving the CSS from the blocks
style.scsstotheme.scss, this style is part of thewp-block-stylestheme support, and theme developers can decide if they want to use this style or not.This pull request is a continuation of a style change already made for the group and template part blocks.
This change must be considered carefully because it is a visible change for existing websites.
The change gives developers and users more control, which may outweigh the initial visual change.
All the affected blocks have padding support, except for preformatted (PR).
Users can add the padding back if the theme has support for padding.
add_theme_support( 'custom-spacing' ).The default padding can be added back for all theme types with
add_theme_support( 'wp-block-styles' )Testing Instructions
Sample block markup for testing
Screenshots or screencast
Classic theme (with no custom CSS)
Editor, before:
Editor, after:
Front, before:
Front, after:
Twenty Twenty-Three
Editor, before:
Editor, after:
Front, before:
Front, after: