Allow registering additional CSS selectors for blocks (to be used by theme.json)

[oandregal]

This issue stems from this conversation #34141 (comment)

The issue

1. There're components of the design for which we don't have a way to change all "components of a type" at once. For example, it seems desirable that the button block, the button within search, and others are addressable all at once.

2. There're components of the design that can't be addressed yet. For example, the button in the search block.

Proposal

Ideally, complex blocks use the button block internally, which would solve this issue - styles set for core/button via theme.json would target all the buttons. I understand there may be valid reasons why blocks can't or don't use inner blocks. It may be also difficult to convert the button to an element. I'd like to offer alternative thoughts.

Right now, namespace/blockname in theme.json resolves to the CSS selector of the block: by default it'll be wp-block-namespace-blockname and blocks can define their own by using the __experimentalSelector support flag. For example, core/button resolves to .wp-block-button__link.

The idea would be that we allow registering additional CSS selectors for blocks. As a result, this:

{
  "core/button": {
    "color": {
      "text": "color-for-text",
      "background": "color-for-background"
    }
  }
}

would be converted into the following CSS:

.wp-block-button__link, // The selector for the button block
.wp-block-search__button // Additional selector (e.g.: button of the search block)
{
  color: "color-for-text";
  background-color: "color-for-background";
}

Implementation

It could be:

• Block-driven. It's the block's responsibility to attach the additional selector. We enable the search block to say "I want the styles of the button block applied to my inner button".

• Theme-driven. It's the theme's responsibility to attach the additional selector.

I haven't explored all the ramifications of this idea but wanted to share and see what others think.

[jffng]

This is interesting because it touches on some key benefits of the global styles system — including consolidation, compatibility, and flexibility of styles provided by the theme and blocks.

The idea would be that we allow registering additional CSS selectors for blocks.

Being able to register additional CSS selectors would provide more flexibility and address a case like button styling consistency. But I worry about opening up potential for unexpected style clashing due to nested selectors, especially if it were opened to the theme to decide.

If it were to be implemented, I think the block-driven approach would result in more predictable style configurations, especially when considering there are core + theme + user styles to merge.

To address the first issue you raised, I like the proposal to extend the elements API: #34198

[scruffian]

i think this will happen using elements: #40966