- From: Ryan Johnson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Oct 2023 01:01:48 +0000
- To: public-design-tokens-log@w3.org
> For consistency sake, having it always be an array makes most sense to me, though it could support both. Having both single object and array creates some added complexity for library maintainers when parsing it, but not too much imo. The internal parser I wrote for our design tokens just coerces every value into an array, regardless of token type. Doing this allows my translation logic to be more robust, because it can handle _any_ number of values that are thrown at it. The tricky part was figuring out how to resolve various configurations that contain aliases. The short answer is that we prohibit aliases that resolve to arrays, because it's unclear if you'd want to merge, concatenate, or nest arrays within arrays. By prohibiting aliases to array values, we can ensure that the resolved value of the parent token is always a 1-dimensional array of tokens. This deviation from the spec is acceptable to us because my team is the only one actually using the parser directly. Given that we're responsible for the _raw_ design tokens, we architect our design tokens to conform to the parser capabilities. If the parser logic is updated, we update our tokens, as needed. We use our own parser to generate various micro libraries that define platform-specific assets, which are then consumed by downstream projects to build out various UIs. Our internal stakeholders rarely (if ever) need to know the exact relationship between the tokens and parser. ----- With that aside... Theoretically, any token value _could_ be an array such that the first value would be the fallback default if a specific platform doesn't support an array of values. However, shadows are definitely one token type that I agree would benefit from being an array by default, because I can't think of a recent project I've worked on that only used a _single_ shadow value. -- GitHub Notification of comment by CITguy Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/100#issuecomment-1767430643 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 October 2023 01:01:50 UTC