CC: @nosolosw @sirreal @stokesman just because of the semi-urgency of this issue, I'd really love your thoughts on how to best approach this. To copy from the ticket, here's the crux. We can either:

1. Reduce the specificity of has-background-dim
2. Increase the specificity of every custom theme color.

So either we have unscoped .has-background-dim { ... }, or we go back to having every custom registered color be double-specificity, such as .has-yellow-background-color.has-yellow-background-color { ... }.

Is there a third solution I'm not seeing, which addresses the Cover problem?

Size Change: +23 B (0%)

Total Size: 1.21 MB

_{compressed-size-action}

Thanks @jasmussen!

This may be redundant but I'll add my notes I get up to speed on this:

• Theme-defined background colors were not being respected before Gutenberg 9.2 and custom Cover Block overlay color overwritten by "has-background-dim" #25290
• The cause was (from description):

  .wp-block-cover.has-background-dim { ... } has higher specificity than .has-contrast-yellow-background-color. So previously, users could simply not choose the color of the overlay at all …

• This manifests with custom backgrounds that themes register. An example is the twentytwentyone theme here.
• The workaround for themes is to increase specificity, like twentytwentyone has done here. .has-yellow-background-color adds an attribute selector [class] for extra specificity resulting in .has-yellow-background-color[class] (class selector + attribute selector).

Regarding the possible changes:

Increase the specificity of every custom theme color.

This would return to the situation prior to #25290 and #25290 would be an issue again, is that correct? Initially, that seems undesirable but is preferable to a regression in existing content.

Reduce the specificity of has-background-dim

This seems reasonable although the name is pretty generic.

To mitigate the generic name we could make the has-background-dim class more unique without increasing specificity, e.g. adding a prefix to the class itself: wp-block-cover--has-background-dim. This can be used directly without much concern for conflicting class names in selectors as .wp-block-cover--has-background-dim { }.

Is there a third solution I'm not seeing, which addresses the Cover problem?

I've been thinking about this and have a third proposal. It depends on the following assumption (please think carefully about whether we expect this to hold!)

We can apply the has-background-dim default background only on blocks that do not have another background color class. We can assume that any block that includes -background-color in its class attribute implies that the block has a custom background color that will be set by another style rule matching the has-{{COLORNAME}}-background-color class.

.wp-block-cover.has-background-dim:not([class*="-background-color"]) {
  background-color: #000;
}

It seems that the color classes for the overlay follow that pattern (has-COLOR-background-color), so the attribute selector approach ([class='-background-color']) would work nicely. I'm going to ping @jorgefilipecosta as he has some background (:drum:) on how this works and could confirm if there may be any edge cases to how those classes are generated.

I'm preparing a PR with the alternative I suggested for comparison.

Alternative: #26569

I much prefer #26569, closing this one in favor of that. We can always revisit. Thanks Jon!