UI, DataViews: Give input and selection controls solid backgrounds

[ciampo]

What?

Give @wordpress/ui input fields and checkboxes solid themed backgrounds. Apply the same fill to unselected DataViews multi-selection indicators.

Add active and disabled variants to the neutral interactive background token family. They currently use the same color as the resting token. Combobox chips keep their existing weak background family, and minimal Select triggers stay transparent.

Why?

Transparent controls pick up the surrounding background. Separate state tokens also let themes change these states later without another component update.

How?

Add neutral resting, active, and disabled background tokens backed by the same theme color for now. Use them in InputLayout, Checkbox, and DataViews while preserving selected and borderless styles.

The nested fallback to background-surface-neutral-strong preserves custom background theming when a new bundle runs under an older ThemeProvider.

Testing Instructions

1. In Storybook, open InputControl and Checkbox. Test resting, hover, checked, and disabled states on default, dark, and custom backgrounds. The solid fill should remain stable between resting and hover states.
2. Open SearchableChipSelectControl. Chips should remain transparent at rest and when disabled, then use their existing weak active fill on hover or focus.
3. In DataViews Layout List, add a Categories filter. Unselected indicators should have a stable solid fill, while selected indicators retain their accent fill.
4. Repeat with WordPress global CSS and forced colors. Confirm that focus, borders, text, and disabled cues remain visible.
5. Check minimal Select triggers and neutral minimal or outline Buttons. Their backgrounds should remain transparent.

Testing Instructions for Keyboard

Tab through the controls, toggle Checkbox with Space, navigate chips and filter options with the arrow keys, and confirm that focus rings remain visible.

Screenshots

Before	After

Follow-up

A follow-up can evaluate a subtler visible active fill without changing the component styles again.

Use of AI Tools

Codex implemented and verified the changes. The author reviewed the result.

Summary by CodeRabbit

• New Features

  • Added neutral interactive background tokens for default, active, and disabled states.
  • Updated inputs, checkboxes, and multi-selection filters to use state-aware neutral backgrounds, including solid white fallbacks for compatibility.
  • Added neutral color options and contrast mappings for themed controls.

• Documentation

  • Updated token references and changelogs to document the new neutral interactive background states and their usage.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. To trigger a review, include @coderabbitai review in the PR description. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: c661f887-ab41-40f2-a3e8-1ec25ddfbd55

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 893630e7-399b-4e44-a36d-d9137df6421e

📥 Commits

Reviewing files that changed from the base of the PR and between 399ace3 and d8fb889.

📒 Files selected for processing (17)

• packages/base-styles/CHANGELOG.md
• packages/base-styles/internal/_wpds-token-fallbacks.scss
• packages/dataviews/CHANGELOG.md
• packages/dataviews/src/components/dataviews-filters/style.scss
• packages/theme/CHANGELOG.md
• packages/theme/docs/tokens.md
• packages/theme/prebuilt/css/design-tokens.css
• packages/theme/prebuilt/js/design-token-fallbacks.mjs
• packages/theme/prebuilt/js/design-tokens.mjs
• packages/theme/src/prebuilt/ts/color-tokens.ts
• packages/theme/src/semantic-color-contrast-pairs.ts
• packages/theme/src/test/build-plugin-parity.test.ts
• packages/theme/src/test/use-theme-provider-styles.jsdom.test.tsx
• packages/theme/tokens/color.json
• packages/ui/CHANGELOG.md
• packages/ui/src/form/primitives/checkbox/style.module.css
• packages/ui/src/form/primitives/input-layout/style.module.css

🚧 Files skipped from review as they are similar to previous changes (4)

• packages/dataviews/CHANGELOG.md
• packages/theme/CHANGELOG.md
• packages/base-styles/CHANGELOG.md
• packages/ui/CHANGELOG.md

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

Changes

This change adds default, active, and disabled neutral interactive background tokens. It distributes the tokens through theme outputs and applies them to input layouts, checkboxes, and DataViews filter indicators. Tests cover fallback transformation parity and provider styles.

Neutral interactive background

Layer / File(s)	Summary
Token contract and generated distribution packages/theme/tokens/color.json, packages/theme/src/prebuilt/ts/..., packages/theme/prebuilt/..., packages/base-styles/..., packages/theme/docs/tokens.md	Defines the neutral interactive background states, contrast pairs, type mapping, generated outputs, fallbacks, documentation, and changelog entries.
Form control background usage packages/ui/src/form/primitives/..., packages/ui/CHANGELOG.md	Applies default, active, and disabled neutral interactive backgrounds to input layouts and checkboxes with surface fallbacks.
DataViews filter background usage packages/dataviews/src/components/dataviews-filters/style.scss, packages/dataviews/CHANGELOG.md	Applies the active neutral background to multi-selection filter items and updates the compatibility comment.
Token transformation and provider validation packages/theme/src/test/build-plugin-parity.test.ts, packages/theme/src/test/use-theme-provider-styles.jsdom.test.tsx	Verifies nested fallback parity and neutral interactive background values derived from a background seed.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to d8fb8

This change gives neutral controls solid theme-aware backgrounds while retaining compatibility fallbacks and preserving transparent minimal controls. The documented state styling and generated token outputs are ready to merge.

Suggested reviewers: mirka

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 7…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: solid backgrounds for UI input and selection controls, including DataViews controls. It is concise and specific.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/ui-solid-input-backgrounds

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: +831 B (+0.01%)

Total Size: 8 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	479 kB	+8 B (0%)
build/scripts/block-library/index.min.js	367 kB	+43 B (+0.01%)
build/scripts/edit-site/index.min.js	379 kB	+17 B (0%)
build/scripts/editor/index.min.js	584 kB	+46 B (+0.01%)
build/scripts/format-library/index.min.js	40.3 kB	+49 B (+0.12%)
build/scripts/media-utils/index.min.js	201 kB	+32 B (+0.02%)
build/scripts/theme/index.min.js	26.8 kB	+46 B (+0.17%)
build/styles/edit-site/style-rtl.css	21.8 kB	+111 B (+0.51%)
build/styles/edit-site/style-rtl.min.css	17.9 kB	+2 B (+0.01%)
build/styles/edit-site/style.css	21.8 kB	+112 B (+0.52%)
build/styles/edit-site/style.min.css	17.9 kB	+2 B (+0.01%)
build/styles/editor/style-rtl.css	31.7 kB	+107 B (+0.34%)
build/styles/editor/style-rtl.min.css	27.1 kB	+1 B (0%)
build/styles/editor/style.css	31.8 kB	+108 B (+0.34%)
build/styles/editor/style.min.css	27 kB	+1 B (0%)
build/styles/theme/design-tokens-rtl.css	3.12 kB	+61 B (+2%)
build/styles/theme/design-tokens-rtl.min.css	1.51 kB	+12 B (+0.8%)
build/styles/theme/design-tokens.css	3.12 kB	+61 B (+2%)
build/styles/theme/design-tokens.min.css	1.51 kB	+12 B (+0.8%)

_{1e969b1 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	2e3583b	trunk	% Change
timeToFirstByte	60.7 ms +11.04% -5.35%	64.85 ms +7.09% -10.95%	-6.4%
largestContentfulPaint	100 ms +2% -8%	100 ms +4% -4%	0%
lcpMinusTtfb	33.15 ms +21.87% -1.96%	32.6 ms +28.22% -5.67%	1.69%
wpBeforeTemplate	30.28 ms +18.86% -7.3%	34.4 ms +3.69% -16.37%	-11.98%
wpTemplate	25.55 ms +4.74% -5.01%	25.26 ms +2.18% -0.59%	1.15%
wpTotal	56.8 ms +10.21% -5.25%	59.81 ms +7.57% -9.96%	-5.03%
wpMemoryUsage	7.52 MB +0% -0%	7.48 MB +0% -0%	0.46%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	2e3583b	trunk	% Change
timeToFirstByte	51.4 ms +17.8% -5.54%	51.1 ms +8.71% -6.26%	0.59%
largestContentfulPaint	100 ms +8% -4%	96 ms +6.25% -4.17%	4.17%
lcpMinusTtfb	46.25 ms +2.16% -3.03%	45.65 ms +3.4% -2.3%	1.31%
wpBeforeTemplate	27.27 ms +29.45% -3.67%	27.83 ms +18.11% -5.75%	-2.01%
wpTemplate	19.3 ms +3.52% -4.92%	18.52 ms +6.91% -1.08%	4.21%
wpTotal	48.16 ms +15.22% -4.98%	47.62 ms +8.23% -5.96%	1.13%
wpMemoryUsage	6.14 MB +0% -0%	6.10 MB +0% -0%	0.58%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	2e3583b	trunk	% Change
mediaProcessingJpeg	408.33 ms +1.22% -0.09%	409.79 ms +3.19% -0.71%	-0.36%
mediaProcessingAvif	6258.33 ms +0.63% -0.36%	6247.64 ms +0.1% -0.09%	0.17%
mediaProcessingJpegToAvif	4438.45 ms +0.45% -0.39%	4427.28 ms +0.15% -0.21%	0.25%

media-upload

Metric	2e3583b	trunk	% Change
jpegUploadProcessing	1434.74 ms +1.28% -1.01%	1426.33 ms +0.56% -0.75%	0.59%
pngUploadProcessing	222.44 ms +5.07% -3.44%	215.34 ms +3.71% -5.16%	3.3%
largeJpegUploadProcessing	1416.39 ms +0.47% -1.19%	1415.89 ms +0.46% -0.73%	0.04%
multipleImageUploadProcessing	1550.98 ms +1.07% -1.42%	1554.14 ms +0.96% -0.97%	-0.2%

post-editor

Metric	2e3583b	trunk	% Change
serverResponse	360.88 ms +5.32% -10.81%	362.13 ms +5.13% -4.65%	-0.35%
firstPaint	190.42 ms +18.14% -11.06%	175.54 ms +13.83% -10.21%	8.48%
domContentLoaded	1027.4 ms +4.51% -1.25%	1052.71 ms +1.2% -1.56%	-2.4%
loaded	1028.63 ms +4.49% -1.26%	1053.89 ms +1.21% -1.56%	-2.4%
firstContentfulPaint	357.34 ms +5.45% -4.78%	359.18 ms +2.66% -4.17%	-0.51%
firstBlock	2782.44 ms +1.54% -1.38%	2800.93 ms +0.8% -1.83%	-0.66%
type	18.94 ms +11.19% -17.95%	18.99 ms +11.85% -13.95%	-0.26%
typeWithoutInspector	17.7 ms +15.82% -19.72%	17.18 ms +18.68% -16.59%	3.03%
typeWithTopToolbar	21.43 ms +5.27% -21.7%	19.98 ms +10.56% -15.22%	7.26%
typeContainer	8.03 ms +6.48% -5.73%	7.83 ms +4.98% -8.17%	2.55%
focus	63.43 ms +10.64% -5.12%	69.8 ms +12.09% -11.62%	-9.13%
firstFocus	140.66 ms +0% -0%	147.88 ms +0% -0%	-4.88%
selectAll	470.91 ms +4.74% -1.28%	489.04 ms +2.23% -2.27%	-3.71%
listViewOpen	53.22 ms +5.32% -10.86%	55.58 ms +9.72% -10.09%	-4.25%
inserterOpen	19.94 ms +4.51% -2.46%	20.42 ms +6.02% -4.21%	-2.35%
inserterHover	3.58 ms +5.03% -7.54%	3.92 ms +11.22% -10.97%	-8.67%
inserterSearch	7.1 ms +12.68% -6.2%	7.54 ms +11.54% -4.24%	-5.84%
loadPatterns	519.34 ms +0.68% -2.81%	569.14 ms +2.62% -1.3%	-8.75%
wpTotal	351.99 ms +5.43% -11.15%	353.3 ms +5.23% -4.77%	-0.37%
wpMemoryUsage	13.12 MB +0% -0%	13.08 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	2e3583b	trunk	% Change
serverResponse	540.39 ms +6.32% -4.26%	570.05 ms +0.88% -0.91%	-5.2%
firstPaint	272.43 ms +10.64% -5.92%	267.14 ms +2.54% -15.2%	1.98%
domContentLoaded	1489.84 ms +0.34% -0.9%	1483.13 ms +1.49% -2.44%	0.45%
loaded	1491.22 ms +0.33% -0.9%	1484.97 ms +1.46% -2.45%	0.42%
firstContentfulPaint	460.18 ms +4.36% -0.87%	467.59 ms +2.15% -1.62%	-1.58%
firstBlock	4674.45 ms +1.54% -0.75%	4702.93 ms +0.98% -2.01%	-0.61%
type	25.34 ms +8.84% -18.27%	23.98 ms +18.06% -14.93%	5.67%
navigate	111.82 ms +15.69% -6.44%	107.14 ms +2.64% -2.45%	4.37%
loadPatterns	1545.11 ms +3.62% -9.73%	1451.52 ms +8.52% -6.87%	6.45%
loadPages	1657.81 ms +6.58% -7.61%	1288.44 ms +33.57% -8.97%	28.67%
wpTotal	530.55 ms +6.34% -4.26%	559.71 ms +0.94% -0.78%	-5.21%
wpMemoryUsage	12.00 MB +0% -0%	11.97 MB +0% -0%	0.24%
wpDbQueries	43 +2.33% -0%	43 +2.33% -0%	0%

_{1e969b1 Run}

🏁 Flaky tests

Show the failures

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.

sort patterns (Site Editor v2) in /test/e2e/specs/site-editor/patterns.spec.js, passed after 1 failed attempt.

Error: apiRequestContext.fetch: socket hang up
Call log:
  - → POST http://localhost:8889/wp-json/wp/v2/blocks
    - user-agent: Playwright/1.62.1 (x64; ubuntu 24.04) node/20.20 CI/1
    - accept: */*
    - accept-encoding: gzip,deflate,br
    - X-WP-Nonce: 6fee5e89b9
    - content-type: application/json
    - content-length: 133
    - cookie: wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_23778236db82f19306f247e20a353a99=admin%7C1788711427%7CrPtunr2rLFntorqJDBUjwoyNvAS8j1SECkSZTznZGxR%7Cbea0d484c26932565759b041f2c85c2b8eb7419417e8ba64f76bdbcb3a415a9a; wp-settings-time-1=1788538931

    at RequestUtils.rest (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/rest.ts:112:39)
    at RequestUtils.createRecord (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/records.ts:20:14)
    at RequestUtils.createBlock (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/blocks.ts:54:14)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/patterns.spec.js:241:17

_{1e969b1 Run}

[github-actions]

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: ciampo <mciampini@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

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

[jasmussen]

Thank you! This fixes an issue I found in an experiment of mine. It will need a code gut-check but just giving my own check here.

[mirka]

Wait, I was under the impression that all the #0000 background tokens we had in the set were a bug. Why do all those need to be transparent in the first place? I'm confused.

Once that makes sense to me though, I feel like there may be other solutions, such as using a surface background token for inputs.

[ciampo]

Wait, I was under the impression that all the #0000 background tokens we had in the set were a bug. Why do all those need to be transparent in the first place? I'm confused.

Once that makes sense to me though, I feel like there may be other solutions, such as using a surface background token for inputs.

That token is applied to the minimal button (resting state), which should not have a background, otherwise it won't look "minimal" depending on the background color of the hosting surface?

[mirka]

That token is applied to the minimal button (resting state), which should not have a background, otherwise it won't look "minimal" depending on the background color of the hosting surface?

Hm, ok 🤔 I think I get it now.

Going back to my thought of using a surface background token instead — conceptually that's not going to work because technically, all the components affected in this PR do have active and disabled states. We just happen to not change the background color for these states at the moment. But does that mean we also need background-interactive-neutral-active and background-interactive-neutral-disabled tokens in the set, and be setting them in our component stylesheets, even though they're currently all the same color…?

I raise this specifically in the context of sufficient affordance in the absence of cursor cues. Right now the only non-cursor cues for active/disabled on these components are the darkness of the border. I think it's plausible that at some point we'll want to add more cues, and that's likely going to be through these background-interactive token states.

I'll defer to your judgment, but I wanted to raise this since the PR currently only adds one new token, which doesn't cover the standard range of interactive states.

[mirka]

Confirmed that the fallback injection plugin will turn this into var(--wpds-color-background-interactive-neutral, var(--wpds-color-background-surface-neutral-strong, #fff)), which I guess is what we want.

Preserve theming when WordPress supplies an older token stylesheet

To be clear though, WordPress supplying an old token stylesheet is not going to be a problem, because we have fallbacks. The problem is only when an old wp.theme.ThemeProvider is wrapping DataViews using a non-default background seed, I think. Which I don't think anybody is doing, because DataViews itself is not really theme-ready yet.

[ciampo]

Yep, an older ThemeProvider with a custom background seed is the case this protects 👌

I updated the comments to say that explicitly and kept the fallback consistent across the affected controls.

[mirka]

If this kind of thing happens a lot, we may want to handle back compat fallbacks in our fallback plugins eventually.

[ciampo]

Yes, let's keep an eye

[ciampo]

Yes, agreed.

I also added background-interactive-neutral-active and background-interactive-neutral-disabled, they all currently map to the same value. We can discuss if we want to change that separately, but it matches the same model adopted for other tokens. It's slightly more redundant, but it's clearer and easier to apply, and it allows us to make tweaks on the WPDS tokens side that apply immediately to all affected components, without additional code changes.

Right now the only non-cursor cues for active/disabled on these components are the darkness of the border. I think it's plausible that at some point we'll want to add more cues, and that's likely going to be through these background-interactive token states.

Exactly. We can explore a solid active value in a follow-up without changing the component styles again.

[mirka]

There's a specificity bug here, but it's preexisting and out of scope so I'll fix it separately.

[ciampo]

#82466

[mirka]

Design system-wise, I don't think a hover on the parent item is going to make the checkbox indicator "active". It's just a visual indicator, not an individual control that can be active. So the blue border color is also weird, but at the very least I'd say this background token should stay non-active.

Suggested change

	background-color: var(--wpds-color-background-interactive-neutral-active, var(--wpds-color-background-surface-neutral-strong));
	background-color: var(--wpds-color-background-interactive-neutral, var(--wpds-color-background-surface-neutral-strong));

[ciampo]

1e969b1