W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2020

Re: [csswg-drafts] [css-color-adjust-1][mediaqueries-5] Fold `forced-colors` and `prefers-contrast`? (#3856)

From: James Craig via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Jul 2020 23:20:09 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-655806870-1594250408-sysbot+gh@w3.org>
@fantasai wrote:
> Your example in #3856 (comment) doesn't work because you're assuming that (prefers-contrast) only matches high or increased contrast modes, but in fact it also matches low contrast modes. 

The spec proposes `low`, but would it ever match? It's a theoretical value that's not associated with any real user preference; there is no "low contrast" switch on any common operating system. I proposed in #2943 that the "low" value be removed since it's not implementable.

Meanwhile, macOS and iOS both have a "non-high-contrast-but-increased-contrast" mode (first shipped in iOS 7, over 8 years ago) that the CSS MQ5 spec does _not_ account for. If those platforms ever ship a true "high" contrast mode, [the current syntax of the media feature would become incompatible](https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-599737863), because it doesn't allow that future flexibility. Adding forced colors into the mix makes the authoring syntax even more complicated. 

The preferable, simple boolean:
```css
@media (prefers-contrast) { }
```
Would become this at minimum: 
```css
@media (prefers-contrast: high) or (prefers-contrast: increase) { }
```
Why force authors to be so verbose in order to match the most common use case? 

We're crossing into the other issue a bit, so instead of going into more detail here, I'll point across to the proposal in https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-599751283.


-- 
GitHub Notification of comment by cookiecrook
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3856#issuecomment-655806870 using your GitHub account
Received on Wednesday, 8 July 2020 23:20:10 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:11 UTC