This is a tracking issue for implementing a Style Engine as discussed in improving our saving/rendering of block styles. The goal is to have a consistent API for rendering styling for blocks, across both client-side and server-side applications. The server implementation is preferred for a site's frontend.

Rather than a monolithic refactor, the aim should be to build the smallest implementation possible and land it in the plugin, and iteratively enhance it with small PRs as we go.

In principle, the style engine should be able to receive a style object, and return the rendered styling for that style object, along with any required class names or other data needed to reassemble or use those styles in all required environments. Depending on the implementation, it may be possible for us to avoid or minimise the current reliance on rendering inline styles directly into block markup.

⭐ Current phase - Phase 1: block styles consolidation and refactoring the layout abstraction

Goals:

• To audit and consolidate where the code generates block support CSS in the backend so that they are delivered from the same place (as opposed to multiple places). This covers CSS rules such as margin and padding, typography, colors and borders.
• Removing repetitive layout-specific styles and generating semantic class names for each layout.

Planning discussions

• Style engine: functionality and design #42028
• Future ideas (not there yet)

To-do

The below to-do list is an assortment of shorter-term to longer-term features that would be great to implement. We should aim to not let the longer-term goals block landing the shorter-term goals — but let's try to use the longer-term goals to inform the design decisions for the shorter-term ones.

The approach will be work iteratively rather than treating this as a project that needs to be complete all at once.

• Think about how styles can still be indicated to theme/plugin authors via classnames: Explore options to add back semantic classnames to block wrappers  #38719 and General CSS Concepts: Declaring style vs. describing state #38694
• As a pre-requisite, ignore style differences in block validation: Ignore style validation errors #37942
• Add an initial client-side version of the style engine. WIP PR: Add initial version of the style engine #37978
• Add a server-side implementation of the style engine. PR Style Engine: block supports backend #39446
• Move server-side implementation to package directory PR Style engine: move backend scripts to package #39736
• Consolidate generation of class names for rendered styles (e.g. replace each block support's ad hoc unique class name generation). Related issues: Use of uniqid() in generated CSS class names breaks ability to cache parsed CSS #38889
• Add support for de-duping common or repeated styles so that there are no duplicate styles rendered. Related issues: Group block's generated CSS are redundant. #41434
• Implement mechanism for generated styles to be accessed for post content fetched via the REST API, to fix: Post Content: Layout styles not applied in editor (e.g. Social Icons, Buttons, etc.) #35376
• Come up with an inheritance model, e.g., Global styles > Elements > Block styles > Child block styles etc etc
• Allow generating styles for nested markup (e.g. calculating widths of child blocks, incorporating block gap of the parent as discussed here)
• Create a style engine glossary (documentation) Style engine: update terminology and docs #41964
• Refactor Global/theme.json styles to use the style engine (if at all relevant). Backend in WP_Theme_JSON class, and frontend in packages/edit-site/src/components/global-styles/use-global-styles-output.js. See Style engine: output global styles CSS rules using selectors #40955
• Refactor padding support to use the style engine. Style Engine: block supports backend #39446
• Refactor margin support to use the style engine. Style Engine: add margin support to frontend #39790
• Refactor colors support to use the style engine.
• Refactor border support to use the style engine. Style Engine: add border to backend #40531 Style engine: add border to frontend #41803
• Refactor layout support to use the style engine.
• Refactor blockGap support to use the style engine.
• Refactor typography support to use the style engine. Style Engine: add typography and color to backend  #40332 Style Engine: add typography and color to frontend #40665
• Refactor element (e.g. link) blocks support to use the style engine. Style engine: elements backend support #40987 Tracking: Add a Style Engine to manage rendering block styles #38167 Consider moving ELEMENTS const to style engine once we've dealt with JS global styles
• Refactor duotone support to use the style engine.
• Explore adding support for nested style objects, scoped by pseudo class or media query (to add support for hover/active styles, or potentially different styles based on viewport size)
• Come up with a way to support custom selectors such that inner elements or pseudo states such as hover/focus/active can be targeted and adding support for responsive blocks / media queries. This should also help with styling compound components/blocks such as search, navigation, and table blocks (see styles for blocks with a wide design surface area). E.g., [WIP] Style engine: add elements and states to the backend #41619
• Support being able to render block styles in async contexts (for example, properly rendering block styles for post content fetched via the REST API, which will help address issues like: Post Content: Layout styles not applied in editor (e.g. Social Icons, Buttons, etc.) #35376)
• Create filters for CSS/style engine output and, possibly, general config options such as prettify (context) See also Proposal: Add More Ways to Filter Global Stylesheet Output #45322

Project board

We've started a project board for managing the above tasks over in: Gutenberg Style Engine (view)

Relevant discussions

• General CSS Concepts: Declaring style vs. describing state #38694
• Where blocks end and themes start #35469
• The Block - Theme contract #35470