Re: [csswg-drafts] [css-color] Add a function to allow authors to specify colors reacting to `color-scheme` (#7561)

> As a very simple example, what happens when a site that uses this grows to the point where they need to add a high contrast mode? At that point this will require a refactor.

I've always thought of things like high-contrast as somewhat orthogonal to light/dark, for what is worth. Something can still be light or dark _and_ high-contrast.

For the record, I think `light-dark` is still pretty useful for high contrast. Think of the simple example:

```
:root {
  --text-color: light-dark(#ddd, #333);
  @media (prefers-contrast) {
    --text-color: light-dark(black, white);
  }
}
```

> The other element I'm concerned with here is it all but seals the deal that `color-scheme` will never grow beyond light|dark, despite custom identifiers being allowed for that field. What I'd much prefer is a solution that scales, rather than something that only helps one specific use case.

FWIW, my understanding is that `color-scheme` was never intended to provide custom theme capabilities like suggested above, but is a way to expose the browser's color-scheme support. It might be worth filing an issue to discuss that, if that's something people want.

> As a simple example, consider if it were implemented this way instead:
> 
> ```
> :root {
>   color-scheme: light dark high-contrast;
> }
> 
> body {
>   background: scheme(light #eee, dark #333, high-contrast #fff);
> }
> ```

As @bramus said, we did have this discussion. `light-dark` is still fairly useful regardless, and allows you to exploit the `color-scheme` property properly in the way the browser already does with system colors.

Anecdata, but in my experience with the Firefox front-end it's gotten quite a bit of adoption (see [uses](https://searchfox.org/mozilla-central/search?q=light-dark%28&path=&case=false&regexp=false)).

Firefox does support all sorts of themes, and that didn't make us not use this. Quite the opposite, it did simplify the theming setup quite a bit, from [icons](https://phabricator.services.mozilla.com/D190070), to [link colors](https://phabricator.services.mozilla.com/D188364), etc...

As soon as you have a complex enough theming setup, you need parts of the UI to be light and parts to be dark, and `light-dark` allows you to react to these like the browser does.

It seems you kinda want a more general theming mechanism than what the `color-scheme` property provides. And that's fair, maybe we should extend that property to not only expose built-in color schemes, or have a separate mechanism, or something. I encourage you to file an issue about it (with or without a proposal, that's ok). But FWIW I don't think that makes `light-dark()` here less useful (though I'm obviously somewhat biased).

I'm happy to hold off shipping `light-dark()` on Firefox if people thing it's fundamentally wrong, or a step in the wrong direction that would prevent us from doing something that we might want like extending `color-scheme` to support custom author-provided palettes, somehow, but I don't think it's the case.

-- 
GitHub Notification of comment by emilio
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7561#issuecomment-1755187074 using your GitHub account


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

Received on Tuesday, 10 October 2023 11:47:44 UTC