[css-color-adjust-1] Limits on the `only` color scheme keyword

[AmeliaBR]

Regarding the color-scheme property and its associated meta tag.

In the discussion of #3807, there was a lot of debate about acceptable use of the only keyword in the property. We made a temporary resolution to adopt the property in the Editor's Draft, with an open issue. There's currently an inline issue in the spec, but this is opening it up for continued discussion.

The story so far:

The only keyword, as defined in the original proposal, allows website authors to override the user preference expressed in browser/OS settings, and instead directly ask the user agent for a specific color scheme.

Some WG members are concerned about allowing authors to override user preferences. Other WG members are concerned that authors will assume that an only request for a specific color scheme would always be respected, and won't design for user agents that don't have that color scheme (e.g., dark) available.

The compromise currently in the spec is to only allow only in combination with light, and to require user agents to have a light theme available.

I'll leave a separate comment with my opinions.

[AmeliaBR]

I do not agree with restricting only to light mode. I think it limits the ability of authors to create accessible, user-friendly interfaces within reasonable design constraints.

Consider the following use cases (which have been mentioned previously, but I don't think everyone quite understood them):

• An author wants to add a light mode / dark mode switch on their website. This switch will expose these color modes to users who aren't familiar with the OS/browser modes, and will support users who may want a different mode for this specific website than what they use for the rest of the OS. (Toggling dark mode for specific websites is something I hope will be supported in future browsers, but it doesn't yet exist!)

• A website design is dark for brand or content reasons, or uses a mix of dark and light sections to contrast and emphasize different types of content. The author wants form elements and widgets that match with that design.

As currently spec'd, the only way for the website author to get dark mode form elements and scrollbars in either of these cases is to style them from scratch using appearance: none and prefixed pseudo-elements and everything that authors (and users) have been complaining about for years.

If we support dark only, these author use cases would be easy, allowing them to directly use the native styles. Yes, this means that the designs would be sub-optimal on user agents that don't have dark-mode widgets available. But that doesn't mean that they will be broken. (A website doesn't have to look the same in every browser, after all.) It certainly doesn't mean that the end result will be any more broken than if the author tried to implement their own custom dark mode widgets.

The whole reason for exposing dark mode controls is to make it easier for authors to use the native controls instead of re-implementing them. Preventing authors from requesting dark mode widgets counteracts this.

[tabatkins]

If the page uses color-scheme: dark;, they'll get dark inputs when the UA supports dark mode, and either the user wants dark mode or doesn't care.

The only difference from color-scheme: only dark is that only dark will also do dark inputs when the UA supports dark mode but the user specifically wants not dark-mode. Importantly, tho, they'll still get light inputs when the UA doesn't support dark mode at all.

So, since the only difference between dark and only dark is a case where they're not respecting an explicit user choice at all, and only dark does not ensure dark controls in the first place (in particular, Firefox on Linux might not be able to support dark mode), I'm sympathetic to the "don't allow only dark" position. If the page really wants to ensure dark controls, it'll need to style them from scratch anyway.

[xeenon]

The only keyword was added based on discussions with @FremyCompany in October 2018 to satisfy some of the needs Microsoft had with trying to adapt this with their high contrast mode. It also helped us (Apple) with Mail's auto darkening feature.

The only keyword isn't just about form inputs. It signals to the UA that the page should have no transformations (like auto darkening of the page colors/images supported by macOS Mail and being explored by Chrome).

If you say light (or nothing, the default), the UA could still be allowed to transform the content into a dark color scheme if the user prefers a dark color scheme. Saying light only prevents that. Similarly, a page or email designed with a dark color scheme could say dark and a user who prefers a light color scheme could have a UA that transforms the content to a light color scheme. Saying dark only would prevent that. It could also just be a suggestion — the UA could ignore it if there is a need to transform content for accessibility reasons for example.

Also light dark only would prevent other transformations in the hypothetical future if another color scheme is added to the known list.

[FremyCompany]

I strongly regret caving in on this during the phone call, because I had not considered the algorithm properly when I said I could achieve what I wanted with dark light only. I checked and this is not accurate. As a result, I am strongly in favor of rescinding the dark only ban, which doesn't seem to provide any value to me.

It is absolutely incorrect to say that a website is not respecting the user choice when requesting dark only because as mentioned by @AmeliaBR before, each application could have its own toggle switch for themes and if the user chooses something there, this user decision needs to be enforceable somehow. I know many developers that use Visual Studio Code in dark mode but all their other apps in light mode, and that makes sense to them, and apps absolutely should be able to provide such mechanism without having to avoid using any platform-provided control. Visual studio code today doesn't use any native platform control, do we really want all apps to look like that?

Besides, in most cases, restyling all controls to enforce dark yourself is not going to work properly anyway, because styles do not have subtle enough control over some controls (like scrollbars, select menus, pop-overs and many parallel ui surfaces likes selection). These elements cannot be styled properly for dark mode because not enough information is known about the platform to have a native feel for the dark theme, so an arbitrary choice has to be made and that cannot possibly match all platforms.

Moreover, the argument given by @dbaron that Firefox on Linux cannot support a dark theme looks bogus to me. If an operating system does not provide a way to get dark form control theming, browsers can draw these control themselves using the fallback theme like they already do for light-theme control with non-default styles. There is nothing stopping any browser to do that. This would still look better than forcing a site to use light form controls with a dark theme otherwise.

[AmeliaBR]

@xeenon To clarify, you're suggesting a situation where the user agent would override author styles to apply a dark/light mode? I think that's outside what we're talking about here, and is more consistent with the forced-colors media query and the forced-color-adjust: none property that we're working to spec elsewhere.

We should spec that a forced color mode can override the color-scheme property, though (unless an author sets forced-color-adjust: none on the same element).

[xeenon]

@AmeliaBR Ah, yep. I didn’t realize that split off into forced-color-adjust.

[dbaron]

I'd be more sympathetic to @FremyCompany's position that we could switch to non-native controls if we had a spec for how form controls worked (including details of rendering, and which CSS properties apply and what effects they have) and browsers were implementing it. In the absence of such a spec, we're stuck chasing each other for web compatibility, and that chasing is a good bit harder when you have multiple platforms to worry about.

[laukstein]

css-color-adjust-1 mentions property color-scheme and mediaqueries-5 prefers-color-scheme. Mustn't it be under same naming?

[FremyCompany]

@dbaron That is fair, and that is definitely something that should be worked on eventually.

But in all fairness, that problem isn't new. In the end, we only introduce an ability to switch the colors of the fallback theme here, not a new type of layout for these controls. The fallback theme is already in use on most author-styled form controls on the web today, since changing pretty much any css property on these controls triggers the fallback. Dark theme wouldn't affect layout or anything, it's pretty much only about changing the colors you use for text and backgrounds;

Based on that, I will admit I don't see how changing the colors of the fallback input controls is an additional compat risk, but maybe I'm missing something out (totally possible!)

[dbaron]

The risk I'm talking about is that of triggering the fallback controls in more cases.

[tabatkins]

If you say light (or nothing, the default), the UA could still be allowed to transform the content into a dark color scheme if the user prefers a dark color scheme.

That is absolutely not what the spec says, which we copied over with only light alterations from Rune's first draft of a spec.

If the page says color-scheme: light, the UA is allowed to apply a "light" scheme (if that's what the user wants) or the "default" scheme (if the user wants anything else) (which, for web compat, will be "light" in all web-facing UAs). It cannot use a "dark" scheme.

If y'all are doing something different, please describe exactly what it is (in a new issue) so we can discuss altering the algorithm for choosing a used color scheme.

(This, btw, is why you should write the dang spec for features you're leading and shipping early on; if you make us guess what you're doing, we won't necessarily match it correctly.)

[FremyCompany]

@tabatkins From what I recall, they use supported-color-schemes: light as the content only works for light, but if the user wants dark, the user agent is allowed to darkify using a filter or forced-colors (only used in their email client I think) while supported-color-schemes: light only prevents the mail client from doing that.