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
Feedback: It is confusing that adding background color also adds padding. #30725
Comments
The fifth call for testing for the FSE program also led to similar feedback being shared:
I imagine this will be implemented as more padding controls are explored but wanted to pass this feedback along! |
Associated: |
Just want to chime in here with a +1. The confusing thing about this behavior for me is that the padding changed, but wasn't communicated to me in any way. I'm not sure it should work this way, but even if it was, it would be really nice if somehow the new padding number would be displayed to me. Because my user experience was padding was blank before there was a background color and it was blank after there was a background color. |
Definitely agree that this is confusing behaviour. It came up in this forum thread, when a user was confused by the large amount of padding added automatically the moment a background colour was put on a paragraph block within a column: https://wordpress.org/support/topic/how-can-i-make-all-blocks-within-a-row-with-one-height/ |
This continues to come up in the FSE Outreach Program as well, including the fifteenth call for testing:
Since we have more dimension controls, it would be interesting to iterate on this! |
+1 on this ... I was very confused why adding a background color to a column would also add padding. |
This came up in the nineteenth call for testing for the FSE Outreach program:
|
Is there any way to remove this behavior (padding added automatically when a background color is applied) without affecting existing blocks? |
Didn’t realise this issue existed and created another one today based on this issue. Really confusing and frustrating functionality IMO, especially when the UI can control padding easily so the opinionated CSS being applied is irrelevant and more confusing than helpful. My notes from duplicated issue #49230 What problem does this address? I am currently trying to move more and more away from ACF blocks in favour of core blocks, and today while setting up a header template part for my navigation, I wrapped it in a group block to enable the sticky functionality, added a white background colour so the navigation is still visible on scroll, and for some random reason there is padding now added to the group block on the basis that it has a background colour. The CSS being applied: :where(.wp-block-group.has-background) { There is already a padding UI setting for the group block so it makes no sense really for this opinionated CSS to be applied. I can think of some use cases when this may be helpful but it is so easy to add in the UI, it doesn't seem necessary to have a blanket CSS rule on background colours. What is your proposed solution? Remove the unneccesary CSS targeting blocks when they have a background colour to apply padding. It isn't needed and only gets in the way. I could very easily add padding, if that is what I needed or wanted. The opposite isn't true. |
During a user testing session on April 9, several users asked why adding a background color to a block also adds padding, this result was unexpected for them.
Comments included:
Coloring the background of my text, the text automatically moves to the right. I can’t get it back.
Why does the column change size when changing the color in the settings? At least it definitely seemed like it happened that way. That’s unnecessary and unexpected
The text was updated successfully, but these errors were encountered: