[community-group] Pull Request: Proposal: changes to type: $dimension and type: $duration tokens

drwpow has just submitted a new pull request for https://github.com/design-tokens/community-group:

== Proposal: changes to type: $dimension and type: $duration tokens ==
## Summary

This proposes the following changes to `$type: dimension` and `$type: duration` tokens, which have the same designs:

- Changes `$value` from a string to an object with `value` and `unit` keys
- Removes restrictions on what `unit` can/can’t be

## Reasoning

This addresses the following discussions/decisions in the following ways:

- #121: ✅ **Accepted**
- #218: ❌ **Rejected**

## Pros

- Simplifies tooling because these token types would no longer need string parsing (which could potentially introduce bugs))
  - Other types like shadows and borders already split their values into an object with keys
  - This makes the token type “less CSS-like” by removing the need for parsing
- Reduces errors in output.
  - For example, if someone was exporting dimension tokens to `.js`, they could normalize everything to `px` and just output numbers (which is the default behavior of JS styling). Tooling wouldn’t have to try and parse the string for the number, potentially introducing bugs.
- Simplifies validation because string pattern matching is no longer required
  - Validation is now as simple as checking for the object wrapper, both keys, and both keys match their expected primitive types.
- Loosening the restriction on dimension `$value.unit` results in a more flexible, evergreen design that works for everyone.
  - For example, consumers may want to declare typography tokens in `pt` units, or screen sizes in `dp` units
  - If consumers only need a singular unit in their tokens, their needs are still covered. If consumers need multiple units, their needs are covered too. Nobody is left out.

## Cons

- Objects are more verbose to type
- Not validating dimension `$value.unit` is a tradeoff for tooling—it lets each tooling make individual decisions on which dimensions it does/doesn’t support.

## Alternatives 

- We could keep a limited set of values for `unit`. But based on current opinion in issues, I’d recommend expanding the allowed list to a wider set ([do a quick search for all units mentioned in #218](https://github.com/design-tokens/community-group/issues/218#issuecomment-1664402517)).
- We could accept #218, and downconvert all dimensions into `px` values and durations into `ms`. But this would break many setups in tokens (chiefly, web—`rem`s and `px` are distinct values with different uses, and based on implementation, aren’t always mathematically-equivalent).
  - We could also split the difference, and keep the object for dimensions, and just number for duration (standardizing on milliseconds only). That’s just “syntactic sugar” anyway.

## Notes

- The original proposal had `$value.number` instead of `$value.value`, possibly to reduce duplication but I didn’t find a rationale. This changes to `value` because that’s a more common nomenclature for this term, e.g. `csstree`: 

  ![CleanShot 2024-08-16 at 16 48 08@2x](https://github.com/user-attachments/assets/782d9438-fbc1-4a01-9922-df15bda5d871)

- Duration tokens still have their limitation to `"ms"` / `"s"` because unlike units, those are universal, scientific units of measurement that aren’t dependent on user preference, technology, or platform (in other words, digital dimensions are imaginary in some sense and open to interpretation whereas durations are the same whether digital or “physical”).

See https://github.com/design-tokens/community-group/pull/244


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

Received on Friday, 16 August 2024 23:10:06 UTC