- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Jun 2018 09:28:30 +0000
- To: public-css-archive@w3.org
> I don't think there is any connection between dark mode and high contrast. I don't think they necessarily have to be in the same query (they probably should not), but: * as settings, these two have been tied in some OSes, where the only way to get darkmode was through one a high contrast mode * as preferences, these two are sometimes correlated, especially in accessibility use cases. Example: some users with dyslexia want low contrast and darkmode. So, while I do not expect to solve all of my laundry list from earlier with a single query, I do think we should think through the whole set before settling on something. > Enforced color inversion [...] applied by the OS would be something else entirely. I'm still not sure that these should be exposed at all. When that is implemented at the pixel level, It is needed, so that authors can turn off shadows, and invert images (so that they get double inverted), otherwise everything looks terrible. `forced-color-adjust: none | invert` ? It is less obvious to me that reacting to pixel level contrast boost/reductions or color tints is needed. > Looks like WebKit have already implemented something – `prefers-dark-interface`, but weren't intending to expose it to web content without a standards discussion that, or maybe `prefers-color-scheme: none | dark-on-light | light-on-dark` together with something like `prefers-contrast-adjust: none | high | low` might be a reasonable pair to cover the preference side of things. > Similarly, I am skeptical of a light-level media query [...] Maybe we can skip it entirely, and browsers have some built if feature (possibly optional) that turns on `prefers-color-scheme: light-on-dark` and `prefers-contrast-adjust: low` in night conditions, and `prefers-contrast-adjust: high` in over-bright washed conditions. Maybe. ---- With that in place, we'd cover forced pixel level inversions, preferences (for dark, high, low), and reacting to the environment (via preferences). We're left with forced contrast and forced color schemes that operate at the CSS level, rather than the pixel level. I think that this is found in: * Microsoft browsers, in terms of the Windows High Contrast Mode * Ebook readers, for their dark-on-light / light-on-dark / sepia modes. This is possibly the hardest, because it is not clear what properties it can affect (theoretically any, not limited to colors: could change fonts to add or remove serifs, add or remove borders or backgrounds…), how many different themes can exists (theoretically unlimited), and what these various themes mean and what an author should do in response to them. I think Microsoft has the right idea, and having both a [media feature](https://msdn.microsoft.com/en-us/library/hh771830(v=vs.85).aspx)to detect that this is happening, and a [property](https://msdn.microsoft.com/en-us/library/hh771863(v=vs.85).aspx) to turn it off if you have a better way of providing that effect is a good idea. But that doesn't help us with the potentially infinite list of color schemes. I am a little uncomfortable with closing the whole thing without having a good answer to that last problem, as I worry that the answer might change how we scope the rest. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2735#issuecomment-398335884 using your GitHub account
Received on Tuesday, 19 June 2018 09:28:32 UTC