css/commerce.base.css sets the admin palette as fixed light-mode values on :root (--commerce-color--light: #f3f4f9, --commerce-color--dark: #232429, --commerce-color--border) with no dark-theme override, so under a dark admin theme those regions render as light panels while their contents keep the theme's dark styling.

Worst case is the order item inline form on the order edit form (modules/order/css/commerce_order.admin-order.css:146): Gin's #d2d3d3 labels on a #f3f4f9 panel, about 1.4:1 against the 4.5:1 required by WCAG 2.1 SC 1.4.3 - screenshot attached. The dashboard inbox and management links do the same (css/commerce.inbox.css:42,153, css/commerce.management-links.css:38). Any dark admin theme hits it, not just Gin. Seen on Drupal 11.4.6, Commerce 3.3.8, Gin 5.0.15.

Suggested fix: derive the surfaces from the text color already inherited from the admin theme - no theme detection, light mode unchanged.

:root {
  --commerce-color--light: color-mix(in srgb, currentColor 4%, transparent);
  --commerce-color--border: color-mix(in srgb, currentColor 20%, transparent);
  --commerce-color--icon-bg: color-mix(in srgb, currentColor 45%, transparent);
}

--commerce-color--dark can then become inherit at its two text call sites (css/commerce.inbox.css:93, css/commerce.management-links.css:29).

Steps to reproduce:

  1. Clean Drupal 11.4 install, then composer require drupal/commerce:^3.3 drupal/gin:^5.0 and drush en commerce_order commerce_product.
  2. Set Gin as the admin theme and enable dark mode at /admin/appearance/settings/gin.
  3. Add a store, a product with a priced variation, and an order with one order item.
  4. Open the order edit form and click Edit on the order item row.

The inline form panel is light on a dark page, with unreadable labels and a near-invisible Cancel button. /admin/commerce shows the same on the inbox and management links, no order needed.

CommentFileSizeAuthor
commerce-gin-dark-mode-issue.png47.08 KBchizh273

Issue fork commerce-3620898

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

chizh273 created an issue. See original summary.

chizh273 opened merge request !736

chizh273’s picture

chizh273 commented
Status: Active » Needs review

jsacksick made their first commit to this issue’s fork.

majmunbog’s picture

majmunbog commented

Nice work @chizh273. The approach makes sense to me, but a few things.

Worth being explicit about which themes this actually covers. Canvas/CanvasText only track the OS preference when a theme opts into color-scheme, and Claro doesn't declare it anywhere, so on the current default admin theme this leaves dark mode unchanged and only shifts the light palette a little. It does work under contrib Gin and under core's default_admin, both of which set color-scheme: dark on .gin--dark-mode. Since that's where core is heading anyway the change makes sense, the summary just shouldn't imply Claro gets fixed too.

The border mix is too heavy. The old rgba(212, 212, 218, 0.8) composites to #dcdce1 on white, but color-mix(in srgb, CanvasText 20%, Canvas) gives #cccccc, which reads a lot harder on the dashboard cards and inbox rows. Around 13% matches. The --light value is spot on at 4%, so it looks like the border just didn't get the same treatment.

--commerce-color--dark: CanvasText turns body text pure black in light mode, from #232429. That's used for the management link labels and inbox text. Claro avoids pure black for body copy, so maybe color-mix(in srgb, CanvasText 88%, Canvas) instead.

The brand colors stay fixed and a couple of them don't hold up on a dark Canvas. Against Chrome's #121212, --danger #dc2323 is about 3.8:1 and --neutral #777 about 4.2:1, both under AA. --success and --warning are fine. Since dark readability is the point here, those two probably need handling or an explicit note that they're follow-up.

No fallback for color-mix. If it ever fails to resolve, the var substitution is invalid at computed-value time and background-color goes transparent, border-color goes currentColor. It's Baseline 2023 so probably fine, but declaring a plain hex first costs nothing.

Last one: commerce.toolbar.css goes out via hook_toolbar_alter in CommerceToolbarHooks.php, which means it renders on front-end pages in the front-end theme. So the badge at lines 114-118 resolves Canvas against Olivero rather than the admin theme. Nothing breaks today since Olivero doesn't set color-scheme, but it would for a front-end theme that does. Those lines should also use --commerce-color--surface and --commerce-color--dark instead of the raw keywords, so overrides stay in one place.