- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 19:17:40 +0000
- To: public-css-archive@w3.org
I'm sorry, I'm not sure I understand what most of these replies have to do with what I was saying. I suspect you're reading some additional stuff I didn't say into my post. > 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. In #9992 this seemed to be a relatively important part of the proposals for you. Why is it so much lower priority here? > I don't see why we'd bake the specific tint levels into the ramp. [...] I'm not sure what this entire paragraph is in reference to. > 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'm not sure how what I said in my most recent reply has any bearing on this. Can you elaborate on what problem you're seeing here? > 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. As I said, the end user being able to override a specific color choice from a design system's color scale seemed to be an important thing in your comments in #9992. What's different about this situation, where the color scale is encapsulated into a value rather than being implicit across multiple custom properties? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10034#issuecomment-1984255460 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 19:17:41 UTC