- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Sun, 25 Aug 2024 21:52:21 +0000
- To: public-design-tokens-log@w3.org
No the `vendor` property is only meant to be used as an escape hatch. The spec should cover all commonly needed units. ------ If a vendor is prototyping a new unit and wants to already start using this in token files, then they can create their own `unit` value and denote it with their name in the `vendor` property. This allows tool creators to ship features without needing to wait for the standard to catch up. But also without causing naming conflicts with other tools or the spec itself. We don't want multiple vendors coming up with multiple different definitions for `x`. Ideally this never happens and every vendor always goes through the standards process. But this severely limits what can be tried in the field in a short time frame. Even if a vendor starts prototyping while going through the standards process it is still prudent to use the `vendor` annotation. Maybe the unit name changes based on feedback from others in the community group. ---- Alternatively a vendor might have a unit that only makes sense in their ecosystem. They might still want to expose it through token files, but it wouldn't make sense to standardize. I would strongly urge tools not to do this. But if it does happen, then it is better to have an annotation as to who "owns" this non-standard unit. ---- This has nothing to do with the platforms that values will be used on. A vendor might be `figma` or `meta`. But not `web` or `android` -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/245#issuecomment-2309007656 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 25 August 2024 21:52:22 UTC