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

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-5] `light-dark()` should resolve at used value time, not computed value time ==
The spec currently [defines](https://drafts.csswg.org/css-color-5/#funcdef-light-dark) that `light-dark()` resolves to one of the two colors at computed value time:

> For the color form, this function computes to the computed value of the first color, if the [used color scheme](https://drafts.csswg.org/css-color-adjust-1/#used-color-scheme) is [light](https://drafts.csswg.org/css-color-adjust-1/#valdef-color-scheme-light) or unknown, or to the computed value of the second color, if the used color scheme is [dark](https://drafts.csswg.org/css-color-adjust-1/#valdef-color-scheme-dark).

As a result, when authors define color tokens as registered color properties, they lose their dynamic switching and just inherit as one of the two colors — depending on the value of `color-scheme` on the element where the token was defined.

Meaning this will work:

```css
:root {
 color-scheme: light dark;
 --color-accent: light-dark(yellow, blue);
}

.dark {
 color-scheme: dark;
}

.card {
 background: var(--color-accent);
 color: canvastext;
 padding: 1em;
 margin: 1em;
}
```

<img width="593" height="147" alt="Image" src="https://github.com/user-attachments/assets/287a60bf-7a07-4967-b7dc-9c4c7c1565ad" />

but once we define `--color-accent`…

```css
:root {
 color-scheme: light dark;
 --color-accent: light-dark(yellow, blue);
}

@property --color-accent {
 syntax: "<color>";
 initial-value: skyblue;
 inherits: true;
}

.dark {
 color-scheme: dark;
}

.card {
 background: var(--color-accent);
 color: canvastext;
 padding: 1em;
 margin: 1em;
}
```

<img width="595" height="153" alt="Image" src="https://github.com/user-attachments/assets/0f5fd1e2-3c5c-42cb-acdb-7210de92a8f4" />

Whoops.

This is compounded by the fact that it works as expected for unregistered custom properties and for system colors, so it's very easy to have code that works, register a property, and suddenly have undetected failures that make content inaccessible or even entirely unreadable.

This is not just an issue with registered custom properties, but _any_ inherited `<color>` property. Here's another example:

```css
:root {
 color-scheme: light dark;
 --color-accent: light-dark(yellow, blue);
}

body {
 color: light-dark(darkblue, white);
}

.dark {
 color-scheme: dark;
}

.card {
 background: var(--color-accent);
 padding: 1em;
 margin: 1em;
}
```

<img width="587" height="152" alt="Image" src="https://github.com/user-attachments/assets/e245ebb5-ca2d-4805-b102-a8d65b658ee9" />

Ideally, we should have defined that **the function computes to itself and resolves at used value time**.

There are two questions here:
1. Is this **desirable**? I suspect it will complicate implementations in a way that is similar and possibly even worse than `currentColor`, looking forward to hearing from implementors! cc @emilio @weinig(not sure which Blink implementor is working on color but hopefully @andruud or @tabatkins know?)
2. Is it **web compatible**? [Per ChromeStatus](https://web-platform-dx.github.io/web-features-explorer/features/light-dark/) `light-dark()` as a whole is used on **1.23%** of page loads, though the number is climbing so this is urgent, hence the Agenda+. While 1.23% is high, this change would only affect a (likely small) subset of cases and presumably we can easily measure how big the subset is (though that would delay things further).

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13836 using your GitHub account


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

Received on Thursday, 23 April 2026 22:34:16 UTC