@Jdlrobson we try to use the tokens in a semantic way, so I'm a little concerned that encouraging template editors to use a -disabled token (intended for disabled interactive elements) to style image backgrounds is sending the wrong message here.

Codex has a couple of other background-color tokens (neutral, neutral-subtle, etc) which might be more appropriate for this use-case. Would any of these work (provided that we added a -fixed variant to keep the color the same)?

If not, we might need to consider introducing a new token with a value very similar (or identical to) background-color-disabled, but with a unique name to reflect that it is intended for different usage. We actually *do* want disabled background colors for buttons and the like to change between light and dark modes, so I don't want to introduce any confusion there.

Anyway let me know what you think, and I'm sure we can add these new tokens shortly.

For clarification background-color-disabled is not needed for community. It's needed by web team in T370074. color-base is the only one that I am proposing for community.

In T371529#10033065, @Jdlrobson wrote:

For clarification background-color-disabled is not needed for community. It's needed by web team in T370074. color-base is the only one that I am proposing for community.

I think we should consider using a different token (or introducing a new one as Eric suggests) for this use case, since the application is not for any kind of "disabled" state. Have you explored using background-color-neutral?

In T371529#10033077, @CCiufo-WMF wrote:

In T371529#10033065, @Jdlrobson wrote:

For clarification background-color-disabled is not needed for community. It's needed by web team in T370074. color-base is the only one that I am proposing for community.

I think we should consider using a different token (or introducing a new one as Eric suggests) for this use case, since the application is not for any kind of "disabled" state. Have you explored using background-color-neutral?

We looked at neutral, but it's too dark in dark mode. The issues tend to be black SVG diagrams on dark background. The neutral token isn't bright enough, and the background-color-base-fixed token is too bright.

If we're going to have a specific token for image backgrounds in dark mode, you folks might want to consider incorporating that into the naming convention you use for it.

El T371529#10033077, @CCiufo-WMF escribió:

In T371529#10033065, @Jdlrobson wrote:

For clarification background-color-disabled is not needed for community. It's needed by web team in T370074. color-base is the only one that I am proposing for community.

I think we should consider using a different token (or introducing a new one as Eric suggests) for this use case, since the application is not for any kind of "disabled" state. Have you explored using background-color-neutral?

Regarding background-color-disabled-fixed, I agree with Eric and Chris, we should not use "disabled" for a non-interactive background. Additionally, we try to include decision tokens in Codex only if they will be reused more than once. Since this token will currently be used just as a background image, what if we create it as a component token instead to avoid adding a new decision token that would only be used once for now?

As for color-base-fixed, I think we could reuse this token more than once so in this case I agree with adding this as decision token.

Cross posting my reply from T370074#10035630:

I would recommend not tokenizing this value for now. This seems like a very specific use case that should live as a decision in the skin until we either find more uses for it or it becomes more "stable". I have a feeling the color might change as we get more feedback about how it behaves with different SVGs and I don't think a dependency on Codex there makes sense. Does that work for you all? We can still add color-base-fixed as requested in T371529.

I support adding in these -fixed tokens as we find needs for them. I agree with what others have already said about not using a -disabled token where something is not disabled. I would be in agreement with Bárbara to add a specific component token here for this use, not only because it is the only use for this at the moment, but also to support the way we have structured all text tokens to have at least a 4.5:1 contrast ratio on all potential background color tokens. So if this new token would be intended for use of images only, we should keep it that way, since encouraging use of text on this darker gray background could cause accessibility issues depending on what text token would potentially be used on it.

(Descoped)

Change #1064044 had a related patch set uploaded (by Dtorsani; author: Dtorsani):

[design/codex@main] tokens: Add color-base-fixed application token

https://gerrit.wikimedia.org/r/1064044

Change #1064044 merged by jenkins-bot:

[design/codex@main] tokens: Add color-base-fixed application token

https://gerrit.wikimedia.org/r/1064044

Change #1064134 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v1.11.0 to v1.11.1

https://gerrit.wikimedia.org/r/1064134

Change #1064134 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.11.0 to v1.11.1

https://gerrit.wikimedia.org/r/1064134