Status Update
No update yet.
Comments
ia...@google.com
After discussing, keeping these values makes sense so that we'll match the pattern established elsewhere (e.g., Scaffold). We should update the kdoc to make it more clear that these apply across the entire NSS area, including the content. I'll separately add details to DAC.
le...@google.com
This is the current kdoc of the different colors params of the NSS:
@param navigationSuiteColors [NavigationSuiteColors] that will be used to determine the container
(background) color of the navigation component and the preferred color for content inside the
navigation component
@param containerColor the color used for the background of the navigation suite scaffold. Use
[Color.Transparent] to have no color
@param contentColor the preferred color for content inside the navigation suite scaffold.
Defaults to either the matching content color for [containerColor], or to the current
[LocalContentColor] if [containerColor] is not a color from the theme
so do you want to add something to the contentColor param part? It already mentions it affects the content. Could you help me clarify what is needed?
ia...@google.com
I think it's both containerColor and contentColor that aren't fully clear, but part of that is just that the main content is technically inside of the NSS but might not be in the developer or designer's mental model (especially because of the trailing lambda syntax.
Maybe something like:
@param containerColor the color used for the background of the navigation suite scaffold, including the passed content composable. Use [Color.Transparent] to have no color
The contentColor is harder because 'content' in that context means the Material3 concept (sort of, the 'ink' that's used for UI on the Surface) but it basically just applies to the content lambda since the navigation UI components have theirs set separately. AFAICT, this isn't talked about on the mio site and M3 doesn't seem to have a page for Surface like M2 did (best I could find was "Surface – A role used for backgrounds and large, low-emphasis areas of the screen."), so I'm not sure what the best language is.
Here's what I've got so far:
@param contentColor the preferred color to be used for typography and iconography within the content lambda. This defaults to the 'on' color of the [containerColor] or to the current [LocalContentColor] if [containerColor] is not a color from the theme
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3-adaptive-navigation-suite:1.0.0-alpha06androidx.compose.material3:material3-adaptive-navigation-suite-android:1.0.0-alpha06androidx.compose.material3:material3-adaptive-navigation-suite-desktop:1.0.0-alpha06
Description
NavigationSuiteScaffold draws a Surface using
This covers the whole scaffold, including the content lambda. It's a bit unclear what the intended usage is. For example, contentColor will override the color of text in the content lambda but not the nav items (since they have their own colors set separately). It seems a bit odd to have the scaffold affect the content in that way, but I'm not sure if there was a specific intent behind this.
The default Compose templates uses this layout:
So maybe the intent is to replace the default surface with the NavigationSuiteScaffold?