- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Feb 2021 17:41:10 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced`<br> <dael> Github: https://github.com/w3c/csswg-drafts/issues/5433<br> <dael> alisonmaher: For a bit of context chromium has impl of prefers-contrast behind flag. Pretty sure FF does as well<br> <alisonmaher> In favor of 'prefers-contrast: forced'- https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954048<br> <alisonmaher> Against 'prefers-contrast: forced'- https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954108<br> <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 ^<br> <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<br> <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<br> <jcraig> q+<br> <florian> q+<br> <dael> alisonmaher: I tend toward remove b/c simplifies and matches more to prefers color scheme approach which jsut matches to dark or light.<br> <dael> alisonmaher: Perhaps a middle ground where we remove but still capture the users, but not sure what that would look like.<br> <jcraig> q?<br> <dael> jcraig: Thanks alisonmaher for the summary<br> <astearns> ack jcraig<br> <TabAtkins> q+<br> <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<br> <astearns> ack florian<br> <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<br> <dael> florian: Thanks to alisonmaher and jcraig.<br> <TabAtkins> q-<br> <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<br> <TabAtkins> florian is saying exactly what i was going to<br> <dael> florian: b/c of that I thinkw e fall into needing reduced complexity<br> <fremy> I agree with florian<br> <jcraig> dlibby's comment: https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-780191074<br> <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<br> <dael> astearns: Any other comments?<br> <dael> [silence]<br> <jcraig> q?<br> <dael> astearns: Proposal is remove the forced value for prefers-contrast<br> <jcraig> q+<br> <fantasai> s/prefers-contrast/prefers-contrast and de-link the two media queries/<br> <Rossen_> q?<br> <dael> florian: I think we've made progress about where there's an issue. Not sure we agree on the solution<br> <Rossen_> ack JaseW<br> <astearns> ack jcraig<br> <Rossen_> ack jcraig<br> <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<br> <dael> jcraig: We don't have direct plans to do that, but I'd like to see it.<br> <Morgan> q+<br> <TabAtkins> q+<br> <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<br> <dael> Rossen_: Quick point, chrome is almost done so won't be only one I presume<br> <dael> jcraig: I'm talking platform, not browser<br> <dael> Rossen_: My bad. I thought you were talking about browser<br> <astearns> ack Morgan<br> <astearns> ack TabAtkins<br> <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.<br> <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<br> <jcraig> q+<br> <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<br> <dael> TabAtkins: I don't think that's consistent with idea of forced-colors as we have<br> <dael> fantasai: yeah, forced-contrast mode<br> <astearns> ack jcraig<br> <fantasai> s/way up/way up, but that would be a different feature/<br> <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<br> <florian> q?<br> <florian> q+<br> <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<br> <astearns> ack florian<br> <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<br> <dael> TabAtkins: In IRC both fantasai and I said we think the same as you<br> <dael> fremy: And I did<br> <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<br> <dlibby> q+<br> <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<br> <dael> Rossen_: Do you have data?<br> <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<br> <jcraig> q+<br> <dael> Rossen_: What about data of use removing it and looking for compat risk?<br> <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.<br> <astearns> ack dlibby<br> <astearns> ack jcraig<br> <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<br> <dael> jcraig: I would agree if there's evidence. but florian said it was based on logic, sounded like speculative logic.<br> <dael> jcraig: Quoting dlibby from the issue, florian said MS would be one to know. dliby says [reads]<br> <dael> jcraig: It's about author and user benefit<br> <TabAtkins> q+<br> <florian> q+<br> <astearns> ack TabAtkins<br> <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 ?<br> <dael> dlibby: Yes<br> <fantasai> agree with jcraig's last assessment<br> <fantasai> (and also the point TabAtkins is making now)<br> <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.<br> <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)."<br> <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<br> <jcraig> ..."As anecdata, I also ran across this blog post that expresses some of the same sentiments:<br> <jcraig> https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/ "<br> <astearns> ack florian<br> <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<br> <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.<br> <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<br> <jcraig> q+<br> <tantek> regrets+<br> <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.<br> <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<br> <jcraig> @media (prefers-contrast) or (forced-colors)<br> <dael> emilio: Can't you just not use or?<br> <emilio> s/not//<br> <jcraig> q+ to mention these are different features<br> <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<br> <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<br> <dael> fremy: Then maybe name is misleading. We want to use feature to reduce complexity, maybe name is wrong. Seems it would be unfortunate<br> <astearns> ack jcraig<br> <Zakim> jcraig, you wanted to mention these are different features<br> <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<br> <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<br> <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."<br> <dael> jcraig: I get it, but I don't agree it's a match. I also suggested similar to your suggested fremy ^<br> <dael> jcraig: The contrast features should be about constrast and forced-color should be about colors. I don't agree with a 100% corrilation<br> <myles> +1 to what james just said<br> <dael> fremy: What you said makes sense<br> <dael> astearns: TabAtkins suggestion in IRC I think we should consider separately<br> <dael> astearns: Prop: Removed the forced value<br> <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<br> <jensimmons> I agree with what James just said — the 100% association between the two isn't best.<br> <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/<br> <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<br> <leaverou2> +1 to what TabAtkins suggested<br> <dael> TabAtkins: That was jcraig suggestion and I was [missed]. Just aminutes correction<br> <TabAtkins> s/TabAtkins suggestion/jcraig suggestion/<br> <dael> astearns: Will anyone object to removing it?<br> <dael> florian: Can we get a promise to collect data about the cases where it would be different?<br> <dael> fantasai: What data do you want?<br> <Morgan> q+<br> <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<br> <dael> fantasai: Won't know unless you look at a page<br> <astearns> ack Morgan<br> <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<br> <aja> planning on keeping (prefers-contrast: no-preference), i hope<br> <fantasai> of course<br> <dael> Morgan: Adding probes in FF which should detect browser and platform<br> <dael> astearns: Objections?<br> <dael> RESOLVED: Removed the forced value from prefers-contrast MQ<br> <florian> thanks Morgan<br> <jcraig> q+<br> <dael> astearns: TabAtkins proposal to drop prefers-constrast all together. Would get in way of collecting data<br> <dael> florian: Not necessarily. Collecting data about user settings, not sites<br> <dael> TabAtkins: Yeah, data isn't about if MQ is used, how categorization would work<br> <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<br> <astearns> ack jcraig<br> <aja> q+<br> <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<br> <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.<br> <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.<br> <aja> might want to consider a way to SET prefers-contrast in user stylesheet<br> <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<br> <jcraig> s/Would object to removing/Would object to removing prefers-contrast/<br> <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.<br> <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<br> <astearns> ack aja<br> <aja> might want to consider a way to SET prefers-contrast in user stylesheet<br> <dael> astearns: [reads IRC comment]<br> <dael> fantasai: Can't really set in user stylesheet. Can in user preferences. We're not going to introduce cycle between MQ and properties<br> <dael> astearns: And users know how to set browser preferences much more<br> <astearns> ack fantasai<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <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.<br> <florian> q+<br> <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<br> <dael> fantasai: If someone wants a reduced visual complexity category, that's broder and separate.<br> <tantek> s/pallate/palette<br> <fremy> Proposal: (color-reduction: forced | optional) and that is `optional` when prefers-contrast is set to more or less<br> <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.<br> <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<br> <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?<br> <dael> TabAtkins: Sure<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-785251576 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 February 2021 17:41:14 UTC