[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 Create a 'high-contrast' media feature within CSS media queries css-a11y#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