Closed michaldudak closed 4 weeks ago
I'm reopening to keep track of https://github.com/mui/material-ui/pull/40205#discussion_r1439301669. I think that each breaking change is important, and deserves to be covered in depth on why of each change (helps build trust with developers).
What's the plan for Material UI class names, change them to .mui-Button-root? If we don't plan to change it, .BaseButton-root looks like a clear direction to take. It's arbitrary, so we might as well be consistent before we make it stable.
Effectively, I don't understand:
base-Button-root
and not BaseButton-root
. Why should we teach developers two different conventions?base--focused
and not Base--focused
(assuming Mui-focused
will progressively go away, because we will mostly use Base--focused
in Material UI/Joy UI/MUI X, so we can solve the similarity problem between pseudo states class names and slot class names by using -- and not -)Side thought 1.
The change to remove the Mui prefix makes sense to me in the strategy to teach developers and make them aware of what they are working with. For instance, if a developer relies a lot on the class names to know which component you can override in the theme (how I would use it), then Base UI using Mui in the class names is horrible DX.
Side thought 2.
A quick benchmark:
react-aria-
prefix, e.g. https://react-spectrum.adobe.com/react-aria/Button.htmlI wonder if we even need class names on slots (we need pseudo-states) Isn't this annoying for a developer who wants to work headless? There are no class names on a <select>
(though you can use a select selector, so not a fair comparison). I get the value when relying on slots
, it's a pain to add class names, but if we are moving to have the DOM node to be user-facing, then it's easy?
Yes, this is being discussed in https://www.notion.so/mui-org/base-ui-Style-hooks-e943c3051ca74ce79f2e5af98a0f43eb
Closing the issue as Base UI does not use classes anymore.
To allow Base UI components to be styled with plain CSS and coexist with Material UI components in the same projects, we need to be able to differentiate between them.
According to https://github.com/mui/material-ui/issues/33260#issuecomment-1243841054, the preferred solution was to add a product-specific class name to Base UI components (such as
Mui-Base
), so , for example, the resulting classes on a disabled button would beMui-Base MuiButton-root Mui-disabled
.However, as we're considering decoupling Base UI from the MUI umbrella, we can also reconsider the class name pattern (especially that
{productName}{componentName}
was voted for only slightly less than the winning option).