Theming Blocks and Components

[youknowriad]

Gutenberg uses a global _variables.scss and _colors.scss SASS variables to share common styling (fonts, colors, spacing, ...) across the code base. In addition to that we can use The PostCSS themes plugin to support WordPress Admin Schemes. For example using theme( primary ) as a color will result in the primary color of the Selected Admin Theme to be used.

This solves the consistency and the admin schemes support issues but it falls short when it comes to:

• Use a consistent "theme" across blocks while allowing themes and plugins to edit these easily. (using editor styles for instance)
• Allow the WordPress npm packages consumers to use the reusable components of Gutenberg but adapt them to the branding of their own products. (tweaking colors, fonts...)

One way of solving this is the usage of CSS variables:

for example, all blocks that render headings (core and third-party blocks) could do:

.my-heading {
  font-family: var(--headings-font);
}

and a theme would be able to change all heading colors from all blocks (even non core blocks) by doing so in the editor styles:

:root {
  --headings-font: "my heading font";
}

This also suggests that these variables are identified, documented and used consistently across core and third-party blocks.

Caveats

CSS variables are not available across all of our supported browsers. https://caniuse.com/#feat=css-variables

We could implement this as a "progressive enhancement" with fallbacks. If the user's browser support the CSS variables, the UI is adapted, otherwise we fallback to the defaults.

[haszari]

Related: #16274

[psealock]

We could implement this as a "progressive enhancement" with fallbacks. If the user's browser support the CSS variables, the UI is adapted, otherwise we fallback to the defaults.

👍 wc-admin currently uses postcss to run theme( primary ) functions which creates a surprisingly large amount of CSS. Introducing CSS variables would be welcome in this regard and allow us to simplify the build step as well.

What would fallbacks look like?

button {
  background-color: yellow;
  background-color: var(--primary);
}

This would mean unsupported browsers render Gutenberg components in their default colors, not Woo-themed, in our case. Is that an acceptable side affect?

[jasmussen]

This would mean unsupported browsers render Gutenberg components in their default colors, not Woo-themed, in our case. Is that an acceptable side affect?

Probably a lead call. But in my opinion, it is absolutely and thoroughly an acceptable side-effect, since it does not affect accessibility, and because of the browsers we support it only visually affects IE11 (released 2013).

[jameslnewell]

CSS variables offer a lot of potential!

One potential blocker could be the current design's use of color functions. Some components use color functions on the color variable e.g. button contains code like color(theme(button) shade(6%)).

I don't know of any color functions that are built into CSS which might mean that moving to CSS variables will require some alteration of the design (@davewhitley has been experimenting with some aspects of this).

[youknowriad]

The reason we use this color(theme(button) shade(6%)) is to support WordPress Admin Schemes. This notation is processed using a PostCSS plugin to generate the right colors for each WordPress Admin Schemes.

I think it's probably possible to avoid these entirely if we rely on CSS variables and just have each admin schemes define its own variables. We'd probably need more "shades" than the one available in the config of each Admin Scheme, but that's fine.

[jameslnewell]

To support the current design, the following color variations will require an additional 13 variables on top of the existing color variables and their shades. While that can be implemented it feels like an intimidating interface for a theme author to achieve their goal.

# primary color
color(theme(primary) shade(15%))
color(theme(primary) shade(50%))

# button color
color(theme(button) shade(5%))
color(theme(button) shade(7%))
color(theme(button) shade(20%)) 
color(theme(button) shade(25%)) 
color(theme(button) shade(30%))
color(theme(button) shade(50%))
color(theme(button) tint(40%))

# outlines color
color(theme(outlines) shade(25%))

# alert colors
lighten($alert-green, 45%)
lighten($alert-yellow, 35%)
lighten($alert-red, 35%)

find packages/components -name "*.scss" -exec grep "shade\|tint\|lighten" {} +

The color variations are limited to a small number of components and a simplified design for these components could be feasible, offering a simplified theming interface for theme authors.

[youknowriad]

The color variations are limited to a small number of components and a simplified design for these components could be feasible, offering a simplified theming interface for theme authors.

yes, I like that. I think we should explore reducing the number of these shades.

[youknowriad]

the alerts ones are not important though as these don't rely on "theme" functions, they can be just static to begin with.

[youknowriad]

Going to close this as a duplicate of #9534 where we explore similar ideas