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

Great points on the parsing algorithm. I think any recommendation by the spec here would be non-normative, but it's good to see how different strategies to parsing apply.

Our microformat definition could be as simple as "A string containing a number (defined by JSON's `number` type) followed by a unit (defined by a list of valid units). The number and unit can not be separated by a space."

Then, implementers can use whatever parsing algorithm they want.

To state the issues:

1. You have to know whether or not a value is a number and unit tuple in order to correctly parse it
The spec has to define which token types can and can't be a number+unit tuple, so a parser can use this information to avoid incorrectly parsing. In fact, it might be interesting to explore the possibility of defining `dimension` and `duration` as ALWAYS being a number+unit tuple, which removes a lot of ambiguity.

2. You have to check the unit against known/defined units
The spec currently takes the approach of defining valid units, so that list is normative. Even if we split units out, the parser still needs to check the unit against the list to validate the token.

3. Composite tokens require additional algorithms
This is something that I think necessitates a separate thread, as I'm seeing a lot of potential problems with our current approach to implicitly typing the values of a composite token. If the values of a composite token were explicitly typed, this issue is no a concern.

---

So, if the spec is written so that the first type of algorithm can work for all cases, and as you said it's "simple to implement," then it seems like it might be a viable way to enable authors to write number+unit strings instead of breaking them out.

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


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

Received on Monday, 12 December 2022 16:31:43 UTC