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

Custom Types / Interpritations #233

Open
tryoxiss opened this issue Dec 11, 2023 · 2 comments
Open

Custom Types / Interpritations #233

tryoxiss opened this issue Dec 11, 2023 · 2 comments

Comments

@tryoxiss
Copy link

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)
@danosek
Copy link

danosek commented May 30, 2024

  • There is fontWeight in the latest draft
  • I think radius is dimension type
  • 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?

@tryoxiss
Copy link
Author

  • There is fontWeight in the latest draft

    • I think radius is dimension type

    • 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.

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