[Checkbox, Radio, Switch] Change default color, add color prop

[mbrookes]

Closes #4706

Breaking change

The Material Design specification says that selection controls elements should use the application's secondary color.

-<Checkbox />
-<Switch />
-<Radio />
+<Checkbox color="primary" />
+<Switch color="primary" />
+<Radio color="primary" />

[oliviertassinari]

@mbrookes What about applying #9742 (comment) here and everywhere else?

• Benchmarking what Bootstrap is doing, I have noticed that they use a specificity of 1 for a variant and increase it to 2 for a variant modifier (disabled, hover, focus, checked, etc). I think it's smart. It can make the override of our components simpler.
• Same story on Ant design side.

[mbrookes]

Sure, I'll do it here. Doing it everywhere else is for another PR! 😰

[oliviertassinari]

Doing it everywhere else is for another PR!

@mbrookes Yes, it's! What's important is to decide on the CSS specificity approach.

[mbrookes]

@oliviertassinari Done.

[oliviertassinari]

This is a pilot toward solving #10010 and #9742 at scale. It's inspired by the Bootstrap approach to write CSS. Basically, it's following two rules:

1. A variant has a one level specificity. People override can be considered a variant. So we can keep things as simple as possible.
2. We increase the specificity for a variant modifier. We already have to do it for the pseudo-classes (:hover, :focus, etc.). It's allowing much more control at the cost of an extra complexity. Hopefully, it's making it more intuitive to our users.

const styles = {
  root: {
    color: green[600],
    '&$checked': {
      color: green[500],
    },
  },
  checked: {},
};

[mbrookes]

@oliviertassinari It doesn't look like you started with the latest version of this PR, as we have lost some of the docs changes. I can force push to my branch so you can rebase your commit.

[mbrookes]

Alternatively we can omit the specificity change in my last commit (leaving the docs changes), merge this PR, and you can submit a separate PR for the specificity pilot. (What we should probably have done in the first place.)

[oliviertassinari]

@mbrookes I'm sorry If I have lost some changes you did. Yes, please submit them back :).

merge this PR, and you can submit a separate PR for the specificity pilot. (What we should probably have done in the first place.)

So the plan is to limit the scope of this pull-request to the selection control color breaking change and I will push the specificity change in another pull-request targeting the tabs and the selection control components? (I don't want to touch the button before @nathanmarks effort on this component)
Sounds good to me.

[mbrookes]

Okay, I've removed the specificity change from the last commit & force pushed.

I know you had added an unlabelled Checkboxes example in one of your commits, but I'd had the opposite thought, as the unlabelled radios & switches don't really make much sense. I"m not sure what the anticipated use case might be; in a table perhaps? If so, that's probably what the demo should show. As for the unlabelled switches example, that contradicts the text before it:

"The option that the switch controls, as well as the state it’s in, should be made clear from the corresponding inline label."

[oliviertassinari]

as the unlabelled radios & switches don't really make much sense

@mbrookes No it doesn't. But I think it's too much assumption that people are going to use our label helper. For instance, Open Collective isn't. Better showing them the simplest example possible first (unlabeled).

[mbrookes]

In that case the ordering of the examples as it is for Radio makes most sense, with the unlabelled selection control being a minimal example. I'd still prefer to see them in the context of a use-case, but it isn't a priority.

[gabrielliwerant]

@mbrookes Just curious, but if the spec says to use the secondary color, why is it being set to the primary color?

[oliviertassinari]

@gabrielliwerant The diff shows the upgrade path to keep the previous behavior. But if you are happy with the change. No need to do anything.