- From: David Leger via GitHub <noreply@w3.org>
- Date: Tue, 21 Oct 2025 00:36:12 +0000
- To: public-design-tokens-log@w3.org
While this is an older issue, just wanted to share an update and some thoughts around this since I think the spec has evolved a fair bit since this issue was raised which. are relevant to this proposal. The most recent draft (19 Oct, 2025) for the format spec gives some more specific guidance on types and how they relate to aliases: https://www.designtokens.org/tr/drafts/format/#types I think it's becoming clearer that we either need to: 1. Inherit the `$type` from the alias. 2. Validate that the defined `$type` matches the alias. If we just define the `$type` as `"alias"` then we're explicitly deciding that the `$type` should be inherited. (maybe that's a valid use case for an `"alias"` type?) However, since aliases can be referenced as parts of another token, there are places where we can't specify `$type: "alias"`, which might make it less useful. For example: ```jsonc { "thick-border": { "$type": "border", "$value": { "color": "{primary}", // must be a color token "width": { "value": "{base.border.thickness.px}", // must be a number token "unit": "px" }, "style": "solid" } } } ``` So while an `"alias"` type would help in some cases, I think interpreting aliases as a valid value for _any_ token type, and using `$type` to narrow down which tokens are valid aliases, makes a bit more sense in context with the most recent spec draft. -- GitHub Notification of comment by davejsdev Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/214#issuecomment-3424242033 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 October 2025 00:36:13 UTC