Improving our saving/rendering of block styles

[youknowriad]

Over time, we build an impressive list of block supports to customize the look of different styles: borders, colors, background, spacing, layout, duotone, typography... but these things have been implemented organically adding one by one and solving potential complexities as we face them. The result is that we have different approaches depending on the styles we're changing and their values:

Inconstency1

• Most customizations apply the changes by either adding an inline style or a classname to the wrapper of the blocks
• Some customizations apply their values in the server because they're more complex than just an inline style (duotone, blockgap, layout)

Inconsistency2

• Most customizations have their values stored in the "style" attribute (which is consistent with global styles)
• Some customizations (presets mainly) store their values in separate attributes (which is inconsistent with the global styles style object)

About the save mechanism (inconsistency 1)

• Applying the styles in the saved markup have the advantage that the block editor customizations are generic and don't depend on WP backend or any backend code.
• Applying the styles on the server have the advantage that we can change the generated styles over time without much effort or impact on the saved content.
• Customizations like that are not "semantic changes", meaning putting them in the markup is just adding unnecessary things to a semantic markup.

Can we solve this by introducing a "styles engine" that has two implementations: one on the server, one on the client. The client implementation is opt-in (used in the editor and also can be used by third-party block editors to render their blocks as needed), the server implementation is preferred for the frontend in WordPress.

About the attribute saved value (inconsistency 2)

Can we solve this by replicating the "style" attribute format used in global styles entirely in blocks (getting rid of the preset values and using the preset format we use in global styles)?

On deprecation and validation

The downside of both the proposed changes above is that it creates a lot of deprecations for all core blocks basically. We discussed in the past whether "style" and "classnames" markup changes should actually be considered invalid content in the past, so potentially we could start by implementing this: Consider style or classnames differences in the saved markup as valid diff (ignore them)

On the block supports

The changes above will impact third-party blocks as well, how to solve the backward compatibility here:

• introduce a v2 for these block supports and leave both implementations?
• or auto-upgrade all blocks including third-party blocks which might be a possibility considering the fact that we won't consider existing content as invalid content.

On the advantages of the new approach

The style engine will be something that we can change over time without deprecations and without breaking changes. For instance we could evolve to introduce fluid typography automatically.

cc @WordPress/gutenberg-core @andrewserong @aaronrobertshaw

[andrewserong]

Thanks for raising this @youknowriad, it's a very welcome discussion!

Can we solve this by introducing a "styles engine" that has two implementations: one on the server, one on the client. The client implementation is opt-in (used in the editor and also can be used by third-party block editors to render their blocks as needed), the server implementation is preferred for the frontend in WordPress.

I love the idea of a dedicated "styles engine" / API that can centrally consolidate and manage the different approaches each of the block supports currently use to implement their rendering. However it gets implemented, it'd also be great to include in scope accessing the generated styles via the REST API (to resolve issues like in #35376). Ideally the rendered markup can be easily matched / paired to the generated styles.

A couple of other parts that would be good to deal with in the implementation: at the moment, block supports that generate a .wp-container-xxx class, do so for each instance of the block, and the unique id number in the class name is random. I was wondering if it'd be good to de-dupe classes and have the class name be deterministically generated based on style values. This way, for very long posts or pages, we can limit the style generation to just the limited set of unique styles instead of one class/style for each block.

For a consumer of the generated markup (either the front end of the site, or a block preview of a post within the editor as in #35376) it'd be great to be able to either fetch the relevant styles generated for that post, or to be able to reconstruct them based on the rendered markup, without requiring access to the raw block comments stored in post_content.

potentially we could start by implementing this: Consider style or classnames differences in the saved markup as valid diff (ignore them)

I really like this idea. Dealing with deprecations surrounding styling changes is a big pain point, and it'd be great to skip it if we can. A couple of points in favour of leaning toward server-rendering block supports styles:

• For large sites with hundreds of pages or posts, it'd be good for changes in block supports styles to happen automatically when upgrading WP/GB instead of having to manually go back and edit posts or pages, or deal with deprecated styles in post content.
• Better separation between the rendered markup delivered over the REST API endpoint for posts, and the styles for that post content. For REST API consumers, I've seen a few use cases where folks need to strip the HTML of styling, and if we can tidy up the output, that might be helpful for folks.

[youknowriad]

A couple of other parts that would be good to deal with in the implementation: at the moment, block supports that generate a .wp-container-xxx class, do so for each instance of the block, and the unique id number in the class name is random. I was wondering if it'd be good to de-dupe classes and have the class name be deterministically generated based on style values. This way, for very long posts or pages, we can limit the style generation to just the limited set of unique styles instead of one class/style for each block.

Yeah, my idea for that is to make the default layout work as a preset #36944

[andrewserong]

Nice, that sounds like a good way to deal with it. I was wondering if it's possible for flex or other custom layouts to use a preset-like approach, too. I did a tiny exploration into more granular classnames (kind of inspired a bit by Tailwind CSS) in #36847 a few weeks ago in case it sparks any ideas. My experiment wound up with class names that were probably a bit too verbose to be practical, though.

[youknowriad]

I was wondering if it's possible for flex or other custom layouts to use a preset-like approach, too

I tried using classnames for the "common properties" of the different types of layouts here #35867 It was too complex IMO and not worth it.

[aaronrobertshaw]

It's great to see us moving to address these concerns, thanks for starting the discussion @youknowriad!

Put me down as another +1 for a dedicated styles engine.

In addition to what has already been raised. I'd like to see it be able to offer more flexibility to where within a block the styles are applied. At the moment, we allow skipping serialization of block support styles on individual blocks. This generally creates problems with theme.json or Global Styles due in part to a limited Elements API. An example of this issue is adding border support to the Image block or the application of block support styles to the Search block.

I was wondering if it'd be good to de-dupe classes and have the class name be deterministically generated based on style values.

This would also be a great addition to whatever solution is implemented.

On deprecation and validation

Deprecations have been a concern for a while as the block supports evolved. It has also lead to increased code to handle backwards compatibility e.g. moving from unitless numeric values to strings containing units for border radius.

A change in approach here might also offer the opportunity to make some code more concise and easier to reason about.

or auto-upgrade all blocks including third-party blocks which might be a possibility considering the fact that we won't consider existing content as invalid content.

I like the idea of being able to auto-upgrade all blocks if possible.

The style engine will be something that we can change over time without deprecations and without breaking changes. For instance we could evolve to introduce fluid typography automatically.

This sounds like a big win to me! Robust but still with the flexibility for us to iterate on it.

[ramonjd]

Thanks for writing up this issue.

More broadly, having a consistent/single, dedicated API to manage styles would be terrific also from a contributor viewpoint.

A case in point: I've been researching into (potentially) adding block support for writing-mode (PR), and have spent some time pondering the question: "Where am I going to put the CSS?"

There are several approaches to follow.

At first my mind turned to block container inline styles, such as we use for padding, margin and many other supports.

No, I might need up to five CSS definitions.

There's also printing out block-specific CSS in a styles tag. Duotone does it this way. Similarly, so does Layout. This would theoretically work, but it would add yet another bunch of rendering code for a bespoke feature.

I haven't yet looked closely at the Elements styles.

With a "styles engine" I'm imagining being able to register styles and styles metadata in a central hub.

The engine would render my posts' consolidated styles to the editor and frontend in the background.

I wouldn't have to concern myself with the rendering engine at all, only my block's styles, saving a bunch of time I would have otherwise spent on worrying about implementation details.

[andrewserong]

I've added a tracking issue to consolidate many of the ideas from this discussion (and to track our work of course). Feel free to add / edit the to-do list items as needed!

[dmsnell]

Consider style or classnames differences in the saved markup as valid diff (ignore them)

Adding a quick note for a tie-in to broader block validation issues. A more robust block-loading process with a stronger "parser" (quotes because it's not parsing text but rather the block attributes and inner blocks that a block is transforming to input) should open up new opportunities to handle this more gracefully.

Your recent changes in #37942 made me think of this, even though that's a slightly different topic. I'll be writing up some issues soon on validation and I'll try to link back here.

[ramonjd]

Starting a project over at https://github.com/orgs/WordPress/projects/19/views/1. We'll be putting meat on the bones and adding issues as we progress.

[michalczaplinski]

Do you also plan to optimize the CSS based on the contents of the CSS class declaration?

In the example below, we generate a single class for a preset, but if the color value is user-defined, it is being set inside of the style attribute of each element.

Screen.Recording.2022-01-27.at.14.00.33.mov

We could solve this by hashing the contents of the css declaration similar to how many CSS-in-JS frameworks do it. Goober is one (and probably the simplest) example:

https://github.com/cristianbote/goober/blob/master/src/core/hash.js#L39-L41

[ramonjd]

We could solve this by hashing the contents of the css declaration similar to how many CSS-in-JS frameworks do it.

Thanks for idea and the link @michalczaplinski !

Do you mean we could create a hashed classname and include all the block's related class properties/inline style definitions?

.wp-block-paragraph-f2e3e {
    color: #eeeeee; // custom color
    // some other styles
}

Could you elaborate or illustrate the idea? I think we'd want to consolidate a block's styles and optimize the output, but I'm not crash hot with the innards of emotion or goober so I thought I'd ask before I check out the project and try it out 😄

Thanks!

[youknowriad]

We could solve this by hashing the contents of the css declaration similar to how many CSS-in-JS frameworks do it.

I see that (optimization based on content) as a secondary goal of the style engine, a cool one though. It is indeed an interesting thing to explore but in our case, it's not yet clear whether it's better over just having customizations per block because basically I'm not sure whether there's enough shared customizations to warrant the extra CPU time to make the optimization.

[luisherranz]

I'm not sure whether there's enough shared customizations to warrant the extra CPU time to make the optimization

Are you worried about the CPU time of the JavaScript engine (Editor) or the PHP engine (SSR)?

[michalczaplinski]

EDIT: This was meant as a reply, not a top-level comment. Sorry for the confusion!

Could you elaborate or illustrate the idea? I think we'd want to consolidate a block's styles and optimize the output, but I'm not crash hot with the innards of emotion or goober so I thought I'd ask before I check out the project and try it out 😄

Upon taking a second look I think you wouldn't even need to hash anything. I think we could have a simple in-memory "cache" (a regular JS object would do) and compare strings:

<!-- wp:paragraph {"style":{"color":{"text":"#40e63c"}}} -->
<!-- /wp:paragraph -->

<!-- wp:heading {"style":{"color":{"text":"#40e63c"}}} -->
<!-- /wp:heading -->

here (once you stringify), the {"style":{"color":{"text":"#40e63c"}}} parts are identical so no need to generate separate CSS rules. That's the gist of it.

I see that (optimization based on content) as a secondary goal of the style engine, a cool one though. It is indeed an interesting thing to explore but in our case, it's not yet clear whether it's better over just having customizations per block because basically I'm not sure whether there's enough shared customizations to warrant the extra CPU time to make the optimization.

What do you mean by "customizations per block"?

I understand your point - premature optimization, etc. 🙂 I'm not sure if this is what you meant but this optimization would make sense only if the engine were to process the styles globally and not per block. If the CSS rules are generated per block then this optimization might not help very much because we you will still end up with duplication. Using a similar example as before, a duplicate CSS rule would be generated for both block 1 and block 2:

<!-- block 1 -->
  <!-- wp:paragraph {"style":{"color":{"text":"#40e63c"}}} -->
  <!-- /wp:paragraph -->
<!-- /block 1 -->

<!-- block 2 -->
  <!-- wp:heading {"style":{"color":{"text":"#40e63c"}}} -->
  <!-- /wp:heading -->
<!-- /block 2 -->

[ramonjd]

this optimization would make sense only if the engine were to process the styles globally and not per block

If we ever get there we also might want to look into exploiting some of cssnano's features on the client side. It's something we already use .

[noisysocks]

Can we solve this by replicating the "style" attribute format used in global styles entirely in blocks (getting rid of the preset values and using the preset format we use in global styles)?

Hey @youknowriad what do you mean by this? I'm having trouble understanding. Could you illustrate with an example? 😀

[youknowriad]

Sure :). Right now when when choose a color for instance, we store it differently depending on the chosen color:

• If it's a "color preset" color, we use the backgroundColor attributes (or text one) and save the slug of the color.
• If it's a custom color, we just store its value in the style attribute of the block.

In Global Styles, we only have "style objects" but we're able to differentiate preset values from static values because the value has the following format var:preset|color|custom-color-2.

My thinking here is that we should unify both and drop the backgroundColor (and similar) kind of attributes from blocks and just use the style attribute for everything.

[noisysocks]

Makes sense!

[cbirdsong]

Would that lead to preset colors being stored as hex values in markup/block metadata instead of instead of using their slug? If so that will make content much less portable.

[youknowriad]

@cbirdsong no, it's more how we represent the value in the block.json and nothing changes for the result/markup.