Re: [community-group] Split units and values in type definitions (#121)

>  this proposal smells of over-engineering

no, it is the opposite :)

This proposal aims to use what is already there in JSON, what is freely and readily available in the underlying tech.
It doesn't require any further spec work or work on the side of implementations.

Not splitting units and values into separate fields however might very well lead to over-engineering:
- need to define or reference a spec for numbers
- need to define or reference a spec for units (is `px2` a valid unit?, it is in CSS at the tokenizing, parsing level)
- need to define general parsing guidelines

This proposal is to "under-engineer" the dimension type.

--------

I can understand and sympathize that an extra object that is **visibly** present in a tokens file is perceived as extra complexity.

At the end of the day what I truly find important is that this specification is precise and exact and doesn't leave room for implementors to make the wrong assumptions.

If this is done with a strict number, unit and parsing definitions, fine by me, but this is work that needs to be done.

It can't be assumed that it is obvious how to parse `10px` into `10` and `px` because people will not consider all the edge cases and will create subtly different implementations. Each meaningfully different implementation will cause friction in the ecosystem and places future constraints on this spec.

Separating units and numbers adds perceived complexity but reduces very real implementation complexity.


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


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

Received on Tuesday, 10 September 2024 06:57:49 UTC