Repository navigation
Expand error family of tokens - #73793
Merged
Merged
Conversation
jameskoster
added
[Type] Enhancement
|
Size Change: +590 B (+0.02%) Total Size: 2.57 MB
ℹ️ View Unchanged
|
aduth
approved these changes
Dec 5, 2025
aduth
left a comment
aduth
left a comment
Member
There was a problem hiding this comment.
Hard to visualize without real-world usage, but we can tinker as we go 😄
| | `--wpds-color-stroke-interactive-brand-active` | Accessible stroke color used for interactive brand-toned elements with normal emphasis that are hovered, focused, or active. | | ||
| | `--wpds-color-stroke-interactive-brand-disabled` | Accessible stroke color used for interactive brand-toned elements with normal emphasis, in their disabled state. | | ||
| | `--wpds-color-stroke-interactive-error` | Accessible stroke color used for interactive error-toned elements with normal emphasis. | | ||
| | `--wpds-color-stroke-interactive-error-active` | Accessible stroke color used for interactive error-toned elements with normal emphasis that are hovered, focused, or active. | |
Member
There was a problem hiding this comment.
Just to clarify, we don't need a disabled token here? And if not, how come we need one for brand ?
Contributor
Author
There was a problem hiding this comment.
With one eye on adding 'neutral' toned button I think we'll want all disabled buttons to have the same visual style; light gray background and gray text, no stroke, regardless of variant. This will ensure a disabled brand outline button doesn't look too similar to a neutral secondary button. So we won't need the disabled stroke token.
And if not, how come we need one for brand ?
Good question. I can't think of a use case for that off the top of my head. Do you think we should remove it?
Member
There was a problem hiding this comment.
And if not, how come we need one for brand ?
Good question. I can't think of a use case for that off the top of my head. Do you think we should remove it?
Yeah, I had a hunch about your answer, and I think it makes sense as a logical action item for consistency if we don't think we'll need these disabled states.
|
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. |
Contributor
Author
Fair point haha. Here's a visualisation of the different tones and states: 
|
This was referenced Dec 10, 2025
Contributor
|
I remember that a few months ago we discussed this very topic and decided against having destructive buttons. We agreed that, instead, we'd use other tones + a confirmation dialog when needed for destructive actions — which influenced some decisions in the token architecture and naming. What's the reason for reverting this decision? |
Member
|
@jameskoster may have more insight, though I think the idea with additional danger tones was specifically for irreversibly destructive actions, with the current confirmation dialog pattern using primary tones being sufficient for destructive, reversible decisions. |
Contributor
Author
|
@ciampo @poligilad-auto worked on a revised workflow for destructive actions that included red accents for buttons in certain situations. See more in #66810 (comment) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Expands the error family of design tokens by adding interactive color tokens for error-toned elements. Adds:
bg-interactive-error(normal, strong, weak) with resting, active, and disabled statesfg-interactive-error(normal, strong) with resting, active, and disabled statesstroke-interactive-error(normal) with resting and active statesAlso: Remove
--wpds-color-stroke-interactive-brand-disabledas it's not a token with any obvious use case currently. It can easily be added back later if necessary.Updates generated outputs (CSS, JS, JSON, TypeScript) and documentation to include these tokens.
Why
These changes will enable the creation of destructive button variants.
How
packages/theme/tokens/color.json:design-tokens.cssdesign-tokens.jsfigma.jsoncolor-tokens.tsds-tokens.mdto include the new tokens in the reference table.