Material Design 3 Roadmap

Keboo commented 2 years ago

Google has release Material Design 3. The intent here is to outline the needed work to support it in this library.

You can find the latest details here.

All of the tasks listed here can be considered up for grabs and I am happy to accept PRs for any of them.

New control resource dictionaries should be named as: MaterialDesign3.<ControlName>.xaml

High level changes

At a minimum these tasks and the color changes need to be implemented to start releasing these new styles.

Tasks

[ ] Create a copy of the MaterialDesignTheme.Defaults.xaml resource dictionary, it should be called MaterialDesign2.Defaults.xaml.
[ ] Create a new top level resource dictionary along side MaterialDesignTheme.Defaults.xaml it should be called MaterialDesign3.Defaults.xaml. For all of the new M3 styles, they should get referenced by this resource dictionary.

Color

This library already support some amount of the new Dynamic Colors, will need to evaluate the M3 implementation to determine how viable it will be to implement here as well.

Because the color brushes are all going in the same code path (ie will be treated and available at the app level), there will be some un-used brushes depending on which control styles are being used.

Tasks

[ ] Add tertiary color to the theme classes
[ ] Add container brushes for primary, secondary, and tertiary colors
[ ] Add neutral color brushes. Evaluate if the "Surface" ones are actually needed (I suspect we can simply use the background brushes instead).

There is another font Noto Sans that could be included in this library. Right now the fonts make up a significant percentage of size, this would add approximately 1.3MB. Alternatively we could pull fonts out, and make them opt-in with a csproj flag or similar. I am interested in hearing feedback on this, not sure if file size of the assembly matters much to people.

Tasks

[ ] Create a copy of the existing MaterialDesignFontExtension and name it RobotoFontExtension. MaterialDesignFontExtension should be marked as obsolete.
[ ] Create a new NotoFontExtension (similar to the one above) and include the Noto Sans font files.

Buttons

This will be the largest portion of the work as there is quite a bit to do.

Tasks

[ ] Create style for Elevated button
[ ] Create style for Filled button
[ ] Create style for Filled tonal button (I suspect the template can be shared with the one for Filled button).
[ ] Create style for Outline button
[ ] Create style for Text button. This will be the same style used for Icon button. Simply replace the content of the button with a PackIcon.
[ ] Create style for Floating action button (FAB). Be aware that this style should be expected to accommodate the sizing changes documented for the Extended FAB as well.

Cards

The cards here are not that different from the ones in the existing library. We should still copy the style into a new M3 card resource dictionary, but it may initially be the same as the M2 version.

Tasks

[ ] Create style for Elevated card.
[ ] Create style for Filled card.
[ ] Create style for Outlined card.

Chips

Most of this functionality should already be in place. Just the colors and the corner radius look to be the big differences.

For all of these styles, I suspect a single template could be shared as the look and elements of each of these is pretty similar.

Tasks

[ ] Create style for Assist chip
[ ] Create style for Filter chip
[ ] Create style for Input chip
[ ] Create style for Suggestion chip

Dialogs

For the most part, the dialogs are already done. This library only supports the "Basic dialog" not the "Full screen dialog". For the most part, none of the new features of the dialog affect the DialogHost (our implementation) directly.

Navigation Bar

This is a control has not been implemented. Though happy to accept a PR for it, not a requirement for initial release. See #652 for details.

Navigation Drawer

This is a control has not been implemented. Though happy to accept a PR for it, not a requirement for initial release.

Navigation rail

This is largely done, just a few minor updates to how the selected item appears.

Tasks

[ ] Create Navigation rail style

Top app bar

This is a control has not been implemented, nor do I believe a very useful control for WPF apps. Happy to hear suggestions and use cases if you think otherwise.

MichelMichels commented 2 years ago

In previous PR, you said:

As for the namespace I think we want to keep it as MaterialDesignTheme.Wpf. I think the goal will be to have the Material Design 3 templates being able to be used on the same controls along side the Material Design 2 templates.

Do you want to support both styles at once? Because I'm currently replacing each ResourceDictionary, not appending them.

Keboo commented 2 years ago

@MichelMichels Yes, let me see if I can explain better. Part of not changing or duplicating the namespace is to try to keep some separation between the controls (code) and the Styles/Template (it matches the look-less nature of many WPF components).

What I am imagining is something like this (obviously this does not work at the moment):

<Window.Resources>
  <ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesign3.TextBlock.xaml" />
  <ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesign2.TextBlock.xaml" />
</Window.Resources>

....

<TextBlock Style="{StaticResource MaterialDesign3.DisplayLargeTextBlock}" />
<TextBlock Style="{StaticResource MaterialDesign2.DisplayLargeTextBlock}" />

One thing that would go along with that would be adding (not renaming) additional styles with those different key names. The reason for wanting to add additional keys, rather than renaming is to both keep people's existing code working, as well as to make it easy for someone to toggle Material Design 3 styles on by simply adding MaterialDesign3.Defaults.xaml last in the App.xaml.

So for someone's app to "update" to include MD3, my hope would be that they change their App.xaml From:

                <materialDesign:BundledTheme BaseTheme="Inherit" PrimaryColor="DeepPurple" SecondaryColor="Lime"
                                             ColorAdjustment="{materialDesign:ColorAdjustment}" />
                <ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesignTheme.Defaults.xaml" />

To:

                <materialDesign:BundledTheme BaseTheme="Inherit" PrimaryColor="DeepPurple" SecondaryColor="Lime"
                                             ColorAdjustment="{materialDesign:ColorAdjustment}" />
                <ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesign3.Defaults.xaml" />

This second point I believe is exactly what your existing work accomplishes (which is great!).

Hopefully that makes more sense, and thank you for all of your help!

MichelMichels commented 2 years ago

Thanks for the explanation.

How would you handle naming changes for Typography? I'm singling this issue out as I already implemented the Material 3 typography styles for TextBlock and I noticed they are different from the Material 2 guidelines.

Wouldn't it be confusing mixing those 2 typography set of styles? On the other hand, if the route of separation is choosen, this would be a fairly large breaking change.

Keboo commented 2 years ago

Good question. So initially when I wrote that, my intention had been to make it so that someone could easily switch over by simply changing their "default" resource dictionary. However, I am realizing now, that is somewhat wishful thinking, as they will also need to go through and update any merged resource dictionaries that are pointing to MaterialDesignTheme.TextBlock.xaml. Thinking on it more, I am realizing we should probably update MD3 styles that you did to the newer naming (MaterialDesign3.*) and not continue to propagate the older names. This will make updating for people a little more painful, but I have some thoughts on potentially producing some automation to help with it. In short, I think going with a hard separation with the MD3 stuff is probably best.

In one of the next 4.x releases, I would love to create additional styles with the better name. Something like this:

<Style
    TargetType="{x:Type TextBlock}"
    x:Key="MaterialDesign2.BodySmallTextBlock">
    <Setter
    Property="FontWeight"
    Value="Regular" />
    <Setter
    Property="FontSize"
    Value="12" />
    <Setter
    Property="LineHeight"
    Value="16" />
</Style>
<Style
    TargetType="{x:Type TextBlock}"
    x:Key="MaterialDesignBodySmallTextBlock"
    BasedOn="{StaticResource MaterialDesign2.BodySmallTextBlock}" />

That way the old style keys continue to work, but it also allows people the opportunity to use the newer ones if they wish. At some point in the future the old styles could be deleted. I would probably put a copy of the old style keys in the Release notes or similar, so if it did end up being a large breaking change for someone, they could simply pull that into their project and continue working.

I am already queuing up breaking changes that will come in the library in the 5.0.0 release, so there is a bit of a decision to make as to exactly when this breaking change should occur. If it is ready (or close to ready) then I might just make it a bigger release and do it all at once (I keep saying that I want to do more frequent smaller releases, and then fail miserably at it...). Otherwise, I think the plan will be to bring in those breaking changes in a 6.0 timeframe.

MichelMichels commented 2 years ago

@Keboo I like the MaterialDesign3.* naming convention.

Maybe we should consider putting the work for Material Design 3 on a different branch as to not clutter the current project until most standing questions are resolved? Or at least communicate that it's currently a WIP.

Keboo commented 2 years ago

I am fine leaving it in for now. For any releases that go out before this item is resolved I will make sure it is noted as a WIP.

MaterialDesignInXAML / MaterialDesignInXamlToolkit