Ian Hickson
Ian Hickson
test-exempt: code refactor with no semantic change
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...
> 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...
It doesn't look like it _can_ be a seamless flag flip, e.g. looking at https://github.com/flutter/flutter/issues/89853 it seems the typography sizes don't match, which is a pretty serious breaking change all...
> 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...
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...
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...
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...
I'm not saying it's a blocker, just that it's one of the things we need to keep in mind.
That's definitely one of the downsides of having a package for material. You'd basically have one ecosystem per material version.