Skip to content

[css-forms-1] Account for forced-colors mode #12060

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lukewarlow opened this issue Apr 8, 2025 · 9 comments
Open

[css-forms-1] Account for forced-colors mode #12060

lukewarlow opened this issue Apr 8, 2025 · 9 comments

Comments

@lukewarlow
Copy link
Member

Historically in forced colors mode the CSS system colors have been whats used for large parts of the UI. However, in css-forms-1 most colours are defined in terms of currentColor and transparency. Effectively this boils down to only Canvas, and CanvasText having an impact.

This feels like a regression to me? It would be good for css-forms to at least mention forced-colors mode with an explanation and perhaps justification on what the actual expected behaviour is.

@lukewarlow
Copy link
Member Author

cc @josepharhar it would be interesting to know what Chrome has done for base appearance select in this case?

@josepharhar
Copy link
Contributor

I thought the idea was to change the UA styles in forced colors mode to something else, but I could be wrong

@nt1m
Copy link
Member

nt1m commented Apr 9, 2025

currentColor should be contrasting enough against a transparent background, but I'd be fine with forced colors mode forcing system colors too:

@media (forced-colors) {
   button {
      background-color: ButtonFace;
      color: ButtonText;
      border-color: ThreeDShadow;
    }
    ...
}

@lukewarlow
Copy link
Member Author

lukewarlow commented Apr 9, 2025

I'm not familiar with the reasoning for the different options in windows contrast themes but the fact button background and test colours are configurable makes me think we should honour them. Even in base mode.

I think in practice border-color can be set to ButtonText and that would be fine. Windows only actually lets you customise a foreground and background colour for "buttons" (I think it actually should apply to at least select and other button like elements too). Though maybe ButtonBorder is better to allow for other forms of forced colors with more granularity.

We might also need this so the colour Swatch renders correctly? (Not sure exactly how forced colors applies to UA styles).

::color-swatch {
   forced-colors-adjust: none;
}

There's also some thought needed for the disabled states (and I guess placeholder too) such that they might need to use GrayText system colour to be styled correctly.

It would also be good to consider stuff like hover and active states and see if they'd need any special handling.

@nt1m
Copy link
Member

nt1m commented Apr 9, 2025

I'm not familiar with the reasoning for the different options in windows contrast themes but the fact button background and test colours are configurable makes me think we should honour them. Even in base mode.

Using system colors should be sufficient to get high contrast themes honored. I think we should do this only behind a forced-colors media query though.

I think in practice border-color can be set to ButtonText and that would be fine. Windows only actually lets you customise a foreground and background colour for "buttons" (I think it actually should apply to at least select and other button like elements too). Though maybe ButtonBorder is better to allow for other forms of forced colors with more granularity.

ButtonBorder probably makes sense here. It'll probably set to ButtonText on Windows anyway.

We might also need this so the colour Swatch renders correctly? (Not sure exactly how forced colors applies to UA styles).

::color-swatch {
forced-colors-adjust: none;
}

There's also some thought needed for the disabled states (and I guess placeholder too) such that they might need to use GrayText system colour to be styled correctly.

GrayText for disabled states is what's typically used. Placeholder should just use currentColor/inherit in forced colors mode, I think that's what Windows does.

It would also be good to consider stuff like hover and active states and see if they'd need any special handling.

Last I remembered, hover uses the Highlight/HighlightText pair.

@lukewarlow
Copy link
Member Author

I think we should do this only behind a forced-colors media query though.

I completely agree with this.

@josepharhar
Copy link
Contributor

Here is the resolution we previously made to use system colors in the UA stylesheet when forced colors is enabled: #10909 (comment)

Are the specific values that we use in forced colors supposed to be specced/interoperable?

@lukewarlow
Copy link
Member Author

I think they should be specced and interopable. I don't think forced colors should mean browsers diverge (especially because I doubt it's hard to come up with a coherent stylesheet).

@lukewarlow
Copy link
Member Author

We might also need this so the colour Swatch renders correctly? (Not sure exactly how forced colors applies to UA styles).

::color-swatch {
   forced-colors-adjust: none;
}

This seems to be correct from my tests. Chromium has this rule on the color input itself but its actually the only the swatch that really needs it. Gecko doesn't explicitly have this in their stylesheet but the color swatch does correctly render.

Arguably <meter> styling should apply it too as the colours actually convey meaning but this isn't implemented in either Chromium nor Gecko right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants