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

> I don't see why that's the case, since we're discussing this in the context of spec-defined types like dimension, duration, etc.

> A hex code, which is a string that always starts with a # followed by 3,4,6, or 8 alphanumeric characters 0-9,a-f, A-F.

What if you want to express a string value that starts with `#` ?

I think this rule already is an oversimplification.
The hex color value parsing should only come into play once `"$type": "color"` has been determined.
In any other type it would just be a string literal and invalid (in the current specification).

> A string that starts with a non-numeric character and contains any numeric- or non-numeric character afterwards (ie, a string like "bold")

Ok

> A string that starts with numeric characters and contains only numeric characters and/or a single decimal (ie a string that can be cast into a float or int, like "500")

Negative numbers?
`-10` ?


What if a string literal starts with a number?
`"10 horses"`
Is this a parse error or a string value?


How do I express string literals that contain only numbers?
`"10"` but must be processed in translation tools as a string value, not a number.

-----------

> Do you foresee this causing any problems?

I think the main issue is vagueness.
Limiting the number type to make parsing easier doesn't really make it easier in practice.

I can just pass `123e3` to something like `parseFloat` in JavaScript and get the intended result. But if the specification does not allow scientific notation then I must also intercept and error on any values with scientific notation.

`123e3px` doesn't go away by not allowing it.
Implementations now need to intercept it and mark tokens as invalid.

There are only two options :
- go for a structured format like I propose here and use the transform format fully
- write a detailed specification for all possible values

A detailed specification includes error handling.


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


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

Received on Friday, 9 December 2022 18:21:47 UTC