- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Aug 2020 16:59:31 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS``, and agreed to the following: * `RESOLVED: Change high and low in the MQ to more and less` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2943<br> <dael> [we can't hear jcraig]<br> <dael> jcraig: Thank you for delaying this until I was available<br> <dael> jcraig: Is everyone generally familiar and just wants my PoV or should I introduce issue?<br> <dael> astearns: Discussed recently so pretty up to speed<br> <dael> jcraig: Posted a few comments earlier in the week.<br> <dael> jcraig: Main issue I obj to is that the term high is typically interpreted as at the extreme end. I'm sure you've seen screenshots but what we have with iOS and macOS a11y it's up to min or a little past but far from high.<br> <dael> jcraig: Difference between MS high contrast and our increased contrast is very different and don't want to conflait.<br> <dael> jcraig: Multi solutions. florian prop high and max. I don't like high and max, but we could do increase and max to be more explicit.<br> <dael> jcraig: Second issue is we ideally shouldn't have authors write long MQ to match both. Ideally like to see it match the bool but another proposal was allow it to match the greater than query. @media prefer-contrast greater than increase<br> <dael> jcraig: florian had a prop that was close that said if there's a client that matches high it also matches increase. A little confused by that.<br> <tantek> s/patient policy/patent policy<br> <dael> jcraig: I feel like risk is some authors will use the max/high value and leave out the iOS<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask whether the problem is the name or that there is only one level<br> <dael> jcraig: Those are two main issues. Happy to answer questions or add detail<br> <dael> fantasai: There's a number of sub issues within this. Some depend on others. Like to focus on first question is the problem about naming or do we need 2 levels to express the somewhat high and very high? Need to figure that our first.<br> <tantek> this does sound perhaps similar to font-weights<br> <tantek> s/sound/sounds<br> <dael> jcraig: I think it's both. Right now iOS and macOS don't offer true high contrast. Underlying tech would allow a true high contrast in the future. If by expecting apple increased contrast matches high it limits us from shipping higher<br> <dael> fantasai: So we need 2 levels<br> <tantek> i.e. the same arguments for why we don't just have "normal | bold" for font-weight could be applied here<br> <dael> jcraig: Yes b/c [missed]. Most authors won't need but some will want<br> <dael> fantasai: If we need to express 2 levels in MQ...I want to go piece by piece...does anyone argue against 2 levels?<br> <florian> [still cannot rejoin webex: would like to hear why we need both, given that no OS ships non-forced max contrast]<br> <tantek> florian, see my analogy to font-weight<br> <jcraig> q+<br> <dael> TabAtkins: Yes, the fact that no OS exposes 2 levels and expresses at best slightly different levels makes me loathe to do this. If we don't do multi-match I'm really unhappy. Even then super high contrast on windows is forced. If OS has absolutely max you have to be careful and that maps to forced.<br> <Rossen_> +1 to TabAtkins<br> <Rossen_> q+<br> <tantek> back when we standardized font-weights 100...900, no OS exposed more than 2 levels of font-weights, and now most do<br> <dael> AmeliaBR: I think that's important distinction between windows and mac mode. It's not how much but if it's preference or forced override to extreme. Do we realistically expect any authors/users to have prefers extreme contrast w/o forced-color mode?<br> <dael> AmeliaBR: If that's not a combo we expect to see where authors have setting for max-contrast but don't force it then I'm not sure why we have to have that in MQ<br> <jcraig> ack me<br> <tantek> we should model the levels of contrast *across* the different features of different OS, not just per-OS<br> <tantek> and then give authors the ability to reason about it, like we did with font-weights (perhaps not quite as granular)<br> <astearns> ack jcraig<br> <tantek> q?<br> <dael> jcraig: I'm glad TabAtkins and AmeliaBR brought up that's it's only possible through forced. That's only way for user to change. Same with low-contrast, we only know it in forced colors. We have forced-colors media features. If we want to rely on forced colors as other way to differentiate it could drop to one increased value of prefers-contrast which matches windows and mac. If we do that we have vocubulary which needs to match. higher is in prose whic[CUT]<br> <astearns> ack Rossen_<br> <dael> jcraig: Even if it's higher it leaves it open for future poss<br> <dael> Rossen_: Couple of things making me uneasy. Mostly repeating. Clear distinction between forced-color and prefers-contrast. One is opt in one is opt-out. One authors proactive, the other could be reactive. in forced-colors it's opt-out for authors. Authors need to be proactive to opt out and supply style.<br> <dael> Rossen_: In macOS increased contrast it's more opt-in preferential styling<br> <dael> Rossen_: jcraig question as to how and why forced/high got into MQ. Couple of efforts to harmonize MQ starting to alsmot dup each other. They have to do with contrast, color, and there is clear user choice supplied through OS setting<br> <dael> Rossen_: Motivation behind hamonizing is good<br> <dael> Rossen_: If we contrast with color scheme where harmonizing dark, light, etc is easier<br> <tantek> I see jcraig's numerical range proposal too<br> <jcraig> not asking why "forced-colors" is in... I'm asking why we have both "forced-colors: active" and "prefers-contrast: forced" which are duplicates...<br> <dael> Rossen_: Harmonizing of dark and light in presense of forced-color is easier to achieve b/c we can detect if primary bg and fg are dark or light and match appropriate colors<br> <dael> Rossen_: In case of contrast we had discussion where prefers-contrast:forced maps well into this picture similar to how we map prefers color scheme.<br> <florian> q+ to comment on forced<br> <jcraig> q+<br> <dael> Rossen_: Forced we should revisit and figure out if it makes sense<br> <aja> q? from non-member<br> <aja> q+ from non-member<br> <jcraig> q+ to ask why "forced" was added to prefers-contrast instead of prefers-color-scheme<br> <dael> TabAtkins: As florian said in thread it is try prefers-contrast:forced and the MQ duplicate it's for histoic reasons. prefers-contrast:forced is the preferred way to do it, but shipped later. Knowing that the user prefers the forced colors is useful to do that. We wouldn't have produced forced-colors today<br> <dael> fantasai: And you can match high and forced at same time<br> <astearns> ack florian<br> <Zakim> florian, you wanted to comment on forced<br> <jcraig> q+ aja<br> <astearns> ack from<br> <jcraig> q- from<br> <jcraig> q- non<br> <aja> a mid value, as distinguished from no-preference would be good<br> <jcraig> florian citation of that?<br> <fantasai> aja, gray on gray is not readable ^_^<br> <dael> florian: Key intent to have it in same MQ is thinking of how people react. If it's high|low|forced you'll do a lot different but with all you'll do some simplification of the page. Not a given but a slight simplification is something you'd want to do for any contrast preference.<br> <aja> oops...sry<br> <dael> florian: This is the discussion leading to the resolution of that topic<br> <chris> q+<br> <dael> jcraig: I've heard that mentioned but the abstraction...certainly the detail is reduced in high but you mentioned low and I'm not aware of user need reducing complexity for low. That's where I was looking for information source.<br> <astearns> ack jcraig<br> <Zakim> jcraig, you wanted to ask why "forced" was added to prefers-contrast instead of prefers-color-scheme<br> <dael> jcraig: First, TabAtkins answered my previous question. not convinced we need it in both places. Not convinced prefers-contrast is ideal. Seems better match for prefers-color-scheme. Having some way for author to learn if this is higher or dark|light of forced-colors is useful, but I don't see change there.<br> <dael> jcraig: Esp b/c forced-colors doesn't have direct relationship to contrast. User can set it to whatever. Low, high, no difference. Not sure why it's in here. Seem to overcomplicate it.<br> <dael> florian: If there is a preference for dark or light it doesn't imply desire for visual simplification. That's why doesn't belong<br> <dael> jcraig: Not convinced forced-color mode provides desire for simple. If you have high, sure, but doesn't only have high<br> <dael> TabAtkins: forced-colors you only have 8 colors so you can't have high visual complexity. high contrast is complexity reducer b/c then you have less space to play in. low you have less space to play so less ability to do visual decoration<br> <dael> astearns: Not sure visual complexity is useful thing for this discussion<br> <dael> jcraig: Can set aside<br> <dael> fantasai: Factor into why we have these features all in one instead of low and high as sep MQ and forced-color different. We wanted this to be all one thing so you can select as use case to reduce visual complexity.<br> <jcraig> q+ to mention Alice's request<br> <dael> fantasai: That plays into overall feature design. Doesn't help with if we have 2 levels or only 1. THen we can decide what to name. Then if they're all in one property<br> <dael> Rossen_: One addition to what fantasai said. reason why we chose forced-color and moved away from high contrast is that there's 2 aims of this which windows has had. One is guar user preferred contrast and reduce cognitive load by reducing everything to small set of colors and drop visual feature which can overload<br> <dael> Rossen_: This is about simplification and reduction in visual complexity<br> <dael> [can't hear aja]<br> <astearns> ack chris<br> <dael> chris: Did I hear something say they didn't see a need for reduced contrast?<br> <aja> some authors would want a AAA / SAPC 100 by default, but want to honor a mid (AA / SAPC 85) or low (SAPC 70) preference...possibly scripted based on a radio, or from browser pref, and not necessarily from OS<br> <dael> jcraig: I said I don't believe any impl with a default value to allow low contrast other than through forced colors. Impl is forced-colors is enough and low contrast doesn't need to go into original prop.<br> <dael> chris: I do need low contrast on occasion so there is user need. If you weren't arguing that I don't need to rebut.<br> <florian> q?<br> <dael> jcraig: There's definitely a need for that<br> <astearns> ack jcraig<br> <Zakim> jcraig, you wanted to mention Alice's request<br> <aja> there's WCAG language for low contrast being preferred by dyslexics<br> <dael> jcraig: fantasai mentioned use cases. Alice's main reuqest was she hasn't seen use casesmentioned in spec. Would be nice to have list of use cases and what we're trying to solve. Where we started is what are system setting on platforms and how do we put it in these media features<br> <tantek> +1 to explicitly listing the use-cases, *and* linking to WCAG for details<br> <dael> jcraig: She's asking for what are use cases we're solving. Low vision is one that's difficult to solve b/c there's a lot of levels to it. A lot of variants. If we can put together a few or a list of problems, that's what she requested in discussion yesterday<br> <florian> q+<br> <dael> astearns: That's it for the queue. I'm assuming aja was on to mention low contrast is user need based on IRC chat<br> <astearns> ack florian<br> <AmeliaBR> q+<br> <dael> florian: I could imagine an OS wanting to ship a high contrast that's not forced. I can imagin low contrast not forced. We should go with design that's amenable to having both values. If we have them are they best combined or best sep.<br> <aja> yes....and a specified mid value vs no-preference<br> <jcraig> Florian's comment: https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076<br> <dael> florian: I think design I made in the spec, Syntax 1 is current spec and can evolve into 3b. With current we can now or later add keyword for non-forced very high contrast<br> <aja> mid in addition to no-preference, actually<br> <dael> florian: Current syntax and 3b are extension of same. BReaking apart isn't. Breaking low contrast out separate is a different design and not an extension<br> <dael> florian: I feel we should take current or 3b b/c compat and let you take all variants and let you not distinguish if you don't need to. It's more verbose to do simple things<br> <dael> florian: Syntax 4 is break everything apart and have low and high as separate. It can have multiple levels. Separate MQ for each level in high and low. Different design than current<br> <TabAtkins> q+<br> <dael> florian: Syntax 3b is compat with current. Same name or not can use that syntax and add a keyword for higher.<br> <dael> florian: I prefer 3b if we're having multiple levels. It's approx same number of characters and by combining we make it possible to target very high and increased and forced and low together as a non-verbose query if you want visual simplifications<br> <aja> TabAtkins, examples I've seen have just had to assume mid=no-preference. can find url for a switcher (bt google, IIRC)<br> <dael> jcraig: Coming around to that. If you leave high and max out it allows us to feature expand to a non-forced max contrast<br> <jcraig> @media (prefers-contrast > increase)<br> <dael> jcraig: Other with that pattern is > < syntax<br> <jcraig> @media (prefers-contrast: max)<br> <dael> florian: I think that's weird b/c allow a query that matches on increased and low but not extremely high. seems like...why?<br> <jcraig> @media (prefers-contrast < max)<br> <dael> jcraig: Why not like ^ or ^<br> <dael> florian: What's the 2nd? Prefer contrast less than max?<br> <dael> jcraig: SHould have been ><br> <dael> florian: But you can write what you did and I"m not sure what it means. If they're not all comparable and no preference isn't > or < then how can you sort?<br> <dael> jcraig: No preference is 0, n+ and n- values<br> <astearns> ack AmeliaBR<br> <dael> AmeliaBR: I think we have an important discussion about are we trying to represent options that are there or trying to create an ideal schema of user options we hope will one day be there?<br> <dael> AmeliaBR: Not sure that's ever going to happen when talking OS level user options<br> <jcraig> current syntax does not solve either of those ABR<br> <florian> q+<br> <dael> AmeliaBR: There is definitely an argument for creating a schema open to options that don't exist. Like please no extreme contrast. Use cas for prefers contrast < max I have a migraine. We don't have a browser or OS way to express that<br> <dael> AmeliaBR: OS options for that use case are reduce screen brightness and turn on night mode<br> <dael> AmeliaBR: That doesn't mean we shouldn't be open to someone adding a browser extension but it makes it a lot harder to get right when we don't have examples a spit balling what we think users want and might make sense.<br> <dael> AmeliaBR: Difficult to get it right. As aja said in comments why isn't there prefers medium contrast to express I don't like low contrast or higher contrast. We can't express that use case.<br> <dael> AmeliaBR: I don't have a clear solution. I think better to focus on a simple schema that represents options that exist and can be expanded as new options come in<br> <tantek> a medium preference would be kind of nice frankly, if web authors actually respected it, to provide for a more consistent contrast across reading different pages instead of having the contrast jump high / low all of over the place based on designer artistic preferences<br> <dael> AmeliaBR: How? One way is try and keep independent concept sindepended. Maybe keep preference around high contrast; hate, like, don't care- separate from low contrast. Preference on one side doesn't impl preference on other<br> <dael> AmeliaBR: Keep simple by keeping distinct concepts separate<br> <jcraig> q+ to answer ABR's historical background of "increase contrast" research from the Apple side... I can't speak to the Windows research.<br> <dael> AmeliaBR: Avoid assumption things always go together<br> <dael> TabAtkins: Pulling back to original topic of issue where jcraig found 'high' misleading can we rename 'high' and instead use more and less. Easier than decrease and increase. Would that resolve the issue?<br> <dael> AmeliaBR: We can agree but if we might take the whole thing out is it right time to bikeshed?<br> <jcraig> so "more" would match both the iOS/Mac style, and Windows?<br> <dael> TabAtkins: We didn't start with disagreement about purpose? We're talking about and thinking again but we've discussed before. If nothing ever happens on ripping it all out we can fix the original problem with the name<br> <astearns> q?<br> <astearns> ack tantek<br> <astearns> ack TabAtkins<br> <dael> florian: To answer jcraig irc more would match windows and macOS. If we add extremely high it would match...That's the b of 3b is where we make it like color-gamut. If preference is for extremely high on query you match extremely and somewhat high. You want at least high<br> <dael> jcraig: I like more/less better. I also like b/c leaves open max value or to adjust it to linear steps. Solves original question<br> <florian> q-<br> <dael> astearns: If people on queue are okay I prop we resolve change the current value from high to more<br> <dael> florian: And low to less<br> <florian> wfm<br> <dael> astearns: More discussion on changing high and low to more and less?<br> <dael> AmeliaBR: Anyone shipping?<br> <dael> jcraig: [missed] might be shipping<br> <dael> jcraig: MS was shipping prefixed values<br> <dael> AmeliaBR: Rossen_ have you shipped the prefers-contrast: high|low syntax?<br> <dael> Rossen_: Not more than Google chrome would have<br> <dael> florian: We're proposing rename<br> <dael> Rossen_: Don't believe will be issue. DOn't know if Alison is on. Do you recall?<br> <dael> alisonmaher: I didn't do anything for prefers-contrast. Nothing additional to Chromium<br> <aja> AmeliaBR, FF is "shipping" only on nightly....pref'ed on, IIRC<br> <dael> Rossen_: The change will be as fine for as as anyone else<br> <dael> astearns: Prop: Change high and low in the MQ to more and less<br> <dael> astearns: Obj?<br> <dael> RESOLVED: Change high and low in the MQ to more and less<br> <astearns> q?<br> <dael> AmeliaBR: Other part of issue was change how binary matches. Bool mode. Set that aside or discuss?<br> <dael> jcraig: Resolves my concern. It's short and authors will type most of time. prefers-contrast:more is only a few extra characters<br> <dael> florian: Since this thread is enormous and jcraig is satisfied I think we should close this and consider another issue if other concerns<br> <dael> astearns: If more to discuss on this good to open a separate issue<br> <dael> jcraig: Other possibilities in issue are covered. Will raise separate if I need<br> <dael> AmeliaBR: I think this improves the state but to the point from Alice it would help to look at use cases and figure out which user needs are not being met. Then we can move forward. That might be something to follow<br> <dael> astearns: THat's good to call out. AmeliaBR will you raise an issue on that where we need USs in spec?<br> <dael> florian: There are some in spec, may want more<br> <dael> AmeliaBR: I'll pull out relevant points from issue and spec<br> <dael> jcraig: TO channel Alice she's not particular if it's in spec or explainer. I think spec is better but alice didn't have a preference<br> <dael> astearns: This group prefers in spec.. We can raise an issue.<br> <jcraig> ack me<br> <Zakim> jcraig, you wanted to answer ABR's historical background of "increase contrast" research from the Apple side... I can't speak to the Windows research.<br> <dael> jcraig: My comment was about background, but AmeliaBR we can do a separate call<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-672994920 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 August 2020 16:59:34 UTC