[Select] Add comment on why padding-right is enforced on Select component

[nebbles]

https://github.com/mui-org/material-ui/blob/42954448866f204b0cf7e35127d5d0af9c24d6fb/packages/material-ui/src/NativeSelect/NativeSelect.js#L42-L44

In the above src code, the paddingRight style is applied with higher (double) class specificity to the component. Strangely, this is the only style rule applied in this way. This means, to override this style, I have to use the exact same pattern in my makeStyles class, i.e.

const useStyles = makeStyles((theme: Theme) => {
    return {
        select: {
                "paddingTop": 12,
                "paddingBottom": 12,
                "paddingLeft": 16,
                "&&": {
                    paddingRight: 40, // only way to override
                },
        },

//...

		<Select
                classes={{ select: classes.select }}

the above works.

However, by not following the exact same pattern to override, and instead applying the paddingRight in the same way as the other padding values, then the underlying NativeSelect style takes priority. As you can see in the Chrome style window (see image), the specificity of Mui's implementation means it cannot be overridden using the simple class prop.

(.MuiSelect-select.MuiSelect-select is ranked higher than .makeStyles-select-2357)

Screenshot of Chrome style window

Why does the style specified in NativeSelect use the higher specificity (double ampersand)? Is what I have done the expected way to override the right padding in this case?

[oliviertassinari]

@nebbles This style was added in #18520, a similar issue was raised in #18520 (comment). You can better see in #18771 why this is required.

To make it short, the CSS injection order between the input components and the select component is nondeterministic. To ensure the select always wins on the same CSS property (padding-right), we use a CSS specificity of 2 instead of 1.

I think that we could add a comment to explain it. It's not a common situation. We wouldn't need it with emotion, but because we also support sc, and because the select is meant to extend custom inputs, we need to keep this rule.

Maybe something like this:

diff --git a/packages/material-ui/src/NativeSelect/NativeSelect.js b/packages/material-ui/src/NativeSelect/NativeSelect.js
index f41e1a4de2..6e62ec6eaa 100644
--- a/packages/material-ui/src/NativeSelect/NativeSelect.js
+++ b/packages/material-ui/src/NativeSelect/NativeSelect.js
@@ -39,6 +39,7 @@ export const styles = (theme) => ({
     '&:not([multiple]) option, &:not([multiple]) optgroup': {
       backgroundColor: theme.palette.background.paper,
     },
+    // Bump specificity to allow extending custom inputs
     '&&': {
       paddingRight: 24,
     },

[nebbles]

Ah I see. I did find the tangle between the atomic components that Select combines a bit fiddly when working on my own style override.

🙏 Thanks for the explanation. I'd agree that adding in the docs would be helpful but can understand this is a little niche. For now, I'll be sticking with && specificity.

Looking forward to v5! Can't wait for the upgraded styling system with much better custom palettes!