Expand `light-dark()` to support non-color values

[nmn]

Description

The current specification for light-dark() requires the two values passed into the function to be <color> values. The proposal is to expand the capability of the light-dark() function to support arbitrary value types.

e.g. these should be valid uses:

• border-width: light-dark(4px, 2px);
• color-scheme: light-dark(dark, light);

Rationale

light-dark() is a very useful function that massively improves custom theming. Instead of being forced to maintain three separate themes for light, dark and auto, light-dark() allows us to define a single theme with light and dark values and then be able to actually control the theme applied using the color-scheme property.

It would be a superior alternative to prefers-color-scheme media query for most use-cases expect it has one major shortcoming: It only works for color values.

While it's true that colors are the most common values that need to change for light/dark color schemes, there are exceptions.

Some usecases

Using different length values for light and dark mode

It is sometimes desirable to have thinner border in dark mode because light lines on black backgrounds tend to "bloom" more. In such cases using this becomes desirable:

border-width: light-dark(4px, 2px);

Flipping the color-scheme

It is often very desirable to be able to "flip" the current color-scheme for a particular UI sub-tree. For example, it is common in design systems to use the opposite color-scheme for tooltip than for the rest of the page.

For such scenarios, usage like this becomes desirable:

color-scheme: light-dark(dark, light);

Investigation Roadmap

• Discuss whether this expanded functionality is viable and possible
• Update spec and tests
• Implementation

[chriskirknielsen]

I myself would love to see more progress on this. I posted a similar issue to the CSS working group a while back: [css-color] Allow light-dark() to be used for any property, not just color #10152 Turns out this is planned but not for light-dark: instead it would be schemed-value.

[nmn]

Turns out this is planned but not for light-dark: instead it would be schemed-value.

I have no objections to working on a schemed-value() function that can eventually supersede light-dark, but can we please not block the enhancement to light-dark() in the meantime?

I think there are many more aspects of custom color schemes that will need to be discussed and resolved which could take a long time. In the meantime, we could improve light-dark() today with changes that are uncontroversial and obvious.

[romainmenke]

Allowing any value in light-dark() is very unlikely to happen.

CSS is a typed language there is a difference between functions like var() or env() that can return anything and all the other functions.

light-dark() already shipped as a function that only returns a <color>. Expanding it to allow anything would make it less useful for colors by making it invalid at computed value time and it would also break back compat.

In any case, the interop project is not ideal to discuss spec details. Each submission should have a complete specification and WPT tests. Spec changes themselves should be taken up with their respective working groups.

[nmn]

In any case, the interop project is not ideal to discuss spec details.

I submitted it as an investigation proposal, which doesn't need to have complete specs as I understand.

Expanding it to allow anything would make it less useful for colors by making it invalid at computed value time and it would also break back compat.

I understand what you mean, but this wouldn't be the case because I'm not asking for light-dark() to be any typed, but to be a generically typed function. It's type should be the same as the type of its two arguments.

So something like this:

background-color: light-dark(1px, 2px);

which is syntactically invalid today, should remain invalid even in the future. This would ensure that there is no breaking change and the function would only be more useful.

calc works similarly, so we already have prior art for a generically-typed function.

[romainmenke]

In any case, the interop project is not ideal to discuss spec details.

I submitted it as an investigation proposal, which doesn't need to have complete specs as I understand.

Sorry, I meant that this is fully specced already and that any proposed changes to that spec is probably better be discussed in that working group. This is already happening :)

https://github.com/w3c/csswg-drafts/issues/10577