jtheisen
commented
1 year ago I second this.
MudBlazor's utilities are quite minimal. On the other hand, MudBlazor's controls are designed so that the use of explicit classes is only rarely necessary (there's MudStack, most component configuration is done with typed enums rather than encouraging the use of certain css classes, etc.)
It makes sense for MudBlazor (more than for other toolkits) to get out of the user's way in terms of it's css classes and let the user choose the css utility library they want to work alongside it. It mostly already does so. Only the small set of utilities remain and perhaps whatever MudBlazor has as base styles.
It may be sensible for MudBlazor to adopt this as a "design" in the sense that it can then de-prioritize the extension of the utilities which may otherwise be considered necessary. Arguably, the utilities should have a prefix (or at least the term "mud" appearing in them somwhere) even by default for new projects as to encourage new MudBlazor projects to be in a state that allows putting in a different utility library later.
Feature request type
Other
Component name
No response
Is your feature request related to a problem?
MudBlazor's utility CSS classes interfere with other utility frameworks, specifically tailwind.
Describe the solution you'd like
In addition to
<link href="_content/MudBlazor/MudBlazor.min.css" rel="stylesheet" />provide another one such as<link href="_content/MudBlazor/MudBlazor.core.min.css" rel="stylesheet" />where@import 'utilities';is omitted.Have you seen this feature anywhere else?
No response
Describe alternatives you've considered
For tailwind, prefixing can be used but is more verbose and unnecessary if the overriding css from mudblazor can be excluded. Likewise, tailwind's important selector setting cannot be used since mudblazor marks utility classes with !important.
Pull Request
Code of Conduct