- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 May 2020 16:24:15 +0000
- To: public-css-archive@w3.org
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> <dael> Topic: [mediaqueries-5] UA guidance on light vs no-preference<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-631126143<br> <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> <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> <dael> florian: Sad but agree<br> <jensimmons> +1 to all of that.... well stated TabAtkins — the sense of the current state of reality<br> <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> <dael> TabAtkins: Yes parse and be true. no-preference is unknown and unknown or true is true<br> <dael> fremy: Windows have light, dark, custom<br> <dael> TabAtkins: Windows custom is defined based on light or darka nd matches light or dark MQ.<br> <dael> fremy: In your impl. Windows has 3 values and you're saying we don't match it so we don't care<br> <dael> TabAtkins: I didn't test FF one windows. I'd be surprised if they do tri-state<br> <dael> astearns: Custom isn'tt he same as no-preference<br> <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> <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> <fantasai> s/I expressed/Tab strongly expressed/<br> <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> <dael> fremy: That's called a bug. I don't see point of removing a feature that's used on most used platform<br> <dael> florian: But if it's not in all browsers on that platform it doesn't exist in the web<br> <dael> TabAtkins: Yeah, it doesn't exist on those browsers<br> <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> <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> <AmeliaBR> q?<br> <dael> myles: I agree with TabAtkins formulation that there's a long history of modifying CSS spec to match reality<br> <dael> astearns: Prop: Remove the no-preference value<br> <jensimmons> q+<br> <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> <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> <dael> fremy: Is anyone from MS in this discussion?<br> <dael> Allison: I'm from MS<br> <dael> fremy: If someone from MS is okay I don't care. If you're fine it's good.<br> <AmeliaBR> s/Allison/alisonmaher/<br> <astearns> ack jensimmons<br> <dael> alisonmaher: I worked on forced colors in blink and we were doing no-preference for forced colors mode<br> <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> <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> <dael> astearns: We will be talking about color adjust later in the meeting if we get to it.<br> <fantasai> s/no-preference/no-preference when the chosen colors are clearly light or dark/<br> <fantasai> s/So what/But what/<br> <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> <dael> AmeliaBR: If it's in-between like blue on red is that light or dark mode? How does that calc work<br> <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> <dael> astearns: alisonmaher would you be okay resolving to remove or would you rather a week to talk to collegues.<br> <dael> alisonmaher: I think it's okay to resolve and then open a new issue if it comes back.<br> <dael> astearns: Prop: Remove the no-preference value<br> <dael> astearns: Sounds like mostly agree we should do it even if we don't want to<br> <dael> RESOLVED: Remove the no-preference value<br> <dael> fantasai: I think put a note in the spec that there was a value and remove bc no impl<br> <dael> TabAtkins: Good with that<br> <dael> fantasai: And if someone wants to impl we're happy to add it back<br> <dael> astearns: Come talk to us about it!<br> <dael> astearns: Objections?<br> <dael> RESOLVED: Add a note that no-preference used to exist but was removed due to lack of impl<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-634779976 using your GitHub account
Received on Wednesday, 27 May 2020 16:24:17 UTC