- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Feb 2019 17:52:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Clarification on prefers-color-scheme issues`, and agreed to the following: * `RESOLVED: Close this issue no change, there is already language in the spec` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Clarification on prefers-color-scheme issues<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3278<br> <Rossen> ah, misread the log...<br> <dael> emilio: Bascally, people are about to ship this MQ. There were unsolved issues. Should be straightforward<br> <dael> emilio: One is what should MQ evaluate in boolean context.<br> <dael> florian: It's defined in spec. If there's disagreement to what's defined I'm happy to hear it<br> <dael> emilio: Peoplediscussing on issue, but if spec says that's fine<br> <dael> florian: Same as no preference<br> <dael> dino: It makes using that form almost useless. You can't derrive meaning from it. If the query is prefers color scheme it will eval to true if they picked on<br> <dael> fantasai: Not prefers color scheme is interesting though. Makes it shorter to type out.<br> <dael> dino: You save 5 characters<br> <dael> TabAtkins: Prefers color scheme and not is clearly you either do or don't. It makes it this thing exists or doesn't and that's what null communicates<br> <AmeliaBR> `@media not (prefers-color-scheme)` and `@media (prefers-color-scheme: no-preference)` make sense as equivalents, to me.<br> <dael> emilio: Other question is if it should match light on print or if that's too smart<br> <dael> dino: That is another issue<br> <dael> astearns: I hadn't read the entire thread on #3278. Is that only what to do in boolean context?<br> <dael> emilio: Yeah<br> <dbaron> do existing implementations follow that answer?<br> <dael> astearns: Sounds like we have an answer. @media prefers-color-scheme is the same as null<br> <dael> astearns: It sounded like dino found it useless<br> <dbaron> (sorry, I can't unmute since the machine I'm dialed in on is semi-frozen thanks to yesterday's Windows update...)<br> <dael> dino: I don't know why you'd use it, but it does follow behavior so it's fine<br> <dael> TabAtkins: Yes, we're looking for consistency in how other MQs are handled<br> <dael> astearns: Prop: Close this issue no change, it is defined in spec. dbaron asked in IRC if impl match this<br> <dael> florian: I think we're light on tests<br> <dael> dino: We don' have any no-preference option<br> <dael> ??: I think blink is one that would have to change<br> <dael> emilio: Blink matches<br> <dael> dino: We should contribute tests for this. not sure how you can test user choice<br> <dael> florian: That's always the problem with testing MQs.<br> <dael> TabAtkins: Generally they're all manual tests. They're very hard<br> <dael> dino: Internally we have JS API only exposed in test system to set user preference for that page. Would be nice if al browsers could standardize on an API to do things like this. Would cover media style but nice if pointer events and touch events and that type of thing. Not for this WG I guess<br> <fantasai> sgtm<br> <dael> astearns: Sounds like there's consensus to close this issue and take what's in the spec currently. Objections?<br> <dael> RESOLVED: Close this issue no change, there is already language in the spec<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3278#issuecomment-463298698 using your GitHub account
Received on Wednesday, 13 February 2019 17:52:14 UTC