- From: Travis Spomer via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Feb 2022 03:22:25 +0000
- To: public-design-tokens-log@w3.org
Omitting details like the type of gradient doesn't make much sense to me. A reasonable expectation is that for any given token, a design tool has everything it needs to display that gradient (like a Figma style), and a dev tool has everything it needs to turn that token definition into code. The current gradient spec doesn't work for either case. As it stands, I'm not really sure how I could use a gradient token for anything at all, without encoding all of the missing information as extensions. At absolute minimum, I think that a gradient token needs to also include: * The type of gradient * The start and end points (0-1) It would also be unfortunate if gradient stops were limited to specifying stops as a number 0-1. Other systems also allow stops to be defined as absolute units. For example, you might specify a gradient as going from black at 0, to transparent at 10px, to transparent at 1—that would get you a "poor man's shadow" that was always 10px wide no matter the size of the object you paint with it. That's admittedly a less common case, but it's something that I'm using today to support web and WinUI, and to continue supporting it I'd need to add an extension property like `"actuallyTheseAreTheRealGradientStops": [ 0, "10px", 1 ]`. -- GitHub Notification of comment by TravisSpomer Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/101#issuecomment-1039812020 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 February 2022 03:22:27 UTC