- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jan 2022 23:50:49 +0000
- To: public-design-tokens-log@w3.org
(FYI: We've now ditched the `group.metadata` idea in favour of using a `$` prefix for our format-specific properties on groups and tokens.) Allowing the `$extensions` property on groups as well as tokens seems like a good idea to me - especially if tools like yours already have potential uses for that. As you've noted, the question to answer is whether it should be an inherited property or not. I'm tempted to say that it should _not_ be inherited - i.e. tokens and groups within a group that has `$extensions` should not be treated as though they themselves had the same `$extensions` property. `$extensions` is just a container where teams and/or tool vendors can add arbitrary data that has some special meaning to them. If the spec mandates that it is inherited like `$type` is, it would be imposing additional behaviour on anything people put inside `$extensions`. _However_, there's nothing stopping a tool from implementing some logic to make its own extensions behave like inherited properties. So rather than forcing all extensions to be inherited, my preference would be to say they're not. But tool vendors are welcome to implement their own inheritence behaviour for their own extensions if they wish. -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/106#issuecomment-1021717305 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 25 January 2022 23:50:53 UTC