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

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 19 Oct 2020 23:05:09 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-712488803-1603148707-sysbot+gh@w3.org>
The CSS Working Group just discussed `forced-colors and prefers-contrast`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: forced-colors and prefers-contrast<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/5433<br>
&lt;TabAtkins> Morgan: We've been implementing prefers-contrast and forced-colors in Moz for a while<br>
&lt;TabAtkins> Morgan: Hoping to unpref adn ship soon<br>
&lt;TabAtkins> Morgan: Hesitant until this issue is resolved<br>
&lt;TabAtkins> Morgan: Don't have an opinion on the stances taken here<br>
&lt;TabAtkins> florian: Attempted summary of where we are<br>
&lt;TabAtkins> florian: We have two related things here<br>
&lt;TabAtkins> florian: prefers-contrast MQ, which is about letting the author know whether the user prefers higher or lower contrast on the page<br>
&lt;TabAtkins> florian: So author can change colors, add/remove borders, etc<br>
&lt;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<br>
&lt;TabAtkins> florian: But general rule is that, regardless, removing visual clutter is often a good thing<br>
&lt;TabAtkins> florian: A related thing was added to css, forced-colors mode<br>
&lt;TabAtkins> florian: Not a user pref, it changes colors for the author automatically<br>
&lt;TabAtkins> florian: When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such<br>
&lt;TabAtkins> florian: So we ahve a (prefers-contrast: forced-colors) value to indicate this<br>
&lt;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<br>
&lt;cbiesinger> q-<br>
&lt;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.<br>
&lt;TabAtkins> florian: So right now we ahve both the (forced-colors) MQ as well, for legacy reasons<br>
&lt;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<br>
&lt;TabAtkins> jcraig: We also have prefers-reduced-transparency; I mention because we use it more to indicate reducing clutter<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> jcraig: Also reached out to aboxhall<br>
&lt;TabAtkins> jcraig: She shared this:<br>
&lt;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)<br>
&lt;TabAtkins> jcraig: So she doesn't have a strong opinion, but tends to agree that (forced-colors) is better<br>
&lt;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.<br>
&lt;Morgan> q+<br>
&lt;TabAtkins> jcraig: But I have opposite opinion from Florian for the author experience<br>
&lt;TabAtkins> jcraig: I think the convenience of being able to just write (prefers-contrast) doesn't outweight the clarity gained from writing (forced-colors)<br>
&lt;astearns> ack fantasai<br>
&lt;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.<br>
&lt;TabAtkins> fantasai: Doesn't necessarily force a high contrast, but it does force a *fixed* contrast<br>
&lt;TabAtkins> fantasai: So not unreasonable for it to fall under the (prefers-contrast) MQ<br>
&lt;TabAtkins> fantasai: I have a side question on (prefers-reduced-transparency)<br>
&lt;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?<br>
&lt;TabAtkins> fantasai: bc if it's actually about visual clutter, that's not stated by the name<br>
&lt;jcraig> q?<br>
&lt;TabAtkins> fantasai: Also, prefers-contrast *will* be true in the majority of cases where Windows High Contrast will be on<br>
&lt;jcraig> q+ to respond to Elika's q re background pattern versus transparency<br>
&lt;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.<br>
&lt;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<br>
&lt;TabAtkins> fantasai: And in general, both (prefers-contrast) and (prefers-color-scheme) do reflect the choices made by Forced Colors mode<br>
&lt;TabAtkins> Morgan: Turns out I have an opinion<br>
&lt;astearns> ack Morgan<br>
&lt;TabAtkins> Morgan: I added some info to the issue just a bit ago<br>
&lt;TabAtkins> Morgan: Firefox has a high-contrast mode built in, that's not OS-specific<br>
&lt;TabAtkins> Morgan: It triggers True when Windows High Contrast, or the browser-local HCM, is on<br>
&lt;TabAtkins> Morgan: So far we've found people using it for both high and low contrast reasons<br>
&lt;TabAtkins> Morgan: But also for things like photosensitivity<br>
&lt;jcraig> What does Firefox HCM "regardless of browser" mean?<br>
&lt;TabAtkins> Morgan: Those don't necessarily fall into high or low contrast bins<br>
&lt;fantasai> jcraig, suspect she meant "regardless of OS"<br>
&lt;TabAtkins> Morgan: So I agree with fantasai's concerns that they might not have their prefs reflected by authors<br>
&lt;TabAtkins> Morgan: Also, we find that devs often dont' have the ability to test with high contrast themes.<br>
&lt;astearns> ack jcraig<br>
&lt;Zakim> jcraig, you wanted to respond to Elika's q re background pattern versus transparency<br>
&lt;TabAtkins> Morgan: So if our local HCM doesn't trigger this query, they dont' have a way to test<br>
&lt;florian> q+<br>
&lt;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<br>
&lt;Morgan> jcraig, sorry yeah regardless of OS :)<br>
&lt;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<br>
&lt;TabAtkins> jcraig: There's often overlap, but the clarity from breaking them into separate settings is worth preserving, I think<br>
&lt;TabAtkins> jcraig: With the patterned background - in iOS we have a lot of transparency, but not a lot of loud backgrounds<br>
&lt;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<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to re-explain her point<br>
&lt;TabAtkins> fantasai: So james had one point about "this is not a preference, so why is it in a MQ about preference)<br>
&lt;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)<br>
&lt;TabAtkins> fantasai: And an author will thus usually see those turned on when they test in forced colors mode<br>
&lt;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<br>
&lt;TabAtkins> fantasai: So it's easy to leave out a class of users by accident<br>
&lt;TabAtkins> q+<br>
&lt;jcraig> I don't agree that "most prefers-contrast users" will have forced colors on... iOS "increase contrast" doesn't  force colors.<br>
&lt;TabAtkins> fantasai: So I think that's another reason why having forced colors *explicitly* fall under prefers-contrast helps out<br>
&lt;TabAtkins> jcraig: I think elika said taht most prefers-contrast people will ahve forced colors...<br>
&lt;Morgan> q+<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> florian: So adding the 'forced' keyword in makes sure they trigger at all times<br>
&lt;TabAtkins> jcraig: So as an author, I'm not sure whether to check for (prefers-high-contrast: high) or (prefers-high-contrast: forced)<br>
&lt;TabAtkins> jcraig: And then it's just weird still to have another setting to the exact same thing<br>
&lt;jcraig> q?<br>
&lt;astearns> ack florian<br>
&lt;TabAtkins> florian: Both in terms of transparency and patterns and this argument, I think there's a general tension between a11y features here<br>
&lt;TabAtkins> florian: On the user side, general desire to express complex needs, because users have many needs and preferences<br>
&lt;jcraig> s/(prefers-high-contrast: high) or (prefers-high-contrast: forced)/(prefers-contrast: more) or (prefers-contrast: forced)/<br>
&lt;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.<br>
&lt;TabAtkins> florian: So trade-off of perfect responses (that ar eless likely) vs okay responses (that are more common)<br>
&lt;TabAtkins> florian: I think the current design is about right for this reason, but we can disagree on the limit<br>
&lt;astearns> ack TabAtkins<br>
&lt;astearns> ack Morgan<br>
&lt;fantasai> TabAtkins: Florian made the exact point I  was going to<br>
&lt;TabAtkins> Morgan: Last time this discussed, no definition of "more" or "less" ratios<br>
&lt;jcraig> more than default, less than default<br>
&lt;TabAtkins> Morgan: Saw this as a sliding scale of more and less as higher and lower ratios defined by user agent<br>
&lt;fantasai> s/ar eless/are less/<br>
&lt;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<br>
&lt;TabAtkins> jcraig: Responding to florian's, I agree we ahve a decision to make about granularity<br>
&lt;TabAtkins> jcraig: My opinion is that it should be towards granular side.<br>
&lt;TabAtkins> q+<br>
&lt;TabAtkins> florian: The people who ask for it know what they want, but if too granular, they just wont' get what they want often<br>
&lt;TabAtkins> jcraig: How i understand windows hcm right now, it'll match both 'forced' and either 'more' or 'less' if appropriate<br>
&lt;TabAtkins> jcraig: I think it's quite reasoanble to match 'more' if HCM is on<br>
&lt;TabAtkins> jcraig: is on with a high-contrast scheme<br>
&lt;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<br>
&lt;TabAtkins> jcraig: You're talking about a boolean match for contrast that is high, or low, or in the middle.<br>
&lt;emilio> q+<br>
&lt;emilio> ack TabAtkins<br>
&lt;fantasai> TabAtkins: wrt granularity choice, directly related to what you were saying<br>
&lt;fantasai> TabAtkins: our current proposal has that granularity<br>
&lt;fantasai> TabAtkins: You can target high contrast, low contrast, and forced contrast specifically and independently<br>
&lt;fantasai> TabAtkins: But something you are likely to want to do for all of them is to simplify the page<br>
&lt;fantasai> TabAtkins: If this is indeed the case, then we should have something that catches everything simply<br>
&lt;fantasai> TabAtkins: And certainly should be something that catches the more common and less common cases the same way<br>
&lt;fantasai> TabAtkins: I would rather authors have an general switch, rather than needing to list each thing independently<br>
&lt;fantasai> TabAtkins: If your argument is that there is no reasonable thing to do that applies to all these contrast modes<br>
&lt;fantasai> TabAtkins: then we don't need it<br>
&lt;jcraig> Loss audio in the middle of Tab's comment<br>
&lt;fantasai> TabAtkins: but if there is, then we need a good syntax for doing so<br>
&lt;fantasai> jcraig: if ... about syntax, then happy to take it to a vote<br>
&lt;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<br>
&lt;fantasai> astearns: Any input from ppl not yet part of the conversation?<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> Going for a more general "prefers-simple" MQ doesn't sound unreasonable...<br>
&lt;fantasai> emilio: Conversation was we cannot remove 'forced-colors: active'<br>
&lt;TabAtkins> emilio: Convo started with "we can't remove (forced-colors)<br>
&lt;fantasai> emilio: I don't see 'prefers-contrast: forced' adding a lot of value<br>
&lt;TabAtkins> emilio: I dont' see (prefers-contrast: forced) having a lot of value here<br>
&lt;TabAtkins> emilio: prefers-contrast and forced-colors are technically unrealted and they should be separate MQs<br>
&lt;TabAtkins> florian: On the one hand, I don't think this is a breaking point; I'd be willing to yield if necessary.<br>
&lt;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<br>
&lt;TabAtkins> florian: I don't think we're wrong that the syntax is convenient, but are we wrong about the use-case?<br>
&lt;TabAtkins> astearns: Is the user-case enabled by (forced-colors)?<br>
&lt;TabAtkins> florian: No, it's not about responding to forced colors specifically.<br>
&lt;jcraig> q+<br>
&lt;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.<br>
&lt;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<br>
&lt;jcraig> (prefers-contrast) versus (prefers-contrast or forced-colors)<br>
&lt;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?<br>
&lt;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<br>
&lt;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.<br>
&lt;fremy> FWIW I agree with @fantasai's latest comment; authors will not expect the block to turn off<br>
&lt;emilio> q+<br>
&lt;TabAtkins> fantasai: So having pages fall into codepaths that aren't tested is a great way to have a broken page<br>
&lt;astearns> ack jcraig<br>
&lt;TabAtkins> jcraig: I see the point, and the mild syntax convenience<br>
&lt;astearns> zakim, close queue<br>
&lt;Zakim> ok, astearns, the speaker queue is closed<br>
&lt;TabAtkins> jcraig: Potentially could match something that might provide a convenience in the interface to an author that wants to reduce complexity.<br>
&lt;TabAtkins> jcraig: If we assume that authors will know that and respond to it.<br>
&lt;TabAtkins> jcraig: But I think the risk is that authors will conflate different things<br>
&lt;TabAtkins> jcraig: Recent years, authors conflate small viewport widths to mean it's on mobile<br>
&lt;TabAtkins> jcraig: Or check the user agent and see iOS and assume it's a phone and not an iPad<br>
&lt;TabAtkins> jcraig: Apple had to do a lot of work to make sure iPads get desktop sites, for example<br>
&lt;fantasai> The reason authors are conflating those things is because they had no other way to detect the things they were interested in<br>
&lt;TabAtkins> jcraig: So even tho these are somewhat conflated, risk of conflating them<br>
&lt;fantasai> e.g. knowing you're on a touchpad is important consideration in design, but there was no ability to query that directly<br>
&lt;fantasai> so authors made a lot of assumptions<br>
&lt;TabAtkins> emilio: I get fantasai's point, but we can solve it without ahving to expose the 'forced' value<br>
&lt;fantasai> We don't have that problem here because we already have the individual options available to query<br>
&lt;jcraig> s/somewhat conflated/somewhat related/<br>
&lt;TabAtkins> emilio: You can just say if you're forcing colors you *must* match high or low<br>
&lt;TabAtkins> emilio: When forcing colors you most can't override system colors<br>
&lt;TabAtkins> emilio: I think having two MQs mean the same thing isn't amazing either<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 October 2020 23:05:12 UTC

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