Default group values

[Mike Engel]

There's a lot of (stale) discussion in design-tokens/community-group#97 (in which you contributed early on!), but it seems like the proposal from c1rrus is a pretty clear path forward and avoids name conflicts.

I know you don't want to stray too far from the spec, especially if things could change, but I wanted to see how open you would be to adding a $default key for allowing tokens defined at the group level?

This input would translate to js as:

{
  "accent": {
    "$default": {
      "$value": "{colors.purple.700}"
    },
    "weak": {
      "$value": "{colors.purple.300}"
    }
  }
}

export const tokens = {
  'accent': '#5721CC',
  'accent.weak': '#BA9CFF',
};

[Drew Powers]

Oh I see. I’m not opposed to the idea, but I think it could have some interesting side-effects, like it could conflict with nested tokens (#79)—you just wouldn’t see the default values in certain outputs.

But overall no strong reason to not think about including this. Yes, I don’t want to stray too far from the spec, but also I can’t think of any other possible future usage of $default other than the use you’re describing. That’s opposed to mode, that I felt was safer to scope under $extensions because I foresaw a pretty high likelihood of $mode, if it were ever implemented, being different from a syntax I guessed at.

[Mike Engel]

Hmm yeah, that's a good point about nested tokens 🤔 I suppose the alternative there is to create a default key in the token object. I'd be curious to hear if you have alternative thoughts on default values for groups

[Drew Powers]

I’d be interested to explore if your usecase is actually a composite token in disguise, or if it’s just a naming problem.

For example, in some semantic naming systems (like Asana’s) they just commit to using default as the “non-word” (e.g. color-success-default / color-success-hover / color-success-active / color-success-disabled). So it’s not really a hierarchy per se—these are all sibling values—it’s just a matter of terminology.

Or, perhaps there is some inherent relationship between your default value and the other tokens in this group. For example, a gradient is a composite collection of colors that must be consumed in a way that produces intermediary values between a “start” color, an “end” color, and potentially other colors in-between. Just saying that there are some things that transcend a mere “group” into needing more metadata that describe them as one cohesive unit that is universally understood. Is that the case?

Just thinking out loud, this may be why “default” values for groups are slippery terms—if there’s a clear way to “hold it wrong” for a group, then maybe that needs to be some composite type of token (even if it only exists in your DS—the spec allows for custom types). But if the group is flexible / open-ended, and there just needs to be an “other” value, then that may just be a matter of guidelines imposed that are outlined somewhere else other than the tokens schema (again, using Asana’s system as one example)

[Mike Engel]

Yeah, we're essentially replicating asana's system here with sentiment-usage-prominence-interaction. If we think about a button, here are some sample tokens that we have without default group values:

• default-background-default-default
• default-background-strong-default
• default-background-strong-hover
• accent-background-default-default
• error-background-default-default

and so on. It's all doable with what's currently supported in cobalt now, but it would be nicer if we could erase all the defaults to have something like this (which I think asana also does):

• background
• background-strong
• background-strong-hover
• accent-background
• error-background

We could of course write a transform or custom plugin for this, or abstract this within the consuming code, but it's always nice to have this close as close to the spec/source as possible 😄