You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The light mode on color for onPrimaryContainer, onSecondaryContainer, onTertiaryContainer and onErrorContainer were changed from 10 to 30 for all MaterialDynamicColors except Fidelity and Monochrome. They also had their contrast curve requirement reduced.
While this increases the "color expression" on these containers and their on color, it also significantly reduces the contrast with the normal contrast level, to become quite low. To the extent that with some color combination it feels like a reduction in design fidelity.
The change is illustrated with this change using the default TonalSport using the past default seed color #FF6750A4.
.
I was trying to find a spec update concerning this tone change in the Material3 guide, but was unable to do so.
Is this commit based on some additional not yet published changed to the M3 spec?
As far as I can see, the Material3 baseline still specifies tone 10 for all these on colors and not 30:
Also the baseline colors in the M3 guide color scheme are not based on the default MCU TonalSpot scheme, even prior to this tone change. In fact currently with a seed color and using MCU MaterialDynamicColors you cannot replicate the baseline color scheme with any seed color or MaterialDynamicColors variant. With the past scheme based you could get the baseline scheme with seed color #FF6750A4.
Is there also a plan to change and update the baseline ColorScheme?
Just from a practical point of view, the new color "expressive" on color tones in light mode, produces container contrast in light mode with normal contrast setting that is often too low and not acceptable, making the otherwise normal contrast not very usable.
Going forward, I'm going to use a fork that offers this expressive variant as an extra deliberate opt-in feature and deviate from this new standard by keeping the old one as default, as this new one is less usable than before.
The text was updated successfully, but these errors were encountered:
Concerning Material Color Utilities (MCU) expressive on-colors
In a recent commit here:
Update MCU to for expressive on-colors.
The light mode on color for
onPrimaryContainer
,onSecondaryContainer
,onTertiaryContainer
andonErrorContainer
were changed from 10 to 30 for allMaterialDynamicColors
except Fidelity and Monochrome. They also had their contrast curve requirement reduced.While this increases the "color expression" on these containers and their on color, it also significantly reduces the contrast with the normal contrast level, to become quite low. To the extent that with some color combination it feels like a reduction in design fidelity.
The change is illustrated with this change using the default
TonalSport
using the past default seed color#FF6750A4
..
I was trying to find a spec update concerning this tone change in the Material3 guide, but was unable to do so.
Is this commit based on some additional not yet published changed to the M3 spec?
As far as I can see, the Material3 baseline still specifies tone 10 for all these on colors and not 30:
https://m3.material.io/styles/color/static/baseline#b5a485b5-ee5f-4890-b7a2-ead284121e37
Also the baseline colors in the M3 guide color scheme are not based on the default MCU TonalSpot scheme, even prior to this tone change. In fact currently with a seed color and using MCU
MaterialDynamicColors
you cannot replicate the baseline color scheme with any seed color orMaterialDynamicColors
variant. With the past scheme based you could get the baseline scheme with seed color#FF6750A4
.Is there also a plan to change and update the baseline ColorScheme?
Just from a practical point of view, the new color "expressive" on color tones in light mode, produces container contrast in light mode with normal contrast setting that is often too low and not acceptable, making the otherwise normal contrast not very usable.
Going forward, I'm going to use a fork that offers this expressive variant as an extra deliberate opt-in feature and deviate from this new standard by keeping the old one as default, as this new one is less usable than before.
The text was updated successfully, but these errors were encountered: