Closed jonathantneal closed 5 years ago
Maybe a good candidate for an environment variable?
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.
(Generally supportive of the idea)
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 ...
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.
@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?
@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.
... 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. 😁
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:
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.
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.
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.
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.
Would just prefer high-contrast-colors: active
to accessible-colors: active
Would just prefer
high-contrast-colors: active
toaccessible-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.
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
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.
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:
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:
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.
There was discussion at the July 2018 F2F about dark mode and related media queries.
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
?
Sorry to bother, but is inverted-colors
like described here on MDN (Media Queries Level 5) the same thing?
@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.
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
🤔
@Keyes I like prefers-ui-theme: light-on-dark
+1 to prefers-ui-theme: light-on-dark | dark-on-light | no-preference
Clear and simple terminology, but not so short it becomes ambiguous.
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.
@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.
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:
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.
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…
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:
My hunch is that the least bad solution for inverted-colors-as-ersatz-dark-mode will probably involve:
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.
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)
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.
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.
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/
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?
@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.
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 :)
@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.
@jonathantneal https://codepen.io/jonneal/pen/vzPwWo/ is working on Safari Technology Preview Release 68 (Safari 12.1, WebKit 14607.1.11)
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
@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
Is there really not any way for a website to automatically discriminate between these situations?:
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.
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.