Skip to content
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

[css-color-adjust-1] Forced colors mode usage beyond high contrast mode #6664

Open
beverloo opened this issue Sep 22, 2021 · 3 comments
Open

Comments

@beverloo
Copy link
Member

https://www.w3.org/TR/css-color-adjust-1/#forced-colors-mode
https://www.w3.org/TR/mediaqueries-5/#forced-colors

[css-mediaqueries-5] defines a new forced-colors media query, that can be set to active when "forced colors mode" is active. This is defined as:

Forced colors mode is an accessibility feature intended to increase the readability of text through color contrast. [...] Users can also customize their own themes, for example to provide low contrast or hue contrast.

Chrome has an experimental feature (available in chrome://flags) to apply a generated Dark Mode to Web Contents that don't provide one themselves. It strikes me that allowing developers to detect this as follows would be very appropriate:

@media (prefers-color-scheme: dark) and (forced-colors: active) {}

I'd like to ask whether it would be appropriate to scope up this definition?

@lilles
Copy link
Member

lilles commented Sep 22, 2021

According to the css-color-adjust spec, forced-colors is a different thing than color-scheme override.

One possibility is to introduce a new media feature for this where the feature matches the color-scheme override:

@media (color-scheme-override: dark) {}
@media (color-scheme-override: light) {}
@media (color-scheme-override: none) {}

@lilles
Copy link
Member

lilles commented Sep 22, 2021

If fingerprinting is an issue, the color-scheme override is detectable today per spec since system colors are affected by the used value of color-scheme and color-scheme override will affect the used color-scheme in the case where the computed color-scheme does not contain the override color-scheme.

@lilles lilles added the Agenda label Sep 22, 2021
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-color-adjust-1] Forced colors mode usage beyond high contrast mode.

The full IRC log of that discussion <dael> Topic: [css-color-adjust-1] Forced colors mode usage beyond high contrast mode
<dael> github: https://github.com//issues/6664
<dael> Rossen_: Tagged by rune
<dael> Rossen_: Can anyone take this?
<dael> TabAtkins: fantasai and I can
<dael> TabAtkins: Question is how to reflect UA feature that does forced dark mode. Being tested on Android, I believe iOS has it
<smfr> only forced dark mode in apple mail, not in the browser
<dael> TabAtkins: Suggestion is reflect as a forced colors mode. Would imply we're doing things forced colors does
<dael> TabAtkins: Assuming auto-darkening does match up enough I think that's fine and we reflect that in prefers-color-scheme. Acts like author chose a11y feature to set colors to dark
<dael> TabAtkins: Seems straight forward. Doesn't give authors more things to react to. I suggest we accept Beverly's suggestion
<Rossen_> q?
<dael> Rossen_: Feedback?
<alisonmaher> q
<dael> smfr: Not sure if auto-darkening and forced colors are same. There's a bunch we resolved on for forced colors that's a lot difference
<Rossen_> ack alisonmaher
<dael> alisonmaher: Haven't looked too much, but I don't think forced dark is same. I think it's paint time. Don't use system colors to force darkening. I don't hitnk impl would match as spec for forced colors
<dael> Rossen_: You're saying darkening is paint?
<dael> alisonmaher: Yes. haven't looked that much
<dael> smfr: That's true of what Apple did in mail
<dael> Rossen_: That's a pretty major difference in behavior. Not sure harmonizing the two makes sense
<alisonmaher> q-
<dael> TabAtkins: Enough difference that authors should react differently? Not sure. If similar enough people can act the same way and for auto-darken should change colors it's fine. If they should do other changes should use another MQ
<dael> Rossen_: Would adjust-color override apply to auto-darkening?
<dael> TabAtkins: I would assume it would
<dlibby> q
<Rossen_> ack dlibby
<dael> dlibby: Regarding difference between featurs a lot of authors will writed forced-color MQ and use system colors. With forced dark mode being at paint time it could lead to some inconsistencies. Seems hard to map the two concepts directly
<fantasai> 1 to not linking this with forced-colors mode
<dael> Rossen_: Feedback I'm hearing is that even though conceptually there are similarities it doesn't necessarily mean it will be gray-dark or green-dark or whatever in order to match the paint time effects
<dael> Rossen_: I think we should take it back to the issue and do more work there
<dael> Rossen_: Sound reasonable?
<dael> TabAtkins: Yep

@astearns astearns removed the Agenda label Oct 11, 2021
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

4 participants