@rami-a

Just noticed this, appears like title shifts from larger text to regular text (similar to Cupertino Navigation Bar)
I couldn't find an issue for this, wdyt?

Hey @TahaTesser, yeah that is one of the variations of app bar now. We should create an issue for it, I can do that

Done: #92093

Is the goal to support a seamless upgrade path (flip a switch and you're in Material 3 mode, and your app should work fine), or is this the expectation that upgrading to this library will require effort?

If the latter, maybe it makes more sense to provide this as a separate library?

These changes will be provided as an opt-in solution for now and the current Material 2 functionality will remain a part of the framework for a while (at least 1 year+). This will give developers to a lot of time to opt-in and move over their projects.

I don't think that's a lot of time. People maintain projects for a decade or more with minimal investment. We can make minor breaking changes that can be migrated with dart fix or flipping a switch, but something of the scale of a whole new library with a new design language and so on is too high an investment for an application in maintenance mode. For example, concretely, I would not expect to ever migrate my Rainbow Monkey app to material3; I just don't have the time to do that work if it's more than a flag flip.

@Hixie the goal is to have a seamless upgrade path (i.e. toggle a flag on ThemeData and all Material widgets adjust appropriately). We're still working through all the details to make this possible.

One problem with offering this as a separate library is that as Material continues to evolve, Flutter's packaged material library will become stale and outdated.

It doesn't look like it can be a seamless flag flip, e.g. looking at #89853 it seems the typography sizes don't match, which is a pretty serious breaking change all on its own.

I'm also a bit worried about what this will do to the API complexity and performance. Can we add these new features without making the widgets have more complicated APIs? They're already really complicated and confusing as it is, because of having to support material 1 and 2 features (which we'll have to support forever); if we add material 3 features as well it's going to be really hard to pick up the framework. Performance is also an issue since all these widgets are going to be full of branches to handle all the various options, and that's slower than having a dedicated simple library just for one design language.

Flutter's packaged material library will become stale and outdated.

Is that a problem? We can have people import the material3 library instead of the material library in the templates. The idea is just not to break old apps.

The M3 spec is now live at https://m3.material.io/

I'm also a bit worried about what this will do to the API complexity and performance

The 'issue' I see is that Flutter is extremely coupled with Material (even the iOS slider depends on Material slider). There are some open issues for decoupling Material, but they never moved on. I am 100% in favor of a Flutter material components library that can be instantly updated and break everything (I was the person that caused TextTheme to be updated to Material 2 😛). I don't want to wait 3 years for Material You changes; It could also help in versioning, as someone could still use RaisedButton (without the deprecation warning) if so wanted. Right now there is not much option, people need to update Flutter (like on Apple Silicon) and sometimes it makes it harder for them.

My question is just... how could such a library exist? The imaginary library will probably have ElevatedButton (with some tweaks), but Flutter already has it. Will I as a user suddenly need to figure out which import I want? Or shall Flutter deprecate every material widget and say "please import the material 2 library" (so that then switching to material 3 is easy)? Like, this would be nice, but possibly too radical? Or Flutter will somehow import Material 3 and then we will have to deal with conflicts "you use an unsupported material3 version" (which could also create trouble when Material 4 reaches).

I want this, I hope we get this, but how? Is it possible?

It is better to update the complete library of material, rather than keep it, since in the long run the components of material 2 will be without maintenance and obsolete, the current version could still be kept and perhaps to use version 3 it is only indicated through of a parameter in the import, that indicates that I want to use version 3 and not 2, or by default in new projects that it is version 3 and be able to use the current version if one wants, but not both at the same time. you see.

even the iOS slider depends on Material slider

Actually the cupertino library doesn't depend on material; the dependency is in the other direction.

someone could still use RaisedButton

There's nothing stopping someone today from just copying the material library and putting it into a package if they want to continue using the older widgets, FWIW.

You are right. So the question that remains is: how could we have a material3 library with Flutter's existing material in the same project without conflicts?

• Convert Flutter's material to material2 library and add a dart fix that adds that import everywhere.
• Somehow add a material flag to pubspec where when >= 3, hides the visibility for Flutter's default material (at least for IDE suggestions; it would still work, just don't suggest/auto-import them). Or maybe just having material in pubspec would trigger the IDE plugin to not auto-import the older material.

If you are talking about uncoupling things, we could also remove Material Icons from Flutter and put them into a package. This is a frequent request as it is always breaking something/not updating/the script that updates are private and its changes get in the middle of Flutter releases, so people need to wait for the next stable to have the icons.

The impression I get is that the delta from the current material library to Material 3 is actually pretty minimal, and it would be simplest to just keep adding to the current library. The main complexity seems to be around the typography changes.

@Hixie you're correct that the M2 to M3 delta is pretty minimal.

The typography changes are likely the most disruptive:

• Renaming all the text styles will require folks to familiarize themselves with them again (though dart fix can help alleviate some of that complexity).
• The actual changes to the font sizes will be purely opt-in (just like the 2018 font size changes were) using the Typography class and named constructors

As a consumer of Flutter, I'd prefer to see separate package:flutter/material.dart and package:flutter/material_you.dart (or something to that effect).

My use case would be to be able to cleanly opt-in or out of Material3 widgets and styles. I recognize that this might not be very straightforward given ancestor themes.

This is only a consumer perspective, too, but maybe such a split into a new material3 package could also be a great chance to risk some breaking changes and throw out all the legacy theming APIs?

I found the theming system to be very confusing when I started with Flutter and, after heavily working with it for some time, I think it still is. And the updated M3 color scheme (#89852) will probably not make that situation any better. All these redundancies and complexity could probably only be removed with such a new, fully opt-in package to which developers have to migrate their app code anyway, making the breakage less painful.

In the best case, users of the new material3 package would then find a clean and straight-forwarded theming API without any leftovers from the previous material design revisions, color schemes and theming systems, making it way easier for users to implement theming best practices and understand how things hang together Flutter-internally. Maybe the material library could also be more decoupled along the way, for example by removing all the references to single widgets from the ThemeData class to make things more flexible and extensible. But I'm just dreaming. 😉

The downside is, that many breaking changes would probably steepen the effort needed to migrate existing apps to the new Material 3 design.

The actual changes to the font sizes will be purely opt-in (just like the 2018 font size changes were) using the Typography class and named constructors

2018 style was only implemented in 2020 with bodyText (which is nowhere in the official docs but was authorized) to not break the existing body and it is still not null-safety. Also, 2014 styles are still the default in Flutter. We could say the 2018 migration is not yet complete.

Material3 also revamps how elevation changes (color changes on both dark and light mode, there is a tonalElevation parameter). So now we would have an additional parameter in ThemeData besides ThemeData.applyElevationOverlay (which was also only truly implemented in 2020 #57526).

Finally, I guess there will be the new MaterialColors.green90 which is also going to be a duplicate of Flutter's Colors.green (from Material 1). A lot of duplications, but nothing impossible. This is the issue of Material 3, there will be additional parameters everywhere, it will be so 'opt-in' that most people will never opt-in because it will be too complex, they will forget or something else. Or ThemeData will get even more verbose.

I myself also think that decoupling the material and also the cupertino library from the flutter framework would be a major benefit for the whole ecosystem. All the libraries get more and more complex just to support legacy m2 styling.. Also things like the m2 snackbar styling are still opt in because of that.

It currently is quite painful to create a new flutter app, that uses all widgets in its modern styling, as you have to opt into so many things. And also having to fight with all the old m1 properties and major inconsistencies everywhere.

I think having a material library, that is versioned independent from flutter, enabling developers to update the flutter version of old maintenance projects without the need to handle breaking changes in the material library, would be a major benefit for everyone, as it not only would make the life of each maintainer much more easy, as breaking changes do happen over time, but also making the life of everyone else, who wants to have the modern styling so much easier, as the material library package could just have breaking changes following semver etc.

Altogether I would say, especially if we are trying to think long term, the benefits outweigh the costs by far.
So I would very much recommend to fix this rather soon then late, so that we don't have the same conversation again when materail4 arrives :)

MaterialRail is a good example, it was never "correctly" implemented in Flutter. The duration and curve was wrong and stayed wrong for years(?). I think it was fixed a few months ago, but it had "luck" that almost no one uses the Rail, so the behavior change was fine and no one complained. Officially, if it were a more important component, it would have taken 1 year to deprecate with additional parameters and etc. I like that libraries can move faster.

FWIW, the main reason to not have material be its own package is that we want the out-of-box experience to be quick. That is, people should be able to download Flutter, and immediately start writing an app with pretty buttons.

I agree with the points that were brought up above, though. It's definitely put us in an awkward situation. I also agree that adding M3 is not going to make it better.

FWIW, the main reason to not have material be its own package is that we want the out-of-box experience to be quick. That is, people should be able to download Flutter, and immediately start writing an app with pretty buttons.

This could easily be solved by adding the new material library package to the pubspec.yaml file of the template for new projects

That ends up being tricky for various reasons, e.g. we would have to pin the dependency which means now you can't upgrade the package without upgrading Flutter. (We have to pin all our internal dependencies, so we try to minimize how many packages we depend on.)

But yes, that's one approach we've discussed in the past.

But having material as a dependency in the pubspec template isn't really a flutter dependency. As its only part of a template that is being genrated when a new project is generated just like "cupertino_icons" which is added aswell

Besides that also I still don't see, how

"having an easier start (not needing to add material to pubpec)"

outweighs

"having a very hard time throughout the whole development process by fighting the inconsistent, fragmented and in general weird library that also has a hard time being up to date with modern styling because of backwards compatibility"

But having material as a dependency in the pubspec template isn't really a flutter dependency. As its only part of a template that is being genrated when a new project is generated just like "cupertino_icons" which is added aswell

Besides that also I still don't see, how

"having an easier start (not needing to add material to pubpec)"

outweighs

"having a very hard time throughout the whole development process by fighting the inconsistent, fragmented and in general weird library that also has a hard time being up to date with modern styling because of backwards compatibility"

And if Flutter were able to use the native libraries, using as a widget and not XML, so the native design libraries would not require any coding to be used in flutter, it is just a dream.

That is, people should be able to download Flutter, and immediately start writing an app with pretty buttons.

Yeah, but Flutter kind of already does that for icons and it works, right? There is uses-material-design: true and cupertino_icons in every app (because of the template) and you don't see people complaining it is hard to add material icons to Flutter because most use the template.

I'm not saying it's a blocker, just that it's one of the things we need to keep in mind.

Is it possible to move the material and cupertino packages outside of Flutter?

• Components for other platforms are separate from Flutter (fluent, macos_ui, yaru, ...)
• You can update packages without updating Flutter

Moving those packages outside flutter would be nice so you don't import a widget from the wrong package by mistake.

-- off-topic
@Hixie You can see my proposal to help with migration
for example, MaterialButton will be auto migrated to MaterialButton3 and so on
By letting contributors make extensions or config templates, everyone will be able to migrate his project to M3 and give it a try

Advanced Dart Migration Tool
#78735

Will there be a Standard Navigation drawer as described here https://m3.material.io/components/navigation-drawer/overview

Will there be a Standard Navigation drawer as described here https://m3.material.io/components/navigation-drawer/overview

Are you going to contribute new navigation drawer? I can do it if you won't

Will there be a Standard Navigation drawer as described here https://m3.material.io/components/navigation-drawer/overview

We don't currently have a 'Navigation drawer' per se, but just a bare bones Drawer widget that can be populated with anything. I just opened an issue to track a full featured NavigationDrawer feature: #103551.