- From: Nicolaos Skimas via GitHub <sysbot+gh@w3.org>
- Date: Sun, 25 Aug 2024 22:50:06 +0000
- To: public-design-tokens-log@w3.org
@romainmenke thank you for the more in depth explanation. > No the vendor property is only meant to be used as an escape hatch. The spec should cover all commonly needed units. How do you define a commonly needed unit? Are the spec authors open to standardizing platform specific units? My understanding was that there was a desire to keep the spec mostly platform agnostic. Additionally, this explanation makes it sound like option 3 in @drwpow's original post is not so much its own distinct option, rather its an additional detail that could be paired with option 1 or 2. It might be helpful to update that list for clarity. > 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. > Ideally this never happens and every vendor always goes through the standards process. > 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. I think you just outlined many of the reasons why browser's have moved away from using [vendor prefixes](https://css-tricks.com/is-vendor-prefixing-dead/) for prototype implementations of new CSS features. "Nothing is more permanent than a temporary solution" as the saying goes. If the spec designate a new `vendor` property as _the way_ to prototype new units, I think there's a good chance it ends up getting used a lot. CSS spec implementers have solved this issue by shipping new implementations behind features flags in the end user environment (browsers). That approach works because CSS parsers are forgiving, they ignore lines they don't understand rather than throwing an error. I think a similar approach would be a better way to address prototype/pre-spec implementations. The spec can allow parsers/transformers to ignore invalid tokens. If a vendor wants to add a unit that isn't in the spec yet, they just use it in the `unit` property as if it was valid and then end users can use a plugin or custom transform (perhaps written by the vendor) in the parser to handle it. -- GitHub Notification of comment by dev-nicolaos Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/245#issuecomment-2309025448 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 22:50:07 UTC