[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 [css-color-adjust-1][mediaqueries-5] Fold forced-colors and prefers-contrast? #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 [css-color-adjust-1][mediaqueries-5] Fold forced-colors and prefers-contrast? #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 #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 #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.

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 [css-color-adjust-1][mediaqueries-5] Fold forced-colors and prefers-contrast? #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//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 #5433 (comment) and #5433 (comment) 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?

[dlibby-]

We didn't get to this in the F2F last week, but I agree with the core of @cookiecrook's argument - I don't think there is strong evidence for the boolean form of prefers-contrast being used to reduce visual complexity, and would probably be difficult for authors to reason about (enhancement in service of respecting a user preference is much different from adjusting in response to forced changes to a page's appearance).

As anecdata, I also ran across this blog post that expresses some of the same sentiments:
https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/

Also, if this does become a larger problem in practice, we would have the option of re-adding the value, whereas removing it would be more difficult. Another option (either now, or if the boolean usage ends up being problematic) would be always mapping forced colors mode to more or less, similar to what is done for prefers-color-scheme.

[cookiecrook]

FYI @astearns added this on the agenda for tomorrow's CSS meeting at your local time.

[MReschenberg]

Going to gather some data on user-set (or platform-inhereted) contrast ratios in firefox :)

[css-meeting-bot]

The CSS Working Group just discussed [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced` , and agreed to the following:

• RESOLVED: Removed the forced value from prefers-contrast MQ

The full IRC log of that discussion

<dael> Topic: [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced`
<dael> Github: https://github.com//issues/5433
<dael> alisonmaher: For a bit of context chromium has impl of prefers-contrast behind flag. Pretty sure FF does as well
<alisonmaher> In favor of 'prefers-contrast: forced'- https://github.com//issues/5433#issuecomment-716954048
<alisonmaher> Against 'prefers-contrast: forced'- https://github.com//issues/5433#issuecomment-716954108
<dael> alisonmaher: p-c:f is duplication of forced-colors MQ. Previously agreed to keep for compat. Do we want to keep p-c:f or not? Strong arguments on both. jcraig summarized them well ^
<dael> alisonmaher: In favor is it shortens the MQ needed to match any combo of users and reduces likelyhoold that authors overlook users with a different color sceme than less or more
<dael> alisonmaher: against it doesn't add any additional benefit and removing provides more clarity to authors on which to use and how it works
<jcraig> q+
<florian> q+
<dael> alisonmaher: I tend toward remove b/c simplifies and matches more to prefers color scheme approach which jsut matches to dark or light.
<dael> alisonmaher: Perhaps a middle ground where we remove but still capture the users, but not sure what that would look like.
<jcraig> q?
<dael> jcraig: Thanks alisonmaher for the summary
<astearns> ack jcraig
<TabAtkins> q+
<dael> jcraig: One piece not mentioned is there's an assumption that all forced-color users reglardless of match less or more want reduced complexity. I don't believe it's true. Don't have evidence, but don't think evidence exists. My hunch is these people customize and don't have a preference on complexity. Seems coorilation vs causation
<astearns> ack florian
<dael> jcraig: Suggestion alisonmaher mentioned about a way to match both, I don't think it's desirable b/c I don't know of need. Looked like dlibby commented along the same lines
<dael> florian: Thanks to alisonmaher and jcraig.
<TabAtkins> q-
<dael> florian: I disagree with jcraig this is people tweaking colors b/c forced-colors changes the colors of your webpage and since you don't have full range of colors available a number of htings will break like gradients. force-color pallate is reduced
<TabAtkins> florian is saying exactly what i was going to
<dael> florian: b/c of that I thinkw e fall into needing reduced complexity
<fremy> I agree with florian
<jcraig> dlibby's comment: https://github.com//issues/5433#issuecomment-780191074
<dael> florian: Otherwise, I think priority of consistency applies. For authors separation is nicer. Slightly shorter syntax is probably not worth it. Users, though, nice for the small set of users not to be forgotten
<dael> astearns: Any other comments?
<dael> [silence]
<jcraig> q?
<dael> astearns: Proposal is remove the forced value for prefers-contrast
<jcraig> q+
<fantasai> s/prefers-contrast/prefers-contrast and de-link the two media queries/
<Rossen_> q?
<dael> florian: I think we've made progress about where there's an issue. Not sure we agree on the solution
<Rossen_> ack JaseW
<astearns> ack jcraig
<Rossen_> ack jcraig
<dael> jcraig: On mac and iOS the underlying archetecture allows us to use increased contrast and other settings and would allow a really high contrast forced-colors in the future. Similar to MS. Issue we've seen in the past is b/c MS is only impl of forced-colors we don't know end result will match that exactly
<dael> jcraig: We don't have direct plans to do that, but I'd like to see it.
<Morgan> q+
<TabAtkins> q+
<dael> jcraig: Leaving the forced-colors media feature open and extensible would allow us to better match varients across impl. Shoehorning into prefers-contrast limits that in the future. I think it would be good to leave extensible
<dael> Rossen_: Quick point, chrome is almost done so won't be only one I presume
<dael> jcraig: I'm talking platform, not browser
<dael> Rossen_: My bad. I thought you were talking about browser
<astearns> ack Morgan
<astearns> ack TabAtkins
<dael> Morgan: I have a follow up. FF has its own version of forced-colors that we allow on any platform. It's another impl same as MS one. There is another sort of platform impl there.
<dael> TabAtkins: In jcraig earlier comment you seemed to say you should leave forced-colors more open. Do you think there's anything we could query for about forced colors beyond on or not? From our designs there wasn't anything you can conclude beyond on or not
<jcraig> q+
<dael> fantasai: And forced-color limits the pallate. You could have forced-color that's similar to increased contrast which keeps hue but turns the constrast way up
<dael> TabAtkins: I don't think that's consistent with idea of forced-colors as we have
<dael> fantasai: yeah, forced-contrast mode
<astearns> ack jcraig
<fantasai> s/way up/way up, but that would be a different feature/
<dael> jcraig: Speculating on that question. Closest thing I'm aware of is closed captions have default colors and forced colors. Similar to user styles vs overwritten user styles where you can say if media doesn't spec the font then I want it to be in monospace. If it does spec leave as spec. And you can override author
<florian> q?
<florian> q+
<dael> jcraig: Closest thing to speculate on is this mixed force-ness where you may say for caption blocks I want forced, but don't care about others. mixing of DOM and elements. All speculation
<astearns> ack florian
<dael> florian: I think today I'm the only one who explicitly was in favor of retaining it. I would like a sense of if I'm alone
<dael> TabAtkins: In IRC both fantasai and I said we think the same as you
<dael> fremy: And I did
<dael> astearns: My take is we have two separate opinions and neither side has conviced the other. My bias is remove until people can be all convinced it should be there
<dlibby> q+
<dael> fantasai: Would create compat problems. prefers-contrast is triggering...I guess can try, but if triggering on some cases but not other and we change it. Would be a minority of cases, I guess
<dael> Rossen_: Do you have data?
<dael> florian: My part it's logic but not data. I suspect MS is only party with data. We would want to look at the particular color schemes used by those with forced-colors which are neither high or low contrast
<jcraig> q+
<dael> Rossen_: What about data of use removing it and looking for compat risk?
<dael> florian: That's future compat. If we do it one way and switch there are problems. If we remove it a small minority of users would have things worse if you follow my logic.
<astearns> ack dlibby
<astearns> ack jcraig
<dael> dlibby: Wanted to note we can gather data as we ship to understand impact. On compat point seems main motivation is for user and not web author. If seeing harm for users I think that's more of a concern than compat since those are the users who want these rules. But data of shipping without value could be useful
<dael> jcraig: I would agree if there's evidence. but florian said it was based on logic, sounded like speculative logic.
<dael> jcraig: Quoting dlibby from the issue, florian said MS would be one to know. dliby says [reads]
<dael> jcraig: It's about author and user benefit
<TabAtkins> q+
<florian> q+
<astearns> ack TabAtkins
<dael> jcraig: And if this is larger problem in practice we can add, but removing is more difficult. It sounds like that comment is in favor or removing now. Fair dlibby ?
<dael> dlibby: Yes
<fantasai> agree with jcraig's last assessment
<fantasai> (and also the point TabAtkins is making now)
<dael> TabAtkins: Not to belabor too much. Idea about unclear author guidance, the point is there is explicit author guidance. ANyone with contrast preference you should reduce visual complexity.
<jcraig> dlibby from the issue: "We didn't get to this in the F2F last week, but I agree with the core of @cookiecrook's argument - I don't think there is strong evidence for the boolean form of prefers-contrast being used to reduce visual complexity, and would probably be difficult for authors to reason about (enhancement in service of respecting a user preference is much different from adjusting in response to forced changes to a page's appearance)."
<dael> TabAtkins: Concern with add later is by then benefit of hey this is a new feature user guidance is lessened. Would be nice to have consistent story to say most of the time use prefers-contrast in bool and you can listen to more or less or system pallet, but for overall design bool works great
<jcraig> ..."As anecdata, I also ran across this blog post that expresses some of the same sentiments:
<jcraig> https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/ "
<astearns> ack florian
<dael> TabAtkins: If we decide we don't want it's not more problematic then adding in the future. Worst case we say it never matches. Not great, but we've had it before and cna shove in an appendix
<dael> florian: I did feel strongly against removing while we hadn't reached understanding about the question b/c felt bad to users was inappropriate. We do understand the disagreement now. Still feel strongly, but less bad about being overruled.
<dael> astearns: Can we get a resolution to remove the value and unlink the features and if there's user data in the future we can revisit
<jcraig> q+
<tantek> regrets+
<dael> fremy: Removing the value, we also mean if people enable the high contrast but set at middle contrast they won't match the MQ. That makes the feature useless. On windows I would jsut use MQ for forced-colors. Or I would have to dup the code. I'm not sure if value is nes but it makes sense.
<dael> fremy: Even if you treat the contrast as peole from Apple said, you want to remove complexity. You want same behavior when using forced colors
<jcraig> @media (prefers-contrast) or (forced-colors)
<dael> emilio: Can't you just not use or?
<emilio> s/not//
<jcraig> q+ to mention these are different features
<dael> fremy: True, but thing is devs won't test special case. They will assume prefers-contrast works. nobody will catch this tiny use case. That's the key of the issue
<dael> astearns: From my PoV, your particular case where someone used forced-colors to select with no contrast, I would prefer it did not match rpefers-constrast b/c there is no constrast. I think it's an argument to delink
<dael> fremy: Then maybe name is misleading. We want to use feature to reduce complexity, maybe name is wrong. Seems it would be unfortunate
<astearns> ack jcraig
<Zakim> jcraig, you wanted to mention these are different features
<dael> jcraig: Was going to say same. This is core of disagreement. Half the people think there's an association between people using forced colors in the window where it doesn't match but they still want less complexity
<TabAtkins> Alternate proposal: we drop (prefers-contrast) entirely for right now while we study the problem more and see if there's better things to do in the visual complexity sphere
<jcraig> "In my opinion, if CSS needs a media feature for prefers-reduced-complexity or prefers-improved-legibility, the working group should consider those separately."
<dael> jcraig: I get it, but I don't agree it's a match. I also suggested similar to your suggested fremy ^
<dael> jcraig: The contrast features should be about constrast and forced-color should be about colors. I don't agree with a 100% corrilation
<myles> +1 to what james just said
<dael> fremy: What you said makes sense
<dael> astearns: TabAtkins suggestion in IRC I think we should consider separately
<dael> astearns: Prop: Removed the forced value
<jcraig> s/should be about constrast and forced-color should be about colors/should ONLY be about contrast and forced-colors should ONLY be about forcing colors
<jensimmons> I agree with what James just said — the 100% association between the two isn't best.
<jcraig> s/should be about constrast and forced-color should be about colors/should ONLY be about contrast and forced-colors should ONLY be about forcing colors/
<fantasai> jcraig, the reduction in complexity isn't because that's specifically requested. It's because in a reduced palette, you don't have the option to use intermediary colors and you *have to* make changes accordingly
<leaverou2> +1 to what TabAtkins suggested
<dael> TabAtkins: That was jcraig suggestion and I was [missed]. Just aminutes correction
<TabAtkins> s/TabAtkins suggestion/jcraig suggestion/
<dael> astearns: Will anyone object to removing it?
<dael> florian: Can we get a promise to collect data about the cases where it would be different?
<dael> fantasai: What data do you want?
<Morgan> q+
<dael> florian: Color schemes people use that would be neither high nor low and therefore would no longer match. So we can look and see if we made thigns better or worse
<dael> fantasai: Won't know unless you look at a page
<astearns> ack Morgan
<dael> TabAtkins: Since we have requirement that forced-color sheme opts into more or less, assuming there's a middle ground collecting data about it is would be valuble
<aja> planning on keeping (prefers-contrast: no-preference), i hope
<fantasai> of course
<dael> Morgan: Adding probes in FF which should detect browser and platform
<dael> astearns: Objections?
<dael> RESOLVED: Removed the forced value from prefers-contrast MQ
<florian> thanks Morgan
<jcraig> q+
<dael> astearns: TabAtkins proposal to drop prefers-constrast all together. Would get in way of collecting data
<dael> florian: Not necessarily. Collecting data about user settings, not sites
<dael> TabAtkins: Yeah, data isn't about if MQ is used, how categorization would work
<dael> astearns: I thought it would be useful to have to get set of people that have choosen a color scheme and have the MQ but missing out
<astearns> ack jcraig
<aja> q+
<dael> jcraig: Sounds like a windows argument. If we drop prefers-contrast can't impl apple contrast settings. They indecate a preference for more contrast. We have a beta impl for prefers-constrast:more in WK
<dael> TabAtkins: The prop is we drop temp while we think about problem space of constrast and visual complexity. We can bring right back when decide separate or don't need to think about visual complexity. It would be worse if we ship and then decide should be different.
<dael> jcraig: I don't think we've done this quickly. Has taken years to standardize prefers-constrast values. Just agreed less and more instead of high and low. Taken years b/c difference between Windows, and MacOS, and Android.
<aja> might want to consider a way to SET prefers-contrast in user stylesheet
<dael> jcraig: Reduced complexity has higher association to prefers-reduced-transparency. I don't know we want to mix streams, but if you're associating should be reduced-transparency. Would object to removing
<jcraig> s/Would object to removing/Would object to removing prefers-contrast/
<dael> TabAtkins: they're all reasonably linked, sure. Concerned we have large set of prefers options and authors need 6 MQs to target when there's a potential most people can be well served by broader MQs. Let the specific ones exist, but I don't want 10 prefers queries that subtilly interact in ways that are confusing.
<dael> TabAtkins: Worried if we don't guard against it. Has taken a while, but it's because people talk slowly. WE can move quickly if we want
<astearns> ack aja
<aja> might want to consider a way to SET prefers-contrast in user stylesheet
<dael> astearns: [reads IRC comment]
<dael> fantasai: Can't really set in user stylesheet. Can in user preferences. We're not going to introduce cycle between MQ and properties
<dael> astearns: And users know how to set browser preferences much more
<astearns> ack fantasai
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<dael> fantasai: When you have a reduced pallate which happens when you have increased or reduced constrast or forced colors you have to make changes. yOu don't have intermediary colors. You have to remove things that require drawing these colors.
<florian> q+
<dael> fantasai: Applies with forced-color or change in constrat. Argument for prefers-constrast triggering isn't that they want to reduce visual clutter, it's that you have less colors and need to adapt. You can't use a subtile drop shadow. You need a solid border or nothing
<dael> fantasai: If someone wants a reduced visual complexity category, that's broder and separate.
<tantek> s/pallate/palette
<fremy> Proposal: (color-reduction: forced | optional) and that is `optional` when prefers-contrast is set to more or less
<dael> fantasai: Regards to prefers-constrast, if we want to try without forced value at first we could. But I agree with TabAtkins it means we can't teach it when forced-colors is on and you can loop it into same MQ. Authors won't get benefit of trigger on both. Forward compat issue won't be that huge b/c most people will fall under prefers-constrast.
<dael> fantasai: The people that do fall in will have a problem or won't and we can handle it later. But you don't get author benefit to teaching the grouping
<dael> astearns: I'd like to close the discssion for this meeting. TabAtkins if you want to continue the idea can you open a new issue on GH?
<dael> TabAtkins: Sure

[frivoal]

Fixed through a2f6a35 (and d7b7f4b for typos), so closing.

@cookiecrook, I'd appreciate if you could confirm being satisfied with this edit.

[michael-n-cooper]

Note APA is just waiting for signoff from @cookiecrook before closing in our tracker.

[cookiecrook]

@frivoal Just seeing this, but I don't see a unified PR linked. PR review assignments are usually the way I would spot these.

Is a2f6a35 the only substantive diff?

[cookiecrook]

Comments in each individual diff: a2f6a35 and d7b7f4b

[cookiecrook]

@frivoal?

[frivoal]

@cookiecrook we had a resolution, so I went ahead without a pull request. a2f6a35 is indeed the only substantive commit. I'll respond to your two comments.