It makes me so angry that they named the CSS function `light-dark` instead of leaving the door open to allowing generic user- or site-specified color schemes. I mean it was right there in all the other mechanisms around this feature, they just had to read and think about why these are structured the way they are, and why "light" and "dark" were always values and not keywords in all of these..:

    - <meta name="color-scheme" content="light dark">
    
    - :root { color-scheme: light dark }

    - @media (prefers-color-scheme: dark) { }

    - <picture><source media="(prefers-color-scheme: dark)">

Did they not look at the prior art and notice that "one of these things is not like the other?" All the other pieces of this puzzle, conceivably, could have one day had something like `:root { color-scheme: halloween }` or `@media (prefers-color-scheme: supercontrast)` but no, we're just going to cement `light-dark()` as the only two possible color schemes we'd ever want to switch between forever.

I’m not sure what kind of function you’re asking for that would support arbitrary user-defined themes. With the if() function and/or @function declarations you could build pretty much any system you want for defining theme-specific values for arbitrary themes.

Color schemes (luminance modes) and color themes (aesthetic styles) are not the same thing. Halloween theme can have light and dark schemes.

Also, prefers-contrast media query exists, which can be used in combination with the luminance modes (color-scheme): halloween-light, halloween-dark, halloween-light-high-contrast, halloween-dark-high-contrast.

https://news.ycombinator.com/item?id=47832705

It’s always irked me that light and dark are given privileged positions in the namespace. They’re just themes (or schemes if you like), like all the other possible themes.

Web standards are discussed in the open aren't they? I'll see if I can find what reasoning lead to this.