Re: [community-group] [RFC] Format specification (#1)

I would imagine simply allowing anyone to use any function within the tokens as (likely) an external library/source. I have doubts about standardizing specific functions within the token spec. For color in particular, you’re not only defining functions based of specific properties within a variety of color spaces and modes, but then this almost implies a full color library would have to be implemented as part of the spec just to be able to have a consistent set of standard functions. That sounds like boiling the ocean. What is more reasonable in my mind is to say tokens can be written using external functions, such that a token value is returned from the function prior to implementation in components. For example, this could be done using build scripts. 

I second @calebdwilliams recommendation. Deprecation is a big hurdle and at least incorporating basic statuses for tokens such as “experimental”, “stable”, and “deprecated” would be very useful. In terms of “what does deprecated mean?”, well it means don’t use it any more. Leave it to individual teams to decide if that means they will version or follow certain processes. We don’t need to standardize release/versioning/process in here but I do believe status is very important. To that affect, it is helpful to have a reference when deprecating tokens. We always output `tokenA is deprecated; use tokenB` to ensure we offer actionable information. Perhaps that type of message could just be an updated description, however.



-- 
GitHub Notification of comment by NateBaldwinDesign
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/1#issuecomment-580471608 using your GitHub account

Received on Thursday, 30 January 2020 21:37:03 UTC