Re: [csswg-drafts] [mediaqueries-5] UA guidance on light vs no-preference (#3857)

The CSS Working Group just discussed `[mediaqueries-5] UA guidance on light vs no-preference`, and agreed to the following:

* `RESOLVED: Remove the no-preference value`
* `RESOLVED: Add a note that no-preference used to exist but was removed due to lack of impl`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [mediaqueries-5] UA guidance on light vs no-preference<br>
&lt;dael> github:<br>
&lt;dael> TabAtkins: Discussed at F2F with no conclusion. Since UAs have firmed behavior. Every UA I have access to (I don't have iOS but was told they only light and dark) android is light dark and is windows. No one maps to no-preference.<br>
&lt;dael> TabAtkins: Rather than define it we should drop it and acknowledge authors should test light and dark. Right now it gives a false impression and we can re-introduce later if there's a thrid value<br>
&lt;dael> florian: Sad but agree<br>
&lt;jensimmons> +1 to all of that.... well stated TabAtkins — the sense of the current state of reality<br>
&lt;dael> AmeliaBR: Syntax thing. Defined open ended syntax so if there's author code that says prefers dark or no-preference that would parse, correct?<br>
&lt;dael> TabAtkins: Yes parse and be true. no-preference is unknown and unknown or true is true<br>
&lt;dael> fremy: Windows have light, dark, custom<br>
&lt;dael> TabAtkins: Windows custom is defined based on light or darka nd matches light or dark MQ.<br>
&lt;dael> fremy: In your impl. Windows has 3 values and you're saying we don't match it so we don't care<br>
&lt;dael> TabAtkins: I didn't test FF one windows. I'd be surprised if they do tri-state<br>
&lt;dael> astearns: Custom isn'tt he same as no-preference<br>
&lt;dael> fremy: Custom is the default. Light is not the same. Custom means some dark some light. Default on windows is custom. Light theme is different.<br>
&lt;dael> florian: This is what I expressed preference for, but given no UA is doing that that's why we're moving away. If a UA wants that it would be interesting<br>
&lt;fantasai> s/I expressed/Tab strongly expressed/<br>
&lt;dael> AmeliaBR: Coming to the browsers it's one thing if OS allows light|dark|default that's the model we wanted. But if browsers don't expose it to webpages we shouldn't say they do i nthe spec<br>
&lt;dael> fremy: That's called a bug. I don't see point of removing a feature that's used on most used platform<br>
&lt;dael> florian: But if it's not in all browsers on that platform it doesn't exist in the web<br>
&lt;dael> TabAtkins: Yeah, it doesn't exist on those browsers<br>
&lt;dael> fantasai: We've had a number of discussions and all browser venders are aware of no-preference. They're clearly choosing not to do it. I don't agree that's right, but that's what they're doing<br>
&lt;dael> fremy: I won't object but this makes no sense. It's saying we the browser doesn't want to represent all values because we don't care<br>
&lt;AmeliaBR> q?<br>
&lt;dael> myles: I agree with TabAtkins formulation that there's a long history of modifying CSS spec to match reality<br>
&lt;dael> astearns: Prop: Remove the no-preference value<br>
&lt;jensimmons> q+<br>
&lt;dael> AmeliaBR: question: where are we in publication and is it reasonable to add it as at-risk and give it a timeline? Or have we done that?<br>
&lt;dael> astearns: Given it's been under discussion for a long time and no indication from any impl they're considering it's right to remove<br>
&lt;dael> fremy: Is anyone from MS in this discussion?<br>
&lt;dael> Allison: I'm from MS<br>
&lt;dael> fremy: If someone from MS is okay I don't care. If you're fine it's good.<br>
&lt;AmeliaBR> s/Allison/alisonmaher/<br>
&lt;astearns> ack jensimmons<br>
&lt;dael> alisonmaher: I worked on forced colors in blink and we were doing no-preference for forced colors mode<br>
&lt;dael> jensimmons: We're not debating on best for authors, but I feel simplier is better. Since the long conversation at F2F I've seen little interest from authors about doing anything for dark mode. I think we're choosing on reality but this is better<br>
&lt;dael> fantasai: On interpolate forced-colors spec requires mapping to light|dark|no-preference. It shouldn't be mapping to no-preference. So what do we map to if you're middle gray?<br>
&lt;dael> astearns: We will be talking about color adjust later in the meeting if we get to it.<br>
&lt;fantasai> s/no-preference/no-preference when the chosen colors are clearly light or dark/<br>
&lt;fantasai> s/So what/But what/<br>
&lt;dael> AmeliaBR: Issue from fantasai isn't about color-adjust. Browsers asked to take forced-color and determine if it's light, dark, or in-between.<br>
&lt;dael> AmeliaBR: If it's in-between like blue on red is that light or dark mode? How does that calc work<br>
&lt;dael> TabAtkins: I presume we spec browsers should lean toward light. Even if we thought value of no=preference for this case I still wouldn't support keeping because it's not tested. Sounds like a recipie for bugs rather than help user.<br>
&lt;dael> astearns: alisonmaher would you be okay resolving to remove or would you rather a week to talk to collegues.<br>
&lt;dael> alisonmaher: I think it's okay to resolve and then open a new issue if it comes back.<br>
&lt;dael> astearns: Prop: Remove the no-preference value<br>
&lt;dael> astearns: Sounds like mostly agree we should do it even if we don't want to<br>
&lt;dael> RESOLVED: Remove the no-preference value<br>
&lt;dael> fantasai: I think put a note in the spec that there was a value and remove bc no impl<br>
&lt;dael> TabAtkins: Good with that<br>
&lt;dael> fantasai: And if someone wants to impl we're happy to add it back<br>
&lt;dael> astearns: Come talk to us about it!<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Add a note that no-preference used to exist but was removed due to lack of impl<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 27 May 2020 16:24:17 UTC