- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Nov 2023 23:20:06 +0000
- To: public-css-archive@w3.org
Hm, we should be clearer on the exact use-case here. The only effect of color-scheme is to change the system color keywords; if you're changing all of the colors to your own chosen set of colors, you can just use your own color custom properties instead. But it does seem like there are two reasonable arguments to make here: 1. While you *can* use your own colors, you then have to manually set all the existing system color usages to instead use your color variables. And you have to keep that up to date as we add more controls, or more system colors. Letting you set the system colors directly means you can skip a big block of selectors setting those colors. 2. The Web Preference API can potentially persist this. Especially if #2 comes to pass, this does seem pretty useful. Design-wise, hm, we'll need to make sure that it's compatible with us adding more system color keywords in the future. I propose we require you to specify a "base" color-scheme (one of the already-defined ones; no particular need to do a full inheritance chain here), and then you can override any or all of the color keywords; any you don't override get taken from the base. So, like: ``` @color-scheme --solarized-dark { base-scheme: dark; CanvasColor: #002b36; CanvasText: #93a1a1; AccentColor: #6c71c4; } html { color-scheme: --solarized-dark; } ``` This would override the "main" colors (text and background) used by everything (page background, inputs, etc), but take any remaining colors from the standard `dark` scheme. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9660#issuecomment-1834713634 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 November 2023 23:20:09 UTC