[css-color-adjust-1] Allow a page to express a theme pref when the user doesn't

[tabatkins]

Rune's spec's processing algorithm handled two cases: letting the page pref win (using "only"), user pref be damned; and letting the user pref win (not using "only"), page pref be damned. If the user doesn't express a preference, and the page doesn't force one, the page automatically gets rendered with "light".

This misses an important use-case, where a page would like to express a default preference for one color scheme, but let the user pref, when it exists, win out. (That is, a page might prefer dark-mode and want dark form controls/etc by default, but be fine with rendering in light mode if the user actually wants light mode.)

I've modified Rune's algorithm in the spec to allow this: if the user doesn't have a preference, then the first understood value in 'color-scheme' is used. So a page that prefers dark-mode but doesn't want to force it can say color-scheme: dark light and get what it wants.

Does this sound reasonable?

[quasicomputational]

I like the idea and it should definitely produce better results in terms of more people's preferences being more satisfied. But there's a loose end left, since I dunno what's meant to happen if step 4 is reached - none of the rest of the text deals with the used colour scheme being null. Should it be no-preference instead, for compatibility?

[tabatkins]

Oh, sorry, that's leftover text from when I was using 'null' to indicate no preference. I'll fix.

[FremyCompany]

This sounds reasonable to me.

[css-meeting-bot]

The CSS Working Group just discussed Allow a page to express a theme pref when the user doesn't, and agreed to the following:

• RESOLVED: Keep this language in the spec

The full IRC log of that discussion

<dael> Topic: Allow a page to express a theme pref when the user doesn't
<dael> github: https://github.com//issues/3850
<dael> TabAtkins: According to early proposal from rune color scheme can be used in 2 ways, what you're okay with the user selecting and say what you must be opted into. If you say only dark you get dark.
<florian> q+
<jensimmons> There's a philosophical debate underneath all these details, about how much visual display could/should be under the control of the user vs browser vs author. 25 years of evolution of the web has already answered a lot of this.... the web started expecting 100% browser / user. We ended up at 100% author. Light/mode will change this... but imho, only so far.
<dael> TabAtkins: Middle ground is if they user doesn't have a preference please opt into this color scheme. This way pages that want to be dark can get dark without forcing the user into dark.
<dael> TabAtkins: Proposal is we interpret color scheme without the only keyword we opt the page into the first in the list if they user doesn't have a setting.
<dbaron> I don't know how to distinguish OS defaults from "user doesn't have a preference".
<Rossen_> q?
<dael> dbaron: I still think no preference is a complicated UI no one will try and get users to express. You can flip between users that look like this or like that. I don't picture someone building a UI for that
<dael> florian: I like reddit being dark on light. I don't want them to support. I like supporting site rendering.
<Rossen_> q?
<dael> TabAtkins: If it turns out no preference you don't use that part of algo. Once you do support no preference you already said you're okay with any. This prevents a browser that wants to support no preference from forcing everything to light
<florian> I like github being light, and arstechnica being dark. These are there branding, and I have no desired to override everything into being all light or all dark
<jensimmons> +1 to what dbaron said.
<jensimmons> We aren't going to have a complex set of web browser preferences to set a pref for each website, one by one.
<dael> fantasai: Current state of the web is no preference. If we want preferences to be an enhancement then we need to have a default setting that is no preference so there's no degredation. In the OS you can ask light or dark. You controls aren't your user preferences on the page. Adobe uses dark controls but drawn on light content.
<dbaron> Isn't the current state of the web 'light' rather than no preference?
<tantek> implicit 'light' is the same as no preference
<tantek> so I agree more with fantasai that current default is no preference
<dael> fantasai: Similar to rest of UI for an OS. You might want to have dark controls and a normal page. Current state, use case for dark controls is I'm in a dark room and want to switch everything. Light mode it's less likely you hate dark themes. Don't want to force websites to switch that off. As interpret bianary preferences it's not true we get only light or only dark for the user
<fantasai> dbaron, in terms of form controls yes, but not in terms of media queries. and these two need to integrate
<dael> tantek: Current UI there's either no preference or an explicit setting of dark. I don't think it's right to assume current setting is light mode.
<fantasai> dbaron, legacy pages won't specify 'color-scheme: light dark' so we will know that they need light form controls for compat
<AmeliaBR> jen: Why wouldn't we have preferences for each website? Most browsers remember my zoom level preference for each site & allow me to easily change it. Why not colors?
<dael> florian: Based on websites today agree. How OI work macOS has a button for light and for dark
<florian> s/OI/UI/
<dael> Rossen_: Back to original issue- TabAtkins request has specific purpose. Not sure we're addressing that or getting close to accept/reject
<dael> florian: I think we've established it's harmless and desirable. Haven't established it will work.
<dael> AmeliaBR: About enabling UAs to have this option without conflicting spec
<dael> myles: Which OSs have or may have no preference?
<jensimmons> Do we have any requests from browser to have more complex controls? (What AmeliaBR is saying right now.) Has any browser asked for such control yet?
<dael> AmeliaBR: Not about OS level. About a browser that can say let websites use whatever color scheme they want rather than use my OS color scheme.
<dael> Rossen_: True for form controls
<fantasai> See also https://github.com//issues/3857
<dael> tantek: And things like scrollbars. Right now if a eb author want s adark theme they have to go through every stylistic and carefully make it dark. Being able to say i set a dark background and light text, hey browser can you do the rest for me is great.
<dael> tantek: This is another way to let authors do the smart thing easier then do things awkwardly
<jensimmons> What we really need to do is expose all the visual styling of form controls. Not just light/dark/foobar. So authors stop replacing form controls with JS + spans & divs.
<fantasai> jensimmons, that's being worked on but it's a really hard problem
<dael> TabAtkins: This is one line in the spec that says if user has no preference use the first author preference. If there is no option for no preference you skip that line. It's future compate with no appriciable increase in complexity to the spec. It's good to aim for in the future.
<florian> I support keeping it in the spec
<bkardell_> seems good to keep as in the spec
<dbaron> I think the spec text is ok, but I don't think it's going to do the things people imagine it will do.
<AmeliaBR> +1
<dael> TabAtkins: If people want to remove we can discuss at F2F. I'd like to resolve to keep as spec
<dael> tantek: +1
<dael> fantasai: +1
<bkardell_> +1
<dael> Rossen_: Objections to keep this in the spec?
<dael> RESOLVED: Keep this language in the spec
<dauwhe> +1
<fantasai> https://github.com//issues/3857
<dael> fantasai: light vs no preference has a separate issue. I flagged it as for the F2F

[lilles]

Closing based on resolution: #3850 (comment)