Blocks with ad-hoc UI controls, global styles, and patterns

[oandregal]

The recommended way to add styles to a block is via the block support mechanism. However, that's not enough for certain situations and blocks: blocks that want the UI control to update styles in an inner HTML element of the block, blocks that want the style to be coordinated in a number of properties.

One of the latest examples I've ran into was the search block. This effort has gone through some iterations:

• Try using ad-hoc UI controls. Search Block: Add support for setting the border radius #25553
• Try using the block support system (automated UI controls). Search Block: Add border radius #27664
• Try adding CSS variables in the block's CSS. Search Block: Add border radius support using CSS variable approach #27991

While the block support mechanism is the recommended way to add support for styles, in this particular case the whole experience would be odd and it sounds like this block would benefit from a custom UI control. This isn't specific to the search block but we've ran into this with other blocks (IIRC, with the social links).

---

While some blocks may need ad-hoc controls for style properties, I see two issues with allowing them:

1. How those blocks can be styled (in a predictable way) via global styles?

At the global level (theme.json), we only allow style properties that are supported at the block level (supports object in block.json). Each block may declare support for a subset of all the style properties we support. The current mechanism we have attaches the styles to the wrapper node (block level) or outputs a single style rule for the block in a new stylesheet (global level).

Allowing ad-hoc UI controls that aren't "managed" by us, poses a few challenges:

• Target inner markup: at the global level, the selector for the block could be anything. So, core/search in theme.json could be compiled to .wp-block-search .some-inner-class in the resulting stylesheet. It departs a bit from what we've done so far that the generated block selector targets some inner markup. I think this should be evaluated block by block.

• Target many elements at once: we don't have a way to do this at the global level, there's a single style rule generated per block.

• If custom blocks use style properties we don't support, we don't have info about what needs to be done at the global level.

2. How those blocks can be used in patterns?

To add style to patterns themes add inlines styles. Those inline styles need to be "managed" by the block support system. Blocks can't have any random property as inline styles, otherwise, they'll be invalidated because the style property can't be regenerated from the block's attributes. Example with a regular block:

• Insert a block in the editor.
• Open the code editor and add style="text-shadow: 1px 1px 2px pink".
• Publish the post and load the front-end. The style should be present.
• Go back to the editor. Switch back to the visual editor or reload the page so the parser & validation process kicks-in.
• The block will be invalidated.

So, if blocks use the supports mechanism they can have inline styles. However, for blocks that don't, what's the way forward to support patterns?

[oandregal]

I've revisited this and edited a bit the issue description to better capture what's the issue. I've also ran this by some folks to clarify my thoughts.

Here's my current thinking:

1. How those blocks can be styled (in a predictable way) via global styles?

There are some issues in here that I think we may want to revisit later in the development of the block style system, such as being able to offer a coherent user experience for blocks with inner blocks (e.g.: exposing in the parent block some tools that affect the inner blocks).

There are other issues that I'm not sure the core editor should tackle. If a block needs a very special interaction it's fine it uses ad-hoc controls, although that means it can't use the "global styles" mechanics either.

2. How those blocks can be used in patterns?

I've noticed that there's a property that probably faced a similar issue: the class markup attribute. There are some classes the block editor "manages" (presets, align) and other that it doesn't ― it seems that the custom class name block attribute was created to support the "unmanaged" ones. An potential option would be to follow this pattern and create a "custom styles" block attribute that gathers the styles the block editor doesn't manage. It doesn't need to be shown in the UI.

The other answer to this would be recommending not to add inline styles in the patterns but target those via a theme stylesheet instead.

[oandregal]

Going to close this one as there's now a plan to alleviate some of these struggles at #28913