[mediaqueries-5] UA guidance on light vs no-preference

[fantasai]

The Web consists of a wide variety of content types, some of which are application-like, and others which are art-like: for dark mode to be useful for e.g. night reading, as has been suggested, authors need to perceive (prefers-color-scheme: dark) not as a preference for UI in app-like interfaces, but as a global preference for content. I would also like authors to be able to consider (prefers-color-scheme: light) to be as serious as (prefers-color-scheme: dark), and both to be perceived as a real and meaningful request from the user.

For that to work, however, no-preference needs to be a thing. In other words, an OS can't have a light vs dark switch that applies to UI elements which is then simply propagated through the UA to the page. The default case needs to be no-preference, indicating that the page should theme itself however it sees fit, and both "light" and "dark" need to reflect a desire for not just the OS widgets, but content in general, to be "light" or "dark". Otherwise "(prefers-color-scheme: light)" becomes a meaningless signal, and we may as well remove it.

[frivoal]

Given the way that a number of first-party apps from Apple, such as Garage Band, iMovie, or the Pro Apps, look dark no matter what, I suspect that the so called "light mode" of MacOS is would be more accurately described in the context of this media query as a "no preference" mode, in which apps take their default look and feel, most of which is light, but not all. As far as I can tell, despite what it says in the UI, MacOS doesn't actually have a "prefers light" mode that pushes default-dark apps to become light.

[AmeliaBR]

As someone who prefers "dark mode" UI but absolutely cannot stand to read light-on-dark text for anything longer than a label, this is very important distinction. As a user, what I'd really want is the ability to request light or dark mode for individual web domains & have the browser remember that choice. But at the very least, don't assume that my OS setting is what I want for web content.

[AmeliaBR]

For comparison with Florian's notes about MacOS:

Windows 10 has an OS-wide personalization setting for light or dark. But it's defined as your "default app mode". It directly changes the color scheme for system dialogs and for small utilities like the calculator and alarm clock. More complex native apps (well-maintained, Microsoft-built Universal Windows Apps, anyway, like maps, photos, and weather) have a three-value option for the "app mode": light, dark, or Windows default (with a link to the OS settings).

Of course, for other apps (not made by Microsoft, or not updated to the latest OS features), the results will vary.

[css-meeting-bot]

The CSS Working Group just discussed UA guidance on light vs no-preference.

The full IRC log of that discussion

<fantasai> Topic: UA guidance on light vs no-preference
<fantasai> github: https://github.com//issues/3857
<hober> q+
<myles_> ScribeNick: myles
<myles_> ScribeNick: myles_
<myles_> fantasai: The bakcground is we have a wide variety of content types on teh web. some are application-like, and some are art-like. For the use case of night reading, authors need to perceive dark not as a UI choice, but as a global choice for all content.
<myles_> fantasai: anyone disagree?
<myles_> jensimmons: are we saying that every part of a page should be on a dark background with white text?
<myles_> fantasai: no. It means the user wants a dark mode (such as being in a dark environment) so please adapt to that expectation. It's not just "i think black looks cool"
<myles_> jensimmons: There are cases where 1 blog designer might say the article textshould be light on dark in dark mode. But a different one might only want to do that to the sidebar, not to the body text
<myles_> jensimmons: I think what you're saying is the first is good, but not the second
<dbaron> I think the text fantasai read was "The Web consists of a wide variety of content types, some of which are application-like, and others which are art-like: for dark mode to be useful for e.g. night reading, as has been suggested, authors need to perceive (prefers-color-scheme: dark) not as a preference for UI in app-like interfaces, but as a global
<dbaron> preference for content."
<myles> fantasai: it means "it is difficult for me to work with a light-mode scheme", or "
<fantasai> We need to distinguish between "I want my apps to be dark mode, but content whatever, because I want the app interfaces to fade into the background wrt the content I'm focusing on"
<fantasai> vs. "I'm in a dark room or otherwise have difficulty with light-mode theming, please make things dark for me"
<hober> q?
<florian> q+
<myles> fantasai: the other thing: light has the same weight as preference/desire as dark. If an implementation wants to have a no-preference mode, it maps to a no-preference mode. I don't carewhat the UI is, but the default mode of the web is no preference. The default mode that is communicated is no-preference.
<myles> TabAtkins: Current dark websites should not be told "everyone on the web prefers light, please use a light mode" when in reality most users don't have a preference, use any mode
<myles> TabAtkins: Even though you only have two states, you should map it to "no preference" and dark.
<astearns> ack hober
<myles> hober: We have no notion of no-preference on our platforms. At OS install time, we prompt the user to pick light or dark. You have to to move on to the next screen. There is no system concept of no preference. We're not interested in pretending otherwise.
<jensimmons> a website I designed over a decade ago: http://runesofgallidon.com
<myles> florian: You're describing what you call the buttons in the UI. On macOS, there is a light and dark button. If you pick dark, all apps are dark. If you pick light, only some are light. So yes, you call it light, but in reality it doesn't mean that. Apps don't get forced into light mode. The mode you ahve been calling light is a no preference mode. It's not a preference for light.
<myles> florian: all the pro apps are still dark in teh light mode
<myles> hober: Not all websites are going to listen for this thing. That's okay.
<myles> jensimmons: I disagree with the first statement: Dark mode means everything has to be dark. We don't need that. That belongs in teh hands of the designer. Some sites can interpret "dark" differently than other sites. Authors can interpret it differently.
<myles> TabAtkins: If i want dark mode because i'm in bed, I would be unhappy with any light
<myles> jensimmons: Your'e speaking as a user. Websites can do tha tto their users.
<myles> florian: We are describing what this preference means.
<myles> jensimmons: That is not how this is going to work out.
<myles> TabAtkins: You are arguing that the notion of dark mode is not useful
<myles> dbaron: I think you started from the assumption that this should be symmetric. In reality, it is not symmetric. So saying "therefore it should be symmetric" is not helpful. The reality we're starting from is that existing content wouldn't work if users had dark defaults. If you want a mdoe where all we bcontent is dark, then you need a browser that is going to make destructive modifications to websites
<una> q+
<AmeliaBR> ack dbaron
<tantek> I'd like "I (webpage) can handle dark mode, except can you take care of dark form controls and scrollbars for me" ?
<TabAtkins> TabAtkins: That's not what I'm saying. I know I"ll get blasted by light sites sometimes. But *if* I say Dark Mode, and I visit a reasonable site that pays attention to it, I expect the site to be dark. That's just the general expectation of what that value means.
<myles> dbaron: I think we're starting from a world where most web pages are light. And some pages are going to be willing to design two options, some aren't. That's the reality. We're also ina. world where a bunch of OSes have introduced these dark mode preferences. It's a request that a lot of stuff be dark. So, we have preferences htat users have chosen where one option in that preference is "the legacy behavior where most stuff but not all was light" and the
<myles> other is "i request more stuff be dark". Those are the preferences that people are asking to be reflected to the web. Those aren't symmetric. Trying to map into a thing that's symmetric or pretend that one is an expression of no preference at all, where the light one is a weak preference for maybe no preferences, and maybe "i have not chosen the dark mode". The dark mode preference is a stronger preference. It's not "no preference at all' but it's pretty
<myles> weak. The other is strong. That' sthe thing we have. Trying ot map that onto a tri-state, wehre two optinos are symmetric, and one must express no preference at all is not going to work
<jensimmons> q+
<myles> florian: I don't think no-preference means no preference. No-preference mode means "the state of today". Most websites tend to be white. Some websites are dark, and some are fuscia, and I'm okay with that, which results in most content being light. This is No-preference. If we had two states, it would be "what you've been doing" and "dark". If we had 3 states, it would be "light", "dark", and "no-preference"
<jensimmons> But what in the world are the browsers / OSes going to do with three states? What are Authors going to do with three states?
<myles> florian: THe default shouldnt' mean "i really need you to be light". If an UI has 3 states, it should map to 3. If it has 2 states, the one that isn't dark, the one remaining should be a no-preference value. Or, we shouldn't have al ight mode at all, but the default one should nto be a request to be light
<fremy> q+
<AmeliaBR> +1 for florian's summary
<hober> +1 to dbaron
<AmeliaBR> ack florian
<astearns> ack una
<myles> una: Yes, a lot of websites tend to be light with dark text on light background. That's true for media websites with text, but landing pages are often dark. We have light and dark modes; I see them, and people interpret modes where their current astehtic is not sufficient, then use light to create a light version of the website. Mercedes is a dark theme, with many dark pages. There are use cases for both. There's no benefit in separating out no-preference
<myles> from light and dark.
<myles> florian: i am confused.
<myles> una: no-prefernce is equal to brand identity
<myles> florian: Yes, and it should be the default
<myles> florian: In macOS, one is dark and one is the default. Even though you labelled it as light, it means no-preference
<myles> florian: so the request is to for macos to map what is called "light" to no-preference
<myles> hober: no
<bkardell_> <room chuckles>
<myles> florian: so mercedes can continue to be dark
<myles> astearns: we are asking for changes in UA behavior
<jensimmons> q?
<myles> TabAtkins: in dark mode, you expect all apps to be dark, right?
<myles> hober: no. i agree with dbaron
<myles> TabAtkins: A well-behaved app should be dark, right?
<myles> hober: I don't know what "well-behaved" means
<myles> hober: If I'm in photoshop, the canvas's background is white, I don't expect it to be black in dark mode
<myles> hober: If I change the preference, I expect many things to change, and some things not to.
<astearns> ack jensimmons
<TabAtkins> q+
<AmeliaBR> Do we agree that browsers should give users a no-preference option? Or is that also controversial?
<myles> jensimmons: Priority of constituency. This is a theoretical purity vs practicality argument. Theoretically, users should pick light and everything should be entirely light. but that won't happen because of the history. So we should explain how dark means everything should be dark, and vice versa? I'm not on board with that. The control that's presented to users is light and dark. Sometimes it's in the OS, and some are in the browser, and this doesn't make
<myles> sense to me. I don't know how to tell authors how to make 3 designs? Should some AI do it for the artist? So why do we want 3 options? What should the browser hook up to each option in the media query?
<myles> jensimmons: The reality is that we don't know yet what designers are going to want to do with a vague idea of dark "mode" and the vague idea of light "mode". Users might hate it, but it's their right to make something users hate. Maybe both modes will be lightish, but that's just the design of the page
<astearns> ack fremy
<myles> fremy: We have been saying that all OSes have 2 themes: light and dark, where light doesn't mean anything strong. In the latest windows, there is 3 options: no preference, dark, and light.
<florian> q+
<myles> Light on windows means, all dark things that are dark by default get light.
<myles> There is this new mode that is "light" in which case the start menu and settings become light
<myles> fremy: This is how the media query should be modelled
<myles> q+
<fantasai> q+
<myles> fremy: Maybe we should revisit this issue in a little while. It doesn't sound crazy to me to map 2 preferences to no-preference and dark
<astearns> ack TabAtkins
<myles> TabAtkins: dark mode means something. Applications/pages can respond to it and do something. There is an expectation about what a page responding to dark mode is. Something will happen to a page. And it will be dark.
<myles> TabAtkins: What is the expectation for a page in light mode?
<myles> hober: As mild as the preference for dark
<myles> florian: For the pages that do respond, what do they do?
<myles> TabAtkins: If you respond to the query, and you do something with your colors, is the expectation that they will be light?
<astearns> q?
<myles> heycam: The expectation is that for pages and apps that have both, they will chose the light, but that's not the expectation that all pages will do that. Some ::more:: will be light or dark.
<myles> fantasai: Specific example of the mercedes page. Let's say they make a light and dark background pages. My branding strategy is that I want most people to see the dark one, but if they want light, they will turn that one on. On macOS, are they going to switch into the light mode, or would the expectation be that they get the branding colors they ideally want the users to have in light mode?
<fremy> if someone want to learn about the new windows light mode aka "the perfect antithesis of the dark mode", here is a blog post: https://www.windowschimp.com/windows-10-light-theme/
<myles> TabAtkins: In dark mode, we expect mercedes to use dark colors. In the other mode, we expect them to use their normal brand colors, which are light
<myles> astearns: we can't be that black or white about our expectations. Given the desires of advertisers, I can certainly see one saying "theyr'e in dark mode, I'll use light colors to stand out"
<myles> TabAtkins: People can be assholes no matter what
<myles> TabAtkins: What do teh values mean? What should authors do with the media query? If we can't answer those questions, we remove the media query
<bradk> I think most of the time ‘light’ and ‘no-preference’ would be designed the same way. But Mercedes might have a ‘light’ version that is not shown for no-preference.
<myles> q?
<jensimmons> q?
<bkardell_> q+
<myles> jensimmons: Your example: team at mercedes, they have had a design for years, so they design two more versions of the site: light and dark. So what do they do with the no preference mode? I don't want to give them three options
<bkardell_> q-
<fantasai> jensimmons, we're not expecting to design three options. Either the website doesn't care (ignore all options, one design only)
<AmeliaBR> No preference doesn't mean, design a third color scheme. It means the website author gets to pick whether to use the dark scheme or the light scheme.
<jensimmons> I simply don’t understand how three options will work.
<dauwhe> +1 to astearns plan
<myles_> astearns: We are done for the day.
<fantasai> jensimmons, or it designs two: light mode and dark mode. In no-preference mode, they pick whichever one they like the most
<bradk> And liaBR: +1

[css-meeting-bot]

The CSS Working Group just discussed prefer-color-scheme.

The full IRC log of that discussion

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

[astearns]

We do not yet have consensus on what to do with light and/or no preference (everything proposed so far annoys a few people). So here's a new option that's sure to annoy a few more:

Let's break the convention that a media query must have more than one value, and (for now) only allow 'dark'. It is my impression that the main use for this new query is to allow authors to opt-in to dark styling, which this would provide. Once authors have more experience in adapting their styles to a UA dark preference, perhaps we will get a better idea of how other UA theme preferences should be exposed.

[AmeliaBR]

(for now) only allow 'dark'

Unfortunately, we're specifying the behavior of this feature after it has shipped in multiple implementations (Firefox and WebKit both support it in stable builds and it's in the Chromium beta build). Limiting the spec to only one keyword won't prevent the other keywords from being used & therefore won't prevent de facto definitions from authors trying to work with browser behavior.

But, given that this feature is out in the wild, I'd certainly like to know if anyone has early usage data about how the media query is being used by authors.

[frivoal]

@astearns if it's web compatible, and existing implementations are willing to unship the other values, I think you proposed solution is quite reasonable indeed. +1

[litherum]

Honestly, I don't quite understand why this issue is so contentious. Three major operating systems (four if you count iOS betas) all have the same concept: light vs dark. Android (and future versions of Windows?) have an in-between setting. This seems to map very naturally to the existing spec.

Expecting every web author to create a light mode and a dark mode of their entire site is unreasonable. Instead, this media query simply exposes a choice that the user has made. The page author can choose to incorporate that, or not incorporate that, into their design. We're not trying to (indeed: can't) make an alternative "dark mode" or "light mode" universe where every web page is dark or light.

[AmeliaBR]

I have to agree with Myles: the terms "light" and "dark" are consistently used in UIs as equal alternatives. Saying that only one of those values is a meaningful choice is user-hostile.

Since many websites are by default light, many website authors are going to specifically query for dark preference to serve an alternative design. But as the trendiness of dark mode reaches it peak, and there's more discussion about the readability benefits of traditional dark text on light backgrounds, I expect that some sites (and maybe even native apps) which were traditionally designed with dark backgrounds will start querying for a light mode preference.

I would still prefer as a user to have more nuanced options in my browser: to be able to set no-preference, use a different mode than my OS, or toggle light/dark preferences for individual websites. And I think it's fair for the spec to say that browsers should give users a no-preference (let the website choose) option.

But the absence of that option in some environments is not enough justification to specify that browsers must ignore an explicit user choice for "light" mode, treating it as default/no preference. Authors with default-dark styles should be able to detect a light mode preference to trigger alternate designs, just like authors with default-light styles want to be able to detect a dark mode preference.

[petergoes]

From a developers point of view, it feels strange to have a dark option but no light option. Especially since the values map to the OS preferences which also provide (at minimum) two values. If an OS would only provide a dark mode, it would have been a checkbox-like interface, but instead they all went for a radio-button like interface making the choice for either of them explicit. That kind of explicitness is what I'd like to see in my code as well. I can see scenarios where the design of my site is colourful by default, extra bright on the light choice and extra dark on the dark choice.

In the examples of @litherum and @AmeliaBR, Android and Windows show an in-between state, which gives your 3 options. From a users perspective, that would be my ideal situation.

To illustrate why, as a user, I want to explicitly state a light theme: when walking outside, reading in sunlight, an explicit light theme would be welcoming. The most ideal situation for me would be that a setting is available in the browser which overrides the OS setting. In the case of an OS without a light/dark setting but with a browser that does, temporarily choose a light theme is an explicit choice of the user.

[tabatkins]

Agenda+ to discuss dropping the "no-preference" value from 'prefers-color-scheme'. At this point, every single browser only exposes a bi-state, matching either light or dark. Users don't have a way to distinguish between "don't care" and "I really want a light page", and we shouldn't pretend that they do by defining a value for it.

If a future browser does want to expose that difference, the web will have already frozen to treating light as meaning default, and we'll have to expose the "I really want light" as a different value, like bright.

(This is a bad situation and I'm quite annoyed we ended up like this, but c'est la vie.)

[css-meeting-bot]

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

The full IRC log of that discussion

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

[tabatkins]

Removed the value and added a note in 1d2fd71

[astearns]

@tabatkins I think you missed the negation in the first example on this line:

rather than by negation such as ''(prefers-color-scheme: light)'' and ''(not (prefers-color-scheme: light))''.

[tabatkins]

Nope, that's what I meant - that's a pair of MQs that can be used together (but shouldn't, per the advice).

[astearns]

Ah, it wasn't clear to me that those were pairs of MQs. I read it as four separate instances of MQs that should or should not be used. So it reads "match directly, like {A} and {B}, rather than by negation, like {A} and {C}" - {A} being both a good and bad example.

I think it would be much more clear if you just pare the examples down to two:

such as ''(prefers-color-scheme: light)'', rather than by negation such as ''(not (prefers-color-scheme: light))''

If the pair of MQs is required for the example, then call out in the text that they are paired.