Theme JSON: abstract style/CSS logic and utilities

[ramonjd]

What problem does this address?

I believe there is some styles-related utility logic that could be abstracted away from WP_Theme_JSON.

Maybe some other specific theme logic as well 🤷🏻

WP_Theme_JSON and its test suites are very large and difficult to grok for newcomers, and, I'd wager, their size often contributes the friction one experiences when synching changes between Gutenberg and Core, not to mention frightening new contributions.

Not to mention the fact that, as it ages, it grows even bigger as it accommodates changes in the way WordPress expresses CSS/interprets theme.json.

Related:

• https://github.com/WordPress/gutenberg/issues/62594#issuecomment-2290378937

What is your proposed solution?

@oandregal made a valid point in relation to the separation of concerns:

WP_Theme_JSON should deal with the core functions (sanitization, merging, etc) and delegate the style generation to other pieces.

The style engine is sitting quietly in the corner doing its thing.

It already shares some minor style utilities with theme JSON, e.g., preset var parsing and CSS rule sanitization, and I believe its scope can be widened to house theme.json tree style processing and output.

Possibly, a new class could handle theme.json tree consumption, e.g., class-wp-style-engine-theme.php

Below is a very rough start of an audit of current methods:

theme json	style engine
convert_custom_properties	get_css_var_value + get_slug_from_preset_value
compute_style_properties	is_valid_style_value
is_safe_css_declaration	WP_Style_Engine_CSS_Declarations:filter_declaration
compute_theme_vars	Refactor get_css_var_value + get_slug_from_preset_value ?
compute_preset_vars	CSS var definitions...Refactor get_css_var_value + get_slug_from_preset_value ?
to_ruleset	WP_Style_Engine_CSS_Rule
compute_preset_classes	?
get_property_value	?

I'd propose a gentle introduction would be to:

1. replace the theme_json utils with style engine ones for parsing CSS vars and sanitizing CSS rules, then
2. computing rules such as preset vars, and styles already known to the style engine (for example, colors, typography etc. The style engine has no idea about layout, duotone and other more complex, bespoke style logic).
3. iterating over the theme style node tree
4. ??

[oandregal]

WP_Theme_JSON should deal with the core functions (sanitization, merging, etc) and delegate the style generation to other pieces.

Yeah. Ideally, we should be able to remove WP_Theme_JSON->get_stylesheet and all the related methods.

At a very high-level, in my mind, the piece we need to extract is something that can take a theme.json-like structure and convert it to CSS:

$style_rules = $style_engine->parse( $input, $settings );
$css         = $style_engine->to_css( $style_rules );

Then, we apply this everywhere:

• $input can be any source like the block style attribute, or the theme.json of the theme, or the result of merging all theme.json (WP_Theme_JSON_Resolver->get_merged_data())
• $settings allows us to configure which "rules" to extract: the presets, the block styles, etc. depending on the context (front-end, editor, etc.).

[youknowriad]

This was always the vision for the style engine:

A dependency-free function (or list of functions) that takes a "style object" (aka theme.json config) and generates styles. (Styles in a broader sense: CSS + SVG Filters + Fonts imports)

The other part of the vision is for it to be universal: The same function existing both in server (PHP) and client (JS). The frontend rendering using the php part and the block editor rendering using the JS part.

The style engine would be used for both "global styles" (theme.json) styles but also "block styles" (which right now is a mix of inline CSS, classname based CSS...)

---

Once you have that in place (all styles generated by the style engine), you can also implement some additional nice features like: CSS optimization...

[ramonjd]

Thanks for the feedback!

This was always the vision for the style engine:

The fire still burns in me! 😄 I want to chip away at this when time permits, hence this issue. I hope migrating CSS/style related logic from theme json will be the launch pad for the vision.