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

The implicit language for grouping is what is a little confusing to me as I wrote my prototype. From my perspective, groups are the default type for any object, nested or otherwise, until an explicit type is defined. 

Let's look at one chunk of [the group types sample](https://github.com/design-tokens/community-group/blob/example-token-files/examples/04-group-types.json) as it's proposed today. 

```json
  "text-size": {
    "type": "dimension",

    "scale": {
      "0": {
        "value": "1rem"
      },
      "1": {
        "value": "1.25rem"
      },
      "2": {
        "value": "1.563rem"
      },
      "3": {
        "value": "1.953rem"
      }
    },

    "title": {
      "value": "{text-size.scale.3}"
    },
    "heading": {
      "value": "{text-size.scale.2}"
    },
    "body-copy": {
      "value": "{text-size.scale.0}"
    }
  },
```

This reads to me as "this token is not a group, it's a dimension". 

I'd like to propose something like...


```json
  "text-size": {
    "contains": "dimension",

    "scale": {
      "0": {
        "value": "1rem"
      },
      "1": {
        "value": "1.25rem"
      },
      "2": {
        "value": "1.563rem"
      },
      "3": {
        "value": "1.953rem"
      }
    },

    "title": {
      "value": "{text-size.scale.3}"
    },
    "heading": {
      "value": "{text-size.scale.2}"
    },
    "body-copy": {
      "value": "{text-size.scale.0}"
    }
  },
```

It may feel like this is a simple "change the language of `type` to be `groupType` in circumstances" sort of proposal, but I architect the tokens file as "`group` until otherwise denoted", therefore everything is a `group` ` type` until its overridden. Building a library of the groups that can be accessed later on for abstraction layers felt helpful, plus labeling the group with `contains` felt to be "logic" - i.e. everything within this group's type should inherit from the closest value of `contains`. Writing this proposal to avoid overloading the term "type" would seem to be quite helpful for implementors... correct me if I'm wrong too! My proposed modification helped me write more a more reasonable implementation, and craft formatting messages to give structured feedback that had felt reasonable for folks when working with this file during compilation. 

But yeah, even adding the ability to do `description` on a group felt inherently beneficial. 

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


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

Received on Monday, 1 November 2021 16:54:48 UTC