Block Styles: Reducing specificity of default block style variation styles

[aaronrobertshaw]

Part of: #57537

Note: This is a blocker for the extended block style variations feature and section styling.

Problem

To support applying block style variations in a nested fashion, the specificity of block style variation selectors needs to be 0-0-0.

The Button block's stylesheet includes some default styles for the Outline block style variation to make its background transparent. If the selector for the Outline style's transparent background is reduced to zero it gets overridden by any button element or Button block styles in global styles.

This is due to the current style load order which is:

1. block library styles including defaults for block style variations,
2. global styles,
3. and finally in #57908 stylesheets for the application of block style variations.

Additional context can be found in #61032 (comment).

Potential Solutions

The ideal order of styles here would be:

1. Block library styles
2. Global Styles
3. Defaults for block style variations e.g. Button Outline's transparent background
4. Block style variation styles

To achieve this, adding support for a new stylesheet for blocks would be beneficial. Perhaps something like variations.scss for block library blocks which can then be collected and enqueued in the appropriate order.

Alternative Option

One long term alternative could be to extend the styles property within the block.json API to allow them to define styles for block style variations. This would allow for dynamically generating these default styles for variations and outputting them when and if they make sense.

This dynamic approach however might not be a silver bullet solution given the potential for style variations to need styling that theme.json does not yet support. It would also need extra work to ensure compatibility across classic and block themes.

[aaronrobertshaw]

Through further exploration, the best compromise option for WP6.6 appears to be:

• Keeping the variation styles that are already within the block library so they are still present for classic themes
• Adding the variation styles to the base theme.json so they are then not overridden by block type/element styles from theme.json/global styles

This approach has been implemented within #61032.

Long term, the alternate option of extending the block.json styles so they are compatible with classic themes too is probably the best bet.

[colorful-tones]

This is being discussed here: #61810

[aaronrobertshaw]

the specificity of block style variation selectors needs to be 0-0-0.

This was incorrect. Block style variations only need "level" specificity so they match the specificity of global block styles as well as other block style variations so they can be nested.

This is being discussed here: #61810

As noted above there was a discussion related to this which has settled upon proceeding with #61638.

The solution proposed earlier is being rolled into #61638 as well.