Update elevation overlay to apply in both light and dark theme

[rami-a]

As part of Material 3, the elevation overlay is changing in a few ways (link to https://material.io spec to come soon)

• it will now apply in both light and dark theme
• it will use a different color (primary) to blend with the surface and the calculation is slightly tweaked

[MCarlomagno]

Hi Rami, I would like to contribute to the Material 3 migration, but seems that there is no public official guideline to start working on it.
I see that some Google applications are starting to use it, so I guess there is a guideline but is still unpublished, is there a way to have access to it?

Thanks!

[rami-a]

Hey @MCarlomagno thanks for your interest in helping with Material 3! At the moment there is no public guidance but it will be published soon (in the next couple of weeks). At that time, we will have more of a concrete plan for how these updates will be brought to Flutter and should be able to accept your help then. Stay tuned!

[MCarlomagno]

Sounds good, thanks a lot for the info :)

[bernaferrari]

https://m3.material.io/components/cards/specs

[rydmike]

@rami-a on a related note.

I ran into some limitations when using more nuanced dark themes and the way the current elevation color is applied in the SDK by the applyOverlay function.

I proposed a fix for it here #90353 (comment) that would help. However, since I suspected that Material 3 would bring in some new features to this, I decided to wait and see what it brings. Also, I never got around to check if the fix would break any tests, it might not actually.

Looking at Material3 spec it looks like this will be interesting and certainly a new much more powerful and more nuanced way of handling it.

However, I don't think it will solve the issue I was having with the applyOverlay function in Material2. So I think it would still be nice if that worked more as expected and was applied more generally to Material surfaces by the applyOverlay function, by recognizing color property values that may be used by Material in various widget, both via colorScheme properties and the various legacy ThemeData background colors, while they still exist.

Current issue with applyOverlay on M2 Material using widgets

The current issue with applyOverlay is that overlay color is only applied to Material that happens to use a color value that is equal to the colorScheme.surface color value. Problems occur if you create dark themes where you have slightly nuanced differences on various background color properties, primarily then on colorScheme.background.

You might do so if you use eg slightly different colorScheme.primary color alpha blend strength for your colorScheme.background color, compared to colorScheme.surface, then you get no elevation overlay applied in dark mode to Widgets that use colorScheme.background as their default background color.

Actually most widgets still use the ThemeData colors cardColor or canvasColor/backgroundColor, depending on what type of Material the widget is using or widget. Those color properties in return are set to colorScheme.surface and colorScheme.background respectively, by ThemeData() factory or ThemeData.from() factory.

The ThemeData colors cardColor, canvasColor, backgroundColor and dialogBackgroundColor are known deprecation targets, but it would still be nice and proper to included them while they still exist, so the experience is more in line what can be expected from elevation overlay color. Still, even just adding colorScheme.background to the applyOverlay function, as a recognized Material surface color that should get elevation overlay in dark mode, when so configured, would go a long way.

[bernaferrari]

@rydmike you should collaborate on issue 91605 (I'm not even going to link it here).

[cedvdb]

Will this be opt in or every one will have that when it is available ? Just so I get a mental reminder there is a need to opt in.

[rami-a]

This change would be tied to the currently available useMaterial3 flag on ThemeData once it is implemented.

cc @darrenaustin

[github-actions]

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 flutter doctor -v and a minimal reproduction of the issue.