Extending block style variations as a mechanism for styling sections of content

[aaronrobertshaw]

Proposal

After some explorations into styling sections of content (#55563 & #56234), a consensus was reached that Block Style Variations might be the best mechanism to achieve section styling.

For this to be possible, block style variations would need some enhancements, including:

• Allowing block styles to be registered across multiple blocks e.g. group, column, and columns blocks
• Accepting a theme.json-like style object via register_block_style from which a stylesheet can be generated and enqueued
• Being able to be defined through theme.json regardless of where the block style was registered (e.g. the block style registry)
• Allowing nested block type and elements styles within the block style's theme.json object

This issue will track efforts in achieving the desired enhancements and may evolve as requirements become clearer.

Color and Typeset presets

It is worth noting another current proposal for color and typeset presets. While related, these are still separate in scope.

Enhanced block style variations will provide greater control and opportunity for theme authors to leverage the composable color and typography presets proposed in #56604.

History

This proposal has arisen out of a couple of early attempts to provide styling for page sections that might differ from the overall look and feel of a theme.

The first proof of concept (#55563) looked at implementing section-specific theme.json using a block instance's style object to store that block or section's custom styles. While this was promising and worked, it fell short as these section styles weren't easily shared and reused across multiple sections on a page.

The idea was then to store the section's styles within the Global Styles object which would then also mean it could be initially defined within theme.json.

At this stage, the potential solution began to overlap and resemble potential options for Element Colour Sets, so #56234 attempted to merge this into a single new feature under theme.json called sections. This had several shortcomings and as the discussion evolved, it became clearer that the color sets and section styling were still two separate issues and that the latter could be addressed through enhanced block style variations arriving now to this proposal.

Links

• Section specific Theme.json #40318
• Element colour sets #48581
• Colors and typeset variations from theme style variations #56604

Tasks

There is a draft proof of concept PR covering a large portion of this proposal up in #56540. Progress can also be followed along with there.

• Update block style registration to allow a single block style to be registered across multiple blocks
• Update theme.json processing of block style variations to handle nested block type and element styles
• Add a new global function to facilitate registering block styles across multiple block types
• Make the above new function accept a theme.json-like style object and generate the required stylesheet for enqueuing
• Allow for theme.json generated stylesheets to skip root layout styles
• Update the Global Styles block style variation UI (perhaps allowing further drill down for nested block/element styles) PR
• Update the useGlobalStylesOutput hook to match PHP theme.json processing of block style variations

Future Follow-Ups

Eventually, it would be desirable for a section-section (e.g. group block) to be stylable within the editor and then have that collection of style be pushed to global styles as a block style variation. This would include nested block and element styles.

This would require a major change to the inspector controls style panel and as such is out of scope for the time being.

[oandregal]

Accepting a theme.json-like style object via register_block_style from which a stylesheet can be generated and enqueued
Being able to be defined through theme.json regardless of where the block style was registered (e.g. the block style registry)

This could work differently, if that's easier. We could use a full styles object only for block style variation registered via theme.json, for example. And the ones registered via register_block_style would continue to work as expected.

There is precedent for something like this: the first version of theme.json absorbed features that could be registered via add_theme_support. It added some new behavior to them, such as the ability to add presets at the block level. However, we didn't implement that in the existing theme supports mechanism: the theme.json became the primary mechanism for presets, being theme supports a fallback. The same could happen with block style variations. The ability to register block style variations through theme.json gives us a lever to introduce new behavior.

This is just thinking out loud, in case it helps uncover more of the solutions space.

[aaronrobertshaw]

Thanks for sharing your thoughts @oandregal 👍

I'm not sure I'm following, sorry. Could you expand on it at all?

This could work differently, if that's easier.

The acceptance of a style object is already pretty much working in the proof of concept.

We could use a full styles object only for block style variation registered via theme.json, for example. And the ones registered via register_block_style would continue to work as expected.

At the moment, variations aren't really "registered" at all in theme.json only "defined" if that makes sense. Any variation in theme.json that isn't defined on a block type, e.g. via a block's block.json, is ignored. In #56540, it also checks the WP_Block_Styles_Registry for validation.

One of the primary goals of these enhancements was to allow block styles to be registered across multiple blocks. This would prevent the need to repeat theme.json styling for each block's variation.

Do you have suggestions on how only using theme.json for registration would work for this? Would it require changing the shape of theme.json to allow a new variations property that can be shared or opted into across blocks? That sounds similar to the previous sections theme.json approach that was rejected.

I'm clearly missing something 🙂

[aaronrobertshaw]

Closing this issue as the broader effort, issues and discussions are covered under #57537.