Update @wordpress/base-styles and replace deprecated variables

[samueljseay]

Fixes #4732

This updates @wordpress/base-styles, and because @wordpress/components depends on variables from it, that must be updated as well.

There are 3 major changes required as part of updating:

1. The $theme-color variable is no longer exposed by base-styles. Instead there are 3 css vars exposed. These are made available by use of a provided mixin. Situations where $theme-color was darkened using scss have been mapped as best as possible to the 2 other darkened shades of the css var that are available such as --wp-admin-theme-color-darker-20 and --wp-admin-theme-color-darker-10. In some cases this means the colors are not exactly the same as before.

2. The post css theme() call is no longer available. All uses of this have been consolidated to use of the main theme css var --wp-admin-theme-color. This means that calls like theme(secondary) or theme(outline) etc have all been consolidated to the one color.

3. Many of the variables used for different shades of gray have been deprecated. These have been mapped across to the new gray variables. (Mapped according to the list described in Update deprecated color vars #4732)

Accessibility

• All text has at least a 4.5 color contrast with its background

Screenshots

One notable difference is the hover color of calendar days on the date picker. Due to there not being any use of secondary any more the color change is more subtle. Gif below:

Detailed test instructions:

See the testing instructions from #4558

Theme color settings should match those in the user preferences, but now just shades of the primary color from the theme.

Additional note

I've reached out to Jay to request that he take a look at the approach taken with consolidating colors here. But other reviews are welcome!

[psealock]

This is looking great @samueljseay, thanks for the cleanup.

The code looks good, but 2 comments: One for @jameskoster and the other about removing our usage of core-* colors.

@jameskoster, this changes the button colors away from Core WP's buttons. Is that the intention for Gutenberg?

Core WordPress button on Ectoplasm theme:

WC-Admin button after this update, also on Ectoplasm (previously it looked just like above):

[psealock]

I see that these overrides existed before this PR, but I'm having trouble remembering why they would be here. We're just taking colors handed down from Gutenberg and reassigning new colors. Shouldn't we just use $gray-900 instead of our own $core-grey-dark-900? If I'm understanding correctly, we should replace every instance of $core-grey-dark-900 with $gray-900 in an effort to remove our _colors.scss.
I think this is what is intended by #4732.

[jameskoster]

+1. The only color var we should create is the WooCommerce purple, for the very few cases in which we need to use it.

Edit: Oh, and the colors we use for the charts in Analytics :)

[samueljseay]

Thanks I wondered about that one. Most of this was just a find replace. I'll fix this.

[jameskoster]

@jameskoster, this changes the button colors away from Core WP's buttons. Is that the intention for Gutenberg?

The buttons should match core. FWIW they are matching for me on this branch 🤔

I noticed a few small details that are off though. I'm not sure if they're all 100% down to us, or should be addressed in this PR, but I'm going to list them here anyway :)

• Hover state of the quick links
• The little purple 'active' square in reports
• Button focus state in filter creation
• Focus state on filter row
• Focus state on selects in filtering

The purple / blue details in the screenshots above should be mapped to the theme color.

[samueljseay]

@jameskoster @psealock

How can we match other colors from the theme now that base-styles only exposes 3 shades of just one color of the theme?

(ie if we want the buttons to be green in the Ectoplasm case)

[jameskoster]

For the buttons in particular we should be using the core component out of the box with no overrides, so the theme color should be applied automatically.

For our custom components, maybe we can look at core components for implementation inspiration there? I assume they tackled this issue already :D

[samueljseay]

@psealock @jameskoster I have tried to be pragmatic about the refactoring of all the grays here, will need some feedback.

I found that if I tried to map everything directly to a gray that exists in the @wordpress/base-styles that it dramatically changes the look and feel of screens like analytics and the actions side menu, it makes the entire UI look quite dark and in many places worse if we try to map things as best as possible. I really struggled with this, because I couldn't actually make it look right and with no real baseline to go against I think this approach wasn't going to work.

I have opted instead to introduce one more gray variable for WooCommerce. The gray is called $gray-50 and is lighter than any grays in base-styles, but allows us to map most other grays in a better way, it is a blueish light gray shade that existed already in Woo and was used in various places. My thought is that we could look to refactor this gray away later but I think it would require a refactor of the design for those screens like Analytics that heavily rely on grays throughout.

2 relevant commits:

1. I adjusted some direct mappings of one gray to another that felt wrong and made the UI look "wrong": ffe9c16
2. I introduced a new gray variable "$gray-50". I have used it sparingly to recreate the look and feel of existing screens: cdff94e

Also I have mapped existing grays:

• Replace dark-gray-primary with gray-900
• Replace medium-gray-text with gray-700
• Replace core-grey-dark-900 with gray-900
• Replace core-grey-light-100 with gray-100
• Replace core-grey-light-200 with gray-200
• Replace core-grey-light with gray-100
• Replace core-grey-light 400 & 500 with grey-100
• Replace core-grey-light-600 with gray-200
• Replace core-grey-light-900 with gray-400
• Replace core-grey-dark 150 with gray-600, remove core-grey-dark 100,200
• Replace core-grey-dark-300 with gray-700
• Remove core-grey-dark-600
• Replace core-grey-dark-400 with gray-700
• Replace core-grey-dark-500 with gray-700.
• Replace core-grey-dark-700 with gray-900.
• Replace core-grey-dark-800 with gray-900.
• Replace core-form-grey with gray-700

[samueljseay]

For the buttons in particular we should be using the core component out of the box with no overrides, so the theme color should be applied automatically.

For our custom components, maybe we can look at core components for implementation inspiration there? I assume they tackled this issue already :D

@jameskoster I DM'd you a question about this, but I'll also put it here:

Do you mean the Gutenberg button component in @wordpress/components? The reason I ask is, I had a look at the
code there and it indeed only deals with the theme css color in varying shades that is provided by base-styles.
So to me there are a couple of issues here, maybe you can clarify your thoughts on them:

1. Gutenberg is moving towards using just a single color from the theme throughout the base look and feel.
   Older WordPress buttons don’t do this, they use multiple colors from the theme
2. I just don’t know how we can use multiple colors from the theme if we’re just picking up the only css vars we now have available, which are three shades of one theme color? In the ectoplasm it is just the purple that is exposed.

[jameskoster]

Adding a TLDR of what I said on Slack:

We should align our colors with Gutenberg. In this case that means wc-admin buttons with the Ectoplasm theme active should be purple. This is different to wp-admin where they are green, but matches Gutenberg, so that is fine.

---

I noticed these small issues are still outstanding;

• Hover state of the quick links
• The little purple 'active' square in reports
• Button focus state in filter creation
• Focus state on filter row
• Focus state on selects in filtering

Wherever you see the Woo purple, or blue in the screenshots above, let's use the theme color var.

---

Let's try to avoid adding a new custom gray variable, it will only cause headaches down the road. If you can set everything currently using your gray-50 var to gray-100 I am happy to go through with a fine-tooth comb and make adjustments :)

[jameskoster]

Opened a PR on this branch here, to remove the gray-50 var and harmonise the home screen (and some analytics) colors.

[becdetat]

Everything looks good to me apart from a couple of small things after a quick smoke test and scanning the code changes.

[psealock]

Nice job on this one team and especially @samueljseay for seeing this one through