@Infinite-Null @himanshupathak95, Since you are working on the same issue, it would be better to consolidate it into one.

• Style: Update color to use CSS variable in edit-site #79002
• Components: Complete WPDS token migration for remaining borders #79003

@Infinite-Null @himanshupathak95, Since you are working on the same issue, it would be better to consolidate it into one.

Thanks @t-hamano for looking into this.

@Infinite-Null mentioned their PR is focusing on edit-site while my PR is more focused on the components part, I am going to mention this on the issue as well.

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: himanshupathak95 <abcd95@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

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

Thanks for tackling this!

There are more opportunities for refactor that we could tackle in this PR: the search here looks SCSS-only ($gray-300 / $components-color-gray-300), so it misses the gray-300 borders authored in Emotion/JS style files, plus a couple of separators drawn with background-color. These resolve to the same logical token, so for consistency they should move to a WPDS stroke token in the same pass.

Note: stroke-interactive-neutral is #8d8d8d, noticeably darker than the current #ddd, so these are a deliberate visual change rather than a value-preserving swap — worth a design call (cc @jameskoster @fcoveram ).

Re. the disabled-control borders already migrated here (button/toggle/radio), we should usestroke-interactive-neutral-disabled instead.

I'd be tempted to handle ToggleGroupControl separately as it went through a recent design review.

Thanks for the detailed feedback @ciampo! I completely agree with the approach.

I've gone ahead and applied these updates locally:

Swapped the disabled interactive controls (button, form-toggle, radio-control) to use stroke-interactive-neutral-disabled.
Swapped the remaining Emotion/JS files and background-color dividers (tools-panel, menu, dropdown-menu, spinner, and border-control) to their appropriate WPDS stroke tokens as you outlined.
Left ToggleGroupControl untouched.

However, I hit a blocker with the pre-commit hooks when trying to push the Emotion .ts changes. Our ESLint strict configuration is rejecting the direct use of the WPDS tokens inside the styled-components template strings:

/packages/components/src/border-control/styles.ts
  88:6  error  Design System tokens (--wpds-*) should not be used in this context  @wordpress/no-ds-tokens
/packages/components/src/menu/styles.ts
  25:30  error  Design System tokens (--wpds-*) should not be used in this context  @wordpress/no-ds-tokens
✖ 5 problems (5 errors, 0 warnings)

How would you prefer to handle this within @wordpress/components? Should I just add an eslint-disable-next-line @wordpress/no-ds-tokens above these specific usages?

However, I hit a blocker with the pre-commit hooks when trying to push the Emotion .ts changes. Our ESLint strict configuration is rejecting the direct use of the WPDS tokens inside the styled-components template strings:

@himanshupathak95 you're right, my bad. I forgot that, since we can't reliably add fallback values for the --wpds-* tokens in Emotion styles, we're currently forbidding usage.

For now, we can simply add comments about each instance, something like // TODO: should use a WPDS token when refactored to SCSS modules.