custom Cover Block overlay color overwritten by "has-background-dim"

[mapsteps]

Describe the bug
When adding a cover block and picking a color registered by a theme/plugin, the "has-background-dim" class overrides the custom class styles that's added by the theme/plugin.

Here's the CSS classes constructed for the cover block:

class="wp-block-cover has-wpbf-palette-color-2-background-color has-background-dim"

The problem is that the "has-background-dim" class is added AFTER the "has-wpbf-palette-color..." class which makes it override the color.

Because the color tweak is the "more granular" change, the "has-wpbf-palette-color..." class should be added at the end, after the has-background-dim class.

To reproduce
Steps to reproduce the behavior:

1. Create a color block
2. Choose a custom overlay color that was previously registered by a theme
3. Update the post/page & check the result on the frontend.
4. Notice that "has-background-dim" has a higher priority as the custom color added by the theme

Expected behavior
The "has-wpbf-palette-color..." class should be added after "has-background-dim".

Editor version (please complete the following information):

• WordPress version: 5.5.1
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? Default

Desktop (please complete the following information):

• OS: Windows
• Browser Firefox

[luminuu]

Actually the order of the CSS is correct, the issue here is the specificity for the .has-background-dim class. While color palette classes are just defined as a single class, in this example: .has-wpbf-palette-color-2-background-color, it only has a specificity of 0-0-1-0.

However, the .has-background-dim class that is added by the default block editor styles, has a higher specificity, as the rendered CSS creates the following: .wp-block-cover.has-background-dim which has a specificity of 0-0-2-0, therefore overwriting the later defined class.

I guess the solution would be to add a space between the & and the class name over here:

gutenberg/packages/block-library/src/cover/style.scss

Line 30 in 84cbc5f

&.has-background-dim {

I think this is somehow related to #11779.

[mapsteps]

Hey @luminuu,

you're right. I totally overlooked that. The custom color would have priority ofer the "has-background-dim" class if it wasn't "tied" to the "wp-block-cover" class.

Adding a space would solve this.

[youknowriad]

Hi there! did you try using the Gutenberg plugin? I think we fixed this recently and it's something that might come in the next WP major release.

[luminuu]

I have activated the Gutenberg plugin on my development site where I have this issue and it did not fix it. Still having the black color instead of the selected background color on the frontend.

[luminuu]

So I set up a development environment with Gutenberg and changed the mentioned CSS to have a space. Sadly this breaks the default functionality alltogether, so it does not seem to be an option.

Checking how other themes handle this, I assume it's easier to adjust the theme's CSS to either one of these options:

:root .has-wpbf-palette-color-2-background-color

or

.has-wpbf-palette-color-2-background-color[class]

But then the documentation on color palettes needs to be updated.

[webmandesign]

Hi,

I experience the same issue. I don't think rising specificity of theme color classes is the way here. There are other issues with colors in Gutenberg since WordPress 5.5 update and I don't get any luck having them resolved in the plugin while they still cause issues on websites.

I went ahead and adapted the specificity of theme color classes as a temporary fix, but that's really not ideal way as I either need to use !important or simply rise the specificity with some ridiculous selector nesting...

Could anyone from plugin developers please provide feedback on these issues?
Why there are even custom colors applied on blocks by default?
I suggest doing an audit of colors applied on blocks by default and removing all the obsolete ones.

Thanks for any info provided!

Regards,

Oliver