MudGlobal: Deprecate remaining theming properties

[danielchalmers]

Description

Most styling should be done on a situational basis using component parameters.
For more in-depth customization, a mix of our theming system and CSS will be the most effective.
To find more ways to customize your app, refer to our other documentation in the sidebar.

How Has This Been Tested?

Type of Changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation (fix or improvement to the website or code docs)

Checklist

• [X] The PR is submitted to the correct branch (dev).
• [X] My code follows the code style of this project.
• [X] I've added relevant tests.

[sonarqubecloud[bot]]

Quality Gate failed

Failed conditions
D Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 91.35%. Comparing base (137180c) to head (299ef9f). :warning: Report is 292 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev   #11415      +/-   ##
==========================================
+ Coverage   91.10%   91.35%   +0.24%     
==========================================
  Files         465      473       +8     
  Lines       14407    15006     +599     
  Branches     2788     2905     +117     
==========================================
+ Hits        13126    13708     +582     
- Misses        642      651       +9     
- Partials      639      647       +8     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fluxys-sargosn]

Are removing MudGlobal in general ? Because if so, I don't get it. It is nice to have customization at the component level for its appearance, but having defaults at the app level is a huge plus for my IT department.

[danielchalmers]

Are removing MudGlobal in general ? Because if so, I don't get it. It is nice to have customization at the component level for its appearance, but having defaults at the app level is a huge plus for my IT department.

MudGlobal was intended more for backend or behavioural properties, while the theming engine (+CSS) is there for styles. It shouldn't have grown like this in the first place really. Typically in Material Design you want each component to have a specific look for its purpose so applying wide defaults is not necessarily the right approach @fluxys-sargosn

[fluxys-sargosn]

So, let say, I need all my inputs to look like a Variant that is not the default one. I shall either override all MudBlazor CSS or use the Variant property in all my inputs ? Is that what you are proposing ? If so, why proposing a default sytling at all ? Why not do it like FluentUI with very basic styling so you know from the beginning that you will have to rewrite the CSS. Honestly, I've been using MudBlazor for a while now and using those Variants and stuff is really tidious.

[Deepeeper]

I agree with above and im not a fan of this change. Depricating these global options is not ideal for me and manually applying Margin and Variant on all fields would really suck. I have actually been hoping that the MudGlobals would extend even more since its missing on a lot of places today. Writing css to override default styles might work but i do still want the possibility to utilize the parameters on occation.

If removing these globals, i would strongly suggest and hope that this functionality remains somewhere else, e.g. in the theme manager.

[danielchalmers]

So, let say, I need all my inputs to look like a Variant that is not the default one. I shall either override all MudBlazor CSS or use the Variant property in all my inputs ? Is that what you are proposing ?

Yes if you want them to look the same, but Google suggests using different variants for different uses so you ideally wouldn't have the same throughout the app.

I have actually been hoping that the MudGlobals would extend even more since its missing on a lot of places today.

It's just not maintainable to have a global property for every component property in the library.

If removing these globals, i would strongly suggest and hope that this functionality remains somewhere else, e.g. in the theme manager.

Please feel free to create new issues with your suggestions for bolstering the theme manager, but we we prefer not to manage so many properties.

[Deepeeper]

So, let say, I need all my inputs to look like a Variant that is not the default one. I shall either override all MudBlazor CSS or use the Variant property in all my inputs ? Is that what you are proposing ?

Yes if you want them to look the same, but Google suggests using different variants for different uses so you ideally wouldn't have the same throughout the app.

I have actually been hoping that the MudGlobals would extend even more since its missing on a lot of places today.

It's just not maintainable to have a global property for every component property in the library.

If removing these globals, i would strongly suggest and hope that this functionality remains somewhere else, e.g. in the theme manager.

Please feel free to create new issues with your suggestions for bolstering the theme manager, but we we prefer not to manage so many properties.

I reviewed the Material Design documentation but still don’t see a clear explanation of why a framework shouldn’t offer a way to set these kinds of globals. As far as I can tell, Material’s theming docs show how to define color, typography, and shape tokens globally, but they do not address default component props. That kind of global default behavior is a framework-level convenience, Material itself only defines tokens.

Without a global default, I would need to write Variant="Outlined" Margin="Dense" on every <MudTextField>. In a form with dozens of fields, that quickly becomes error-prone and tedious. Angular Material (the official Google-supported Angular library) provides this via MAT_FORM_FIELD_DEFAULT_OPTIONS to set appearance: 'outline' on all form fields by default again, with per-instance overrides available. Link here

I understand that MudGlobals may require refactoring, because a large “globals” object can be difficult to maintain. However, removing global default props entirely seems like a substantial regression for any UI library. I plan to open an issue as you suggested.

I’d feel more comfortable proceeding once there’s a replacement in place, rather than shipping a breaking change that removes this functionality without an alternative.

[danielchalmers]

I reviewed the Material Design documentation but still don’t see a clear explanation of why a framework shouldn’t offer a way to set these kinds of globals. As far as I can tell, Material’s theming docs show how to define color, typography, and shape tokens globally, but they do not address default component props. That kind of global default behavior is a framework-level convenience, Material itself only defines tokens.

Without a global default, I would need to write Variant="Outlined" Margin="Dense" on every . In a form with dozens of fields, that quickly becomes error-prone and tedious. Angular Material (the official Google-supported Angular library) provides this via MAT_FORM_FIELD_DEFAULT_OPTIONS to set appearance: 'outline' on all form fields by default again, with per-instance overrides available. Link here

I understand that MudGlobals may require refactoring, because a large “globals” object can be difficult to maintain. However, removing global default props entirely seems like a substantial regression for any UI library. I plan to open an issue as you suggested.

I’d feel more comfortable proceeding once there’s a replacement in place, rather than shipping a breaking change that removes this functionality without an alternative.

I do appreciate all feedback but I want to be clear that we are a very small team doing it in our free time and will never be able to match a library like Angular. We have a theme engine that we want to rely on, and are open to feedback in that area, but we will not be offering theming options in MudGlobal going forward. As a note, MudGlobal has explicit warnings in both the web docs and the codes docs that it is experimental in every way. I hope this doesn't come off as argumentative, I just want to be as unambiguous as possible.

[fluxys-sargosn]

I do understand that a small team doing that for free might struggle with such a large project, and I hope you all know that we are very grateful for your work. Apart, from that, let me explain: we are indeed now using css to customize yours to have our own look & feel. There are still flaws though: in the case of all MudSelect components (including MudAutocomplete...etc.) we want a special look for readonly (no borders, no placeholder...etc.), but there no way to know if it's readonly or not via CSS as the input is by default readonly, on the contrary of most other components. I guess I can try to create a PR.

I guess it would as simple as adding Readonly="@ReadOnly" on this line: MudSelect. After investigation, it wouldn't work, MudInputControl doesn't have a ReadOnly parameter.

[mouse0270]

I do understand that a small team doing that for free might struggle with such a large project, and I hope you all know that we are very grateful for your work. Apart, from that, let me explain: we are indeed now using css to customize yours to have our own look & feel. There are still flaws though: in the case of all MudSelect components (including MudAutocomplete...etc.) we want a special look for readonly (no borders, no placeholder...etc.), but there no way to know if it's readonly or not via CSS as the input is by default readonly, on the contrary of most other components. I guess I can try to create a PR.

I guess it would as simple as adding Readonly="@readonly" on this line: MudSelect. After investigation, it wouldn't work, MudInputControl doesn't have a ReadOnly parameter.

Not really agree with the teams direction, but I do want to point out that you should be able to do

    .mud-input-control.mud-select:has(input[readonly]) {
     outline: 3px solid red;
    }

Which would let you style your inputs using just css if its readonly or not.

[danielchalmers]

@ScarletKuro I'm thinking we should accelerate the timeline and merge the deprecation notices in v8.13.0/v8.14.0, then remove entirely in v9 so we don't have all these annotations and awkward logic laying around. It's been marked experimental in the docs for nearly a year.

[ScarletKuro]

@ScarletKuro I'm thinking we should accelerate the timeline and merge the deprecation notices in v8.13.0/v8.14.0, then remove entirely in v9 so we don't have all these annotations and awkward logic laying around. It's been marked experimental in the docs for nearly a year.

Sure thing.