Populate alpha 'Button' tokens

[oliverHPE]

Populate tokens for buttons:

Types

• [x] Default
• [x] Primary
• [x] Secondary
• [x] Toolbar

Sizes

• [x] Small
• [x] Medium
• [x] Large
• [x] Xlarge

[taysea]

@oliverHPE I believe these have all been populated except the "selected" state is just one level -- it doesn't reflect the complex "selected.enabled", "selected.hover", ...

[oliverHPE]

@taysea correct me if I'm wrong, but buttons don't have that styling or behaviour right now - for example, there is no selected.hover. It's either selected or not selected. The components that have the more complex state levels are radio buttons, checkboxes and switches for example. On those we have examples like the one's you're describing - checkbox.control.selected.enabled.background.

[taysea]

Correct, we don't have it but wasn't sure if we should still have a consistent structure. So something like:

selected.enabled.background as opposed to currently we just have selected.background.

small beans for alpha learnings so don't want to get too hung up on it, but just a small question for consistency.

[oliverHPE]

I see. To be safe, we could go with the full name button.primary.selected.enabled.background. This route means we could:

1. Introduce more substates easily, e.g. a selected.hover - button.primary.selected.hover.background
2. It's consistent with other components with a selected state

The cons being

1. It's longer
2. Is it necessary on components that we can assume will never have these complex state scenarios? For example, will a selected tab have a selected.hover in the future?

Given that we can't predict this, going with the full name could be worth it.

[taysea]

Good to have these pros/cons documented. Let's go with the "full name" for alpha. And for now, just have "selected.enabled" for button.

Can adjust based on any feedback we get as we test.

[oliverHPE]

@taysea have gone through and updated button tokens. Would you please give it a once over.