![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 7 weeks ago
Closed 13 days ago
#65382 closed enhancement (fixed)
Admin color schemes: improve contrast to make sidebar compatible with Gutenberg editor chrome
| Reported by: | fushar | Owned by: | youknowriad |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Administration | Version: | |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: | ui, accessibility, css |
Description
We want the block editor and Site Editor to follow the user's admin color scheme (see https://github.com/WordPress/gutenberg/pull/78397). With that, the editor chrome will use the color scheme, instead of being always black. However, as also discussed in the linked PR, this has a few problems with the current color schemes:
- The editor chrome's background color is generated from a seed, through the WPDS ramp algorithm buildBgRamp()(https://github.com/WordPress/gutenberg/blob/35487a041c6569399988a96d5956b92cd3da0a71/packages/theme/src/color-ramps/index.ts#L18). This function emits surface colors within a specific luminance bands, and cannot reproduce arbitrary colors. Most of the current scheme sidebars are outside the bands, so the editor chrome will NEVER match them regardless of the seed.
- The primary button may appear in the editor chrome, e.g. as
Review X changes...button. So, the background color should be distinct enough from the sidebar. Currently several schemes have similar colors (e.g. the purple Ectoplasm).
Proposed change
Update the admin color schemes so that they:
- Use sidebar colors that the editor's ramp can reproduce, so the editor chrome can match the wp-admin sidebar
- Use primary button colors that are distinct from the sidebar colors.
- While doing that, improve the contrast for better legibility.
Change History (26)
This ticket was mentioned in PR #12026 on WordPress/wordpress-develop by @fushar.
7 weeks ago
#1
- Keywords has-patch added
@simison commented on PR #12026:
7 weeks ago
#2
I didn't test yet but adding a note to test non-site-editor pages built with WP Build; Fonts, Connectors, etc.
Similarly also plugins building pages with WP Build; a good check would be core AI plugin's settings page.
@fushar commented on PR #12026:
7 weeks ago
#3
I didn't test yet but adding a note to test non-site-editor pages built with WP Build
Yep, this is addressed in the Gutenberg PR https://github.com/WordPress/gutenberg/pull/78397. Together with that PR, this PR even fixes an existing bug with "disconnected" black chrome surrounding such pages. Copying here for easy reference:
Appearance -> Fonts
(see the gutter/border at bottom-left)
| Before | After |
|---|---|
This ticket was mentioned in Slack in #core-css by fushar. View the logs.
7 weeks ago
@youknowriad commented on PR #12026:
7 weeks ago
#5
Checking with .org designers about whether this match the desired direction cc @jameskoster @jasmussen
@Joen commented on PR #12026:
7 weeks ago
#6
Thanks for the pings, appreciate it. My feedback from the reviews I gave in https://github.com/WordPress/gutenberg/pull/78397 stands: ALL core color schemes deserve near total re-invention, but that is not a near-term goal, and this is a solid step in the right direction.
@youknowriad commented on PR #12026:
7 weeks ago
#7
Looking at the screenshots, personally the new adapted colors look easier on my eye, so probably slightly better in terms of a11y but would love other opinions here.
#10
@
6 weeks ago
I'd definitely agree that this is generally an accessibility improvement; it may not bring all the themes fully up to WCAG expectations, but that's not necessary in order for them to be an improvement!
#11
@
6 weeks ago
- Resolution fixed
- Status closed → reopened
I really like the new admin colour schemes, but please can the colours be defined as CSS variables for those of us who develop UIs in WordPress admin?
The introduction of e.g. --wp-admin-theme-color has been a fantastic time-saver but keeping track of new hard-coded colour schemes on a per-WordPress-version basis is time-consuming and avoidable.
#12
follow-up:
↓ 20
@
6 weeks ago
The CSS variables update is going to happen on the next Gutenberg update on Core after the related Gutenberg PR lands (See https://github.com/WordPress/gutenberg/pull/78397). So there's a small period in trunk where the CSS variable is indeed not in sync but it should be solved soon.
This ticket was mentioned in PR #12153 on WordPress/wordpress-develop by @fushar.
6 weeks ago
#14
Trac ticket: https://core.trac.wordpress.org/ticket/65382
This PR bumps the bundled Gutenberg to commit d18be22, which contains https://github.com/WordPress/gutenberg/pull/78397.
This is necessary to backport the updated --wp-admin-theme-color colors, so that the admin bar, sidebar, and primary button background all have the same color. See the linked Trac issue for more details.
The rest of the changes are generated, via npm run gutenberg:download.
## Screenshot
(See the bottom-right button and the bottom-right gutter/chrome color)
| Before | After |
|---|---|
## Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Fable
Used for: Updating the SHA and running the download script .
#15
@
6 weeks ago
That should bring the color tokens (like --wp-admin-theme-color) back in sync. @youknowriad / other core committers, please check :)
@fushar commented on PR #12153:
6 weeks ago
#16
Hi @adamsilverstein , I noticed that you have a similarly open PR here: https://github.com/WordPress/wordpress-develop/pull/12009.
My PR here is pinning to a hash that's seemingly newer to yours. I believe my hash already contains React 19 revert (https://github.com/WordPress/gutenberg/pull/78940), so I believe it's safe.
Can you help confirm? Should we just use this new PR instead of yours? Thanks!
@adamsilverstein commented on PR #12153:
6 weeks ago
#17
@fushar fine to use yours instead of mine. I'll close my PR. We weren't able to merge due to the modified files that weren't meant for trunk.
@fushar commented on PR #12153:
6 weeks ago
#18
@adamsilverstein Thanks for the reply. But I can't seem to find the linked PR that you mentioned :)
Also could you confirm that I did the right thing here? I.e. update the hash and run npm run gutenberg:download?
@adamsilverstein commented on PR #12153:
6 weeks ago
#19
Apologies for the cryptic reply, I'm replying from my phone. The pr I was talking about is https://github.com/WordPress/gutenberg/pull/76715 and it looks like it was merged.
#20
in reply to: ↑ 12
@
6 weeks ago
Replying to youknowriad:
The CSS variables update is going to happen on the next Gutenberg update on Core after the related Gutenberg PR lands (See https://github.com/WordPress/gutenberg/pull/78397). So there's a small period in trunk where the CSS variable is indeed not in sync but it should be solved soon.
So maybe I'm not understanding something here.
Given the comprehensive screenshots of the new colours being applied to the WordPress admin menu and left-hand menu, I thought that these PRs would introduce CSS variables for those colours - but they still seem to be hardcoded in the respective colors.css files.
So given that I can style buttons etc in my backend forms using --wp-admin-theme-color, it is not possible for there to be equivalents for menus, e.g. --wp-admin-menu-bg-color and so on?
@fushar commented on PR #12153:
5 weeks ago
#21
Hi @adamsilverstein, since you already have context, could you help land this PR? I am not a Core committer myself. Also looks like there's failing checks, but I'm not sure if those are real errors or flay ones. I can't restart the jobs myself 😄
@adamsilverstein commented on PR #12153:
5 weeks ago
#22
Sure, let me double check to make sure the build process is in a good place for this update and bring the SHA closer to gb trunk.
@desrosj commented on PR #12153:
4 weeks ago
#23
👋 Just wanted to jump in and note that after r62525 the build script is in a better place and all files should be updated as expected (especially deleted ones).
I noticed that chosen commit corresponds to the most recent Gutenberg release (23.4.0) which was 2-3 days ago. Now that the bugs related to deleting files has been addressed, I plan on posting on Make Core to bump the Gutenberg hash every other week opposite the Gutenberg plugin releases. That way changes are being synced regularly but allowing a bit of time for any X.Y.Z+1 releases that may be necessary.
This PR bumps the bundled Gutenberg to commit d18be22, which contains https://github.com/WordPress/gutenberg/pull/78397.
Since the first plugin release including this fix was 23.4.0, we can update to the latest this time and then move to the every other week cadence.
@fushar commented on PR #12153:
3 weeks ago
#24
It seems Core is already on latest Gutenberg. Closing this issue. Thanks for taking core of bringing the latest Gutenberg to Core.
Trac ticket: https://core.trac.wordpress.org/ticket/65382
## Summary
The block editor and Site Editor are moving toward applying the user's admin color scheme (see https://github.com/WordPress/gutenberg/pull/78397). With that, the editor chrome will use the color scheme, instead of being always black. However, as also discussed in the linked PR, this has a few problems with the current color schemes:
Review X changes...button. So, the background color should be distinct enough from the sidebar. Currently several schemes have similar colors (e.g. the purple Ectoplasm).This PR updates the core admin color schemes to satisfy both, while maintaining each scheme's characteristics.
Several notes:
buildBgRamp()function CANNOT produce low-contrast colors. So, for each such schemes (like Coffee, Ocean) I tried to produce the color with the lowest contrast possible while still being similar to the original color.### Sidebar contrast (white/black text vs sidebar background)
And whether they pass WCAG 2.x AA (it requires > 4.5:1 for normal text)
### Primary button contrast (white text vs button background)
Note that except for Light scheme, this primary button background color is now equal to that of the currently selected menu item.
### Screenshots
## Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.7-4.8
Used for: iterating the color gradients