New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Elevation issue with Material
widget, when opting in on useMaterial3
causes widespread elevation issues
#107190
Comments
To avoid having this issue visible as default in Theme Playground we default useMaterial3 until it is fixed or behaves better flutter/flutter#107190
* Deprecated m3TextTheme and use SDK built in Typography instead * Deprcate: FlexSubThemes.buttonTheme * Bump package versions * Update to use super.params, new in Dart 2.17 * Update LinkTextSpan to use Uri instead of deprecated url * Dep updates * Add larg FAB to theme showcase * Make Example custom themed Cards, also respect useMaterial3 * Add surfaceTint color to SchemeColor enum and functions * Add basic support for surfaceTint * Three more panel M3 useMaterial3 behavior added * Fix lint * Typo/comment corrections * Add support for Flutter 3.0 Theme Extensions * iOs and macOS * Bump package versions * DroidSans font not available anymore in Google Fons 3.0.0 package, replace with Fira Mono * Update change log and TODOs * Bump example version info * Opt-in sub theme toggleables now default to primary instead of secondary * Playground: Toggleable colors and efault text update. Add M3 switch to UI. * Playground: FAB fix of default text when using M3 * Remove not needed TODOs * Correct FAB color behavior when useMaterail3 is true * Doc and typo fixes * Playground app: Workaround for issue flutter/flutter#103864 * FAB component theme color indicator fix for useM3 * PopupMenu style change * M3 defaults support for NavigationBar * Fix Material theme showcase when using M3 * Themes Playground - update M3 presentation of Card * Update CHANGELOG.md * Doc updates * Doc updates * Doc updates * FIX NavigationRail M3 defaults * FIX test for new default rail size 14-12dp * Playground intro text update. Flutter version info update. * Doc updates * Doc updates * Doc updates * Add full support for surfaceTint color, so it is also used as FCS blend color. Needs tests! * Custom surfaceTint and surface blends support in Playground * Example fixes * Update CHANGELOG.md * Cleaning: Hashcode algo changed. Remove not needed finals. * Lint: Remove not needed finals. * HasCode: Change to Object.hash (used jenkins deprecated in master). * Set defaultUseMaterial3 = false due to Flutter issue 107190 To avoid having this issue visible as default in Theme Playground we default useMaterial3 until it is fixed or behaves better flutter/flutter#107190 * Initial/early support for M3 TextField style. * Update flex_theme_mode_switch.dart * Fix InputDecorator test. Update changelog date
Thanks for the well thought out and documented issue @rydmike!
The core issue with this proposal (if I am understanding it correctly) is that in M3 there are widgets that are supposed to show elevation with just a surface tint, just a drop shadow, or both. In order to support all of these options while keeping minimal changes to the API, we chose to determine which of these are presented based on whether the corresponding color was non-null. That is, if a widget needs just a surface tint, just supply the surface tint color and no shadow color. If it needs both, supply both, etc. If we always default the Material widget's shadow color to An alternative that was considered was to have another parameter added to Material that would control how the elevation was presented, something like: enum MaterialElevationPresentation { shadow, surfaceTint, shadowAndTint } Or just values for Unfortunately, this would mean that for every widget built on top of Material that exposed its That said, we completely understand the issues that this is causing during the migration. We'll think some more about this and see if we can find a way to make this better in the interim. |
Hi @darrenaustin, yes I looked at the If all SDK widgets (dialogs, banners, popup etc and their themes, if they have one) that use Since We still have the situation of being forced to also migrate any custom widgets built on My other thoughts on a fix for this was that maybe Widgets that now or later implement M3, then use context theme |
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Steps to Reproduce
When opting in on
ThemeData.useMaterial3
there is no elevation effect ofMaterial
unless itsshadowColor
and/orsurfaceTintColor
is also specified.When using M2 the elevation effect comes from specifying only
elevation
ofMaterial
, this is however no longer the case when using M3 andMaterial
.The impact of this
Material
behaviour change are:Material
gets no elevation of any kind, even if elevation has been specified.Material
will not get elevated, unless additionalshadowColor
and/orsurfaceTintColor
are added during migration, this causes extra migration friction.Material
widget and use elevation, will not get any elevation at all and cannot be elevated even if so specified. Some current such examples are:When using
Material
directly, the elevation issue can of course be addressed in M3 mode by adding any desiredshadowColor
and/orsurfaceTintColor
to it, but it is still two extra properties that were not needed before to elevate surfaces.For the Flutter SDK widgets using
Material
and elevation, the used underlyingMaterial
’sshadowColor
and/orsurfaceTintColor
are not exposed by such widgets or their themes. There is thus no easy fix for them to make them elevated again. The only currently available fix, when opting on M3, is to wrap widgets that are “elevation broken” whenuseMaterial3
is true, with a copy of the effective theme, whereuseMaterial3
is set to false. This is a rather tedious workaround and fix.Developers have been struggling with this, some examples include:
PopupMenuButton
's elevation is not being respected when usinguseMaterial3
#105101Also in:
Potential and Proposed Fix
Please consider changing
Material
default behaviour whenuseMaterial3
is true so that it uses themecolorScheme.shadow
forshadowColor
, andcolorScheme.surfaceTint
forsurfaceTintColor
as defaults.This would make M3 mode
Material
get M3 style elevation (shadow and tint) by default when specifying onlyelevation
, as before when usingMaterial
. Flutter SDK widgets that have not yet been migrated to support M3 internally, would then get M3 style tinted elevation with shadow, when only elevation is used. Such Flutter SDK widgets can then later implement their own more correct M3 elevation design, be it no elevation, shadow or tint only based elevation.This default would also make migrating custom widgets using
Material
easier, since they would still get elevation in M3, using both tint and shadow by default, as mostly expected, without need to specify them explicitly. This would result in less surprises with flat custom widgets usingMaterial
and elevation, where devs expect them to continue to be elevated. I foresee a lot of issues, or at least questions, when migrating custom widgets to M3, that useMaterial
andelevation
with its current behaviour.This proposal has its own challenges, I’m aware. Maybe you can come up with something that works even better.
Since the full migration of all widgets to support M3 is understandably a long journey, the transition period is currently causing frustration among early M3 adopters. The
Material
widget is at the root of many of them, if it had better backwards default behaviour in M3, most issues could be avoided, and widgets not using M3 design yet, can be made more M3 like with current M2 theming capabilities.Why is a Fix Needed?
Eventually all widgets will be migrated to support M3. This issue has previously been closed with that as a reference comment. This is true, eventually all above widgets will support elevation, and hopefully also expose shadow and tint colors as both widget and theme properties. But it is not likely that the M3 implementation for all widgets with this issue will arrive very soon.
The fact that there are no more widgets implemented that would support and fix its elevation issue in M3, in latest master channel, compared to stable 3.0.4, implies that M3 support for any of the widgets with this issue might not even be landing in next stable release. This further underlines why some kind of urgent and/or intermediate fix for the underlying
Material
widget is needed whenuseMaterial3
is set to true.As also demonstrated in this issue, the Material elevation issue with M3 is much more widespread than previously reported, and very troublesome or close to impossible to work around. This makes early adoption of M3 in Flutter a less than pleasant experience.
Current design will also require extra work to migrate custom/composed widgets to M3 that are based on
Material
, which is a very common building block. This will further increase migration friction and slow down its adoption in existing applications.Issue Demo App
In the issue demo app, we can see examples of Flutter SDK widgets that get no elevation when switching to M3. The demo app can switch dynamically between M2 and M3 theme. In addition to the demo theme colors. It only includes the above listed widget as examples, that currently are known to have the
Material
M3 based elevation issue. There might be more widgets usingMaterial
not included here that exhibit the same issue.The issue demo app is available in DartPad for convenience here: https://dartpad.dev/?id=c927904ebd995dd849efc0e7ac958630
The live DartPad example uses Flutter stable 3.0.4, but the issue and results are the same on latest Flutter master 3.1.0-0.0.pre.1515.
Issue Demo App Source Code
M3 demo of no elevation on PopupMenuButton, BottomNavigationBar, NavigationRail, AlertDialog
M3 demo of no elevation on TimePickerDialog, DatePickerDialog
M3 demo of no elevation on MaterialBanner, BottomSheet
This also shows how the underlying
Material
behaves, that causes the elevation issue for all the other widgets. As can be seen, only elevation specified begets no elevation ofMaterial
whenuseMaterial3
is set to true. In a way this also breaks past and expected behaviour of theMaterial
widget.Flutter doctor
The text was updated successfully, but these errors were encountered: