[css-color-adjust-1] Let pages opt in to any scheme

[quasicomputational]

I think it'd make sense to add something like color-scheme: any to indicate that the element is entirely agnostic to the colours that are used (i.e., it's careful to only use currentColor and system colours, never sets background without setting foreground and vice versa, etc), so whatever colour scheme the user most prefers can be used without fear of breakage. This would work better than color-scheme: light dark as it's future-proof against schemes getting added later.

[tabatkins]

Possibly, but the fear as always with this sort of thing is that a page will type "any" because it's shorter than "light dark", even tho it would actually look bad if, say, "sepia" was used.

A user can always force a page into supporting a color scheme with a *{color-scheme: foo !important;} declaration in their user stylesheet (or the UA can fake it with similar mechanics behind-the-scenes), so I don't think this addition is worth the risk of it being misused.

[AmeliaBR]

I disagree that this is something that would be misused. If a website design really works for both light and dark styles, as implemented by any current or future browser, it's unlikely to break for anything in between. I think the worse issue is in not allowing authors to create forward-focused stylesheets that also respect user preferences.

I'd go one step forward, and argue that any should include any user agent color scheme, including ones that haven't yet been standardized in CSS with a particular name.

A keyword like any is clear enough. But we could go with color-scheme: whatever or color-scheme: as-you-wish if you really don't want anyone using it without thinking about anything other than character counts.

A user can always force a page into supporting a color scheme

But this isn't about users forcing color schemes. This is about authors stating that this page or section of a page, can safely be styled in any color scheme.

[css-meeting-bot]

The CSS Working Group just discussed Let pages opt in to any scheme, and agreed to the following:

• RESOLVED: Reject this issue

The full IRC log of that discussion

<dael> Topic: Let pages opt in to any scheme
<dael> github: https://github.com/w3c/csswg-drafts/issues/3859
<dael> TabAtkins: Request is that right now a page has to explicitly say which schemes it supports. Only 2 but if we add more and a page is written for just light and dark and we added sepia you wouldn't get sepia on the page. Request is to say I support any color scheme.
<dael> TabAtkins: Will work if you're careful to only use system colors. Won't work if you're not careful and you design for just light and dark.
<dael> TabAtkins: Somewhat disinclined to add a new value that is opt me into future stuff. It's possible, but hard and rare. People don't use system colors usually because generally makes pages look bad. Most people using this won't have pages that look good. It'll be misused for just light and dark and sepia will break.
<tantek> As someone who has recently added a few different color themes (dark etc.) to their site, I can agree with TabAtkins that this is nontrivial to plan for especially in the abstract!
<dael> AmeliaBR: My argument to the contrary- Just because authors can be careless doesn't mean we should prevent authors from being helpful and user friendly. color scheme any is about being able to say as an author I'm lightweight with styling. I think that's a good thing that should be encouraged.
<dael> AmeliaBR: Spec allows people to say which color schemes they have tested against. Even that we don't narrowly define what dark and light mean. A future browser could create a variation on dark and light that a careless website has problem.
<tantek> q+ to note This feels more like a footgun than something actually useful to authors. Also could see theme/framework default abuse of "color-scheme: any", which is then violated by someone modifying the theme/framework without realizing they are failing to uphold that expectation.
<dael> TabAtkins: Reason I'm still o nmy position is we want to allow authors to do the right thing, but also not deisgn a feature easy to use wrong. Only way to design to take any color scheme is only system colors and almost no pages do that today. Perhaps we'll see that more in the future and then I'd reevaluate. THe good practice to make this work isn't used right now so I'm not happy to add.
<tantek> TabAtkins: "good practice required to make this work is not used at all by anyone"
<dael> dbaron: One more common practice is don't use colors at all
<dbaron> s/more common/slightly more common/
<dael> AmeliaBR: Simpliest case is a lightweight website, a bit of spacing and layout but mostly trying to present text. In that case you want to say draw in colors user wants
<dael> Rossen_: How is this difference then not having at all
<dael> TabAtkins: Not having is white background back text. We don't have a way of saying this is unstyled
<dael> Rossen_: How is color-scheme:any different then not having MQ at all?
<dael> AmeliaBR: Not a MQ. Property that tells browser which UA stylesheet to use. This is about if you use dark form elements or light form elements. Not a MQ.
<dael> Rossen_: Okay
<florian> I'm with Tab on this one
<dael> TabAtkins: Going for unstyled not using colors, it happens more than using system colors, but not a lot overall. I'd rather that's something that opts you in. If this was paired with a restriction that makes it so you can only use safe colors or no colors I'm fine. An uncolored page is rare. Without something that forces you into acting good I don't like something that will likely break in the future even if it works well today.
<fantasai> I'm also with Tab on this one
<dael> TabAtkins: Today it's a shorter way to write what they want but it breaks in the future when we introduce something new
<dael> AmeliaBR: Seems backwards. Future focus is if I write a good coded website today it should work with future features.
<dael> AmeliaBR: I would support adding an example or warning in the spec with a yellow on blue color scheme as a future example to make it clear that things might be different than what you expect
<tantek> Worse than a footgun, this is timebomb
<dael> florian: In general we should not assume people are incompitent. Lazy is reasonable. If they have something that appears to do the right thing today and when it's extended it does the wrong thing you culd know that from the spec, but you didn't read the spec and it does what you want. I'm with TabAtkins on that
<dael> TabAtkins: If there's a control that forces the good mode then I'm totally happy and we should have that option come in.
<dael> AmeliaBR: I don't agree that's a necessary condition. Necessary condition is when you set font you also set background.
<tantek> I'm particularly swayed by TabAtkins point that no one is (we have no examples of) using CSS that could take advantage of this.
<dael> TabAtkins: If you have one element white bg and dark text with a dark color scheme you're not honoring intent of color scheme.
<dael> TabAtkins: This is also generalizing before having evidence we're going to gneeralize. We right now don't have indication we'll introduce a 3rd color scheme. When we do I'd be happy to work on an any value. Right now no guar we'll introduce a 3rd. Giving an any now that would make it hard to extend I'm not comfortable
<tantek> 1. no evidence (of anyone using CSS designs that would work with this feature), 2. no evidence of need for this property, 3. likely to be a footgun or timebomb (worse)
<tantek> s/this property/this value
<fantasai> +1 to tantek
<florian> +1 to tantek too
<dael> AmeliaBR: IRC most people agree with you. I'll aceept this as an in future if it's necessary but maybe not now. We will discuss a 3rd soon with sepia
<tantek> q-
<dael> Rossen_: Proposal is to reject this issue
<dael> Rossen_: Objections?
<dael> RESOLVED: Reject this proposal

[fantasai]

Closing out as rejected. We may reconsider in the future, but given how dangerously misunderstood this feature could be, the convenience is not worth it; and furthermore, due to the subtlety of correctly handling it, the possibility of some pages using it correctly for future-proofing is more than offset by the likelihood that actual usage would create future pitfalls.