[material-ui] i can not let button use the props of MuiIcon in component setting, but instead get hardcode font size declaration

[maapteh]

Steps to reproduce

I have a MuiButton which has a startIcon. The generated code is

Button.MuiButtonBase-root
  span.MuiButton-icon
      svg.MuiSvgIcon-root

Now in the createTheme component options i set MuiButton font-size to 1rem and all sizes of MuiSvgIcon to their specific rem

But the button (actually the span.MuiButton-icon) adds this class:

.css-UNIQUE > :nth-of-type(1) {
    font-size: 18px;
}

While i defined the font-size on Button level and Icon on Icon level. Which is perfect and when i remove the injected extra class it all looks correct. Now i have to overrule this :nth-of-type(1) for each button size and then it wins from the still added font size.

I think this is a bug in the deepmerge functionality. Because how do you want me to just remove the cullprit from the component declaration instead of adding lots of selectors to win. It would be great if i can unset things, certainly when moving to a rem based setup.

Current behavior

Button component adds specific css for the font for the icon by default.
No way to get rid of this during construction of the component with createTheme

I like MUI is having defaults, but it should be nicer to get rid of these when you implicitly want to do so (i see some implementations using unset for example).

Expected behavior

I hoped just like other systems like Chakra that i can remove particular default settings.
so when i set this '> :nth-of-type(1)': undefined|null on theme creation it would remove it :)

Context

We are moving to rems. Now lots of MUI is in pixels, and lots of these are not as we design them. So i endup with lots of extra classes (have to import this from every component being used in a mui component which highly couples the structure mui is using with zero guarentees for the future) to just win while the wrapper in most cases was already fine to begin with. So lots of extra code to maintain.

It would be great if i can remove defaults. So its not a variant or override.

Your environment

its with every mui version, not particular to a single version, lets say im using latest (which i do) :)

Search keywords: merge, style override

[mj12albert]

@maapteh Would you mind providing a minimal repro? You can fork this sandbox: https://codesandbox.io/p/sandbox/autumn-pond-v29s74

[maapteh]

@mj12albert See https://codesandbox.io/p/sandbox/github/maapteh/sandbox-mui-button?file=%2Fsrc%2FApp.js
stand on the svg placed, and notice the hardcoded fontsize in pixels...

[siriwatknp]

I think this is a bug in the deepmerge functionality. Because how do you want me to just remove the cullprit from the component declaration instead of adding lots of selectors to win. It would be great if i can unset things, certainly when moving to a rem based setup.

This is not a bug because we don't provide a way to remove the existing styles. This is more about customization experience, the font-size controlled by the button should not have selector higher than (0,1,0).

We are moving to rems. Now lots of MUI is in pixels, and lots of these are not as we design them. So i endup with lots of extra classes (have to import this from every component being used in a mui component which highly couples the structure mui is using with zero guarentees for the future) to just win while the wrapper in most cases was already fine to begin with. So lots of extra code to maintain.

Based on your context, it sounds like Material UI is lacking a option to let users decide on px or rem. I think that's the next step for this issue.

[maapteh]

Button.MuiButtonBase-root
  span.MuiButton-icon
      svg.MuiSvgIcon-root

The input prop is called iconStart, while you can literally place anything there setting a font-size makes no sense. Because for S/M/L buttons we are already using SVGIcon where we set the correct size per size.
I was just hoping to do nothing, and now only that particular font size is in its way (its the only declaration on this span icon holder by the way!).

[siriwatknp]

@maapteh Got your point. I marked this as an improvement.