⚽ Live Match: WordPress/gutenberg/pull/

t-hamano · 2026-08-07T07:39:40Z

What?

Follow up to #80797

Fixes the text color of site editor sidebar menu items on hover.

Before	After

Why?

#80797 migrated ItemGroup from Emotion to SCSS modules. The Item hover rule went from a single Emotion class to a two-class selector, raising its specificity to exactly match the site editor's own rule. Component styles are injected at runtime, always after the enqueued wp-edit-site stylesheet, so the tie is broken by source order and Item now wins.

How?

Bump the specificity of the site editor rule so the intended neutral hover color applies again. As far as I know, this is the only way to solve the problem without changing the ItemGroup component itself.

Testing Instructions

Open the site editor.
Hover the sidebar items. The text color should be basically white.
Change the admin color scheme and test again.

Use of AI Tools

Claude Code (Opus 5) was used to investigate the root cause and draft the patch. I reviewed the result and take responsibility for it.

The `<Item>` component sets its own `:hover` color to the raw admin theme color. Since the SCSS module migration (#80797) that rule matches at the same specificity as ours, and it is injected at runtime so it always comes later in the cascade — our hover color never applied. The admin theme primary carries no contrast guarantee against the sidebar background, both being seeded from the same admin color scheme. On sunrise that is #ad631e text on #8d2f2c (1.8:1), which is unreadable. Bump the specificity so the intended neutral hover color wins, and drop the explicit drilldown indicator fills — `<Item>` already sets `currentColor`, so the chevron now follows the text color in every state.

github-actions · 2026-08-07T07:45:14Z

Size Change: -154 B (0%)

Total Size: 7.82 MB

📦 View Changed

Filename	Size	Change
`build/styles/edit-site/style-rtl.css`	21.4 kB	-37 B (-0.17%)
`build/styles/edit-site/style-rtl.min.css`	17.5 kB	-41 B (-0.23%)
`build/styles/edit-site/style.css`	21.4 kB	-36 B (-0.17%)
`build/styles/edit-site/style.min.css`	17.5 kB	-40 B (-0.23%)

_{compressed-size-action}

t-hamano · 2026-08-07T07:46:29Z

-		.edit-site-sidebar-navigation-item__drilldown-indicator {
-			fill: var(--wpds-color-foreground-interactive-neutral-weak-active);
-		}


This is a minor improvement. The icon now has fill="currentColor" by default, so this style is no longer necessary. See #79320

github-actions · 2026-08-07T07:51:50Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: juanfra <juanfra@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

github-actions · 2026-08-07T08:06:35Z

Flaky tests detected in ce67ed5.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/31158534160
📝 Reported tests:

Focus management when using the navigation link appender in /test/e2e/specs/editor/blocks/navigation.spec.js, passed after 1 failed attempt.

Error: apiRequestContext.fetch: socket hang up
Call log:
  - → POST http://localhost:8889/wp-json/wp/v2/pages
    - user-agent: Playwright/1.62.1 (x64; ubuntu 24.04) node/20.20 CI/1
    - accept: */*
    - accept-encoding: gzip,deflate,br
    - X-WP-Nonce: 5e628b26a6
    - content-type: application/json
    - content-length: 34
    - cookie: wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_23778236db82f19306f247e20a353a99=admin%7C1786261471%7CDZAIIb1a3fHe7nIEvJYy2WTvXEhX3tFdhXsgIoNiIzo%7Cc022b48bf140a03ae9b0d2251b26444c8d2adbb35c5554966a5f2fb30ce87b95; wp-settings-time-1=1786088870

    at RequestUtils.rest (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/rest.ts:119:39)
    at RequestUtils.createRecord (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/records.ts:23:14)
    at RequestUtils.createPage (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/pages.ts:74:14)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/blocks/navigation.spec.js:303:33

juanfra · 2026-08-07T09:16:01Z

Thanks Aki!

I ran into a pretty similar specificity thing in #80845, where the img reset in boot was winning over components that set their own image sizes. I was wondering what if we adjust the specificity on the ItemGroup side instead? Something like &:where(:hover) on the is-unstyled-* block, which matches the same elements but has the same specificity as the emotion class had before the migration. Then the site editor rule specificity wins without modifying anything there.

From what I checked, I believe boot's navigation item has now the same specificity issue, so it should be covered with that approach as well.

mirka

I think this is fine as an immediate fix. We're also trying to see if we can consolidate these styles in #81088 (comment).

mirka · 2026-08-07T17:20:12Z

About the specificity issues that @juanfra raised, we're currently considering whether to @layer the CSS module styles in wp-components. The big difference between normal enqueued CSS and our CSS modules is that our CSS modules are dynamically injected, so we can't really control load order like when enqueueing. Keeping the styles unlayered will roughly match what we had in Emotion, but on the other hand for any components where we switch from an enqueued stylesheet to a CSS module, it will change the cascade.

So I'm thinking maybe we need to @layer to have any control of the cascade, comparable to enqueueing.

t-hamano · 2026-08-08T05:51:24Z

Thank you all for your reviews. As a temporary solution, let's merge this.

The `<Item>` component sets its own `:hover` color to the raw admin theme color. Since the SCSS module migration (#80797) that rule matches at the same specificity as ours, and it is injected at runtime so it always comes later in the cascade — our hover color never applied. The admin theme primary carries no contrast guarantee against the sidebar background, both being seeded from the same admin color scheme. On sunrise that is #ad631e text on #8d2f2c (1.8:1), which is unreadable. Bump the specificity so the intended neutral hover color wins, and drop the explicit drilldown indicator fills — `<Item>` already sets `currentColor`, so the chevron now follows the text color in every state. Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: mirka <0mirka00@git.wordpress.org> Co-authored-by: juanfra <juanfra@git.wordpress.org>

github-actions Bot added the [Package] Edit Site /packages/edit-site label Aug 7, 2026

t-hamano changed the title ~~Site editor: fix unreadable sidebar item hover color~~ Site editor: fix sidebar item hover color Aug 7, 2026

t-hamano commented Aug 7, 2026

View reviewed changes

t-hamano added [Type] Bug An existing feature does not function as intended CSS Styling Related to editor and front end styles, CSS-specific issues. labels Aug 7, 2026

t-hamano self-assigned this Aug 7, 2026

t-hamano requested a review from a team August 7, 2026 07:51

t-hamano marked this pull request as ready for review August 7, 2026 07:51

mirka approved these changes Aug 7, 2026

View reviewed changes

t-hamano merged commit c7cdb48 into trunk Aug 8, 2026
59 checks passed

t-hamano deleted the fix/site-editor-sidebar-hover-color branch August 8, 2026 05:51

github-actions Bot added this to the Gutenberg 23.8 milestone Aug 8, 2026

Navigation Menu

Uh oh!

Site editor: fix sidebar item hover color - #81317

Site editor: fix sidebar item hover color#81317
t-hamano merged 1 commit into
trunkfrom
fix/site-editor-sidebar-hover-color

t-hamano commented Aug 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

t-hamano Aug 7, 2026

Uh oh!

github-actions Bot commented Aug 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

juanfra commented Aug 7, 2026

Uh oh!

mirka left a comment

Uh oh!

mirka commented Aug 7, 2026

Uh oh!

t-hamano commented Aug 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

t-hamano commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Use of AI Tools

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

t-hamano Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

juanfra commented Aug 7, 2026

Uh oh!

mirka left a comment

Choose a reason for hiding this comment

Uh oh!

mirka commented Aug 7, 2026

Uh oh!

t-hamano commented Aug 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

t-hamano commented Aug 7, 2026 •

edited

Loading

github-actions Bot commented Aug 7, 2026 •

edited

Loading