Final revisions before next draft

[kevinmpowell]

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

[c1rrus]

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

[kevinmpowell]

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

[c1rrus]

Cool, thanks

[c1rrus]

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]

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]

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]

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]

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