A few things to consider:

• Is it ok to change existing bg tokens for disabled interactive bg to be transparent?
• is it ok to use --wpds-color-stroke-interactive-neutral-disabled for the disabled border color, for the outline/minimal variants?
• are the actual colors used for text and border ok?
• Should we apply any changes to the existing Button from @wordpress/components?

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

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

Size Change: -1.25 kB (-0.04%)

Total Size: 3.05 MB

_{compressed-size-action}

Flaky tests detected in b5343df.
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/20958790157
📝 Reported issues:

• [Flaky Test] Block context is reflected in the preview #48826 in /test/e2e/specs/editor/plugins/block-context.spec.js
• [Flaky Test] Should insert content using the global inserter #57525 in /test/e2e/specs/widgets/editing-widgets.spec.js

Is it ok to change existing bg tokens for disabled interactive bg to be transparent?

Is there anything you're concerned about? It seems it'll still be possible to use a light gray background for disabled elements (which is something we might want for some disabled inputs), is that right?

is it ok to use --wpds-color-stroke-interactive-neutral-disabled for the disabled border color, for the outline/minimal variants?

Any reason not to? That seems like a correct application to me.

Edit: I suppose there's a question about whether using a neutral token for a brand toned button is okay. I think that's fine though. There's not much benefit in creating a bunch of disabled brand tokens as they'll essentially end up 'neutral' anyway.

Should we apply any changes to the existing Button from @wordpress/components?

Where feasible we should aim to keep things as close as possible. This change actually moves us closer to parity :)

Rebased to include the recent addition of the destructive variant.

Is there anything you're concerned about? It seems it'll still be possible to use a light gray background for disabled elements (which is something we might want for some disabled inputs), is that right?

It is by using the --wpds-color-bg-interactive-brand-strong-disabled, --wpds-color-bg-interactive-neutral-strong-disabled, and --wpds-color-bg-interactive-error-strong-disabled tokens (which currently all alias to #d2d2d2).

The --wpds-color-bg-interactive-brand-disabled, --wpds-color-bg-interactive-brand-weak-disabled, --wpds-color-bg-interactive-error-disabled, --wpds-color-bg-interactive-error-weak-disabled, --wpds-color-bg-interactive-neutral-disabled and --wpds-color-bg-interactive-neutral-weak-disabled have been all changed from #e2e2e2 to transparent.

Are you ok with this scenario?

I suppose there's a question about whether using a neutral token for a brand toned button is okay. I think that's fine though. There's not much benefit in creating a bunch of disabled brand tokens as they'll essentially end up 'neutral' anyway.

Yes, this is what I was concerned about (sorry for not being more specific in my previous comment).

That makes sense, although we are doing the opposite for the bg-interactive-[brand|error] tokens (see above), where each "tone" has its color even if they're all the same value as the neutral tone.

I guess it would be good to document how we're thinking about this and apply it as consistently as possible? I believe originally our approach was for having as few tokens as possible, but I'm not sure if for this case we'd still apply the same reasoning.

This change actually moves us closer to parity :)

Awesome!

Separately, one additonal aspect that I wanter to bring up is that, in the outline variant, the text and the border are not the same color (text is #8a8a8a, border is #d8d8d8) — just to make sure we're ok with that.

Not a strong opinion, not offering blockers. The disabled state in this case looks slightly too emphasized to me, in all three versions, though especially the solid versions. Noting that the reason there is no contrast requirement for disabled elements is to ensure there is visible contrast between enabled and disabled buttons; you shouldn't be confused whether a button is interactive or not, even at a glance. Can we make them lighter?

The disabled state in this case looks slightly too emphasized to me,

Agree about the solid variants in particular. I think we can address that by mapping --wpds-color-bg-interactive-neutral-strong-disabled to surface5 which will change the background from #d2d2d2 to #e2e2e2. We can also use the same text color for all variants.

I rebased on top of latest trunk and pushed a couple of updates:

Mapped --wpds-color-bg-interactive-neutral-strong-disabled from surface6 to surface5, resulting in a slightly lighter color

This was suggested by @jameskoster, following @jasmussen 's feedback, in order to make the solid variant's disabled state less visually prominent.

Before	After

Removed *-disabled DS color tokens for brand and error tones when they are the same as the neutral counterpart

This is a tenative approach based on my previous comment, to which @jameskoster replied "There's not much benefit in creating a bunch of disabled brand tokens as they'll essentially end up 'neutral' anyway."

As such:

• I removed the bg-interactive-brand-disabled and bg-interactive-error-disabled => bg-interactive-neutral-disabled can be used instead
• I removed the bg-interactive-brand-strong-disabled and bg-interactive-error-strong-disabled => bg-interactive-neutral-strong-disabled can be used instead
• I removed the bg-interactive-brand-weak-disabled and bg-interactive-error-weak-disabled => bg-interactive-neutral-weak-disabled can be used instead
• I removed the fg-interactive-brand-disabled and fg-interactive-error-disabled => fg-interactive-neutral-disabled can be used instead
• I removed the fg-interactive-brand-strong-disabled and fg-interactive-error-strong-disabled => fg-interactive-neutral-strong-disabled can be used instead

As usual with tokens, there isn't a clearly right approach, but it's mostly a matter of compromises. In this case, we'd be reducing the number of tokens, in exchange for more indirection (ie. brand and error tones don't have dedicated disabled tokens). How does it feel like?

Note: there may be a couple extra changes to apply to tokens, potentially:

• bg-thumb-brand-disabled: the bg-thumb group of tokens only has a disabled token for the brand variant (since the thumb doesn't exist in neutral tone), although I'm not sure if we'd also like to rename it to neutral for consistency?
• the bg-interactive-neutral and bg-interactive-neutral-weak tokens have the exact same values across the line (including active and disabled states): do they make sense as a separate set of tokens, or should we remove them too?

Again, this is mostly about creating a set of conventions and rules that make sense for us. We could de-duplicate tokens very aggressively, although I feel we'd get to a point where the UX of consuming tokens would really suffer, and the tokens would become less and less "semantic" and much closer to being renamed "primitives"

In summary, the high-level design decision here is that disabled elements should always convey a neutral tone. This seems like a good direction to me and strengthens the overall visual language. Reflecting it in the tokens makes sense as well.

For the button itself, I think it would be okay to use --wpds-color-fg-interactive-neutral-disabled for the solid button text to further reduce prominence.

I think it would be okay to use --wpds-color-fg-interactive-neutral-disabled for the solid button text to further reduce prominence.

If we do that:

• the overall contrast would be 1:2.28 (down from 1:3.42) — I assume that would be acceptable, even considering previous feedback?
• there wouldn't be any usage left of the --wpds-color-fg-interactive-neutral-strong-disabled token. Would it make any sense for that token to exist?
  • We could consider, instead, to change the token's value from #6d6d6d to #8a8a8a? Which would also mean that fg-interactive-neutral-disabled, fg-interactive-neutral-weak-disabled and fg-interactive-neutral-strong-disabled all have the same value 🤔

Update:

after talking with @jameskoster , we agreed on applying some changes to the tokens.

In an effort to reduce ther amount of tokens where possible (wihout compromising on their semantics), we made the following changes:

• removed all disabled tokens associated with non-neutral tones. All *-disabled tokens are now marked as neutral, since we realized that all other tones had the same value as the neutral tone anyway. We removed
• removed the bg-interactive-neutral, bg-interactive-neutral-active and bg-interactive-neutral-disabled tokens. This is because, with the latest changes, they hold the same exact values as the bg-interactive-neutral-weak couterparts;
  • We chose to keep the strong and weak variants (and discard the default emphasis for now) because we felt like we can't really go stronger or weaker anyway, while there may be space for a middle ground in the future.
• same for the bg-interactive-brand, bg-interactive-brand-active and bg-interactive-brand-disabled tokens
• renamed the --wpds-color-bg-thumb-brand-disabled token to --wpds-color-bg-thumb-neutral-disabled for consistency

I also tweaked the --wpds-color-fg-interactive-neutral-strong-disabled token as suggested.

I updated the @wordpress/theme CHANGELOG with a compehensive list of the changes, and the PR description with the latest screenshot.

Separately, I feel like we could now really benefit from a proper VizReg setup to keep track of all the ripercussions when tweaking DS stuff (especially when the changes happen in a different package, such as Theme)

@mirka @jameskoster quick check that everything looks good with you before merging?