- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 May 2024 17:33:25 +0000
- To: public-css-archive@w3.org
I was reminded about this when I came across https://noahliebman.net/2024/04/recursion-in-the-stylesheet/ . These are the lengths authors have to go to today to achieve this. After thinking about it some more, I don’t think overriding individual colors is something that should drive the design of this feature, and certainly not something that warrants complicating the base case. Authors can always override the individual colors used to generate the scale, and design systems can make sure to include enough extension points if they want to enable this. I think we should keep the MVP as simple as possible. This means: 1. A single function for picking the colors AND specifying the scale. Authors can abstract the scale away via CSS variables as they have been doing for `color-mix()`. Having two functions puts us in the awkward position of having to specify what `color-scale()` returns. 2. Syntax that mirrors gradients and color stop positions as closely as possible. As a design goal, you should be able to throw a color scale into a `linear-gradient(to right, ...)` and see exactly the same colors you’d get from the scale. Something like this: ``` <color-scale()> = color-scale ( at <percentage> <color-interpolation-method>?, <abstract-color-stop-list> ) <abstract-color-stop-list> = <abstract-color-stop> , [ <abstract-color-hint>? , <abstract-color-stop> ]# <abstract-color-stop> = <color> <percentage>{0,2} ``` Which would look like this: ```css --scale: in oklch, var(--color-green), var(--color-yellow) 40%, var(--color-orange) 60%, var(--color-red)); background: color-scale(at var(--progress) var(--scale)); ``` I’m in two minds about whether the position you are selecting should be part of the preamble like above, slash separated, or even a separate argument. One consideration is that while colors are possibly the most pressing need, length scales are also in wide usage ([example](https://open-props.style/#sizes)). Whatever syntax we come up with should be consistent across different types of scales. I think the syntax above does lend itself nicely to `calc-scale()` (except hints can't be allowed there as there's no way to tell if they are hints or actual arguments). -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10034#issuecomment-2123113355 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 May 2024 17:33:26 UTC