- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 00:19:32 +0000
- To: public-css-archive@w3.org
As I wrote in [my reply today](https://github.com/w3c/csswg-drafts/issues/9992#issuecomment-1981379030): - Wrt overridding the interpolation, there are two use cases here: - The design system _author_ doing the overriding, e.g. to make darker yellows orangish, to spread out lighter tints etc. I think that's the bigger use case around overriding, and an inline function caters to that just fine, as it's defined by the design system author. - The design system _user_ doing the overriding, e.g. the red 900 tint is too dark for my liking, I’ll make it a bit lighter. That is far lower priority. - I don't see why we'd bake the specific tint levels into the ramp. I think one of the advantages of a rank primitive is to abstract the naming scheme away, and `progress()` makes it easy to apply it externally. I think that's more of a nice to have, and not that important to address. It also seems to be introducing a new alternative color stop syntax, when we already have a color stop syntax for exactly this very thing, which also means it's much harder to generate a gradient from the color scale (either as actual output, or for debugging) - From experience, having to adjust the other colors when inserting a color is *incredibly annoying* and one of the things I was trying to avoid with this proposal. - I do agree that having to match the exact percentage by precision is annoying, but we should not let complex cases get in the way of common ones. We can continue to discuss how to best design a syntax that allows overriding without this problem. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10034#issuecomment-1982094912 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 March 2024 00:19:33 UTC