Final revisions before next draft

design-tokens / community-group

This is the official DTCG repository for the design tokens specification.

https://tr.designtokens.org

Other

1.56k stars 63 forks source link

Final revisions before next draft #108

Closed kevinmpowell closed 2 years ago

kevinmpowell commented 2 years ago

[x] camelCase consistency on all spec properties, values and sub-value names. Example: "cubic-bezier" should be "cubicBezier"
[x] Add clarification on group property inheritance ($type is inherited, $description is not)
[x] Round of review from all editors prior to publishing
[x] Update all format properties with a $ prefix. For example type becomes $type

c1rrus commented 2 years ago

I think we should also include an update to prefix all format properties with $ (e.g. type --> $type).

kevinmpowell commented 2 years ago

@c1rrus I've updated the main checklist to reflect that change.

c1rrus commented 2 years ago

Cool, thanks

c1rrus commented 2 years ago

I've opened PR #111 to take care of the $ prefix and camelCase stuff.

Re-reading the spec, I think it's already quite clear that, when set on a group, $type is inherited and $description is not. I'm not sure if we need to add any additional clarification.

drwpow commented 2 years ago

A general question/possible opportunity for clarification (also forgive me if this has been answered elsewhere): with #111, the $ prefix was added to groups to distinguish between group properties vs subgroups/tokens. And $ was added to tokens as well for parity (correct?).

In that case, does the spec allow any non-$ properties on tokens, or are those simply ignored? And if the latter are non-$ properties on tokens the recommended approach for arbitrary metadata?

(pending resolution of #97, which would obviously change this)

c1rrus commented 2 years ago

In that case, does the spec allow any non-$ properties on tokens, or are those simply ignored? And if the latter are non-$ properties on tokens the recommended approach for arbitrary metadata?

As it stands (and perhaps this should be clarified in the spec's wording), additional props on tokens are not allowed.

The $extensions property is the place where teams and tools can store additional, proprietary data associated with a token.

c1rrus commented 2 years ago

Add clarification on group property inheritance ($type is inherited, $description is not)

Editors' decision on 5. April: Will leave as is for now, but in later (working?) drafts we may re-arrange chapters and add more details about what properties apply to and whether or not they are inherited in a more standardised way.

c1rrus commented 2 years ago

All items in the todo list have now been addressed, so closing this issue.