Let's talk about inverse component design and implementation

[zarahzachz]

What does inverse mean?

This example for MonthPicker gives a good idea; it's a dark background (I think based on a theme's primary color) and the component styles are altered to fit the newly assigned context.

What's the big deal?

I see a few issues with our current inverse implementation:

1. We don't know if it's actually being used
2. We don't offer guidance showing which components having inverse support or when using an inverse pattern is OK
3. Possible accessibility concerns
4. Developer experience could be improved

We don't know if it's actually being used

This one's pretty self-explanatory - we don't know if this is a pattern used by teams. I've heard form elements aren't intended to have inverse support, but we still offer this as an example in our documentation and the code still supports it. If nobody's using these patterns, or if the usage is more selective than we show, we should update our DS to reflect that.

The other issues mentioned are only valid if this is a pattern being used.

We don't offer guidance showing which components having inverse support or when using an inverse pattern is OK

Not all components support an "inverse" option and we don't offer guidance for users to know when to use this pattern and what this pattern supports.

The DS supports a handful of inverse components:

• Button
• Form elements, including
  • text fields
  • Choice
  • ChoiceList
  • MonthPicker
• SvgIcon
• Spinner
• Tooltip

Because we have a subset of components with inverse support, do we know if teams are creating their own "inverse" styles for components like Accordion, Alert, FilterChip, etc.?

Possible accessibility concerns

If we go back to the MonthPicker example linked above, the contrast ratio between a selected checkbox and the inverse Healthcare background isn't that great.

If you look at CMSgov's Buttons on dark backgrounds, it doesn't support color blindness (as in, users won't be able to tell the visual weight of one button from another unless its styles are drastically different, e.g., pairing ghost buttons with solid buttons)

Developer experience could be improved

To use an "inverse" component, or to create an "inverse" pattern, developers have to apply an inversed prop to each component within an inverse context. See following code for the gist:

<div class="dark-background-color">
  <TextField label="Enter your name" inversed {...props} />
  <MonthPicker label="Select the months you ate eggs" inversed {...props} />
  <Button inversed {...props}>Submit egg eating form</Button>
</div>

It's a convoluted example, but what I'm getting at is the inclusion of all those inversed props. I think the reason this prop exists was in case an application wanted to use any of our utility background colors? So being presented with an unknown number of options, we just provided an escape hatch that instructs each component how they should display. But a better approach might be...

<div class="dark-background-color ds-palette-inverse" data-inverse="true">
  <TextField label="Enter your name" {...props} />
  <MonthPicker label="Select the months you ate eggs" {...props} />
  <Button {...props}>Submit egg eating form</Button>
</div>

The idea here being a developer could add either ds-palette-inverse or a data attribute and anything added within would inherit the correct styles. This seems like a nicer approach for teams because they'd no longer have to apply the same prop to a bunch of components AND we could eventually drop the inverse prop from our JS and let CSS do the work instead.

Next steps

I discussed this during office hours today and a few options were brought up (hinging on whether teams actually use this pattern).

1. Code improvements should hold off until design's done its thing
2. Design should review a11y concerns in existing patterns
3. We might want to hide the inverse pattern until a review's happened

[zarahzachz]

We also discussed using light-dark() for this, but

1. Using light-dark for our inverse problem may preclude it from being used to address any light/dark mode work in the future
2. It doesn't have full browser support yet

[zarahzachz]

It just dawned on me that another DX solution could be that users apply a font color utility class to a wrapper and call it a day. Like this:

<div class="dark-background-color ds-u-color--white">
  <TextField label="Enter your name" {...props} />
  <MonthPicker label="Select the months you ate eggs" {...props} />
  <Button {...props}>Submit egg eating form</Button>
</div>

🪄 through the magic of inheritance, the text colors of all components within receive whatever color the parent dictates.