Use of CSS :where as a class selector can be too specific

[markhowellsmead]

What problem does this address?

Using main :where(h1,h2,h3) (specificity 0,0,0) is less specific than main h1, main h2, main h3 (specificity 0,0,2) because using :where in this scope has specificity zero.

However, using .wp-block-columns:where(.has-background) (specificity 0,3,0) is more specific than .wp-block-columns.has-background (specificity 0,2,0) and offers no practical benefits.

This specificity makes it slightly harder to overrule in theme and plugin CSS.

What is your proposed solution?

Don't use :where as an alternative to a straight class selector. Previously, CSS on the columns block was .wp-block-columns.has-background and the change to .wp-block-columns:where(.has-background) has a negative effect and offers no benefits.

[bph]

We don't have a label for "What is the reasoning behind the change" - I feel the Help Request comes the closest for now.

[ZebulanStanphill]

According to MDN docs, :where always has 0 specificity.

[glendaviesnz]

According to a specificity calculator that understands Level 4 selectors .wp-block-columns:where(.has-background) has a specificity of 0 1 0 which is for the .wp-block-column class. In theory it would only be 0 3 0 in an environment that didn't support level 4 selectors, and so would take into account the second class name and the pseudo selector.

I know there has been some discussion about whether :where should be used due to the fact that older versions of evergreen browsers (that some users can't upgrade for whatever reason) don't support it. @markhowellsmead - are you seeing .wp-block-columns:where(.has-background) being calculated as 0 3 0 across different browsers, or just in a specific environment?

[markhowellsmead]

The specificity calculators return different results. The one you've linked seems to be more up-to-date than https://specificity.keegan.st/, so I'll use that as a reference.

After further research and testing, the problem may not be due to the use of :where after all. (Although the use of :where at all is questionable because of browser support. Over 12% of current browsers don't support it at all.)

The problem is when I try to override the inline rules like .wp-container-24 > :where(:not(.alignleft):not(.alignright)). The specificity of this is 0,1,0. Using the selector .wp-block-sht-category-navigation in the theme CSS is also 0,1,0 and so it should be able to override the inline rule. However, it cannot because inline styles take precedence over any linked stylesheets. (style tags directly within the head.)

The additional fact that the inline styles already use !important mean that they're all but impossible to override without inlining our own CSS. Inlining CSS causes performance issues because the CSS cannot be cached, but has to be loaded on every page request.

See also #36135, #35840, #34047, #29705, #17511.

[markhowellsmead]

Closing this in favour of #40159. (The issue is with inlining the CSS, not with :where.)