Calypso Color Schemes: Scope the accent variable for GB components.

[jasmussen]

Fixes #98823

Proposed Changes

This PR removes the following code from the _default color scheme, which is the scheme that runs on the WordPress.com hosting layer:

--wp-admin-theme-color: var(--color-accent);
--wp-admin-theme-color-darker-20: var(--color-accent-60);

Note, this is not to be confused with the open WordPress core default color scheme, which is actually called "Fresh". That's this one:

That color scheme is still set by default for new Atomic sites, but for new Simple sites, the Modern scheme is set:

The issue at hand here is, that if you have the classic blue color scheme set, the one that uses the legacy WordPress blue, for the moment you still see the modern Blueberry color applied inside the site editor:

What you really should be seeing, and what this PR accomplishes, is the same accent color on the primary button, as is applied to other primary buttons in your admin. The classic blue:

The problem is, that the CSS above, assigned at the :root level, and gets included in this same unscoped form via the Help Center (click the (?) button in the top left of the site editor). Through its inclusion there, it bleeds into the WordPress admin itself, and overrides the local admin color scheme.

So basically, WP.com hosting dashboard modern scheme overrides only parts of the wp-admin color scheme.

Testing Instructions

• Create or use an atomic test site.
• Go to the wp-admin of this test site, then Users > Profile. Ensure the color scheme is set to "Default", which uses the legacy blue.
• Ensure a block theme or hybrid theme is activated.
• Go to Appearance > Editor > Patterns, or Appearance > Patterns, depending on what type of theme you have.
• The add new patterns button should be legacy blue, not Modern blue.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:commit-729bcb1c19a19e1c02f42f1acf2dc4f4c381ef42

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:commit-729bcb1c19a19e1c02f42f1acf2dc4f4c381ef42&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:commit-729bcb1c19a19e1c02f42f1acf2dc4f4c381ef42&env=a8c-for-agencies

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[jasmussen]

I'd love your input on this draft PR. It's draft because it removes a couple of variables. But in my testing of Calypso and other instances, removing that one section that overrides Gutenberg components does not cause issues. But I'd appreciate your input in case there's a better fix. It is, for example, curious that this CSS bleed issue happens only with the default color scheme (the legacy blue), but not with other color schemes, like Sunrise.

To be clear, Blueberry is the brand color for WordPress.com, it should be default there, and for new simple sites. Perhaps even new Atomic sites? But if you explicitly choose the classic color scheme, or another, that choice should technically work, which is the issue that's being fixed here.

[tyxla]

Are we intentionally making this change only to the default color scheme, but not to any of the others?

All of the other color schemes in this package are applying this change currently.

How is the "Default" one different?

[tyxla]

My understanding: this color scheme is not really used in Calypso, so that's how it's different. "Default" in Calypso is actually _fresh.css.

[tyxla]

The --wp-admin-theme-color var used sparingly across Calypso and I've confirmed in a few places (like the verbum comment block editor) that colors still work as expected with a few color schemes (including Modern and Default):

[jasmussen]

This is intentional for now, insofar as I believe it solves the issue in the smallest way possible. This is also recognizing that Modern and the WordPress.com default brand color Blueberry both happen to match the default color that's already baked into the componentry itself. Incidentally that may also camouflage some issues. It's unclear if we should land #99033 first, then rebase this on top.

My understanding: this color scheme is not really used in Calypso, so that's how it's different. "Default" in Calypso is actually _fresh.css.

First off, that's interesting. _fresh.css is the legacy blue color, whereas _modern.css is the new Blueberry blue. _default.css I initially thought was the core default, but that's fresh. You can also see the admin-theme-fresh class applied to the body tag of atomic admin sites, supplying these colors. Hence my comments in the files. Important to get right, of course.

That being said, the real issue here is that most of the calypso color schemes are scoped to CSS classes, i.e. .color-scheme.is-midnight { ... }, whereas in _default.css, it's unscoped, i.e. :root { ... }. That :root class, combined with the practice of reassigning one variable with another (--wp-admin-theme-color: var(--color-accent);) is what's causing the bleed here.

It'd be nice if someone who had worked on the color schemes could help share any nuance, so I'm not missing anything.

Thanks for the review!

[tyxla]

It'd be nice if someone who had worked on the color schemes could help share any nuance, so I'm not missing anything.

cc @Automattic/lego who I believe worked on moving color scheme management to wp-admin recently.

[tyxla]

I left a few comments that indicate my train of thought. TL;DR: I think this makes sense, but due to the fact that CSS is shared, we'll have to test this across:

• wp-admin screens
• apps that run in wp-admin, like notifications, help center, wpcom block editor.