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