[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.

[xeenon]

@tabatkins We described this last year in #3299, which is still open. Indeed, it does look like that original intent (color scheme transformations at least) was lost in translation.

[MatsPalmgren]

I consider this whole supported-color-schemes feature user hostile, fwiw. The preferred theme is something the user should be in supreme control over. Authors should accommodate that preference by using the prefers-color-scheme media query instead and not force their own preferences onto the user, who may have chosen their theme for accessibility reasons. Fighting this horribly bad feature might be futile, given that one vendor have chosen to ship it anyway (browser wars are so much fun aren't they?), but can we at least get rid of the 'only' part? (If it stays, I will fight hard to make Gecko parse it, but then ignore it.)

[AmeliaBR]

@MatsPalmgren I think we all agree that the ideal authoring behavior is to create websites that respect dark/light mode preference. There is text in the spec to that effect:

Authors should not use this value [only], and should instead ensure that their page renders well with whatever color scheme the user prefers (using the prefers-color-scheme media query to adjust styles accordingly). This keyword is provided only for the rare cases where that might not be reasonably possible, and using a different color scheme would render the element difficult or impossible to use.

It doesn't help users if browser modifications of the styles result in broken, unusable websites (e.g., see @dbaron's comments & the linked bug in #3299 (comment) ).

So at the very least, we need a way for authors to indicate that replaced elements and initial styles can be safely switched to a dark mode or any future color scheme — without creating dark text on dark backgrounds, or imperceptible focus outlines, or similar design and usability disasters.

As for the only modifier, I've stated my opinions above. In short: I'd rather have native widgets, in any color, than a poorly-implemented custom dropdown that can't be reached by the keyboard.

If a website indicates that it isn't designed for a given mode, then browsers could offer users the option to switch into a forced colors mode. @xeenon's comments above show that WebKit was clearly thinking of this option as a future enhancement. But hopefully the definition of how it works can be integrated with the work we're doing to standardize Windows High Contrast Mode. What's important about WHCM/forced colors mode is that it sets colors and backgrounds for every element, not just the root, to ensure that good combinations are maintained throughout.

Note that, as currently spec'd, an only colour scheme declaration would not prevent switching to a forced colors mode. But if necessary for usability, authors could still opt out of adjustments with forced-color-adjust, which comes with its own warnings in the spec. Hopefully, misuse will be avoided because it's independent of the color scheme selection and is clearly defined as an accessibility override.

[tabatkins]

We described this last year in #3299, which is still open. Indeed, it does look like that original intent (color scheme transformations at least) was lost in translation.

Ah, you're referring to "If the user's preference does not match something in the list, the UA is allowed to apply transformations to the content (e.g. apply high-contrast)." from Simon's post.

If that's the extent of it, opting the page into forced-colors mode, then that's fine, it's just a separate feature that's technically orthogonal to this.

But if y'all are planning on doing something separate from forced colors, please actually describe it in a new issue so we can talk about it. We're trying our best to make sure these features are described accurately and fully, so authors can have a reasonable idea of how their pages will look. If the "same" feature ends up still acting substantially differently between browsers, then there's no point to it being standardized at all.

[FremyCompany]

@tabatkins The Apple color-scheme-transformer uses a proprietary color-adjust and not forced-colors (I don't think forced-colors would provide good results if you simply want to invert the brightness level of the entire page. ).

I'd note that this was described in decent length at the last or before-last meeting as far as I can remember, at least to me (but maybe that's because I asked).

FWIW, the Windows Mail client also does something along those lines, but I don't know how that one works. Someone from inside Microsoft should ping that team and ask them. I agree it would be nice if they applied the same type of transform, and we could standardize this at least somewhat.

Ping @gregwhitworth ?

[tabatkins]

I'd note that this was described in decent length at the last or before-last meeting as far as I can remember, at least to me (but maybe that's because I asked).

Yeah, dino's given a few presentations about color adjusting stuff in the past, most of which I thought was superceded by this feature. If that's not the case and some of it is still relevant, it would be great to see that actually described in an issue.

[bathos]

Our app respects OS color scheme settings by default, but it also provides an option for the user to expressly choose the color scheme. This is useful if a user is visiting on a device which they’re only using temporarily, for example, or if the user just happens to have application-specific preferences. Leveraging only dark (and only light), these application-level overrides can produce the full effect that the user intends.

I was surprised by the spec’s ‘should not use’ and some of the comments in this thread.

• [...] theme is something the user should be in supreme control over. Authors should accommodate that preference by using the prefers-color-scheme media query instead and not force their own preferences onto the user, who may have chosen their theme for accessibility reasons
• [...] only dark is a case where they're not respecting an explicit user choice at all

These well-intentioned statements seem to include an assumption that users only communicate their preference through one channel, OS settings (and can do so in the first place). It’s not sound to conflate ‘global OS setting’ and ‘explicit user choice’. Users are not OSes. There are users who will not or will not always have control over OS settings.

An example cohort fitting this profile is public library visitors. I understand concern over theoretical misuse, but I believe it’s premature and that ‘fight[ing] hard to make Gecko [...] ignore it’ is not the accessibility win one might think. It’s the opposite.

[tabatkins]

Agenda+ to ask the WG to restore "only dark" as a possibility.

There is a community of users that won't get dark form controls on such a page (some Linux OSes), but I think that's outweighed by the cost to all users of pages switching to JS-driven custom controls just to get dark controls by default. (Notably, last time we discussed this Safari indicated that it would never match (prefers-color-scheme: no preference), and would instead interpret the OS default as light, so pages that wanted dark form controls on Safari for users that aren't actively using dark mode would need to use custom controls.)

[tabatkins]

(Android also currently only exposes "light" and "dark", with no way to indicate "no-preference", ugh.)

[tabatkins]

Actually, we can go stronger than this. If, per #3857, we drop the no-preference value from the 'prefers-color-scheme' MQ, then the interaction of the MQ and 'color-scheme' becomes much simpler. See the table at https://drafts.csswg.org/css-color-adjust/#color-scheme-prop

If we drop the first column, then the only difference between light and only light, or dark and only dark, is that if the user preference is the opposite, then only will still do what the author wants, but non-only will do the browser default.

Note: it will not match the user's preference! Browser default is constrained to be light on the web, so both color-scheme: light and color-scheme: only light will always produce a light page, regardless of user preference. dark vs only dark will give different results (a light page for dark, a dark page for only dark) depending on whether the user wants light or dark.

This will become more weird/problematic if we ever add more values: if we assume sepia exists in the future, then if the page wants dark but the user wants sepia, then it'll result in a light page, making both parties unhappy!

My suggestion is:

• make only a no-op; it continues to be allowed for legacy reasons. (I think we can just fold it into the <custom-ident> case as something to accept but ignore.)
• As the spec says today, if color-scheme: normal, use the browser default (light).
• If the user's preference is in the author's 'color-scheme', honor it. Otherwise, choose the author's first supported choice.

This means that color-scheme: light always produces a light page, color-scheme: dark always produces a dark page, and color-scheme: light dark leaves it up to the user. In a world where sepia exists, if the user wants sepia, color-scheme: light dark will give a light page instead.

[heycam]

There is a community of users that won't get dark form controls on such a page (some Linux OSes)

In Firefox, it's likely that we will move away from rendering widgets using the platform native appearance, and once we control the widget rendering we will add support for dark form controls on platforms where that's difficult now, like Linux.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] Limits on the `only` color scheme keyword, and agreed to the following:

• RESOLVED: Remove only keyword, simplify the table, add a note about dropping only

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1] Limits on the `only` color scheme keyword
<TabAtkins> https://drafts.csswg.org/css-color-adjust/#color-scheme-prop
<dael> github: https://github.com//issues/3881#issuecomment-631115953
<dael> fantasai: Should we do color adjust when we've got Rossen?
<dael> astearns: This would be good to get to
<fantasai> s/grid/grid, particular wrt lines rather than images/
<dael> TabAtkins: Now that we resolved to drop no-preference from color scheme the table I linked to above to showcase interaction gets simplier
<dael> TabAtkins: If we drop no-preference column than light and dark look similar. Only difference is if the author says light and user wants dark or otehr way neither gets what they want and we use browser default. In all other cases author preference wins.
<dael> TabAtkins: Since only cases are author wins or no one wins and we get browser I think we should simplify and make it so that if you say light or dark that's what you get. We drop the only keyword as meaningful value
<dael> TabAtkins: Existing pages using only will continue to work exactly as they have
<fremy> lgtm
<dael> TabAtkins: Drop the only keyword and make light or dark respect author preference. If it's light or dark it's user preference
<dael> TabAtkins: Obj?
<dael> emilio: uneasy about overwriting user prefernce. Not really objecting
<fantasai> s/light or dark/'light dark' (allowing light or dark, preference to light)
<dael> TabAtkins: User preference if honored if author is okay with lgiht or dark. Existing preference wasn't respecting user preference either, just author preference or going to browser default.
<dael> astearns: Other concerns with this change?
<dael> astearns: I like simplification. It's something we could complicate in future. At this point in time simplification makes sense.
<dael> astearns: Prop: Remove the 'only' keyword and simplify the table in the spec
<dael> AmeliaBR: No objections. Same as with MQ a not mentioning the dropped value would be useful if people try and look up
<dael> TabAtkins: Happy to do that
<dael> fantasai: Need text to parse
<dael> TabAtkins: Parses due to property extensibility. It's a dropped unknown keyword
<dael> RESOLVED: Remove only keyword, simplify the table, add a note about dropping only

[smfr]

Sorry, I had to look at code to confirm, and wasn't in front of a computer at the time.

WebKit uses the "only" keyword to prevent auto-transformations (i.e. auto-darkening). So "light only" is an indication by the author that they don't want their content to be auto-darkened. Just "light" allows auto-darkening.

[tabatkins]

Okay, so it sounds like the answer to #5089 is "yes, WebKit is doing color adjustment not described by the spec".

[smfr]

Right, as noted in #5089 (comment)

[smfr]

Also please talk to the Chrome people who have looked at auto-darkening in the past.

[tabatkins]

That said, that's still a totally different meaning for "only" than what we were defining, so dropping the definition the spec had was still the right decision.

I'll rejigger #5089 to be about re-adding only to mean what y'all are doing.