Matt Ström-Awn

My feeling here is that `type` is not relevant for aliases, since we haven't seen a case for re-typing tokens (see #189). So, either: 1. Alias tokens should NOT have...

> If a token is a composite token then the fields have implicit types anyway. Yes, this is an issue that I think we need to dig into in a...

@equinusocio I want to acknowledge that while the principles of design tokens you shared are good principles, they aren't in the current definition of this specification, so it's hard to...

> `link-color` violates the first principle if considered as token, but it doesn't if is considered as theme-key. Just to be super clear, the `link-color` example was meant as a...

Like @PavelLaptev suggested, it's worth asking: should this be the job of the token parser (and by extension the concern of the token format), or should it be the responsibility...

The genesis of this question came from another question: how should we define the typography composite token (#102) ? It seems like there's general consensus around having an "open" definition,...

Definitely agree that we need a type that passes through a string of text, for all sorts of string-y values, not just CSS keywords. I'd want to broaden the type...

> This issue is not about string values, it is about keywords Yes, sorry, I was using "string" to mean "a piece of text". I think many use cases can...

If transformations are specified within tokens.json, there will always need to be another specified format that is the result of applying those transformations; it's really important to define the end-of-the-line...

The spec lists out the following resolution order: > A token's type can be specified by the optional $type property. If the $type property is not set on a token,...