I'm sure I'll have more later, but I really like the idea presented in F11.

Changing default prop values to be configurable site wide. It would clean up a lot of standard things and make writing components a bit quicker.

It would also allow us to localize components better.

I do wonder if it will be easily overridable. I've had some issues with IDialogProvider not accepting local overrides from near where they're called.

That's a good question. The settings service would just set new values in the constructor. I don't think that's a problem. But we'll have to see

I would like to elaborate, now, and say that after a second/third look over of these I think I'm in favor of most of them.

The ones that REALLY make me excited are F1, F2, F3 (& 3.1), F5, F8 (listed two different times, for two different purposes, I mean F8 the former - about defining Custom theme colors), F10, and F11.

I know that's most of them, whatever.

F1 I simply like, I think it'd be a good addition.

F2 I think looks amazing the way MUI does it, if that's something possible, I can't see any drawback. I don't have any big problems with how Elevation shadows look now, but I do admit the MUI look seems cleaner and draws focus better than just the shader outside the element. This might be a personal preference thing, though.

F3, 3.1 are very nice ideas that I think would be great. I believe getting a ThemeService would be great as a moving implementation and allows for some more direct interaction with the theme when needed. It seems a bit niche as /is/, but I believe it expands the possibilities going forward. I believe this might be a way to hook into the MudThemes somehow as well, by injecting a theme on Startup, maybe from a json config instead of in code, allowing you to be able to export your theme from MudTheme and bundle it in your project and easily swap them out? I think that would be a pretty neat way to integrate it on load, which is separate from the portable use cases of just having the values available when you're coding to utilize portions of the theme in non default ways.

F5 I think would be nice to have, though I don't know how it would feel - as in, where does the .css get generated and when? Upon build?

F8 (custom colors F8, not the other) I think would be great to have some sort of... mutable collection of key values that you could add to in the ThemeService that lets you store custom colors to retrieve as needed with your own names. I think that would be neat, potentially useful.

F10 I think I like the idea of a SettingsService housing the IThemeProvider as you mention here, but I would wonder what other settings you'd want to expose. Would this roll into F11's implementation of basically adding theming to components? Would that be considered a SettingsService or still, thematically, just an IThemeProvider?

Speaking of, F11 just seems like it will save so much time typing the same 2 or 3 Key=Value combinations on some high use component types. Since the general theme of the whole website often uses a ton of the same basic setup for TextField / Button etc. I think F11 is my favorite single change of the whole list.

Hopefully some of the above is useful.

Thanks a lot for your detailed feedback!
F2 is also a material 2 standard. Seehttps://m2.material.io/design/color/dark-theme.html#properties
Actually a pretty nice way of doing it with a white transparent overlay

injecting a theme on Startup, maybe from a json config instead of in code

That's another good idea. I think you can pretty easily convert json to C# objects. I'll add it to the list as #F13

F5 I think would be nice to have, though I don't know how it would feel - as in, where does the .css get generated and when? Upon build?

The theme service will collect all styles from all components and then generate a single<style> block.
The css is generated every time a style changes. We have to see if it's worth performance wise. But inline styles are generally worse at performance. So maybe it could be even faster

F10 I think I like the idea of a SettingsService housing the IThemeProvider as you mention here, but I would wonder what other settings you'd want to expose. Would this roll into F11's implementation of basically adding theming to components? Would that be considered a SettingsService or still, thematically, just an IThemeProvider?

Dark theme change, RTL, themes and all default values of the components. We'll have to see if the default values should rather be part of the theme or not

Ahh I used F8 twice. I'll rename it to F12. I hope it's not too confusing

Exactly, that was the idea. At the moment, you have to create your own service that handles darkmode changes etc.

Hmm, that's also a good idea. But that would double our css variables of course

My suggestion is no longer valid I think. I just realized all palette colours are defined in the code, not CSS. That means they can be modified or derived on runtime as needed. If anyone is wondering how:

@usingMudBlazor.Utilities;@injectLayoutService LayoutService@code{MudColormyDerivedColor;voidSetMyDerivedColor(){varbaseColor=LayoutService.CurrentTheme.Palette.Primary;myDerivedColor=newMudColor(baseColor.Value).SetAlpha(70);}}

@using MudBlazor.Utilities;@inject LayoutService LayoutService @code {    MudColor myDerivedColor;    void SetMyDerivedColor()    {        var baseColor = LayoutService.CurrentTheme.Palette.Primary;        myDerivedColor = new MudColor(baseColor.Value).SetAlpha(70);    }}

That's exactly what a meant withOr with F8 it might be not required because then you could just define the color opacity version you need

My suggestion is no longer valid I think. I just realized all palette colours are defined in the code, not CSS.

They are converted to css variables and applied inside a<style>. So, I think it's possible

Agree. F8 was a good idea.

I know that I'm late to the party but I couldn't resist replying since I've recently solved this same problem for myself.
My solution to changing the alpha of hex colors uses the color-mix function like so...

:root {  --mud-palette-error: #f64e62ff;}.mud-alert-filled-translucent {    background-color: var(--mud-palette-error);}.mud-alert-filled-error-translucent {  background-color: color-mix(in_srgb, transparent 80%, var(--mud-palette-error) 20%);}

I'm also able to make the alpha percentage a CSS variable.

Yes, and with#6519 it is possible to make a sub theme by inheriting your base theme with only some changes but keeping it in sync with your base theme for all other settings.

I had a further thought - if the theme manager is to be a repository that is organised by a dictionary of class names, like "MudButton" then a useful addition would be to have the MudButton type have a "CustomTheme" property so that it could use the "MudButton-{CustomTheme}" dictionary element to see if there is customisation for that button. This would allow users to have a general property set in the theme for MudButton, but also have CustomTheme="bluebutton" properties to make for easy centrally controlled styling.

I often require a higher level of density than what is currently considered 'dense', especially when working with tabular data. However, using 0px padding never looks good IMO. Excel-like padding and row/column sizing is usually compact enough to strike a good balance between readability and the amount of data on the screen.

I would change the priority of F6 low. I am still thinking it would be cool to have it but many team members think it is not worth the effort. Maybe if we find a volunteer who wants to implement it all and can show on one component that it doesn't increase component complexity all that much then we might still have it.

F11 is partially done. I would promote it to highest priority and see which other defaults we should make configurable.

We should add another point F12 to find a way to inject theme styles and other dynamic styles in a CSP-compliant manner, i.e. with a custom endpoint like@meenzen suggested. Or a source generator (where applicable), or any other way if anybody has better ideas.

That is essentially it. All the other points seem to be still valid. The team should discuss and agree on priorities for all the points.

I would change the priority of F6 low. I am still thinking it would be cool to have it but many team members think it is not worth the effort. Maybe if we find a volunteer who wants to implement it all and can show on one component that it doesn't increase component complexity all that much then we might still have it.

F11 is partially done. I would promote it to highest priority and see which other defaults we should make configurable.

We should add another point F12 to find a way to inject theme styles and other dynamic styles in a CSP-compliant manner, i.e. with a custom endpoint like@meenzen suggested. Or a source generator (where applicable), or any other way if anybody has better ideas.

That is essentially it. All the other points seem to be still valid. The team should discuss and agree on priorities for all the points.

Was F11, "Change default prop values of components" ever delivered? Was looking to distribute a NuGet package of our defined Theme and was wondering if style variants are covered nowadays?