Re: [community-group] Group & file level properties (#72)

Thanks for the summary @c1rrus 

> 1. Is it OK for some group properties to be inherited by child tokens (e.g. type) and others apply to the group itself (e.g. description)

I vote "yes", this is okay. I think we can outline this in the spec when we define group properties and denote whether or not each property is inheritable. In my mind it's similar to whether or not javascript events bubble (though that's going from child -> parent).

 > 2. Is it OK for groups to have properties that are inherited by child tokens at all?
Concerns have been raised that this might make the format harder to understand and/or parse. Also diffing could become tricky in some situations as the same information could be written in several ways.

Since one of the key principles of the format is that it be human readable and _editable_ then I think we have to keep the ability for some group properties to be inheritable. 

> 3. Assuming we want groups to be able to set a default type for tokens within that do not set their own explicit type, should we name that group propert something other than type to avoid confusion? (childrenType, tokenProperties.type and contains have all been proposed as alternatives)

I prefer the simplicity of `type` so the key name is the same whether it's at the group or token level. If we changed it to `childType`, `contains`, `defaultType` or something else, it'd still mean the same thing. There's not a separate concept of a `type` at the group level that we need to deconflict with.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 3 January 2022 16:31:27 UTC