Regarding material and material3. In material there is an object called `ContentAlpha` which can hel...

# compose

[Stylianos Gakis]

Regarding material and material3. In material there is an object called ContentAlpha which can help by providing a high,medium,low alpha, adjusted properly for light/dark mode. I don’t see an equivalent existing in material3.
If I want to make an item had medium alpha for example, right now I am doing

CompositionLocalProvider(LocalContentColor provides LocalContentColor.current.copy(ContentAlpha.medium))

But I am mixing LocalContentColor from m3 and ContentAlpha from m2, which makes me feel like I am either missing something, or that m3 doesn’t want you to do it this way.

[Albert Chang]

See this thread.

[Kirill Grouchnikov]

M3 has moved to use tonal elevation. See the section at https://m3.material.io/styles/color/the-color-system/color-roles#8edc07d2-1579-4891-819f-b3a182704b19

[Kirill Grouchnikov]

The same applies in general for “distinguishing” two areas, like surface and surfaceContainer.

[Stylianos Gakis]

Oh damn okay, thanks a lot for the links here! So when I got some text which the design is that it should look like it’s “disabled” aka not interactive, and they give me the design where it looks that way, what is the m3 way to indicate this situation?

[Stylianos Gakis]

I see that for button for example, the ButtonColors also take a disabledContentColor and you got tokens specified for these cases https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]%20buttonColors&ss=androidx%2Fplatform%2Fframeworks%2Fsupport
But for a generic “This is some disabled text”, I guess I got to specify my own tokens which is more or less going to be what ContentAlpha does, and apply that as alpha to the contentColor.

[Kirill Grouchnikov]

Yes, disabled state is still using alpha

[Stylianos Gakis]

Right, but there isn’t a specific disabled case for Text itself. Other components like Button have their disabled: Boolean parameter which is very convenient on the other hand.
Where is this last picture from in the docs?

[Kirill Grouchnikov]

https://m3.material.io/components/buttons/specs#c46608e1-3820-4da5-b1ec-b913992852f1

[Chris Sinco [G]]

We have some migration guide material on this as well: https://developer.android.com/jetpack/compose/designsystems/material2-material3#emphasis-and

[Stylianos Gakis]

Wow thanks Chris, this seems to be exactly what I'm looking for.

Some questions.

For the snippet

// Disabled emphasis
CompositionLocalProvider(LocalContentColor provides MaterialTheme.colorScheme.onSurface.copy(alpha = 0.38f)) {

Shouldn't the "onSurface" be contentColor? Since if you're somewhere where the text should be something else it should still work.

Also the 0.38f alpha for disabled seems to be used for the disabled alpha. I assume this time we don't get this special treatment where for high luminescence colors we get a slightly different one than when we got low luminescence. And since it's used universally, wouldn't it be very convenient for the m3 library to expose it as a constant somehow so that it doesn't feel like a magic number in all the places I'll be using it?

Also interesting that for m2, the default emphasis was that content alpha was 1f, so you had the default, and then the normal and disabled as a way to go 2 steps down this scale.
For m3 the default is FontWeight.Normal, and then you got the high emphasis (bolt) which is one step up, and the disabled which is one step down on this scale. Really hard to do a 1:1 mapping this way if your existing design has a normal (1f alpha) emphasis, and then 2 lower ones, since this doesn't match the m3 spec. But anyway, gonna have to figure smth out.

[Kirill Grouchnikov]

Alpha-based color blending doesn't work well/ constantly across the entire gamut of hues, hence the move to tonal surfaces

[Stylianos Gakis]

Hmm coming back to this, I have read the section here https://m3.material.io/styles/color/the-color-system/color-roles#8edc07d2-1579-4891-819f-b3a182704b19 as you suggested, but it seems like what’s specified there vs what we’re working with is quite different.
For example for the surface + bottom nav bar section, they suggest using “surface” for the content, and “surface container” for the navigation bar.
In the compose material3 lib, what seems to be done instead is that the surface color is used, only with an elevation of value ElevationTokens.Level2 which is 3.dp. And then this does this tonal elevation trick to get a different color.
It’s very confusing looking at the material docs and how they don’t exactly apply to what we also use in code, since I have to just trust that the right thing is used, and if I want to make a custom component myself trying to follow some of the specs defined there, I wouldn’t know how to achieve it.

[Kirill Grouchnikov]

Level2 refers to the old surface roles. The new ones are referred to as tonal surfaces. The implementation might not have caught yet to the new spec in all the places.

[Stylianos Gakis]

Right, but in that case nothing has caught up yet, since everything is using these elevation tokens to get a different tonal elevation to differentiate a surface from another. All the material components, like NavigationBar do exactly this, use just surface color, and make themselves different by applying tonal elevation. But I don’t see any reference to that in these docs

[Kirill Grouchnikov]

It'll get there

[Stylianos Gakis]

Alright alright, I was just getting into the weeds of understanding this again as I'm doing some work with colors on our app which uses like 80% material stuff and 20% our stuff, and I wanted to get this right.

But thanks a lot for the heads up. Since m3 version 1.1 is out now, with a lot of super nice work getting out in the stable release, I wonder if something like this is up next in the Todo list. Do you know something about that perhaps?