- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 14:40:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `prefer-color-scheme`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: prefer-color-scheme<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3857<br> <fantasai> TabAtkins: To start, the prefers-color-scheme, being one of the prefers- family of MQs<br> <fantasai> TabAtkins: Is supposed to have a 'no-preference' value, which means website can do whatever it wants<br> <fantasai> TabAtkins: We thought it'd be useful to have a 'light' value which means "give me bright color schemes, maybe I'm in a bright environment or something"<br> <fantasai> TabAtkins: and "dark" means "please don't blast me with light colors right now"<br> <fantasai> TabAtkins: The OSes with only a binary choices, i.e. Mac and Android<br> <fantasai> TabAtkins: I don't know what our non-dark value will map to<br> <fantasai> TabAtkins: but Apple maps 'dark' to 'dark'<br> <fantasai> TabAtkins: and the other value to 'light'<br> <fantasai> TabAtkins: I strongly disagree with this, because it doesn't match the intention in creating these values<br> <fantasai> TabAtkins: But if they insist on doing that<br> <fantasai> TabAtkins: we have a new proposal to do that<br> <fantasai> TabAtkins: light is supposed to actively be light<br> <fantasai> TabAtkins: So proposal is to add another value called "bright"<br> <fantasai> TabAtkins: and light will be the default and will mean "do whatever you want"<br> <fantasai> TabAtkins: which will mostly be light on the Web<br> <fantasai> TabAtkins: This is what we're going to d if nobody changes their minds from yesterday<br> <fantasai> TabAtkins: MSFT will map their three values to three values<br> <fantasai> TabAtkins: So we need to provide three values<br> <fantasai> TabAtkins: If Apple insists on treating 'light' and 'no-preference' as equivalent, then we'll need to make 'light' mena no-preference and add a new value for bright<br> <fantasai> TabAtkins: I will not write a spec if implementations are diverging in a way that doesn't do something useful for authors<br> <fantasai> emilio: I don't see an issue with issues biasing towards bright mode in Macs<br> <fantasai> AmeliaBR: The other option is Safari just doesn't offer one of those three options<br> <fantasai> AmeliaBR: Fact that Safari doesn't offer users user preference of "let the website do whatever it wants"<br> <heycam> fantasai: that means authors will treat light as no preference<br> <jensimmons> q+<br> <fantasai> AmeliaBR: If a website had a light mode and a dark mode, but for branding preferred dark mode, would you expect them to get the light version or the dark version when visiting in light mode<br> <fantasai> hober: I don't understand<br> <fantasai> AmeliaBR: As a website designer I made two variants, light mode and dark mode. I don't like the dark mode design, but if user really wants it I'll provide it<br> <fantasai> AmeliaBR: So in dark mode I'll show dark mode<br> <fantasai> AmeliaBR: of course<br> <fantasai> AmeliaBR: But in light mode, which do you expect?<br> <fantasai> hober: website does whatever it wants<br> <fantasai> hober: Website doesn't have to respond or can respond whatever<br> <bkardell_> q+<br> <fantasai> fremy: Yeah, but the point is that the website should interpret options in an interoperable way across OSes<br> <fantasai> jensimmons: I think there's less disagreement than we realize<br> <fremy> fremy: otherwise authors will need to do (prefers: light) and (os: windows) and that's sad<br> <fantasai> jensimmons: Seems like we really only want two designs in most cases<br> <fantasai> jensimmons: and the designer just chooses in no-pref<br> <fantasai> jensimmons: but there are three choices<br> <fantasai> jensimmons: and the designer could create three designs<br> <Rossen_> q?<br> <Rossen_> ack jensimmons<br> <jensimmons> jensimmons: ...<br> <jensimmons> jensimmons: I think we're going to creat ea situation that's chaotic for authors and it will be hard to teach<br> <jensimmons> jensimmons: I think maybe there shouldn't be a no-pref MQ<br> <jensimmons> jensimmons: but have MQ for light and for dark<br> <jensimmons> jensimmons: and some other tool like a meta viewport that's like a toggle<br> <jensimmons> jensimmons: so that site can say that "in the no-preference state, we prefer dark"<br> <jensimmons> TabAtkins: I think there's some confusion<br> <astearns> s/.../the current expectation we have for authors about the tri-state query won't actually happen with real authors/<br> <jensimmons> TabAtkins: no-preference is intended to be state of Web today<br> <jensimmons> TabAtkins: If the user doesn't care, I would like to be X<br> <jensimmons> TabAtkins: But that still means that on Safari or on Android, depending on how "not dark " s interpreted<br> <jensimmons> TabAtkins: The page will be told "be light" or "be light" instead of "be your best"<br> <jensimmons> TabAtkins: The preference isn't for the page to not have a preference, it's for the user to express they don't have a preference<br> <jensimmons> dbaron: I think in the model that Tab had in mind earlier<br> <hober> hober: i think that sounds great, jen<br> <jensimmons> dbaron: it still had the same goal that you had<br> <jensimmons> dbaron: It was just targetting in a different way<br> <jensimmons> dbaron: with the model Tab had in the spec, if the site wanted to handle the no-preference case by being dark<br> <jensimmons> dbaron: then the site would write MQ only against light<br> <jensimmons> dbaron: so they would write (user wants light) or not (user wants light)<br> <jensimmons> dbaron: latter case would capture both dark and no-preference<br> <jensimmons> This is how MQs generally work<br> <jensimmons> dbaron: If the site's natural preference was light, they would write their MQ as "use rhas pref for dark" and "user doesn't have a preference for dark"<br> <jensimmons> dbaron: This is how Tab's proposal would be used<br> <tantek> fantasai: I hate meta tags for styling<br> <fantasai> fantasai: ...<br> <astearns> q?<br> <fantasai> fantasai: Important to note that MQ with no-pref value is an established MQ pattern<br> <tantek> q?<br> <fantasai> bkardell_: Since the Web until now has not had ability to preference, then current state is no-pref<br> <fantasai> bkardell_: Why do you need a preference<br> <fantasai> bkardell_: someone can actively choose one or the other<br> <fantasai> bkardell_: but some default will happen<br> <fantasai> AmeliaBR: But doesn't have to propagate to the website<br> <fantasai> Rossen_: Might be light sometimes / some apps or dark sometimes / some apps<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <Rossen_> q?<br> <fantasai> TabAtkins: We have to propagate no-pref to the website<br> <Rossen_> ack bkardell_<br> <fantasai> astearns: That's not something authors should do<br> <fantasai> TabAtkins: If not caring about the preference at all<br> <fantasai> astearns: i.e. MQ that hits on no-pref<br> <fantasai> TabAtkins: which is today's world<br> <fantasai> bkardell_: Do you you need a MQ that says "don't do anything special"<br> <fantasai> jensimmons: I think we all want the same thing but disagreeing how to get there<br> <fantasai> jensimmons: There's going to be a lot of code that's not in an MQ<br> <fantasai> jensimmons: that will apply in both light and dark modes and in no-pref state as well<br> <fantasai> Rossen_: I have my preferences for the last 20 yrs, they have been dark bc that's what my page looks like<br> <fantasai> Rossen_: but now my users might want light<br> <fantasai> Rossen_: I want my page to be dark generally, but if they *really* want light I will provide it<br> <fantasai> Rossen_: So I'm only going to respond to (light)<br> <fantasai> Rossen_: On the other side, I might have the opposite<br> <fantasai> Rossen_: e.g. ebay<br> <fantasai> Rossen_: always light, never cared about anything else that light<br> <fantasai> Rossen_: now I know that some ppl might care about dark<br> <fantasai> Rossen_: I don't care about adjusting for anyone else, because light is fine<br> <fantasai> Rossen_: but if user really wants dark, then I'll provide dark<br> <fantasai> TabAtkins: Suppose you have a phone<br> <fantasai> TabAtkins: Has prefs<br> <fantasai> TabAtkins: for dark mode<br> <fantasai> TabAtkins: I expect well-behaved websites to be dark<br> <fantasai> TabAtkins: If you flip on dark mode on the phone, and you visit a website on your phone<br> <fantasai> TabAtkins: do you expect the website to respond to dark?<br> <fantasai> jensimmons: I expect that if the site designed a dark-mode, it will provide that dark mode<br> <fantasai> jensimmons: which could be a range of different types of experiences<br> <fantasai> TabAtkins: If you flip dark mode on, you expect the page to do a "dark thing"<br> <fantasai> TabAtkins: If dark mode is *not* turned on, do you expect them to all be light?<br> <fantasai> TabAtkins: So you expect that if you're not in dark mode currently, websites will be mostly liight<br> <fantasai> jensimmons: I expect users to see the Web as it currently exists<br> <fantasai> TabAtkins: If the dark mode preference is on, pages will be reasonably consistently dark<br> <AmeliaBR> q?<br> <fantasai> TabAtkins: but in light mode, you expect it to be as things are today, mostly light but some dark<br> <fantasai> jensimmons: There are two conversations here. One is what designers "should" do<br> <heycam> q+<br> <fantasai> TabAtkins: My question is about if you have a binary toggle, what do you expect the web to look like?<br> <fantasai> jensimmons: Your'e advocating for websites to have three designs<br> <fantasai> dbaron: Tab isn't advocating that<br> <fantasai> hober: He's giving them a knob to do that<br> <fantasai> jensimmons: But you're advocating to force things?<br> <fantasai> TabAtkins: I'm not<br> <fantasai> TabAtkins: I'm asking what you're expecting pages to look like<br> <fantasai> dbaron: Just because you can write an MQ for 'width' for 400px, 401px, 403px, etc.<br> <fantasai> dbaron: We're not advocating a website have a design for each of those things<br> <fantasai> dbaron: We're advoctaing that the website have design for some pieces of the continuum, and others for other pieces of the continuum<br> <fantasai> dbaron: Tab is advocating that a website have designs for different pieces of this three-part continuum<br> <fantasai> jensimmons: So youre' saying, when a site has intentionally dark "ok whatever"<br> <fantasai> jensimmons: and if site has intentionally light "ok whatever"<br> <fantasai> TabAtkins: ?????<br> <fantasai> jensimmons: If our intention is for authors in the authors to have two designs<br> <fantasai> jensimmons: I don't understand what's wrong with<br> <fantasai> jensimmons: design what's going to show up in light mode and what's showing up in dark mode<br> <fantasai> jensimmons: ...<br> <fantasai> Rossen_: Tab's point is that when I switch my phone away from dark mode<br> <fantasai> Rossen_: consider page like Mercedes, which is currently dark that's their preference<br> <dbaron> s/Tab is advocating that a website have designs for different pieces of/Tab is advocating that a website have two designs for/<br> <fantasai> Rossen_: Should that page switch to a light mode theme<br> <fantasai> jensimmons: Does Mercedes make that decision?<br> <fantasai> Rossen_: Yes. We're not forcing any colors.<br> <tantek> I'm going share these here just for the record, Firefox has at least "Default, Light, Dark" themes today by default: https://support.mozilla.org/en-US/kb/use-themes-change-look-of-firefox<br> <tantek> we intended to communicate this "by default" in prefers-color-scheme: https://bugzilla.mozilla.org/show_bug.cgi?id=1529323<br> <tantek> users can install many more themes: https://support.mozilla.org/en-US/kb/use-themes-change-look-of-firefox#w_how-to-switch-themes_2<br> <tantek> er I mean top of that page: https://support.mozilla.org/en-US/kb/use-themes-change-look-of-firefox<br> <fantasai> dbaron: We've had 2-3 discussions going on here<br> <tantek> as a real world example of a site that has intentionally designed many themes, some lighter, some darker than the default: https://adactio.com/<br> <fantasai> dbaron: I had a proposal related to what I think the discussion between Tab and Tess was<br> <Rossen_> ack dbaron<br> <fantasai> dbaron: which is that maybe three states in this continuum isn't enough. Maybe we want 5 states<br> <fantasai> dbaron: In that there is a strong preference for light, a weak preference for light that is more defaulty, no preference, weak preference for dark, or strong preference for dark<br> <jensimmons> q+<br> <fantasai> dbaron: But it might be the way to represent that some OSes have two states and others have three state<br> <fantasai> dbaron: is more states<br> <fantasai> dbaron: because the continuum is different<br> <fantasai> q+<br> <tantek> +1 dbaron, this is why we're arguing. the lines of the different states don't line-up across interpretations<br> <fantasai> dbaron: One thing I'm thinking is that you have a larger continuum<br> <fantasai> dbaron: and authors will put a breakpoint on one point in that continuum<br> <fantasai> dbaron: but put on breakpoints different points in the continuum<br> <jensimmons> We have to figure this out. We can’t punt and not do it.<br> <fremy> fantasai: the problem is that many options will be confusing<br> <jensimmons> Browsers have already shipped support. So have OSes.<br> <fremy> fantasai: theoritically it works, but it seems suboptimal<br> <fremy> fantasai: also, no preference by the user should then mean light, because that's the normal human preference<br> <jensimmons> I like what David said about 5 options…. yes, that’s likely the reality of whatever…. but it doesn’t matter. Our job is not to represent in code the range of design considerations. Our job is to provide a direct connection between Authors and OS/browser settings.<br> <fremy> fantasai: a no-preference mode in that set wouldn't mean much, and it would be interpreted as light<br> <jensimmons> There’s just two — ligth & dark. If we give Authors 3 or 5 options — what does that mean????<br> <fremy> fantasai: also, rather than adding yet another keyword, it would make a lot of sense to have apple map their preference to map their light theme to both light and no-preference, then websites can respond to this<br> <tantek> s/ligth/light<br> <fremy> fantasai: in a way that's better than just os-targeting<br> <fremy> Rossen_: ok, I hear even more people trying to reply, let's not get into this more<br> <tantek> +1 fantasai, we need a way for implementers to be able to only implement one explicit preference (e.g. dark) and map the others to no preference<br> <fremy> Rossen_: let's have a break, you are all welcome to discuss this during the break<br> <fremy> <br><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-499523323 using your GitHub account
Received on Thursday, 6 June 2019 14:40:29 UTC