Re: [csswg-drafts] [css-color-5] `light-dark()` should resolve at used value time, not computed value time (#13836)

Some things that came up in the call:

### _***"`color-scheme` is mainly useful on the root"***_

As many authors pointed out in the call, there are many valid use cases for setting `color-scheme` on individual elements.
Things like code blocks, media players, galleries, etc. Making sections "pop" by inverting the page's color-scheme. 

`color-scheme` also styles the UA UI elements, and while we have properties and pseudo-elements for some of these:
- The one-shot switch is a way to make simple things easy when the details don't matter
- they evolve at different rates and the one-shot switch is a nice fallback for anything you can't customize individually
- Same concept applies to custom elements: it's a one-shot way to theme them without requiring them to expose all their internals

### _**"Without the current behavior, you also end up with unreadable text if you use `color-scheme` without setting a background"**_

See this is the difference between a use case driven problem vs a theoretical problem: _theoretically_, these seem equivalent. You can end up with unreadable text in both cases! But _in practice_, `color-scheme` is used on *surfaces*, which tend to have a `background-color` **organically**. See the use cases above: all would have a background _anyway_. 

But a factor bigger than organic prevalence is **how much pain working around the behavior involves in each case**.

For the proposed behavior, the workaround for this particular footgun is just a single property: set `background` to something reasonable. Done. O(1).

**The workaround for the current behavior is entirely unbounded:** 
- You need to be aware of every inherited `<color>` property that _may_ have been used on any ancestor element and respecify it. This includes
 - registered custom properties, including those used by components or CSS frameworks you don't control
 - current and future built-in properties
- It's not enough to know what these properties are, you need to also know their values. There's no generic value you can set it to e.g. `inherit` would still get you the wrong value, you need to be aware of the *actual* value. Your CSS framework introduced a new inherited CSS property registered as `<color>` that it uses internally? Bummer, your code is now broken.
- Mixins will only make this worse, since you may now have typed inherited properties that you **cannot** respecify!

To sum up: **The workaround for the proposed behavior is O(1). The workaround for the current behavior is _unbounded_.**

### _**"the exact same concern occurs for all length properties that use ems"**_

* Lengths do not have a one-shot switch for them like `color-scheme`, so there is no such case where the author expectation is broken
* Offhand I cannot think of many inherited properties (besides `font-size`, obvs) that take `<length>` values which are frequently set in font-relative units. There is `line-height`, and that's _exactly_ why the recommendation is to NOT set it to `em`s!

Additionally:
* We don't technically need to reverse the resolution in #6773 to fix this: system colors also tend to use `light-dark()` internally. That said, **system colors are the platform's design tokens**. We can't tell authors not to register their design tokens, and then have system colors resolve differently. Especially given the proposals to allow authors to redefine some of them to reflect actual page-level design tokens. E.g. even if we fix `light-dark()` specifically, we'd have the same issue with the [context-sensitive `AccentColor`](https://github.com/w3c/csswg-drafts/pull/12733).
* **The current behavior kills composability.** Imagine someone setting `color-scheme` on a web component. The web component may be reading its design tokens from a global CSS file. The component consumer does not even know what properties the web component may be using, and the component does not know that the consumer applied `color-scheme: dark` to it. This is exactly the type of unfortunate **coupling** this causes.




-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13836#issuecomment-4443629547 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 May 2026 17:26:33 UTC