Re: [community-group] Dimension type expanded unit types (#245)

> [@brettdorrans](https://github.com/brettdorrans) That won't work in practice because the CSS unit list isn't something that works cross platform. Not all CSS units can be "transpiled" to something that makes sense in iOS, Android, ...
> 
> While I agree in principle that more units should be adopted I don't think that allowing anything is a good design.
> 
> Please re-read all my comments in this thread :)

Hey @romainmenke thanks for the reply! I guess this may be a difference in opinion (I'm aware I lack full historical context, apologies). From my perspective, this is not the domain of the spec itself, but tooling. The spec should advise on units, but is not concerned with how tooling converts between units. That is outside the scope, in my view.  The spec should be neutral on this.

> 
> The issue at hand is not about allowing or disallowing specific units or even about keeping the list of adopted units small.
> 
> It is about keeping the list defined locally or instead allowing any units.
> 
> > For $type: "dimension" tokens, define $value as a dimension: a number followed immediately by a unit string. The unit MAY be any valid CSS unit (as defined by the CSS Values and Units Module [w3.org](https://www.w3.org/TR/css-values-4/#:~:text=6,pc%20%2C%20px%20units)) or any other string. If an unfamiliar unit is used, tools MAY issue a warning but MUST NOT reject the file.
> 
> That is separate from this issue.
> 
> See:
> 
> * [Proposal: changes to type: $dimension and type: $duration tokens #244](https://github.com/design-tokens/community-group/pull/244)
> * [Split units and values in type definitions #121](https://github.com/design-tokens/community-group/issues/121)
> 
> > Remove or make optional any vendor field. Vendors can still use prefixes if they wish, but nothing in the carrier format should require it.
> 
> I don't really understand this point. What is the benefit to allowing any tool vendor to allowing their own units, thereby poisoning the well for everyone. Please remember [smooshgate](https://developer.chrome.com/blog/smooshgate)

I am preparing some concrete examples of this, and to avoid derailing this topic, will present separately.

-- 
GitHub Notification of comment by brettdorrans
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/245#issuecomment-3291013243 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 15 September 2025 08:28:00 UTC