Using locally scoped CSS custom properties on generated color CSS classes

[daviedR]

What problem does this address?

Gutenberg will add a combination of 2 CSS classes to the block's markup whenever user set the block color settings:

Setting the background color to red will add these CSS classes: has-background and has-red-background-color.
Setting the text color to blue will add these CSS classes: has-text-color and has-blue-color.

The current generated CSS implementation directly sets the CSS properties with !important value:

.has-red-background-color { background-color: var(--wp--preset--color--red) !important; }
.has-blue-color { color: var(--wp--preset--color--blue) !important; }

This will force the color to be applied to the block's root markup, where the CSS classes added. In some cases, theme designers needs to apply the colors on the inner elements.

For example:

Table block with Stripes style: Setting the background color on the block editor, will apply background color to the whole table. Theme designers might want to use the background color settings for the alternate row color instead of the whole table background color.

What is your proposed solution?

Let's use locally scoped CSS custom properties for the generated CSS:

// Set the variables
.has-red-background-color { --background-color: var(--wp--preset--color--red); }
.has-blue-color { --text-color: var(--wp--preset--color--blue); }

// Apply the variables
.has-background { background-color: var(--background-color); }
.has-text-color { color: var(--text-color); }

The main advantage of this implementation is: theme designers can reuse the color value inside the block inner elements.

If we use this in the previous example, Table with Stripes style:

.wp-block-table.is-style-stripes {
    background-color: transparent; // Reset the root markup's background color, because of the `has-background` class.
}
.wp-block-table.is-style-stripes tbody tr:nth-child(odd) {
    background-color: var(--background-color); // Reuse the background color for alternating row color
}

Another example: I took a look at the Navigation block styling, which is pretty complex. Currently we need to use inherit and !important value to control the submenu colors, etc. With this implementation, it can be simpler, we can reuse the menu background color and submenu background color easier without the need to use inherit and !important in the CSS.

CSS custom properties naming

If --background-color is too general name, we can use more unique naming to the locally scoped CSS custom properties, e.g. --_background-color, --wp--local--background-color, etc.

[cr0ybot]

Yes please. I'm currently doing this in my theme's CSS, which means I have to generate all of the has-foo-color classes manually and it won't extend to custom colors added in the global styles editor.

[daviedR]

Technically, if we can reuse the way (maybe a function) Gutenberg access the global colors list, we can add our own custom CSS based on that list.

[WraithKenny]

I came up with the exact same idea, since I think it's probably a fairly obvious solution. We almost named the vars the same too, lol

As I mentioned on my version, if we use Local vars (custom properties), we could just pass them to a style attribute directly instead of generating a class and obviate the need to use .has-red-color at all. Or, do both.

[simonwimell]

I'm not sure if there are any other ways to vote for Gutenberg feature request, but yes, please! :D