I'm a bit confused with the magic of compose regarding LocalContentAlpha. Generally our development ...

# compose

[Paul Woitaschek]

I'm a bit confused with the magic of compose regarding LocalContentAlpha. Generally our development workflow is that the designers build screens and define colors for each text.
But now lots of prebuild composables change the LocalContentAlpha which leads to the situation that text colors are always different from what our designers intended. This usually leads to QA reviews like: "Can you check the text color of component a, b and c? It's different from what's in the ardboard".
The only way around that I found so far is to always wrap everything in another CompositionLocalProvider(LocalContentAlpha provides ContentAlpha.high). But that's a lot of overhead and it feels like working against the system.

[Louis Pullen-Freilich [G]]

Does your design system not use alpha for text / icons? It seems strange that you would always want the value to be high - different components by design / by specification use different levels of alpha to represent relative emphasis. For example a disabled component with ContentAlpha.high text could easily be mistaken for an enabled component

[Paul Woitaschek]

Upon further debugging this I think I don't understand what compose is doing with colors at all.

[Paul Woitaschek]

MaterialTheme {
    CompositionLocalProvider(
      LocalContentColor provides Color.Red
    ) {
      Text("Hello World")
    }
  }

[Paul Woitaschek]

#FE2020
Is the color it shows. But why isn't it val Red = Color(0xFFFF0000)? #FF0000

[Louis Pullen-Freilich [G]]

MaterialTheme sets ContentAlpha.high as the default for LocalContentAlpha, and Text will use `

LocalContentColor.current.copy(alpha = LocalContentAlpha.current)

by default if a color is not explicitly set