This is how standards get bloated.
This is how standards get bloated.
You can already do this using the space toggle technique:
:root { --dark: ; }
@media (prefers-color-scheme: dark) { --light: ; --dark:initial; }
.example { color: var(--light, #000) var(--dark, #fff); }
I wonder if custom functions might ever make their way to css.
@media (prefers-color-scheme: dark) { :root { --light: ; --dark:initial; } }
Missed the selector.
Yes, `light-dark()` is very specific in what it can do … but it’s not the end goal. The end goal is to have a generic function – something like `schemed-value()` – that can respond to a plentitude of `color-scheme` values and return more than just `<color>` values.
Reality is, though, that browsers don’t have support for custom `color-scheme` values (it’s explicitly forbidden in the spec, for now) [^1] and that CSS parsers need to know ahead of time what they are about to parse [^2].
By narrowing things down in feature scope, you can use this convenience method now, instead of needing to wait a few months/years until the rest is figured out.
Once `schemed-value()` becomes a thing, `light-dark()` can become syntactic sugar for it:
``` light-dark(<color>, <color>); = schemed-value(light <color>, dark <color>); ```
[^1]: https://drafts.csswg.org/css-color-adjust/#color-scheme-prop... [^2]: https://www.w3.org/TR/css-syntax-3/#parse-grammar
You could deliver the same convenience in a way that’s set up to be repurposable (fullcolor /rgcolorblind) or extensible (light / grey / dark / …n) with as little difference as choosing a more mindful name.