[base-ui] Change the `Mui-` class prefix

[michaldudak]

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 be Mui-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).

[oliviertassinari]

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:

• why base-Button-root and not BaseButton-root. Why should we teach developers two different conventions?
• why 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:

• Ariakit: no class names by default
• Radix Primitives: no class names by default
• Headless UI: no class names by default https://headlessui.com/react/tabs
• React Aria: react-aria- prefix, e.g. https://react-spectrum.adobe.com/react-aria/Button.html

I 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?

[michaldudak]

Yes, this is being discussed in https://www.notion.so/mui-org/base-ui-Style-hooks-e943c3051ca74ce79f2e5af98a0f43eb

[michaldudak]

Closing the issue as Base UI does not use classes anymore.