Style Engine: refactor global/theme.json styles to use the style engine

[ramonjd]

The proposal

The Style Engine generates CSS for block styles in WordPress, and hence knows how to parse block style objects.

Given that theme.json shares the block style object data model, it now should be possible to use the Style Engine to parse global style objects as well.

There will be some exceptions, and it's going to be a big job.

This goal of this issue is to break down and track the tasks/investigations.

Tasks

• Generate CSS for global stylesheet: might involve replacing the WP_Theme_JSON::compute_style_properties WP_Theme_JSON::to_ruleset methods with the Style Engine in WP_Theme_JSON::get_styles_for_block(). The Style Engine can accept a single theme.json style node and a selector.
  • Possibly Start with top-level global styles, then elements, then blocks, then layout... etc
  • Ensure we correctly handle elements and pseudo elements
  • Ensure we correctly handle custom CSS var handling such as blockGap
  • Following from above, we might have to cater for CSS var —wp—style—root— properties and PROTECTED_PROPERTIES if we're skipping compute_style_properties calls in get_styles_for_block.
  • Add support for block.json __experimentalSelector. These are the block support selectors that can be defined in block.json. Can be done by refactoring the relevant logic in WP_Theme_JSON::get_styles_for_block(), and building nodes instead of declaration arrays.
  • Explore how to manage or deal with CSS rules that are not covered by safecss_filter_attr — for example, there are rules that might be applicable to global styles (e.g. setting display: flex on flex layouts) that are suitable for global styles rules, but that should not be exposed generally for users without the unfiltered_html capability.
  • Should there be a lighter-weight way to add allowed / approved CSS rules for output that are more broad than the global values allowed by kses? E.g. if we were to allow transitions, transforms, or other fancy styling features in global styles, that we might not want to expose for all WordPress users.
  • If output is moved away from compute_style_properties, update settings and styles validation to ensure that rules output via global styles are allowed for users without the unfiltered_html capability.
• Come up with a way to enqueue global styles, for example, by replacing/refactoring gutenberg_enqueue_global_styles , taking into account the logic in gutenberg_add_global_styles_for_blocks that enqueues block styles separately via wp_should_load_separate_core_block_assets()
  • Need to ensure that, if we store the global styles, that they’re printed first. Add a priority option?
• Migrate away from preset values to use only the style object for blocks, see comment: Improving our saving/rendering of block styles #37495 (reply in thread)

More to come...

Previous, and maybe relevant, investigations

• 🚧 WIP: Use the style engine in global-styles 🚧 🧪  #48955
• Use the style-engine in global styles #42893
• Style Engine: Try adding blockGap support #43076
• Style engine: output global styles CSS rules using selectors #40955
• Style engine: generate root global styles from global styles object #42143