[Bug]: Table header not respecting container-level dark mode

[TrevorBurnham]

Browser

No response

Package version

v3.0.1156

React version

No response

Description

I have a table that renders inside of a div with the dark mode class. Previously, that table rendered with the correct dark mode styles. However, the background color in the table header recently became incorrect:

To be clear, the table looks fine if the whole page is in dark mode. The styles are only broken if the page is in light mode but the container around the table is in dark mode.

Source code

No response

Reproduction

Add this demo to pages/table/dark-mode-container.page.tsx and run npm start:dev:

// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import React from 'react';

import Header from '~components/header';
import Link from '~components/link';
import Table, { TableProps } from '~components/table';

import ScreenshotArea from '../utils/screenshot-area';
import { ARIA_LABELS, createSimpleItems, simpleColumns } from './shared-configs';

const items = createSimpleItems(5);

const columnDefinitions: TableProps.ColumnDefinition<(typeof items)[number]>[] = [
  {
    id: 'text',
    cell: item => <Link>{item.text}</Link>,
    header: 'Text',
  },
  {
    id: 'number',
    cell: item => item.number,
    header: 'Number',
  },
];

export default function DarkModeContainerPage() {
  return (
    <>
      <h1>Table in dark mode container</h1>
      <ScreenshotArea disableAnimations={true}>
        <div className="awsui-dark-mode" style={{ padding: '20px', background: '#0f1b2a' }}>
          <Table
            header={<Header>Table in dark mode</Header>}
            columnDefinitions={columnDefinitions}
            items={items}
            ariaLabels={ARIA_LABELS}
          />
        </div>
      </ScreenshotArea>
    </>
  );
}

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[jperals]

Hi,

Is there a reason why you would want to render an element in dark mode with the page being in dark mode, instead of using applyMode from the globalStyles package to set the visual mode globally? Even if this undocumented behavior might have changed, this was never a supported use case.

[TrevorBurnham]

This pattern is used within Cloudscape: The TopNavigation component has the dark mode class, automatically styling all components within that navigation element with the dark mode theming, regardless of the surrounding page.

My application has a top navigation with a searchbox. The searchbox results table is rendered in an overlay that (in terms of HTML) is nested within the top navigation, so it inherits the dark mode class. I think that makes aesthetic sense: It helps keep the relationship between the results table and the top navigation clear. (You can see this pattern in the AWS console top navigation.)

It's true that the documentation doesn't mention this functionality, but I think the ability to have "local dark mode" should be supported.

From my investigation, I believe this was broken by a recent change to @cloudscape-design/theming-build: cloudscape-design/theming-core#130 cc @jkuelz

[TrevorBurnham]

I've submitted a patch: cloudscape-design/theming-core#132

[jkuelz]

The TopNavigation component technically doesn't use the awsui-dark-mode class at all. It uses a visual context that picks all (or almost all) of the the dark mode token values and set them as the new default for that context. This is the way that visual contexts work, and it's the reason we needed to implement #4085 alongside theming-core #130.

Modals are not subject to visual contexts as they are not children of the original context in the DOM. If in your case, the overlay is a child within the top-navigation component (and not in another layer), then you shouldn't need the awsui-dark-mode class at all, and the dark mode tokens should be applied automatically since it is within the top-nav visual context. You can see in the screenshot below:

[TrevorBurnham]

🤯 Using .awsui-context-top-navigation does indeed fix my issue. Appreciate it!

I'm still not sure why you'd want the behavior of .awsui-dark-mode to be inconsistent (setting dark mode values for some tokens but not others), which is a side effect of cloudscape-design/theming-core#130 that cloudscape-design/theming-core#132 would address.

[jperals]

Hi @TrevorBurnham, would it also work to use the modal's modalRoot or getModalRoot properties so that it renders within the top navigation instead of the body root?

Even if using the awsui-context-top-navigation class works, this is not official public API so we can't 100% guarantee it will continue to work in the future

[jperals]

I think I misread the thread in concluding that you were using a modal. In any case, as said, that class is not official API. Visual contexts are currently used only internally by our components and are not meant to be used independently: https://cloudscape.design/foundation/visual-foundation/visual-context/#how-can-i-use-visual-context-in-my-application

[TrevorBurnham]

Yes, having an official API for visual context (e.g. a VisualContextProvider component) would be an ideal solution for my problem.

[jperals]

Makes sense. This is something we have in our radar. Changing the label from bug to enhancement.