[mediaqueries-5] Clarification on prefers-color-scheme issues

[jonathanKingston]

Whilst working on trying to implement this for Firefox I and @emilio noticed some ambiguity with the spec text.

The prefers-color-scheme media feature is used to detect if the user has requested the system use a light or dark color theme.

1. Does it really matter if this is a system or user agent preference? For example in non supporting operating systems Firefox could choose to pass light and dark when the user has enabled these themes and no-preference when they haven't.

2. (prefers-color-scheme) never appears to match, however shouldn't it match whenever the user has a preference? Especially given the boolean context statement.

3. We are at slight risk of sites never supporting no-prefererence given safari is only using light/dark and always returning true for no-preference.

/cc @grorg @emilio

[jonathanKingston]

Also as a follow up, would it make sense for something like web driver to be able to control this setting? That way we could perhaps web platform tests for it?

[emilio]

cc @smfr, is WebKit's behavior intentional? If so, knowing the reasoning would be helpful to know what to implement.

[xeenon]

Apple's implementation matches light or dark always when the system / app / view UI is running in light or dark mode — it is a binary choice on macOS — the user / app / view / system has no choice but to be in one of the two modes.

In Safari no-preference is basically treated like a hypothetical prefers-color-scheme: any — kind of like what you suggest for (prefers-color-scheme).

Given that (prefers-color-scheme) does not read well or convey much intent, we decided to make it invalid. But again, we can change (prefers-color-scheme) — and it would always be true for us. Conversely no-preference would always be false for us.

[xeenon]

I filed a bug for WebKit here with a fix: https://bugs.webkit.org/show_bug.cgi?id=191654

[grorg]

Typically we try to make the "empty" form have a falsey value for these prefers- queries.

[grorg]

I agree that's a bit weird for this query, because it isn't clear if no preference is explicit or not. But the no-preference value is supposed to be false. @xeenon has already fixed the bug in WebKit.

As for the other points:

1. Agreed. It could be the UA setting.
2. Yes, I think (prefers-color-scheme) should match if the user has explicitly selected a scheme. I don't know why you'd want to author that though.

[grorg]

I'll update the specification to clarify point 1. What are people's opinions on 2? Should no-preference mean "I don't care" or should it mean "only if i haven't chosen a scheme"?

[emilio]

Thanks @grorg, that all makes sense!

I (but note I'm not an expert in this area) personally think no-preference should be exclusive to any of the other values matching (that is, you should never get into a state where (prefers-color-scheme: {light, dark}) and (prefers-color-scheme: no-preference) apply at the same time. Also, it probably makes sense to require at least one of the values to match over all?

I think I'd be confused as an author if that was not the case, but again I'm not author nor an expert in this area, so my opinion probably doesn't have that much value :-)

[jonathanKingston]

I (but note I'm not an expert in this area) personally think no-preference should be exclusive to any of the other values matching (that is, you should never get into a state where (prefers-color-scheme: {light, dark}) and (prefers-color-scheme: no-preference) apply at the same time. Also, it probably makes sense to require at least one of the values to match over all?

That seems to be my understanding of how this should work also. I think it is fair that Safari for example might decide never to match for no-preference as they are always light or dark.

2? Should no-preference mean "I don't care" or should it mean "only if i haven't chosen a scheme"?

As for Firefox, for the short term no-preference might be used on platforms where we don't have an OS setting. Firefox likely will be using no-preference for users who don't want to convey their preference also like Tor users.

My views are:

• no-preference should never match when light or dark does.
• (prefers-color-scheme) should match if light or dark matches but not match when no-preference matches.

[danosek]

Here are my thoughts from designer's perspective. I know there is a gray area regarding definition of @media (prefers-color-scheme: no-preference) and @media (prefers-color-scheme) but let me explain the bigger picture with this example.

I the near future (I hope), there should be no distinction between light and dark theme, as there is no distinction between user's device screen size. We should only adapt the content and its visual properties to match user's device (whether it's a size or theme preference to something else) with media queries.

The thing is, you should only clearly define default design when there is no support for prefers-color-scheme. In the end, this design is just one of the themes - light or dark. It only depends whether your default design should be light or dark. That's it :)

[emilio]

cc @lilles, I wonder if you have any thought here as the Blink implementor.

[lilles]

Having the keywords being mutually exclusive makes sense to me as well. IIRC, in Mojave you cannot have no-preference. If that's the case, authors will probably not end up having three different designs, but have either the light or the dark being the default, like:

@media (prefers-color-scheme: dark), (prefers-color-scheme: no-preference) {}
@media (prefers-color-scheme: light) {}

I have not checked with ChromeOS/Android if they will have a no-preference, but privacy/finger-printing was brought up as an issue on blink-dev (like mentioned above for Firefox as well).

[dannote]

As for now "light" and "dark" actually mean "as is" and "a specially crafted dark mode" respectively and I can't imagine what will "no-preference" mean in these terms. Maybe we should keep it binary?

[freund17]

I imagine this feature like this:

As a web developer...

...you are presented with 4 cases you might want to cover:

@media (prefers-color-scheme: dark)

If your app has a dark-mode, use it.

@media (prefers-color-scheme: light)

If your app has a light-mode, use it.

@media (prefers-color-scheme: no-preference)

Use whatever mode you, as a developer/designer, thought of as the more suited for your app.
For an image galary app this might mean "dark".
For a text processing app this might mean "light".
Whatever you think of as the "better" mode for your app.

@media (prefers-color-scheme)

Simply means that the webbrowser at hand supports communicating it's users color-scheme preference.
If it doesn't, you will probably want to use the same as if "no-preference" were submitted.
However you might want to use this information to conditionally show/hide manual theme-selection buttons, when the same information can be provided via the users browser.

In a supporting webbrowser...

...I imagine there to be the following settings (maybe with per-domain overrides):

System

Forward the preferred color-scheme by the OS.
If the OS doesn't have a concept of color-schemes, set "no-preference".

No Preference

Let the website decide what is best.

Light

Send "light" as your preference.

Dark

Send "dark" as your preference.

Closing thoughts

Remember, that you, as a developer, are always able to override the "prefers-color-scheme"-value.
For example, if the user explicitly selects a theme in your app.

This feature - at least in my eyes - is most useful to

a) get the fist time visitor directly into his favourite theme
b) have a website responding to the system color-scheme (which might depend on the time of day) and have it in sync with all other applications on the user's device