A new mechanism called theme.json that allows themes to control various aspects of the block editor, from presets to settings to the appearance of blocks, was introduced in WordPress 5.8. There are some cool things that can be done with it already, but I wanted to briefly explain what I think are the more substantial and interesting aspects it starts to unlock:

Interactivity. Style attributes are a subclass of block attributes. As such, the entire block universe understands their values and the interface gets hydrated with it. This means the same ruleset a theme author uses to build a theme is accessible via a graphic interface for the user to interact with. This is huge for opening up an area that used to be closed to users (or required a bunch of ad hoc work from a theme) while also giving the theme the ability to control boundaries and defaults.

Consolidation. Remove overhead from repetitive declarations on themes, particularly around supporting block features. Themes don’t need to concern themselves with structural styles and can be freed to use CSS for specific visual flair, enhancements, and details.

Compatibility. Given it speaks the language of blocks, it is by default compatible with third party blocks provided those blocks are using the core APIs. This can be transformative for the ecosystem where you don’t need to worry if a WooCommerce block would fit with your site design — it will.

Performance. The framework can generate the right bundles on the front based on what content is used. We are barely scratching the surface here as block themes start to roll out but the improvements can be massive. A theme no longer needs to pay the penalty of loading styles for widgets that may or may not be used on a given page.

Flexibility. It opens the door for mixing and merging different block style recipes. For example, you can bring your definitions for block x and z from one theme and keep y from another. You can do this knowing there will be no selector conflicts! This makes it trivial to transfer brand definitions for a family of sites or say “I want to make the buttons of my site look like this theme” without losing any other customization. Specific customizations could also be retained if desired upon theme switching. We are also barely scratching the surface of what can be possible here.

Visual parity. It goes without saying, but the representation of visual aspects in a shared format also allows the platform to ensure the editor and frontend, no matter their setups, can be in sync. The need for editor-stylesheets (which are historically inaccurate and hard to maintain) should be drastically reduced or disappear entirely.

Patterns. This has not been mentioned much, but with theme.json it’d be fairly trivial to send the theme style specification down the wire to the .org directory as structured directives so that you can preview and browse patterns using the actual context of your theme styles!

Portability. The design structure can also be used in contexts outside a theme — think native apps, RSS feed readers, emails, agencies can control look and feel of ads, etc. There’s essentially a coded recipe for how a site looks and feels that is easy to extract values from and use in different contexts.

Accessibility. Tools that tend to be rudimentary (like color contrast) can now properly understand the context of any value because the nested scope of each block is a traversable aspect ahead of rendering time. It’d be possible to generate a higher contrast flavors of an entire site automatically. Similar with dark mode.

Admin. This is more outlandish, but there’s also the possibility to use certain definitions to customize aspects of the look and feel of wp-admin based on the current site design without having to duplicate work or target things specifically.