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.

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.

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.

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

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

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.

(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.

@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

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.

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.

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.

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.)

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

Removed the value and added a note in 1d2fd71

@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))''.

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

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.