- From: Nate Baldwin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jun 2022 00:51:04 +0000
- To: public-design-tokens-log@w3.org
I agree supporting other gradient types is necessary, but I am of the opinion it doesn't need to be a different token type itself. I would like a few things here: First, it would be nice to have a default inferred from a list of values. Ie, `values: [#ff0000, #0000ff]` will automatically infer placement to be [0,1]. Reason being, it may be unnecessary, bloat, or redundant based on certain use cases. My next ask will shed more light. Secondly, I would like the option to just pass an array of values. I go at great lengths to make perceptually balanced gradients, and given technological restrictions, most of the time an array of many values (spaced equidistant in the range) is the best way to replicate the gradient. For instance, if I have a gradient with 20 unique colors, it would be tedious to write all the intervals in the proposed format. Thirdly, it would be great to include an option for interpolation color space. Technology is working to catch up on this notion and certain design tools support it. For instance, defaulting to rgb interpolation is ok, however I may want to use OKLCH for a multi hue gradient. Interpolation color space options can reduce the number of individual color values needed to replicate a perceptually balanced gradient (within these examples) -- GitHub Notification of comment by NateBaldwinDesign Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/101#issuecomment-1155857829 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 June 2022 00:51:06 UTC