Feedback: It is confusing that adding background color also adds padding.

[carolinan]

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

[annezazu]

The fifth call for testing for the FSE program also led to similar feedback being shared:

padding added when applying a background seems quite extreme. Could we provide an option to customise the padding? – https://d.pr/i/HQQoof/D4ciOBn8gY

I imagine this will be implemented as more padding controls are explored but wanted to pass this feedback along!

[paaljoachim]

Associated:
Full Site Editor: Applying background color also updates content padding (possible duplicate?)
#36586

[beckej13820]

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.

[kathrynwp]

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/

[annezazu]

This continues to come up in the FSE Outreach Program as well, including the fifteenth call for testing:

I noticed when changing the background color of the post title (in the query block), it meaningfully change the spacing as well (and made the title take up many lines).

Since we have more dimension controls, it would be interesting to iterate on this!

[richiecarey]

+1 on this ... I was very confused why adding a background color to a column would also add padding.

[annezazu]

This came up in the nineteenth call for testing for the FSE Outreach program:

When adding a background color to my post title, the padding automatically expanded A LOT. I had to scroll down, find Dimensions → Padding and click for it to go back to the normal/original dimensions. I was surprised to see when I went to padding that the dimensions I was seeing didn’t seem to reflect the size of the padding on my title – it was set to minimum; yet when I clicked on minimum, while the slider didn’t move, the size of my background shrank.

[jameskoster]

Is there any way to remove this behavior (padding added automatically when a background color is applied) without affecting existing blocks?

[phil-sola]

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) {
padding: 1.25em 2.375em;
}

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.

[talldan]

Is there any way to remove this behavior (padding added automatically when a background color is applied) without affecting existing blocks?

It might difficult to remove it in a backwards compatible way, as the padding is applied using the .has-background class, and it may come from a theme's stylesheet, so it's very difficult to know the value of the padding.

I can't think of any way to safely remove that style without doing something ugly.

Possibly it could be opted out of at a theme level, that way newer themes could gradually move away from this behavior.

edit: worth noting that there's a more in-depth technical discussion about removing it in this issue - #43110.

[carolinan]

Block themes opt out of it by default.

[talldan]

Block themes opt out of it by default.

Ok, I still see it in some blocks in TT3.

[carolinan]

It's supposed to have been fixed in 6.2 🤔 the file that adds the padding isn't supposed to be loaded unless the block theme opts-in.

[carolinan]

I found padding on .has-background for the following blocks:
Columns, paragraph, list, heading.
I believe this CSS needs to be moved to theme.scss so that they are opt-in using add_theme_support( 'wp-block-styles' );

[carolinan]

• preformatted.
  Looks like I might have forgotten to search for the .has-background class without a space.

[s-d-koenig]

The issue is quite old, but just got the same problem with interesting side effects:
When I add a background color to the navigation it automatically adds the padding
ul.has-background {
padding:1.25em 2.375em
}
as inline css.
This applies to the main and subnavigation on the start pages, but on all other pages it is only applied to the main navigation, but not the submenus.
Would be great to get rid of this, because it just blows up the space for the navigation

[jeflopodev]

I recently had problems with opinionated styles. Adding ugly paddings to my blocks when I added background color. I really dislike that WordPress decides that is good for me to add paddings that I don't want. It required me to override them adding extra lines to my block styles in theme.json

IMHO opinionated styles should be removed.

[ohiawins]

Had this problem when creating a page template with content area with black background. Threw the whole site off. Can this go away in 6.5?

Pretty PLEASE!!

[fefa]

+1 very confusing

[VariantT505]

How come this bug is now three years old (!!!) and still not corrected? It should be a priority. It's not a normal behavior to have a padding added (and we don't have any control on it) when we add a background color.

[carolinan]

@VariantT505 It is actually not an easy decision to make and it is not an easy problem to solve in a way that makes everyone -or at least the majority of users, happy.

If the default padding is simply removed, it will change the design of millions of websites, and it will be an unexpected change for many WordPress users. In other words, there is one set of users, like me and you, who wants the padding to be removed, but other users who wants or expects the padding to be there.

[ohiawins]

Hi @VariantT505. I understand your frustration, it is an unexpected behavior AND as @carolinan said it isn't so easy to make this change or decide to change this behavior now that it is implemented in so many sites. I don't understand the intricacies of changing something on this scale but it seems that it's core and if it changes many sites will break.

I think we need to consider that at some point the person (release cycle cohort) who made it this way thought it was beneficial for the community but since then, it is true, we have seen many frustrated people wanting the padding taken away. For a user that isn't proficient in the block editor this can really slow them down trying to find the solution.

Before I started to become more involved in WordPress I was often confused and definitely frustrated with some of the block editor's behaviors. I now realize, after getting involved in some tickets for design and feedback in GitHub that it is a consensus process with many many people involved and trying their best to provide good experience for the user. I would love to invite you to look deeper into the process of making a change like the one you (and myself) are requesting in this thread. Maybe, looking further into it, you will become inspired to be involved. Many of the changes that are made come from people who feel passionate about "fixing" or modifying a behavior.

At learn.wordpress.org there are lots of lessons for helping with and using WP. This lesson, in particualar, came to mind when reading your response. It says:

"Because contributions to open source projects are usually volunteer work, contributors are usually driven by some personal reason to work on a bug or feature. This usually results in a developer (or other kind of volunteer) who approaches a problem with strong motivation and a passion for solving it, plus some personal experience informing their direction and creating empathy for the end users of the feature/program."

You should get involved if you have time. Maybe we can work on some tickets together.

[hadamlenz]

Just popping in to say, +1 confusing. Someone brought this up to me in a meeting today and all I thought was, "there must already be an issue on the WordPress/gutenberg github for this"

[paaljoachim]

I have likely mentioned this before, but when there is a pre defined setting the UI should reflect it, so the user can see that in this case that padding is added and should also be able to see it and can remove the padding with using the UI.

[kradyy]

Following this thread, this needs to be opt-ed out

[medesigngood]

I have likely mentioned this before, but when there is a pre defined setting the UI should reflect it, so the user can see that in this case that padding is added and should also be able to see it and can remove the padding with using the UI.

This is the bare minimum of what should be done regarding this issue. Obviously, automatically adding padding was a bad idea and not even having the UI reflect that was an even worse idea. @carolinan has made the case that

If the default padding is simply removed, it will change the design of millions of websites, and it will be an unexpected change for many WordPress users

Even if we grant that, there still is ZERO reason that has ever been articulated as to why there would be padding (or any other styling value) applied yet not see those values in the panel where those values are edited. This part should be fixed now and not discussed ad nauseam for another 3 years. Make all applied values show in the panel.

[annezazu]

Just chiming in on the latter comment as there's work underway to show some of the style inheritance options including this PR that sets the stage technically. This is related to individual blocks showing inherited values from Styles and theme.json. I'll note this overall feedback on the last issue as I think these various efforts can collide in a way that creates a better experience for all where anything inherited, whether through adding background color or from Styles, can be easily understood.

[jameskoster]

+1 to the idea of allowing themes to opt out of this behavior. Or updating it so that the values come from the spacing presets included in the theme instead of the current arbitrary values.

Even if we grant that, there still is ZERO reason that has ever been articulated as to why there would be padding (or any other styling value) applied yet not see those values in the panel where those values are edited. This part should be fixed now and not discussed ad nauseam for another 3 years. Make all applied values show in the panel.

One tricky part here is that the values can come from .css files, which cannot be read by the control.

Setting padding locally in the editor will take priority in those cases though, so one option we might consider is: when a block has a background color; display the Padding controls automatically. This might make it more obvious how to change the padding, or set it to 0 if required?

[merijnponzo]

i get the idea of a default padding on a bg colored paragraph but this should come from the spacing padding control like other conversations above mentioned.

I ended up with prefix my tailwind theme with a important strategy on 'body'

I hope this padding will be removed soon instead, an opt-out from out the theme.json would be acceptable

[colorful-tones]

With WordPress 6.6 Beta 1 being targeted for tomorrow: June 4 and no assigned developer or pull request for this issue. The Editor Triage Leads will move this to Punted to WP 6.6.1. This is obviously a critical challenge to overcome and I hope that progress will be made. Thanks!

[carolinan]

I'm a wondering why this was moved to a minor release? As opposed to being punted to any future major released and not placed on a board for now. It is not a new bug or regression, nor is there any progress made.

[colorful-tones]

I'm a wondering why this was moved to a minor release? As opposed to being punted to any future major released and not placed on a board for now. It is not a new bug or regression, nor is there any progress made.

I need some clarification on the ask here.

For clarity: Editor Triage Leads for WordPress 6.6 release cycle triaged items to prepare for the WordPress 6.6 Beta 1 release. We aimed to triage items on the WordPress 6.6 Editor Tasks GitHub project board to keep it focused on general Roadmap features.

Since this issue has no associated pull request, we (Editor Triage Leads) decided it would be best to move it to the Punted to 6.6.1 column to try and allow essential items tied to the WordPress 6.6 release cycle to garner the focus. There is currently no GitHub Project board for WordPress 6.7, so this also reinforced our reasoning to move it to WordPress 6.6.1 in hopes that it would be the next release in which it may garner focus and contributor efforts. Similarly, the tasks that reside in the Punted to 6.6.1 often get triaged to the next WordPress 6.7 Editor Tasks board once it is created.

Hopefully that helps clarify how this landed in the Punted to WP 6.6.1 column. @carolinan where would you prefer to see this task reside?

[carolinan]

I only wanted it to be clarified wether it was truly expected for this to be added in a minor release, because usually features like this are not added in minor releases.

Please understand that these boards are also used by contributors who are planning and choosing what to work on next, and to better understand what needs to be prioritised.

[talldan]

I only wanted it to be clarified wether it was truly expected for this to be added in a minor release, because usually features like this are not added in minor releases.

I would agree that it's not going to end up in a minor release. A fix would probably be something to release in the plugin early during a major release cycle. I'll move it to 'Punted to 6.7'.

Is there any way to remove this behavior (padding added automatically when a background color is applied) without affecting existing blocks?

In contrast to my earlier response, I now think it might be possible. The has-background class on existing block could become a custom classname, that way it would still be honored. This would mean it'd be possible to transition away from the behavior of adding automatic padding without breaking back compat.

The potential issues:

• Is it obvious enough for users to know how to remove the has-background custom classname?
• Existing blocks will behave slightly differently to new blocks. This is often what happens when blocks change through deprecations anyway.

I'll try something out on a PR.

[talldan]

Hmm, actually I'm not so sure having looked at it again. It seems like there are a lot of classes like has-background, has-link-color, has-text-color that themes might be expecting Gutenberg to apply, and removing one would cause an inconsistency. Some kind of opt-out per theme or via theme.json is probably still the best idea.

edit: also has-background is used for more than just padding, so we can't very easily stop adding it to blocks.

[carolinan]

maybe a spacing.backgroundPadding that is enabled by default and new themes can opt out instead of old themes opting in?

[merijnponzo]

That's a good idea:
spacing.backgroundPadding : Boolean|String (value)

When it's not in the theme.json and parsed by php it won't affect the current styling. New themes can adopt a Boolean true (which can have the value that it has now). Or a custom value. False, won't add the padding at all.