You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You say in what I believe to be the most recent version, that if no $type is set or it does not match one in the spec it should be ignored. If it dosent exist then thats fine, but it would be useful--borderline necesarly for .tokens.json to be a meaningful format--to define custom types. Especially since you explictly mention it being simillar to Java or Typesscript where custom types are a deeply core feature.
Maybe a syntax for defining them is too much, or maybe that would work (I don't fully know the goals or state of the project), but some way to allow for non-spec types while still being correct would be useful, such a "$type": "some-extention:color/hsl" for example).
Some examples of useful types which may not justify being in the spec but would be useful:
weight (e.g., for fonts)
radius (e.g., for borders, etc)
animations ( a composite type of all animation traits)
The text was updated successfully, but these errors were encountered:
Yes, if we have transition type, we need also animation
But it is interesting idea to have custom types. How would you define the type and how would you tell any design token tool, how to deal with it?
I imagine custom types using some sort of "prefix" to indicate it is nonstandard, perhaps a namespace (namespace:type). There would likely be some sort of property in the root document to declare what namespaces are being used, including links to the specifications of some types (in human language, like the design tokens spec is). When a program is asked to read the design tokens, it would return an error if it does not implement every namespace to the version specified.
The idea needs a bit of refining, but I stand by the fact that if made, this should be a standard which works just as well far from now as it does today, and we cannot anticipate every need.
You say in what I believe to be the most recent version, that if no
$type
is set or it does not match one in the spec it should be ignored. If it dosent exist then thats fine, but it would be useful--borderline necesarly for .tokens.json to be a meaningful format--to define custom types. Especially since you explictly mention it being simillar to Java or Typesscript where custom types are a deeply core feature.Maybe a syntax for defining them is too much, or maybe that would work (I don't fully know the goals or state of the project), but some way to allow for non-spec types while still being correct would be useful, such a
"$type": "some-extention:color/hsl"
for example).Some examples of useful types which may not justify being in the spec but would be useful:
The text was updated successfully, but these errors were encountered: