[Feature Request]: Add <Layer> to all Carbon containers that change the background-color to $layer

[wkeese]

The problem

Whenever we use a component like <Tile> we need to wrap <Layer> around the Tile’s contents:

<Tile>
    <Layer>
        <TextInput .../>
        ...
    </Layer>
</Tile>

This is because _tile.scss sets

background-color: $layer;

... and so you need the <Layer> to make child <TextInput> etc. have a background that contrasts with the Tile's background.

Otherwise it ends up looking like this:

The solution

Make Tile, ExpandableTile, and Tabs add Layer when they change the background color.

• Tile - example mentioned above
• ExpandableTile - Basically same as Tile. The example at https://react.carbondesignsystem.com/?path=/story/components-tile--expandable-with-interactive looks wrong to me because the input has the same background as the tile. Or at least, that shouldn't be the default behavior. Notice also how Tile.featureflag.stories.js had to manually add a <Layer>; that shouldn't be necessary.
• ComposedModal - This already has a <Layer level={0}> and <Layer> builtin, so it's good.
• Tabs (Contained) - Look how https://react.carbondesignsystem.com/?path=/story/components-tabs--contained needs to manually add a Layer, even though Carbon is responsible for changing the background color. But Tabs are complicated because the contained attribute is on the <TabList> component, but it affects how the <TabPanel> components renders.

Also need to update @carbon/ibm-products' Tearsheet and TearsheetNarrow, but that's a different bugdb.

Examples

Tile

Application/PAL

IKC

Business priority

None

Available extra resources

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[kennylam]

Hi @wkeese, can you elaborate a bit more about this, i.e., would it provide any additional functionality apart from saving users from typing out <Layer /> tags? I'm wondering how this would affect users who do not want to include Layer in their markup.

[wkeese]

Hi @wkeese, can you elaborate a bit more about this, i.e., would it provide any additional functionality apart from saving users from typing out <Layer /> tags?

It's like asking: why does Carbon's _tile.scss setting background-color: $layer? Does it provide any additional functionality apart from saving users from typing out background: $layer?

I would like Carbon to just work correctly out-of-the-box, rather than users having to tweak it.

In other words, the answer to your question is "no", but it's a strange question, because everything @carbon/react does is to save users from typing out JS or markup. This is no different.

I'm wondering how this would affect users who do not want to include Layer in their markup.

You're asking how users can get a non-standard coloring for the TextInput etc. components. You either use <Layer> or <Theme> or (as a last resort) just override Carbon's CSS directly.

But why are those users contradicting IBM's designated styling for TextInputs?

In other words, Carbon should be optimized for the common case.

---

Basically, background-color: $layer should always be paired with <Layer>. That's the point of this ticket.

[sstrubberg]

Hey @wkeese, would you be open to attending Carbon Office Hours? This change could have wider implications across the system and we want to make sure we understand this use-case. Thanks!

[tay1orjones]

Yeah to share some more context, adding Layer to ComposedModal made sense because Modal always needs that layer bump.

For Tile and Tabs there are potential use cases where a Layer is not needed or desired. If we force a layer on these components, there's no way to opt out other than adding 2 more Layer to "loop" back around to the base layer.

If the office hours discussion still lands on forcing a Layer in these components, we need to consider it's probably a breaking change. For ComposedModal we already had styles in place that made sure layer styles were correct for all the inputs, etc. but Tile and Tabs don't have that. Consumers who have already configured a Layer with these would be impacted by a Layer being added to the components.

[wkeese]

Hey @wkeese, would you be open to attending Carbon Office Hours?

That's really difficult for me, it's literally the middle of the night here.

For Tile and Tabs there are potential use cases where a Layer is not needed or desired. If we force a layer on these components, there's no way to opt out other than adding 2 more Layer to "loop" back around to the base layer.

Can you give some practical examples? The devil is in the details.

I saw in https://react.carbondesignsystem.com/?path=/story/components-tile--expandable-with-interactive where the input has the same background as the tile, but (as I said above) it looks like a mistake to me, not a feature.