Csswg-drafts: [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced`

[cookiecrook]

[mediaqueries-5] duplication of forced-colors: active and prefers-contrast: forced

Breaking this discussion out of the large mega thread in #2943.

I believe these statements are true.

1. AFAICT, forced-colors: active and prefers-contrast: forced are exact duplications of each other.
2. I am only aware of one implementation of forced colors: on Windows.
3. forced-colors is already implemented in Edge (and possibly in the Chrome HC extension.)

Opinions:

• I'm not sure why two properties are needed. I think I'd heard both that the forced value is intended as a replacement for the forced-colors media feature, and I've also heard that these are intended to be complementary and co-exist. Which is it, and why?
• Since there is only one implementation (Windows), I worry that shoehorning a single forced value into prefers-constrast is unnecessarily limiting. Another platform (iOS, Mac, ChromeOS, Android, Linux) may support a different forced mode in the future, and forced-colors would be easier to extend.

Editorial: prefers-contrast: forced cross-link to forced-colors: active an confirms the duplication. If both are kept, the reciprocal link and explanatory prose should be added, too.

[cookiecrook]

Even though I'm a WG member, I'm not able to add the requested labels. Is that intentionally limited to full editors?

[astearns]

Nope, it's just a manual step for us to add people to the right team. You should be good now.

[frivoal]

Whether or not its the right conclusion is a separate question, but the current idea is:

They are indeed the exact same thing. We wish we had though of defining it as prefers-contrast: forced first, but we didn't, so MS shipped force-color: active already. We thought we still liked prefers-contrast: forced better, so we defined that, but since forced-colors: active shipped, we're keeping it as well for compat reasons. The fact that one is the desired syntax, and the other is the legacy alias isn't currently clear in the spec, but an editorial cleanup should make that more obvious.

So, with that in mind, I think we can take 3 stances:

1. I think all is all is fine, just do the editorial clean up to make it clear why there's two.
2. I agree that prefers-contrast: forced is the better design, but the benefit isn't strong enough to justify a "good syntax" and "legacy syntax", so we should revert the decision taken in https://github.com/w3c/csswg-drafts/issues/3856 to add forced to prefers contrast.
3. I disagree that prefers-contrast: forced is the better design. Keeping forced colors separate from contrast preferences is desirable, regardless of compat. On that basis, we should revert the decision taken in https://github.com/w3c/csswg-drafts/issues/3856 to add forced to prefers contrast.

---

My stance is (1), and as the spec's Editor, I'll do the editorial clean-up to at least make it clear what the current situation is.

I believe your stance is closer to (3). I'd suggest holding off just a bit to see if the clean-up I'm about to do makes things better in your opinion. If it doesn't, it's probably worth re-reading https://github.com/w3c/csswg-drafts/issues/3856 (I'd say from the top up to and including the teleconf minutes of June 11, after that it goes into a number of tangeants, most of which are answered by https://github.com/w3c/csswg-drafts/issues/2943 or by the editorial clean-up I'm about to make), and responding to the points that were made in favor of the resolution that was taken then.

[cookiecrook]

My stance is partially 2 (added 2b below) and fully 3.

2b. Regardless of which syntax is better, there is only one platform that supports this feature and the current syntax is sufficient to cover that platform. Therefore, the benefit isn't strong enough to justify a syntax duplication. If future platform features require additional syntax changes, it would be better to wait until we know what those are.

1. I disagree that prefers-contrast: forced is the better design. Keeping forced colors separate from contrast preferences is desirable, regardless of compat. On that basis, we should revert the decision taken in #3856 to add forced to prefers contrast.

Yes to this, too.

[MReschenberg]

Some additional context from Mozilla: we implementforced-colors and prefers-contrast too, though they're behind prefs :)

The "forced" parts of our implementations respond to both Windows HCM and Firefox HCM (about:preferences > colors, the dialog allows users to pick customized colors for text, background, visited/unvisited links). We've been doing some work with folks at Google to make sure G-suite sites render appropriately in Firefox when HCM (windows, ours) is enabled. Google is using these preferences to make adjustments (mostly prefers-contrast: forced, if I remember correctly), but our users won't benefit from them until we can unpref. I don't know that I have enough context to take a stance one way or another, but just wanted to give some more usage context :)

[cookiecrook]

@MReschenberg wrote:

The "forced" parts of our implementations respond to both Windows HCM and Firefox HCM (about:preferences > colors, the dialog allows users to pick customized colors for text, background, visited/unvisited links).

To clarify, are you saying the Firefox HCM mode on non-Windows platforms (Mac, Linux) will also match the media features? Good to know. Thanks.

our users won't benefit from them until we can unpref.

By "unpref" do you mean change Firefox to match the Windows system setting? I thought that was already implemented based on your comment that "The 'forced' parts of our implementations respond to both Windows HCM…"

[MReschenberg]

To clarify, are you saying the Firefox HCM mode on non-Windows platforms (Mac, Linux) will also match the media features? Good to know. Thanks.

Yep, exactly -- prefers-contrast: forced will trigger for users running Windows HCM as well as for users on any platform running Firefox HCM.

our users won't benefit from them until we can unpref.

By "unpref" do you mean change Firefox to match the Windows system setting? I thought that was already implemented based on your comment that "The 'forced' parts of our implementations respond to both Windows HCM…"

Ah sorry, bad wording. Right now, Firefox parses prefers-contrast when it finds it in CSS. If it finds the query in a UA style sheet, it'll apply the inner CSS (provided the FF user has some qualifying HCM enabled^). If it finds the query in a non-UA style sheet, it does nothing. The full implementation is available behind a pref (layout.css.prefers-contrast.enabled) in about:config. If _that_ gets flipped, then we'll parse and react appropriately in all style sheets. Does that make more sense? Ultimately, we'd like to do away with the pref entirely and have prefers-contrast on by default (so all users can benefit, not just those that are savvy enough to go into about:config and flip it themselves), but we're waiting for a resolution here.

[css-meeting-bot]

The CSS Working Group just discussed forced-colors and prefers-contrast.

The full IRC log of that discussion

<TabAtkins> Topic: forced-colors and prefers-contrast

<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/5433

<TabAtkins> Morgan: We've been implementing prefers-contrast and forced-colors in Moz for a while

<TabAtkins> Morgan: Hoping to unpref adn ship soon

<TabAtkins> Morgan: Hesitant until this issue is resolved

<TabAtkins> Morgan: Don't have an opinion on the stances taken here

<TabAtkins> florian: Attempted summary of where we are

<TabAtkins> florian: We have two related things here

<TabAtkins> florian: prefers-contrast MQ, which is about letting the author know whether the user prefers higher or lower contrast on the page

<TabAtkins> florian: So author can change colors, add/remove borders, etc

<TabAtkins> florian: And notably, authors can use it without a specific value; (prefers-contrast) just indicates that they have some preference, but not whether it's high or low

<TabAtkins> florian: But general rule is that, regardless, removing visual clutter is often a good thing

<TabAtkins> florian: A related thing was added to css, forced-colors mode

<TabAtkins> florian: Not a user pref, it changes colors for the author automatically

<TabAtkins> florian: When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such

<TabAtkins> florian: So we ahve a (prefers-contrast: forced-colors) value to indicate this

<TabAtkins> florian: So my feeling is that they're theoretically distinct, but in practice they're close together and can be addressed in similar ways

<cbiesinger> q-

<fantasai> Worth noting also that "forced colors" is called "high-contrast mode" in Windows, which developed it. It's clearly intended to handle a contrast preference.

<TabAtkins> florian: So right now we ahve both the (forced-colors) MQ as well, for legacy reasons

<TabAtkins> florian: We probably can't remove (forced-colors), for legacy compat reasons. We probably could remove the (prefer-contrast: forced), but I think it would be more useful to keep

<TabAtkins> jcraig: We also have prefers-reduced-transparency; I mention because we use it more to indicate reducing clutter

<TabAtkins> jcraig: Sometimes lower-vision users who would prefer contrast would also prefer less things floating with transparent bgs, so they'll often be set up together

<TabAtkins> jcraig: One unmentioned theoretical purity arg is that having forced-colors in here is the only instance so far with a prefers-* MQ having a value that does not correspond to a user preference

<TabAtkins> jcraig: Also reached out to aboxhall

<TabAtkins> jcraig: She shared this:

<jcraig> Alice: I am pretty convinced that the MS version (forced-colors: active) is better, but I don’t think I would have any critical arguments to add given there will presumably be MS folks there to articulate the reasoning (i.e. that forced-colours doesn’t necessarily have anything to do with contrast, since the color choices are arbitrary)

<TabAtkins> jcraig: So she doesn't have a strong opinion, but tends to agree that (forced-colors) is better

<TabAtkins> jcraig: Other thing I shoudl probably mention is that Apple doesn't ahve a forced-colors setting, so it's not particularly troublesome from Apple's perspective.

<Morgan> q+

<TabAtkins> jcraig: But I have opposite opinion from Florian for the author experience

<TabAtkins> jcraig: I think the convenience of being able to just write (prefers-contrast) doesn't outweight the clarity gained from writing (forced-colors)

<astearns> ack fantasai

<TabAtkins> fantasai: It's worth noting that the forced-colors feature was developed as Windows High Contrast mode, so it was intended as forcing a particular contrast.

<TabAtkins> fantasai: Doesn't necessarily force a high contrast, but it does force a fixed contrast

<TabAtkins> fantasai: So not unreasonable for it to fall under the (prefers-contrast) MQ

<TabAtkins> fantasai: I have a side question on (prefers-reduced-transparency)

<TabAtkins> fantasai: If you have an opaque BG with a pattern on it, is that something that should be turned off if this pref is on?

<TabAtkins> fantasai: bc if it's actually about visual clutter, that's not stated by the name

<jcraig> q?

<TabAtkins> fantasai: Also, prefers-contrast will be true in the majority of cases where Windows High Contrast will be on

<jcraig> q+ to respond to Elika's q re background pattern versus transparency

<TabAtkins> fantasai: Because those forced colors will generally cause it to resolve to high or low (from the specification fo the forced-colors feature). ONly an indeterminate color scheme will not trigger it.

<TabAtkins> fantasai: So it's concerning a bit if authors are testing with High Contrast mode, and triggering (prefers-contrast), but then a user comes along with an indeterminate scheme, they might not get caught

<TabAtkins> fantasai: And in general, both (prefers-contrast) and (prefers-color-scheme) do reflect the choices made by Forced Colors mode

<TabAtkins> Morgan: Turns out I have an opinion

<astearns> ack Morgan

<TabAtkins> Morgan: I added some info to the issue just a bit ago

<TabAtkins> Morgan: Firefox has a high-contrast mode built in, that's not OS-specific

<TabAtkins> Morgan: It triggers True when Windows High Contrast, or the browser-local HCM, is on

<TabAtkins> Morgan: So far we've found people using it for both high and low contrast reasons

<TabAtkins> Morgan: But also for things like photosensitivity

<jcraig> What does Firefox HCM "regardless of browser" mean?

<TabAtkins> Morgan: Those don't necessarily fall into high or low contrast bins

<fantasai> jcraig, suspect she meant "regardless of OS"

<TabAtkins> Morgan: So I agree with fantasai's concerns that they might not have their prefs reflected by authors

<TabAtkins> Morgan: Also, we find that devs often dont' have the ability to test with high contrast themes.

<astearns> ack jcraig

<Zakim> jcraig, you wanted to respond to Elika's q re background pattern versus transparency

<TabAtkins> Morgan: So if our local HCM doesn't trigger this query, they dont' have a way to test

<florian> q+

<TabAtkins> jcraig: So (forced-colors) just means colors were forced, not anything about the contrast. So I still think (prefers-contrast) isn't right to trigger it automatically

<Morgan> jcraig, sorry yeah regardless of OS :)

<TabAtkins> jcraig: wrt transparency and backgroudn color, on Apple OSes we hav separate settings for these bc the user may want or not want each of them

<TabAtkins> jcraig: There's often overlap, but the clarity from breaking them into separate settings is worth preserving, I think

<TabAtkins> jcraig: With the patterned background - in iOS we have a lot of transparency, but not a lot of loud backgrounds

<TabAtkins> jcraig: So if we wanted to do something more general about legibility, we could do something for that, but trying to tie "increase legibility" to a contrast setting seems weird, it should just be about contrast

<astearns> ack fantasai

<Zakim> fantasai, you wanted to re-explain her point

<TabAtkins> fantasai: So james had one point about "this is not a preference, so why is it in a MQ about preference)

<TabAtkins> fantasai: So it's already going to trigger that in most cases - Forced Colors mode will usually trigger (prefers-contrast) and (prefers-color-scheme)

<TabAtkins> fantasai: And an author will thus usually see those turned on when they test in forced colors mode

<TabAtkins> fantasai: Also, for testing now - if authors write (prefers-contrast) in their stylesheet, and it usually triggers in forced colors (not all users, but most, including themselves), it's likely they'll write code depending on that, which then doesn't trigger for users in the in-between state that coudl still usefully use the adjustments

<TabAtkins> fantasai: So it's easy to leave out a class of users by accident

<TabAtkins> q+

<jcraig> I don't agree that "most prefers-contrast users" will have forced colors on... iOS "increase contrast" doesn't force colors.

<TabAtkins> fantasai: So I think that's another reason why having forced colors explicitly fall under prefers-contrast helps out

<TabAtkins> jcraig: I think elika said taht most prefers-contrast people will ahve forced colors...

<Morgan> q+

<TabAtkins> florian: No, other way around. If they have forced colors, and they are high-contrast, then you'll trigger (prefers-contrast: high). And same for (prefers-color-scheme) if they're light or dark, etc

<TabAtkins> florian: So most of the time forced colors will cause these other MQs to trigger, but if you have a middling color scheme, you'll be in a rare bucket that won't trigger the boolean form at all

<TabAtkins> florian: So adding the 'forced' keyword in makes sure they trigger at all times

<TabAtkins> jcraig: So as an author, I'm not sure whether to check for (prefers-high-contrast: high) or (prefers-high-contrast: forced)

<TabAtkins> jcraig: And then it's just weird still to have another setting to the exact same thing

<jcraig> q?

<astearns> ack florian

<TabAtkins> florian: Both in terms of transparency and patterns and this argument, I think there's a general tension between a11y features here

<TabAtkins> florian: On the user side, general desire to express complex needs, because users have many needs and preferences

<jcraig> s/(prefers-high-contrast: high) or (prefers-high-contrast: forced)/(prefers-contrast: more) or (prefers-contrast: forced)/

<TabAtkins> florian: But if we expose too many fine-grained prefs, it's likely authors won't respond to everything. The more we group them, the more likely the response isn't perfectly targeted at their need, but more likely they'll get a reasonable response.

<TabAtkins> florian: So trade-off of perfect responses (that ar eless likely) vs okay responses (that are more common)

<TabAtkins> florian: I think the current design is about right for this reason, but we can disagree on the limit

<astearns> ack TabAtkins

<astearns> ack Morgan

<fantasai> TabAtkins: Florian made the exact point I was going to

<TabAtkins> Morgan: Last time this discussed, no definition of "more" or "less" ratios

<jcraig> more than default, less than default

<TabAtkins> Morgan: Saw this as a sliding scale of more and less as higher and lower ratios defined by user agent

<fantasai> s/ar eless/are less/

<TabAtkins> Morgan: So if you see this as a continuum, makes sense to me that the middle values also trigger the MQ, rather than there being a threshold that turns it on only for more extreme values

<TabAtkins> jcraig: Responding to florian's, I agree we ahve a decision to make about granularity

<TabAtkins> jcraig: My opinion is that it should be towards granular side.

<TabAtkins> q+

<TabAtkins> florian: The people who ask for it know what they want, but if too granular, they just wont' get what they want often

<TabAtkins> jcraig: How i understand windows hcm right now, it'll match both 'forced' and either 'more' or 'less' if appropriate

<TabAtkins> jcraig: I think it's quite reasoanble to match 'more' if HCM is on

<TabAtkins> jcraig: is on with a high-contrast scheme

<TabAtkins> jcraig: And if we want to have a separate granular reference to forced colors in general, still don't understand why it needs to be the same

<TabAtkins> jcraig: You're talking about a boolean match for contrast that is high, or low, or in the middle.

<emilio> q+

<emilio> ack TabAtkins

<fantasai> TabAtkins: wrt granularity choice, directly related to what you were saying

<fantasai> TabAtkins: our current proposal has that granularity

<fantasai> TabAtkins: You can target high contrast, low contrast, and forced contrast specifically and independently

<fantasai> TabAtkins: But something you are likely to want to do for all of them is to simplify the page

<fantasai> TabAtkins: If this is indeed the case, then we should have something that catches everything simply

<fantasai> TabAtkins: And certainly should be something that catches the more common and less common cases the same way

<fantasai> TabAtkins: I would rather authors have an general switch, rather than needing to list each thing independently

<fantasai> TabAtkins: If your argument is that there is no reasonable thing to do that applies to all these contrast modes

<fantasai> TabAtkins: then we don't need it

<jcraig> Loss audio in the middle of Tab's comment

<fantasai> TabAtkins: but if there is, then we need a good syntax for doing so

<fantasai> jcraig: if ... about syntax, then happy to take it to a vote

<fantasai> jcraig: I don't think authors are going to see (prefers-contrast) or even (prefers-contrast: forced) and jump to conclusion of needing to reduce decoration on the page

<fantasai> astearns: Any input from ppl not yet part of the conversation?

<astearns> ack emilio

<TabAtkins> Going for a more general "prefers-simple" MQ doesn't sound unreasonable...

<fantasai> emilio: Conversation was we cannot remove 'forced-colors: active'

<TabAtkins> emilio: Convo started with "we can't remove (forced-colors)

<fantasai> emilio: I don't see 'prefers-contrast: forced' adding a lot of value

<TabAtkins> emilio: I dont' see (prefers-contrast: forced) having a lot of value here

<TabAtkins> emilio: prefers-contrast and forced-colors are technically unrealted and they should be separate MQs

<TabAtkins> florian: On the one hand, I don't think this is a breaking point; I'd be willing to yield if necessary.

<TabAtkins> florian: But I feel like fantasai and TAb and I are making an argument for it being useful, but y'all keep saying "i dont' see why it's useful" - we just said why it was useful

<TabAtkins> florian: I don't think we're wrong that the syntax is convenient, but are we wrong about the use-case?

<TabAtkins> astearns: Is the user-case enabled by (forced-colors)?

<TabAtkins> florian: No, it's not about responding to forced colors specifically.

<jcraig> q+

<TabAtkins> florian: In the case of an author that has a low and high contrast mode, it seems reasonably likely they'd have some bit of the code specific to those modes, and a shared chunk applied to both high and low modes that, for example, disables backgrounds.

<TabAtkins> florian: The way they'd write that code is with the common code in (prefers-contrast), then specific ones in (prefers-contrast: more)/etc

<jcraig> (prefers-contrast) versus (prefers-contrast or forced-colors)

<TabAtkins> florian: Assuming they do that sort of code organization, should we allow that to still work when the user has HCM set to a middlign contrast, or should we say that authors should know to pay attention to the (forced-colors) MQ as well specifically to handle these cases?

<TabAtkins> fantasai: And more complexity here - the people using HCM will get those shared styles if their chosen colors are high-contrast or low-contrast. And users in the middle have the same needs as high and low, but without 'forced' they wont' get it

<TabAtkins> fantasai: And from a dev POV, devs will very likely test HCM with a high-contrast theme, and they'll assume their page is working in a particular way when forced-colors is on and in a high-contrast mode. But users not matching that case won't get hit.

<fremy> FWIW I agree with @fantasai's latest comment; authors will not expect the block to turn off

<emilio> q+

<TabAtkins> fantasai: So having pages fall into codepaths that aren't tested is a great way to have a broken page

<astearns> ack jcraig

<TabAtkins> jcraig: I see the point, and the mild syntax convenience

<astearns> zakim, close queue

<Zakim> ok, astearns, the speaker queue is closed

<TabAtkins> jcraig: Potentially could match something that might provide a convenience in the interface to an author that wants to reduce complexity.

<TabAtkins> jcraig: If we assume that authors will know that and respond to it.

<TabAtkins> jcraig: But I think the risk is that authors will conflate different things

<TabAtkins> jcraig: Recent years, authors conflate small viewport widths to mean it's on mobile

<TabAtkins> jcraig: Or check the user agent and see iOS and assume it's a phone and not an iPad

<TabAtkins> jcraig: Apple had to do a lot of work to make sure iPads get desktop sites, for example

<fantasai> The reason authors are conflating those things is because they had no other way to detect the things they were interested in

<TabAtkins> jcraig: So even tho these are somewhat conflated, risk of conflating them

<fantasai> e.g. knowing you're on a touchpad is important consideration in design, but there was no ability to query that directly

<fantasai> so authors made a lot of assumptions

<TabAtkins> emilio: I get fantasai's point, but we can solve it without ahving to expose the 'forced' value

<fantasai> We don't have that problem here because we already have the individual options available to query

<jcraig> s/somewhat conflated/somewhat related/

<TabAtkins> emilio: You can just say if you're forcing colors you must match high or low

<TabAtkins> emilio: When forcing colors you most can't override system colors

<TabAtkins> emilio: I think having two MQs mean the same thing isn't amazing either

[jensimmons]

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 the forced-colors media query. (No one has shipped 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)

...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.

[frivoal]

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

There's no difference indeed.

So why is it easier for Authors to have two ways to write the same code?

It's not easier. I'm arguing for both because one of them shipped already so we cannot remove it (at least not easily), and because I see benefits in the other one.

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.

My point is different in a subtle but important way: I don't want to group them so that authors can target all of these users with one query, but because I expect authors will write code that is applicable to all these users with that one query anyway, and asking authors to specifically remember to target a separate small demographic that would be well served by code they already wrote is unfortunate, because some/most of the time they'll forget, and these users will miss out.

In more details:

• Will some authors write styles for @media (prefers-contrast: more) -> yes
• Will some authors write styles for @media (prefers-contrast: less) -> yes
• Will some authors write styles for both -> yes
• When writing styles for both, will some authors refactor the common parts into @media (prefers-contrast) -> yes

When that happens, this common code will be applied to:

• users who have explicitly asked for more contrast
• users who have explicitly asked for less contrast
• users who have picked a forced color scheme that happens to be high or low contrast

The question is then: should it also apply to users who have picked a forced color scheme that is neither particularly high nor low contrast, or should we require authors to specifically remember that these people exist and to target them explicitly.

I'm saying that yes, it should apply, because the shared code is highly likely to be relevant, and authors are overall unlikely to remember to carter for this this relatively small user demographic. Those who do remember still have all the tools needed to tailor the style if a difference is needed, but getting things to work when you don't think about it too much has value. Accessibility gets better when users with similar enough needs are grouped together so that they benefit even when authors don't specifically remember them.

I do agree that from a conceptual point of view, forced colors and contrast preferences are different things, and it would be cleaner to have them be separate, which probably affect teachability. So there's a tradeoff. @jensimmons argues that we should pick author understandability over implementer convenience, and this calls for keeping forced-color: active over prefers-contrast: forced. I completely agree. But I think there are user benefits here that could outweigh the author concerns, and that this calls for the other way around.

[cookiecrook]

As I understand them, all commenters in the meeting and on the GitHub issue are in agreement that either syntax can provide the same functionality and implementability. The disagreements are purely a difference of opinion about the ideal authoring usage.

Most also agree that we should keep forced-colors so the main question is whether to keep prefers-contrast: forced.

[cookiecrook]

As I understand them, these are the main arguments made in favor of keeping prefers-contrast: forced:

1. Shortens the media query that would match any combination of forced colors or contrast preference: the shorter boolean @media (prefers-contrast) as opposed to @media (prefers-contrast) or (forced-colors).
2. Reduces the likelihood that authors will overlook users who have forced colors that don't match either contrast-specific value: less (reduced contrast) or more (increased or high contrast). The follow-on justification for this (if I understand correctly) is the premise that ~"all users who have either forced colors or any contrast preference will also have a desire for reduced visual complexity, such as removing decorative background patterns."

[cookiecrook]

The main arguments I and others made against prefers-contrast: forced:

1. We should keep forced-colors for interoperability, unless the new syntax proposal provides sufficient benefit to warrant deprecating existing implementations. In my opinion, it doesn't provide additional benefit. (More on that below, since it's the primary point of disagreement.)
2. Keeping the two media features separate increases author clarity. prefers-contrast is only ever about a preference for more or less contrast. forced-colors is only about whether colors are forced, regardless of contrast.

[cookiecrook]

So as I see it, the primary argument in for keeping prefers-contrast: forced is based on a causation versus correlation fallacy.

There is an assumption that all people with forced colors want some form of reduced complexity. I don't believe this to be true, and I haven't seen any evidence presented to prove this assumption.

• I do recognize there is a strong correlation between higher contrast and reduced visual complexity. This combination is common for low vision users with loss of clarity or reduced contrast perception.
• I also recognize there is at least an anecdotal correlation between lower contrast and reduced visual complexity.

There's no disagreement on the above two statements, and both of those relate to a contrast preference. But those aren't the justification for keeping prefers-contrast: forced. Instead the argument is this:

Premise: If users have custom colors whose contrast ratios match neither low contrast nor high contrast, every user in this group still wants reduced visual complexity. (???)

I do not believe this ↑ premise is true. My gut feeling is that it's not true. I would assume this group of users just prefer to theme their Windows experience, and don't care about reduced complexity at all. Regardless, we don't know enough about this group of users to prove or disprove either assumption.

In my opinion, if CSS needs a media feature for prefers-reduced-complexity or prefers-improved-legibility, the working group should consider those separately.

[frivoal]

I think @cookiecrook 's summary in https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954048 and https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954108 is a good one, and I agree that the tension summarized there is the core of the argument to be settled, either by picking a point on the trade-off, or by disproving some of the assumptions, thereby doing away with the trade-off. I'd just add one small nuance:

all users who have either [....]

I don't think we need to go as far as "all users". With "most users", the argument still works, as including prefers-contrast: forced would help more often than not. There's a statistical nature to this problem, and depending on how we set up the system, we're may help or inconvenience more people.

Which leads us to

Premise: If users have custom colors whose contrast ratios match neither low contrast nor high contrast, every user in this group still wants reduced visual complexity. (???)

Same here: I'd replace "every user" with "most users". And while I agree the statement with "every" might be a little hard to prove or dubious, it seem much less of a stretch when it's merely "most": when you've opted into a forced (and thus reduced) color palette, you no longer have room for all sorts of decorative things, from a variety of background images, to gradients, or all sorts of embellishments. By picking a forced palette, you're necessarily opting into a visual simplification of some kind. It's going to happen whether we tell the author through a MQ or not, but it's part of the package, so we might as well tell them, so that they can react.

[cookiecrook]

I think my argument stands even if we change the instances of “every/all users” to “most users.” I don’t know of any evidence that indicates “most” want this.

Rather than requesting we disprove the assumption, can someone point to evidence that confirms the assumption?