Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are references generally allowed in arrays? #241

Open
lukasoppermann opened this issue Aug 15, 2024 · 1 comment
Open

Are references generally allowed in arrays? #241

lukasoppermann opened this issue Aug 15, 2024 · 1 comment

Comments

@lukasoppermann
Copy link
Contributor

Hey,

so object stroke styles allow references in the dashArray (see https://design-tokens.github.io/community-group/format/#object-value). However, in cubicBeziers, this is not mentioned and also not in the fontFamily array.

I feel this should be clarified in the docs. Either by allowing it, or by defining that references are not allowed for those cases. However, I am wondering why this should be allowed for the dashArray but not other arrays.

@drwpow
Copy link
Contributor

drwpow commented Aug 15, 2024

As I understand it, it’s the difference from a primitive type (8.x) vs a composite type (9.x). Primitive types may only alias to their own types. A composite type is made up of multiple primitives, and can either alias to their own type, or alias any of their individual parts (more info). I think cubicBezier and fontFamily were considered a primitive type because they get referenced within composite types (transition and typography, respectively).

My guess is it was considered too complicated to nest number aliases within a cubicBezier within a transition token. But I don’t know that was ever expressed as a concern. Also I’m going off memory, but I think the cubicBezier type predates numbers, which weren’t originally unique token types (which would explain why they don’t allow aliasing). All that said, I think as-written if a cubicBezier could have internal aliases then it would be reclassified as a composite type (9.x). But would that be bad? I personally don’t know of any downsides. Just seems like it would add more utility, like you said. Also, currently composite types can contain nested composite types, as in the case of border being able to alias nested strokeStyle tokens (both of which are composite types).

I also don’t have full context of why there’s a distinction between primitive and composite types, also; someone else may be able to answer that better. As long as we’re not allowing aliases absolutely everywhere (aliasing part of IDs or substrings would be chaotic IMO), I don’t have any downsides off the top of my head of allowing aliases wherever they seem reasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants