Re: [csswg-drafts] [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced` (#5433)

What the difference is between using `@media (forced-colors: active) { }` and `@media (prefers-contrast: forced) { }`? It seems there is no difference. 

So why is it easier for Authors to have two ways to write the same code? Sure, they will often be conceptually thinking about contrast and forced colors at the same time — along with light/dark mode, reducing transparency, reducing motion... but that doesn't mean we should try and put all these media queries together into one. Media queries have the power of nesting, AND, OR, etc, so Authors can combine them however they want.

As I spent some time after the CSSWG discussion digging into this a bit more, and came to the opinion that we either need to remove `forced` from `prefers-contrast` — or we need to get rid of the `forced-colors` media query altogether. Having both makes this too complicated for Authors.

In other words, we have three options:
1. remove `forced` from `prefers-contrast`
2. rid of the `forced-colors` media query
3. do neither — and have two different ways for Authors to accomplish the same result

No matter which path we choose, the three options all end up with the same capabilities for Authors — the same usecases and needs are met. It's really a matter of: a) what implementors are willing to do; b) what's best for Authors.

I much prefer removing `forced` from `prefers-contrast`. That makes more sense to me. It feels more simple. It also does not require Edge to [agree to unship](https://caniuse.com/mdn-css_at-rules_media_forced-colors) the forced-colors media query. (No one [has shipped prefers-contrast](https://caniuse.com/mdn-css_at-rules_media_prefers-contrast) yet.)

Having two ways to write effectively the same media query conditional, when all this is already complicated the user preference options on different OSes are very different & most Authors only have access to one). Having two ways to write the same code will only going to result in making Authors think these tools are even more complicated than they actually are.

Florian argued:
>When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such (so summarized in [the minutes](https://www.w3.org/2020/10/19-css-minutes.html#item14))
so therefore having both situations in one media query will be easier for Authors. 

I disagree. I think it's confusing — Authors will wonder what the difference is between using `@media (forced-colors: active)` and `@media (prefers-contrast: forced)`. [Answer: none]. 

They may very well want to do similar things in the code, but these are separate situations that have to be thought through. Plus, `prefers-reduced-transparency`, `prefers-reduced-motion`, and `prefers-color-scheme` will all come into play. A designer should think about reducing transparency, adjusting things for a high/low contrast, reacting to forced colors, and light/dark mode all at once. Having two of these overlap in a mysterious way (for no reason other then theoretical code efficiency) doesn't make things easy for Authors — it makes it harder. 

It is true that _for Implementors_ these two things are tightly connected. Forced colors does often trip prefers-contrast high or low (not always, depends on the color theme). But Authors won't be thinking about it this way. For them, forced colors is one thing. Prefers high or low contrast is another. Exposing browser engine complexity to Authors doesn't help them. 

I see in the minutes the argument being raised that Authors will want to reduce visual complexity for both forced colors and for low/high contrast, so why not put it all in one MQ. To me that's like saying people will want to do things for phones, so why make them think through when to use a MQ for screen size vs a MQ for reduced-data? Let's just put the new `prefers-reduced-data` values into `width`, so Authors can use them at the same time. 


-- 
GitHub Notification of comment by jensimmons
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-713907250 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 21 October 2020 22:13:55 UTC