Styles for blocks with a wide design surface area

[oandregal]

This is for gathering thoughts, so we can support well blocks with a wide design surface.

People working on blocks such as the table, navigation, search, quote, and others have reported that the number of design tokens available to them is not enough for the things we want those blocks to do.

I'll illustrate this with colors, but the same can be argued for any other style property (see #33232 for a related example). We allow 4 types of colors via block.json supports and theme.json styles: text, background (gradient as a variation of background), link, and border. Some blocks need a few more, as these images illustrate:

Table #33157

Pricing	Contacts	Contacts

Navigation #29963

Transparent + White	Single color	Transparent + Color

What approaches do we have available?

So far, approaches used to account for this include:

1. Split the block into smaller ones.

This is the way that is most natural to the blocks model and works well with block.json and theme.json. Cons include that it doesn't cover all the cases and that results in a bad user experience in other cases: to change the color of all children users need to select one by one instead of being able to change them all in the parent. It could be minimized by allowing the parent block to absorb the children's design tools.

2. Use custom controls.

This addresses the issue for the block styles sidebar (user-facing). It doesn't for theme.json (theme-facing) and the global styles sidebar (user-facing) because there's no way to register custom styles and controls, respectively. There's some progress for the new UI for global styles at #32923 so work on allowing custom styles and controls may need to wait a bit.

3. Allow more properties via the block supports mechanism.

This has been talked about in a few places. Some ideas to do this include:

Introducing the concept of "color sets" as in #33157 A way for blocks to register their own colors via block.json and target them via theme.json. The same could be expanded for any other style property.

Expanding the concept of "elements" introduced at #29891 Elements already exist in the theme.json styles and the plan is to make them visible to users in the global styles sidebar. Presumably, also in the block sidebar. While the engine can provide "default" elements (at the moment, only link and h1-h6) we'll likely need to allow custom elements per block as well (e.g. the header and footer for the table block). This has been touched upon at #33157 (comment)

[oandregal]

Closing this as it no longer reflects the reality of the styles sub-system.