Color System: A Wonderful World of Color

[ItsJonQ]

(Expanding on this post: #12)

Check out the Story:
https://g2-components.xyz/?path=/story/references--colors

Base Palette

I've started establishing a base color palette within the core style system. The palette has the following colours:

• Blue
• Green
• Yellow
• Red
• Purple
• Orange
• DarkGray
• LightGray

(The values of these colours were derived from WP Admin / Gutenberg).

From that, I've established a spectrum between 100 (lightest) to 900 (darkest) for each color.

Complementary Text Color

Based on the 100...900 colors, the color system also generates a complementary text color, optimized for readability.

For example, blue500 will have a blue500Text value.

RGBA

For each color, the system also generates a range of RGBA values between alpha 10 (0.1) to 90 (0.9).

Backgrounds

For each color, a set of background and backgroundText` have been created with certain colors receiving special treatment for improved color blindness support. These values offer a "bold" variant where the color is stronger. All background + backgroundText values have dark mode supported adjustments.

CSS Variables (get and mixins)

FINALLY! All of this stuff is compiled into a list of CSS variables:

Within the library, these variables can be accessed with the get() function from @wp-g2/styles

The most common use-cases would be to use colours as backgrounds or text colors (rather than using color grade values like red500).

An example of this would look like:

const CustomView = css`
  color: ${get('colorBackgroundBlueText')}
`

It is recommended that getBackgroundColor and getBackgroundColorText mixins are used instead, as these have color-blind support built into them.

The complete picture

There are multiple parts within the system that work in concert to create simple and cohesive experience when it comes to using colors.

1. A collection of color values that make up the palette
2. Generated complementary text colors optimized for readability (contrast)
3. Generated RGBA colors
4. Color-blind supported background color mixins
5. Color tokens (JSON) -> CSS Variable compiling
6. CSS variable injection + sync
7. Seamless CSS variable referencing (via get or mixins)

Point #1 - #6 are all at the core system level.
Point #7 would be where most devs/designers will be working with colors.

[jasmussen]

(⊃｡•́‿•̀｡)⊃━☆ﾟ.*･｡ﾟ

For WordPress and the block editor usage specifically, we have intentionally moved away from having multiple shades of each color, and even colors in total, for a number of reasons:

• A principle for the recent G2 redesign efforts was reduction, not just in shapes and borders but in colors as well.
• Reduction also makes the UI amenable to wp-admin color schemes, which in many cases are (or should be) limited to one or two spot colors.
• When there are fewer total interface colors (shades of gray) available when you design stuff, it is more likely that you pick a color consistent with what's used elsewhere.

There are efforts underway in https://core.trac.wordpress.org/ticket/49999 to revisit wp-admin color schemes. That's an opportunity to look at a rainbow of spot colors and a limited set of grays to go with those. That could very much help inform the needs for a more elaborate color system. And it's a good point to discuss whether such a system should have a "red-300" and a "purple-700" if they end up never being used in the interface.

[ItsJonQ]

🤗 Thank you for your insight!!

And it's a good point to discuss whether such a system should have a "red-300" and a "purple-700" if they end up never being used in the interface.

That's a good point. I've personally only used 1-3 shades from a typical collection of 100...900.

I just made an update that removes 200, 400, 600, and 800. Each colour has been reduced from 9 to 5.
I've kept the RGBA 10->90 variants, which the components rely on more actively (all based on color500)

With the current system, 4/5 of them are being used for colour computation.
color100, color300, color500, and color900 are used for...

• Preferred shade for light/dark mode
• Generated most readable text complementary colour given a coloured background
• RGBA shade generation

We can still trim them if needed :).

For the most part, the component layer will use things like get('colorBackgroundRed') or get('colorPositive') rather than directly referencing get('color500'). IMO, that's how it should be as it's easier to remember and read. Having that layer will also help maintain consistency, keep deviation(s) under control, and provides us with some flexibility in adjust the underlying 100...900 shades if required 😊

[jasmussen]

Fast response times in this repo! 5 shades in my personal opinion seems far more reasonable!

More importantly (and something that I'm perhaps just realizing now) is that there's a component-technical aspect to this in that it's nice it can handle a system of colors, any color set, that clients can use, and in that vein the fast tweak to the system feels promising.

Looking at this from a WordPress/Gutenberg lens, most of these colors would need tweaking or adjustment and perhaps even further reduction/changing (neutral gray, the right shade of blue etc) — but that feedback is probably worth not addressing here, but rather a bridge to cross if this were to be adopted at one point.

[ItsJonQ]

Closing this up! The color system seems to be holding up well.