Boot: Remove manual fallbacks from design token usages#76414
Conversation
|
Size Change: -7 B (0%) Total Size: 6.89 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 7f513cc. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22972556884
|
|
I tried adding a fallback value, and when I do that, my custom fallback value prevents the system from adding a build-time generated fallback value. I understand it's the expected behavior, so I guess the PR works as expected :) |
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
What?
Removes hardcoded fallback values from
var(--wpds-*)usages in@wordpress/bootcomponent styles.Why?
Design token fallbacks are injected automatically at build time by the PostCSS plugin in
@wordpress/theme. Having manual fallbacks in source is redundant and can drift out of sync with the token definitions.This is a preparatory step for adding a stylelint rule (#76415) that disallows manual fallbacks for
--wpds-*tokens.How?
Straightforward removal of the second argument from
var()calls, e.g.:Testing Instructions
npm run build && npm run wp-env startadmin.php?page=site-editor-v2).The build step should inject the same fallback values that were previously hardcoded, so there should be no visible difference.