[css-color] Add a function to allow authors to specify colors reacting to `color-scheme`

[emilio]

Some UIs require rendering a light button in some places, but dark in another. It'd be nice if you could switch between these by using color-scheme, like you can with native widgets. However, right now there's no way to do this other than exclusively using system colors.

Chromium has -internal-light-dark(<light-color>, <dark-color>) for this. However color-scheme was designed a bit more generically than light / dark, so maybe we need a schemed-color(<custom-ident> <color>, <fallback-color>) or so, where the <custom-ident> is the scheme name, and the <color> is the color for that scheme. So -internal-light-dark(red, blue) would become schemed-color(light red, blue) or so.

This would allow authors to create widgets that properly react to color-scheme.

[bramus]

Big fan of the -internal-light-dark() function here as well. Would make some things easier.

A few questions/remarks:

1. With the proposed schemed-color(<custom-ident> <color>, <fallback-color>), how would support for multiple schemes work?

   Do you suggest to nest schemed-color() – e.g. schemed-color(light red, schemed-color(dark blue, pink)) – or should we allow multiple entries by changing the syntax to schemed-color([<custom-ident> <color>]#, <fallback-color>)?

2. The suggested schemed-color only caters for colors, whereas light-dark() allows things other than colors. This seems pretty limiting. Can we open it up to have it return any value instead of a <color>? So the function would maybe become schemed-value()?

   I’m not an expert on CSS syntax, but I guess the syntax would then become this: schemed-value([<custom-ident> <declaration-value>]#, <declaration-value>)

   Anecdotally: The function in Chromium first was called -internal-light-dark-color() but then got renamed to -internal-light-dark()

3. Maybe light-dark() could be kept, and become a alias (limited to only two schemes) for schemed-color?

   Or if we should not want to pursue this, maybe we can leave it up to authors to define their own custom function once that becomes a thing?

4. With CSS Nesting – and potentially implicit & { } along with that – around the corner, this would become more easy for authors to do:

   1. No Nesting:

      el {
        --img: url(/img/bg-light.png);
        background: transparent var(--img) no-repeat 0 0;
      }
      
      @media (prefers-color-scheme: dark) {
        el {
          --img: url(/img/bg-dark.png);
        }
      }
      
      @media (prefers-color-scheme: other) {
        el {
          --img: url(/img/bg-other.png);
        }
      }

   2. With nesting:

      el {
        --img: url(/img/bg-light.png);
        background: transparent var(--img) no-repeat 0 0;
        
        @media (prefers-color-scheme: dark) {
          --img: url(/img/bg-dark.png);
        }
        
        @media (prefers-color-scheme: other) {
          --img: url(/img/bg-other.png);
        }
      }

   However, the nesting version doesn’t beat schemed-value() imo, so authors would still benefit from having such a function available:

   el {
     --img: schemed-value(
       dark url(/img/bg-dark.png),
       other url(/img/bg-other.png),
       url(/img/bg-light.png)
     );
     background: transparent var(--img) no-repeat 0 0;
   }

[emilio]

I propose to go for light-dark(<foo>, <bar>), then extend to schemed-color or schemed-value in the future, if needed?

I'd propose to do this for <color> (or <color> and <image>) for now, rather than everything.

[tabatkins]

lol, schemed-color() rules as a name. (But probably isn't what we want to go with. ^_^)

But given that we purposely designed color-scheme to be extensible for the future, we should do the same here. (But I think we can optimize too.)

I propose the grammar be <color>#{2} | [ <custom-ident> <color> ]#{2,} - the first branch is just light and dark, the second lets you name the color schemes you want to associate it with.

[mirisuzanne]

In many cases, authors would want to toggle a single channel value (e.g. lightness) within a color. They can do that by repeating the entire color - but allowing <number>/<length> sure would simplify that use-case.

[tabatkins]

We need to either know the value type ahead of time, or lean on var() semantics. So we could do the schemed-color() / schemed-value() distinction that Bramus suggests, with the two behaviors.

[emilio]

In many cases, authors would want to toggle a single channel value (e.g. lightness) within a color. They can do that by repeating the entire color - but allowing <number>/<length> sure would simplify that use-case.

Yeah I didn't want to open this to arbitrary lengths and such because that adds a bunch of new property dependencies that I haven't thought through... Though using var() semantics probably works for that case?