Material-ui: Button disabled gets twice class Mui-disabled

[Elfayer]

When a Button is disabled, it gets twice the class Mui-disabled.

• [x] The issue is present in the latest release.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

There are two Mui-disabled class on a disabled Button.

Expected Behavior 🤔

Only one Mui-disabled class on a disabled Button.

Steps to Reproduce 🕹

https://material-ui.com/components/buttons/
Or: https://codesandbox.io/s/material-demo-mtk0k

Steps:

1. Inspect the disabled Button

Context 🔦

Doesn't affect behavior.

Your Environment 🌎

| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.9.2 |
| React | v16.12.0 |
| Browser | Version 78.0.3904.87 (Official Build) (64-bit) |
| TypeScript | 3.9.0 |

[eps1lon]

Kind of a general question I have about pseudo-class classnames @oliviertassinari.

If these are passed along to child components that also have these classes how are the styles reconciled?

[oliviertassinari]

I thought it was a duplicate but I can't find it.
What's the concern? We could be using a data-disabled attribute instead (reach ui way), it would work identically. The advantage of a class name is that developers can easily toggle it in the dev tools, close to the approach Bootstrap uses (50% of our users are coming from Bootstrap based on our last survey?), and the syntax is "lighter" when used it in a selector.

[eps1lon]

What's the concern?

ButtonBase declaring styles for disabled as well as Button. Since both have the same classname which styles are used?

[eps1lon]

and the syntax is "lighter" when used it in a selector.

I thought we didn't support this anyway since the classnames might get optimized in production?

[oliviertassinari]

.Mui-disabled is a global class name, it's meant to be used. The equivalent in Bootstrap is .disabled.
If we were using a data- attribute, we would get the merge happen seamlessly. We concanate the class names, so it behave differently for us. I'm not aware of any potential bug it can cause.

[eps1lon]

Right, we don't support styles in .disabled only .some-other-class.disabled.

I think this is fine. It's not worth spending time evaluating this at runtime to strip duplicate classnames unless there's an actual bug.

[Elfayer]

The mean of that report was about cleanness as there is no impact, there is just a duplicate class for no reason.

[xenostar]

Is there a reason this closed? This clearly isn't the intended behavior. There shouldn't be two .Mui-disabled classes appended to a DOM node if there is only one disabled prop on the component. It seems to be a real bug and not-intended behavior. @eps1lon Can we re-open?

[oliviertassinari]

@xenostar Why does it matter?

[kachar]

@oliviertassinari

It seems I can't override the disabled state of the button anymore when the Mui-disabled is applied twice.

My custom makeStyle-disabled-104 class gets between the two definitions and color prop gets overridden by the second Mui-disabled class.

<Button
  fullWidth
  disabled={amPm === 'AM'}
  classes={{
    root: classes.selected,
    disabled: classes.disabled,
  }}>
  AM
</Button>

A valid workaround is to use !important but it will be awesome to have a generic solution to the problem.

[oliviertassinari]

@kachar The order of the class names in the attribute doesn't matter for specificifiy.

I start to think that we should remove all the pseudo-classes from the classes API so developers are forced to use &.Mui-disabled, which will have the correct specificity, cc @mnajdova.