[mediaqueries-5] Dark Mode in CSS

[jonathantneal]

Could “Dark Mode” be something we leverage in CSS? Android has it. Windows and MacOS are getting it. We already have system-ui fonts and (deprecated) system colors.

Related to #1286 but not necessarily the same as this isn’t about high-contrast as much as it is about ”dark on light” (Light Mode) vs ”light on dark” (Dark Mode).

If apps can leverage this, it would be swell if webapps could leverage this.

[eeeps]

Maybe a good candidate for an environment variable?

[tabatkins]

No, this is definitely an MQ. env() is for piping values into CSS that you can then use in various properties. This has nothing to do with that; it's about letting the page know that a particular preference exists, so it can respond in arbitrary ways.

[FremyCompany]

(Generally supportive of the idea)

[WebReflection]

if anyhow useful, the Linux GNOME Adwaita Dark theme has been around for 4+ years and it looks stunning: https://github.com/GNOME/gtk/tree/master/gtk/theme/Adwaita

GNOME Dark mode is the default for pretty much every GNOME user I know (including me) so in case you need a reference for implementation, being Adwaita theme OSS maybe it could help speeding up things.

Spoiler: it looks just like macOS dark theme ...

[WebReflection]

P.S. out of experience, browsers blindly applying all CSS had issues with pretty much every website assuming inputs have white background and text on those is black ... without special form elements, links, and others pre-styled overrides, there might be undesired consequences.

TL;DR I'd love to have a dark theme default on the Web, but it'll take years from now to be widely available. UI is brand for most browsers (companies behind) too.

[jonjohnjohnson]

@WebReflection Guessing this issue isn't about browsers blindly applying all CSS, as much as it's about offering a media feature that allows a website access to a users "dark mode" system settings to then style accordingly.

As an aside, has anyone ever found themselves wanting to style around "night shift" features? Not just ambient light, but a users explicit setting, even while it affects a whole screens output?

[WebReflection]

@jonjohnjohnson my bad, I thought it was about providing a default dark theme (html/body background and color + dark form elements + different colors links) to let developers start from a standard (vendor branded) foundation, but if I understand correctly, this is just about knowing via media queries of the user is running on a dark mode, right?

It's valuable info anyway, so +1 regardless.

[jonathantneal]

... we are considering a CSS media query. — @xeenon via https://twitter.com/xeenon/status/1004199249305694209

Sweet! There is maybe some more implementor interest happening here? Now, y’all chat about it before somebody ships. 😁

[frivoal]

I think this is definitely something we need to address, but the major difficulty here is that there is significant overlap between several related features, and we have not yet found a good way to slice the problem up:

• Preference for a light-on-dark mode vs dark-on-light vs no preference
• Preference for a low-contrast mode vs high-contrast mode vs no preference
• The UA has forcibly inverted the colors, at a pixel level
• The UA has forcibly boosted / reduced contrast, at a pixel level
• The UA has forcibly inverted the colors, by changing the styles of elements in the page
• The UA has forcibly boosted / reduced contrast, by changing the styles of elements in the page
• The page is viewed in a brightly lit environment, using a device which is washed out and is hard to read in such situations (eg. LCD, not paper or e-ink)
• The page is in a dimly lit environment, using a device which is blinding in such situations (e.g. LCD)
• The page is in a dimly lit environment, using a device which has no built-in light and is hard to see in such situations (e-ink)
• … and probably more …

Some of these are commonly wanted together, but not always, and which combinations are desirable or not depend on personal preferences but also on accessibility related concerns.

Having a dozen media queries for this is almost certainly not the right solution, but how many are needed is unclear. So far, I don't think anyone has been able to come of with a proposal that covered this problem space reasonably well.

[fantasai]

Wanted to note that the EPUB 3.0 spec included a microformat for addressing this use case via alternate style sheets in http://www.idpf.org/epub/altss-tags/ I think having a media query make sense, though. Also agree with @frivoal’s comments -- we need a comprehensive understanding of the problem space to tackle it correctly.

[FremyCompany]

I don't think there is any connection between dark mode and high contrast. Some high-contrast themes are dark, and could potentially switch the dark mode MQ on, but I don't think we should mix these things up. All operating systems have a user-controlled settings for light vs dark mode, and we should start exposing this setting to web apps.

[AmeliaBR]

Some high-contrast themes are dark, and could potentially switch the dark mode MQ on, but I don't think we should mix these things up.

I really think that's the best way to think about it:

• One media query for dark vs light vs unknown/other color theme (requesting that site content use a consistent color scheme).

• One query for whether or not the browser is enforcing an accessible color scheme, as discussed in https://github.com/w3c/css-a11y/issues/1 (warning site authors that their colours won't be used, and that they should limit the use of decorative effects, and use system colors or currentColor for graphical content that should match text).

The existing -ms-high-contrast media query could map to a combination of the two queries:

• (-ms-high-contrast: black-on-white) = (color-theme: light) AND (accessible-colors: active)
• (-ms-high-contrast: white-on-black) = (color-theme: dark) AND (accessible-colors: active)
• (-ms-high-contrast: active) = (accessible-colors: active)

(@FremyCompany Does that seem reasonable for the Edge implementation?)

Enforced color inversion or time-of-day color alterations applied by the OS would be something else entirely. I'm still not sure that these should be exposed at all. I imagine far too much confusion with author's trying to second-guess the user's decision and browser implementation. Maybe the best way to expose them would be accessibility-filter: active, as a warning that the final colors are changed—without any details in which direction. That way, authors can choose to simplify the color scheme or graphical effects, but cannot make any other assumptions.

Similarly, I am skeptical of a light-level media query being used as a proxy for color themes, because it makes assumptions about what the user wants in a given environment. Using the actual user-chosen OS setting for color theme is much more likely to be accurate. That said, I hope that browsers would provide user control over the setting exposed to websites, separate from the OS-level setting (I personally like dark modes for browser/OS chrome, but hate it for content with any amount of text to read).

A browser-level setting could also be the best way to let users decide if the light/dark mode setting would automatically switch by time of day or ambient light level.

[FremyCompany]

Would just prefer high-contrast-colors: active to accessible-colors: active

[AmeliaBR]

Would just prefer high-contrast-colors: active to accessible-colors: active

I don't like the assumption that the colors will be high contrast. You can use Windows High Contrast Mode (or similar browser extensions) to force any color scheme you want, including soft-contrast ones. People with migraines or concentration difficulties might want to impose a subdued color scheme, as could anyone trying to create a consistent reader mode or night mode.

If "high contrast" is in the name, then devs will think they are being helpful by applying high contrast colors. What is really needed in this case is for the website styles to get out of the way and let the user-selected colors do their work.

[eeeps]

Looks like WebKit have already implemented something – prefers-dark-interface:

https://twitter.com/Keithamus/status/1007557906378706944

UPDATE: but weren't intending to expose it to web content without a standards discussion: https://twitter.com/rmondello/status/1007400236514504706

[jonathantneal]

To clarify, @eeeps, prefers-dark-interface is a private feature that is not available to Safari 12.0 (14606.1.17.40.4) or Safari Technology Preview 12.0 (Release 58, WebKit 13606.1.18.2).

Do other implementors like or have issues with the prefers-reduced-motion, boolean-ish style media query?

Adding @rmondello and @jakemarsh, based on their twitter convo, in case they know more and want to give us updates.

[frivoal]

I don't think there is any connection between dark mode and high contrast.

I don't think they necessarily have to be in the same query (they probably should not), but:

• as settings, these two have been tied in some OSes, where the only way to get darkmode was through one a high contrast mode
• as preferences, these two are sometimes correlated, especially in accessibility use cases. Example: some users with dyslexia want low contrast and darkmode.

So, while I do not expect to solve all of my laundry list from earlier with a single query, I do think we should think through the whole set before settling on something.

Enforced color inversion [...] applied by the OS would be something else entirely. I'm still not sure that these should be exposed at all.

When that is implemented at the pixel level, It is needed, so that authors can turn off shadows, and invert images (so that they get double inverted), otherwise everything looks terrible.

forced-color-adjust: none | invert ?

It is less obvious to me that reacting to pixel level contrast boost/reductions or color tints is needed.

Looks like WebKit have already implemented something – prefers-dark-interface, but weren't intending to expose it to web content without a standards discussion

that, or maybe prefers-color-scheme: none | dark-on-light | light-on-dark together with something like prefers-contrast-adjust: none | high | low might be a reasonable pair to cover the preference side of things.

Similarly, I am skeptical of a light-level media query [...]

Maybe we can skip it entirely, and browsers have some built if feature (possibly optional) that turns on prefers-color-scheme: light-on-dark and prefers-contrast-adjust: low in night conditions, and prefers-contrast-adjust: high in over-bright washed conditions.

Maybe.

---

With that in place, we'd cover forced pixel level inversions, preferences (for dark, high, low), and reacting to the environment (via preferences).

We're left with forced contrast and forced color schemes that operate at the CSS level, rather than the pixel level. I think that this is found in:

• Microsoft browsers, in terms of the Windows High Contrast Mode
• Ebook readers, for their dark-on-light / light-on-dark / sepia modes.

This is possibly the hardest, because it is not clear what properties it can affect (theoretically any, not limited to colors: could change fonts to add or remove serifs, add or remove borders or backgrounds…), how many different themes can exists (theoretically unlimited), and what these various themes mean and what an author should do in response to them. I think Microsoft has the right idea, and having both a media featureto detect that this is happening, and a property to turn it off if you have a better way of providing that effect is a good idea. But that doesn't help us with the potentially infinite list of color schemes.

I am a little uncomfortable with closing the whole thing without having a good answer to that last problem, as I worry that the answer might change how we scope the rest.

[heycam]

There was discussion at the July 2018 F2F about dark mode and related media queries.

The full IRC log of that discussion

``` dino: Talked about prefers-dark mode ones. dino: Other one is prefers-high-contrast dino: Apple has a simple toggle for this. Prefer high contrast? Yes/NO dino: It's much more complicated in Windows dino: Would want auto | yes| no dino: Blocked on not knowing what Windows or Android do, what granualrity do they have, how much do they want to expose. frremy: We have states [light | dark ] high-contrast? florian: In Apple contrast vs light/dark are separate Rossen: That's different Rossen: There's “high contrast” which could be user-defined, e.g. yellow and black Rossen: There are themes, dark theme and light theme, and blue theme, etc. Rossen: Nothing to do with conrast Rossen: Can have bad contrast with dark theme Rossen: they're just dark Rossen: What frremy is talking about is high contrast Rossen: not about themes florian: MS conrast MQ has two options, white-on-black and black-on-white florian: Apple has independent control of hgih-contrast vs not and dark bg vs light bg Rossen: What we wanted to do in high conrast was to guarantee readability. That's what high-contrast is all about Rossen: Had to figure out how to isolate text and make it readable Rossen: Make sure it has ghigh contrast, regardless of colors Rossen: Two options are white-on-black and black-on-white, nothing to do with dark theme florian: I disagree with frremy's statement that this si the smaething as what Apple is doing myles: You said high-contrast is a collection of themes and you also talked about how Window shas theming myles: You can choose one of the many high contrasts or your own theme but not both? iank_ explores the Android Settings men menu Rossen projects Windows Rossen: Here is Edge browser in dark theme Rossen: UI of browser is dark Rossen: Current theme f windows is dark Rossen: In terms of readability, having images with text on top of them is not the best for readability Rossen projects browser with dark chrome, but web pages are rendering as normal Rossen: If I turn on high contrast Rossen: Now what you see is that inside fo the browser, we have applied a numbe rof techniques Rossen: Firstly, all fo the UI is in high contrast Rossen: This current page, as you can see on the images wher epreviously this text was not high-contrast because on top of the image Rossen: Here we compute theb oundign areas of text, and make sure that we have a backing plate that preserves the contrast between the background and the text Rossen: This is not observable by the web author Rossen: In the past we would strip bgimgaes entirely, b/c we didn't know how to deal with it Rossen: but htis is high contrast Rossen: So that was high contrast Rossen: So themes, are something esparate florian: Within constrat, you can pick different styles of high contrast invert colors inverts bitmap images but not vector images on Android. In practice this means everything in Chrome though. Rossen: Right, so I can change the colors instead of having yellow on black, I can flip the colors dino: Apple does that, but only for subtitles in videos dino: We allow complete customization of captions Rossen: We do this for everything Rossen: We have predefined high contrast themes, e.g. white on black and black on white Rossen: Also can have themes Rossen: I can change the UI colors like this Rossen: I can change just the borwser theme, even though the OS is dark theme ScribeNick: heycam ScribeNice: TabAtkins dino: do you have any mode to say turn off the transparency [in the panel]? frremy: yes dino: in accessibility? frremy: no dino: we have that option too, might be worth considering that for a MQ in the future, since some people find that distracting suggests we all buy some of our competitor's equipment for research purposes q+ sees fantasai on the speaker queue ack fantasai sees no one on the speaker queue fantasai: I think there's several things here we're talking about ... not the same thing ... one is general theming of the OS, where you want to change the chrome toolbars etc. but you don't want to change any content ... that is outside the scope of what we're doing here Rossen: that's what I wanted to point out fantasai: we could make it in scope, if you wanted to try to match the theme, but we're not concerned with that today ... rather cases where the user wants changes in the content of pages ... then there's the request for: I want high constrast, and I want dark or not ... four states possible here ... actually more than that ... two axes here ... (whatever, high constrast, low contrast) x (whatever, light, dark) ... default state is whatever, page shows whatever. "light" would mean force dark backgrounds to be light etc. ... for (whatever, light), you don't care what the contrast is ... Windows doesn't have a (whatever, high constrast) Rossen: that's not true ... you can choose some colors fantasai: but you're not responding to what the author said ... there's no setting that says I see there are white colors on dark bgs ... which tries to detect "is this a dark themed page or light themed page" Rossen: I agree ... this is how it will be for the forseeable future astearns: you're talking about forcing things ... I thought we're talking about MQs ... where authors can key off of, and provide a high constrast experience, not forcing something ... if they're cared to provide one fantasai: that's separate Rossen: what francois was trying to describe is available ... currently we provide MQ to say y/n for high-contrast. and for the two default themes, light or dark, what it is florian: when you say "y", in your MQ, you have something to let the author know high contrast has been forced with some colors ... fantasai is asking about a way with MQ to know if the page is forced constrast with its existing page colors Rossen: of course not Q+ sees myles on the speaker queue chris_: [demos what Android does] ... has a Negative Colors option dino: we have a MQ for that ... similar to the color-invert stuff chris_: and there's a color lens thing ... lastly, color adjustment for different color blindness ack myles sees no one on the speaker queue myles: I have a question about Edge's MQs myles: I turn on high constrast on Windows ... web page has a MQ that matches that ... in the MQ that says make text blue, whatever ... does Edge then take that as a signal the web page is handling high constrast itself? and the UA doesn't need to do anything? Rossen: basically what was mentioned this moring, we have a property that lets you opt out an element and its subtree, from high constrast imposed by the OS ... for that particular element and its subtree, you can define whatever colors you want ... if you want to guarantee high constrast go ahead and do it myles: got it Rossen: if it's one the two default high constraints options, black on white, white on black, if you can use a MQ to handle it yourself myles: is it possible to use that property to turn off high constrast handling outside the MQ? Rossen: yes florian: we have the thing Apple brought, is different from this ... because the Windows mode is about forcing the page into one of several high constrast modes ... and letting the author detect this has happend, and through the property let the author opt out ... the thing Apple brought is not detecting it has forced high constrast, but the user requested the page does it to itself frremy: sure Rossen: so your assertion is that the high constrast mode will by default never apply to content, unless the content decides yeah I'll do it dino: for Apple, yes, we don't force high constrast on any content florian: there are multiple types of high constrast. some are preferences, some are enforced ... which you may be able to opt out or not astearns: one of the distinctions in my mind about these things is that I don't think it's our place to specify browser forcing behavior as a CSSWG ... we're not going to specify anything that says "here's what happens when a browser forces changes on content" Chart on the board: x-axis has whatever | forced high-contrast | forced low-contrast | prefers high-contrast | prefers low-contrast y-axis has whatever | forced light | forced dark | prefers light | prefers dark ... the only thing we can do is provide a MQ that says the user prefers a certain high constrast scenario, or that your content decisions have been hijacked by the UA dino: I agree ... and our request is only for the former ... we just want the user to indicate to the dev of the page they've made a preference decision ... the color-filter property discussed this morning is a hammer the dev can use to make it easier to satisfy one of those preferences, but it's not required florian: I was also thinking that combinations of preferences is easier to handle florian: the MS things are reasonable but more complex ... I tried to devise a single MQ query that dealt with all of that, preferences and enforcements ... so I suggest we don't try to solve all these with the one MQ ... the preference thing is simple Q+ sees myles on the speaker queue ... the MS is not as simple, we should solve them separately ... exactly what the page should do if force high constrast and prefer low constrast... shouldn't be exposed to the page ack myles sees no one on the speaker queue myles: I understand there are these two ideas how to implement these features ... is MS making a proposal to standarized their way? Rossen: we made this a long time ago astearns: but it's not the currenty issue frremy: we'd be find having a pref to high constrast frremy: if we force high constrats the user prefers constrast ... if the user forces high constrast they prefer high constrast hears high (dynamic volume) contrast Current description on the board: http://www.tsukune.org/skk/tmp/mq.jpg TabAtkins: what do you think people will do when the MQ is true? prefer high constrast true? frremy: make it high consrast TabAtkins: but it's already happened by the UA myles: he is imagining the content would turn on the property to say "don't do high constrast" and do it themselves frremy: and it's more complex, if you don't set the property, and you have the prop in the MQ, it's applied anyway ... it will work ... if the define everything for prefer, it'll work florian: in that direction it works ... if the page has been devised with Apple semantics in mind, and the browser does what you says, it'll work. ... if it has been designed for Edge design, assumes that prefers high constrats means I've been forced, so I should do nothing, if you run it in Safari the page won't do it myles: if the page will do nothing why would it have this MQ florian: it would turn off some subtle things? frremy: this is not worse fantasai: [whiteboard, chart of different combinations of preferences and forcing] ... you can get all the info you want on what kind of constrast you like or are forced into ... there really seems to be two sets of prefs ... one is about constrast, one is about light on dark and vv ... the MS MQ mixes them into the same thing ... you can have no pref, but also pref for high constrast ... or prefer high constrast, or I've been forced into high constrast ... you can treat them the same or distinct, as an author ... in terms of whether you're forced into dark on light or vv, then having a brightness preferecne will tell you which one you're in already ... these are MQ values I've written frremy: I would be find without these four values s/four/force/ ... you can use the property to opt out of them frremy: if people want to know about them they can use the MQs florian: MSDN says the high constrast MQ has been removed Rossen: that's wrong fantasai's description: http://www.tsukune.org/skk/tmp/mq2.jpg fantasai: frremy your suggestion someone doing the same as MS must create their own vendor specific features to interop with you? frremy: there is no browser who wants to match with us right now astearns: if they want to we can bring something to the group fantasai: we have to standardize their extensions with their syntax dbaron: interoperate with what aspect of what MS does? ... Gecko has certainly to reacted to windows high constrast theme settings in various ways, probably differently from Edge ... it doesn't override a lot of colors emilio: we disable alpha colors astearns: my suggestion is, we've had a discussion, put it into the issue s/alpha/cauthor ... sounds like we do want these MQs in some form s/cauthor/author :) ... and then come back to it at a later meeting Gecko makes quite a few changes when Windows high-contrast mode is set (e.g. dropping the fill of SVG shapes and showing their outline) dino: one point, I don't know if we need a prefers-contrast:low Rossen: actually there is a dyslexia adaptation ... florian: we described the way you react to high constrast active, which doesn't say if it's black on white or vv, I'm the page that knows how to do it, and I'll go into high constrast, [...] Rossen: if you're responsibel you will query the colors fantasai: you can't do that Rossen: you can fantasai: not in a x platform way dino: what do people think of the brightness name? I didn't like the term "dark mode" or "dark content". but "brightness" is a bit weird... fantasai: I just put that up because I needed a word florian: I would go with something like "color theme", but that might be confused with UI theme... ... preferred color scheme? fantasai: it's about the content ... there's the theming scheme, which we might expose at some point in the future, and the prefers light vs dark
The proposal is two media queries: prefers-contrast: none | high | high-forced | low | low-forced, and prefers-brightness: none | light | dark | forced-dark | forced-light | forced-something alternately prefers-contrast: none | high | low | forced or prefers-contrast: none | [ high | low ] || forced not sure preferring no contrast is a thing ```

[jonathantneal]

Were there any actions to be taken from this discussion? Did I understand right that @tabatkins suggested to use the shorter prefers-dark, and that @fantasai suggested instead to use prefers-colors: light | dark | any?

[frank-laemmer]

Sorry to bother, but is inverted-colors like described here on MDN (Media Queries Level 5) the same thing?

[AmeliaBR]

@frank-laemmer inverted-colors indicates that the browser is changing the colors you specify: if you say white, it will show up black, and black will show up white. The purpose of that media query is to let authors turn off effects like shadows that would interfere with readability in the switch. But other than that, inverted colors is a bit of a hammer, with no nuance & no expectation that the colors would be intentionally designed for dark mode.

In contrast, the media query being discussed here is about a request from the user for a dark-themed site, if the site has multiple, well-designed themes available.

[Keyes]

I would prefer something like prefers-interface-colors: light | dark or prefers-interface-theme to be absolutely clear about the purpose of the MQ. prefers-colors could be mistaken for some accessible colorblind mode switch. Also light-on-dark sounds much more specific than dark 🤔

[FremyCompany]

@Keyes I like prefers-ui-theme: light-on-dark

[AmeliaBR]

+1 to prefers-ui-theme: light-on-dark | dark-on-light | no-preference Clear and simple terminology, but not so short it becomes ambiguous.

[equinusocio]

Just a question, why are system dark or light interface considered related to accessibility (issues)? I mean, this discussion is about to expose a way that allows web authors to handle the css based on system preferences (like the actual prefers-reduced-motion), i think what they will do with it can't be "prevented".

I think contrast mode is not related to a dark/light ui preferences since they can both use high contrast color palettes.

BTW prefers-ui-theme: light-on-dark | dark-on-light | no-preference is for me the most clean and unambiguous proposal.

[joshuat]

@Keyes I think having prefers-ui-theme: light-on-dark rather than prefers-ui-theme: dark is unnecessarily verbose.

Using light-on-dark would make sense if there were more than 2 options, but since there are only 2 UI theme options, it just makes more sense to directly label them as such.

[Krinkle]

I recognise that inverted-colors is separate and insufficient, we need a solution for Dark Mode.

However, I'm not sure we can get away with treating it as separate. As a user, if you strongly prefer dark mode, it seems like we should do the best we can to offer the user that, both as OS/browser vendors and as website authors.

I suspect that the current proposal might not offer the best we can because, if I understand correctly, we would leave the user with two bad choices:

• Use inverted mode, and have darkness everywhere, but not very well done design-wise.
• Use dark mode, and have nice designs for the OS and small number of websites, with the rest being mostly too bright.

We should develop a long-term vision that resolves this. It might still involve the media query as proposed, but I think we should think how it fits in with the above before we decide.

The following is just an example, but one way it could work (perhaps) is to encourage users to enable both and have it "just work" (e.g. an extra option within dark mode to "use inverted colors for applications that do not offer a dark mode").

For that to work, a web app would need to be able to "turn off" inverted colour mode and communicate to the OS/browser that it takes full responsibility for dark mode. Such signal could in addition to this media query (e.g. some kind of header or meta tag indicating ahead of time to the browser that the page takes responsibility and will provide a dark mode). Anyhow, this example is just clarify the intended outcome. I have no preference for what technique we'd use.

[frank-laemmer]

shameless plug: I blogged about the topic here: https://medium.freecodecamp.org/how-to-get-dark-mode-working-with-css-740ad31e22e includes: images, opinion and trivia…

[adiabatic]

I suspect that the current proposal might not offer the best we can because, if I understand correctly, we would leave the user with two bad choices:

• […]
• Use dark mode, and have nice designs for the OS and small number of websites, with the rest being mostly too bright.

I wouldn't underestimate the utility of this for people who visit a small number of websites for their workdays. If I could get just GitHub to support dark mode that'd easily halve the amount of black-on-white I see. If MDN, developer.apple.com, MSDN, and Stack Overflow all followed suit, lots of people wouldn't have to see much black-and-white at all.

---

I suppose one way of thinking about the utility of automatic inverted mode is "how much will it break your design if white is black, black is white, blue is orange, and orange is blue?" After a few minutes of fiddling with my iPad in inverted mode ("hey Siri, invert colors"), this is what I saw:

• Lots of formerly-blue buttons are now orange. Seems fine.
• Dark Sky has a blue sun. This sort of reversal is moderately confusing if you're running the app for the first time and all the time in inverted-colors mode, but generally fine.
• My monthly TextExpander report is mostly legible. Its logotype image isn't reversed (iOS is being smart about not reversing them). The images aren't so large that they defeat the purpose of inverted-colors-as-dark-mode, but I'm slightly worried that the now-brown text on a black background isn't high-contrast enough for people who need high-contrast text.
• Bob Ross's smile, in his Twitch avatar, is downright spooky coming from a blue man with white pupils.

My hunch is that the least bad solution for inverted-colors-as-ersatz-dark-mode will probably involve:

• automatically-reversed text and background colors
• OS/browser-based heuristics for when to reverse images (yes for light-yellow bamboo-forest backgrounds, no for logotypes)
• some sort of per-element override for the above heuristics because there's no way all browsers will be able to correctly guess this sort of thing all the time: flip-colors-in-reversed-colors-mode: flip-colors | do-not-flip | flip-as-you-please | inherit…*.

Contra Krinkle, I think a per-element switch would be better than a per-site switch. I can imagine many hobbyist website authors who'd like to support dark mode if it merely involves choosing a second set of colors, but would rather use the browser's ability to reverse images' colors instead of having a second, dimmer version of every picture used.

---

* Awful, verbose names chosen to avoid biasing readers towards names chosen without much thought put into them.

[equinusocio]

Is this topic just about allow developers to check if users are using dark mode and let developers doing things? Why are we talking about auto-inverting colorsare (i think this argument should be discussed in a different topic)

[AmeliaBR]

From the recent comments, I think it is safe to say:

• Using an inverted-colors mode to create a dark effect assumes that most websites have a light mode design. If used on a website with a dark design, the effect is counter-productive.

• Therefore, browsers should not expose a prefers-ui-theme: dark setting at the same time as applying inverted colors.

• Ideally, browsers would switch to using a prefers-ui-theme media query approach as the default strategy, and then let users invert colors on individual web sites if the author-supplied theme doesn't match the user's preference. Maybe even a smart browser could detect when the main body text is dark or light & apply the filter automatically.

[jonathantneal]

From outside GitHub; as of September 6, 2018 Safari devs are still working on a public version of this media query, and macOS Mojave is expected to be released to the public shortly, on September 24, 2018.

[jonathantneal]

I’m closing this thread because a standard was written and merged into this project back in July.

https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

For the extremely curious, I did test the query in Safari 12.0 (14606.1.36.1.9) and it’s not implemented. https://codepen.io/jonneal/pen/vzPwWo/

[AmeliaBR]

I note that the following issue is also included in the spec, and I think the discussion on this page is relevant to it:

Should we include forced-light and forced-dark values? We don’t necessarily want the page to try to undo what the system might be enforcing.

In addition, the recent discussion covers an open issue about the interaction of inverted colors and color scheme: Are authors expected to test for @media ((prefers-color-scheme: dark) AND NOT (inverted-colors)), or are browsers expected to only apply one or the other at a time? Either way, it should be stated in the spec.

@grorg, do you want to add dedicated GitHub issues for discussion of those two points, linking back to the relevant comments here?

[FremyCompany]

@AmeliaBR These things are not dependent and could be applied at the same time. Invert-colors is an effect applied on the entire computer screen, and can be applied regardless of your base theme. I would expect you rarely want dark theme + invert colors as a user, but you should be able to ask for that if you want.

[FremyCompany]

Just for reference, here is a screen capture of my Windows in dark theme with an inverted color + desaturation on Windows 10. It does look quite nice if you ask me :)

[AmeliaBR]

@FremyCompany OK, so maybe my wording was not ideal. If a user wants to use dark mode + invert to create a light mode, that's fine. But I don't think that's the desired outcome of most people using either feature, so browsers need to approach the intersection of the two features carefully.

[adviva]

@jonathantneal https://codepen.io/jonneal/pen/vzPwWo/ is working on Safari Technology Preview Release 68 (Safari 12.1, WebKit 14607.1.11)

[nuts-n-bits]

For that to work, a web app would need to be able to "turn off" inverted colour mode and communicate to the OS/browser that it takes full responsibility for dark mode. Such signal could in addition to this media query (e.g. some kind of header or meta tag indicating ahead of time to the browser that the page takes responsibility and will provide a dark mode). Anyhow, this example is just clarify the intended outcome. I have no preference for what technique we'd use.

I also think browser should communicate this preference via http header, which enables the server to get involved and allows for more logic based implementation.

Request header: X-Prefer-Interface-Style: dark

Response header: X-General-Interface-Style: dark

[eeeps]

@nuts-n-bits :

I also think browser should communicate this preference via http header

If we do this, for security/privacy and header-bloat-prevention reasons, it should probably be via a Client Hint, not a new header cc: @igrigorik @yoavweiss

[James-E-A]

Is there really not any way for a website to automatically discriminate between these situations?:

1. User has actively chosen and prefers a light style
2. User has no expressed preference as to light vs. dark style

[tabatkins]

There is not. Unfortunately, we had a fairly contentious discussion about this several years ago, and browsers refused to commit to no-preference being the default. I cannot speculate as to the reasoning, as it was not communicated at the time.