Preset Feature Feedback
When dashboard.setThemeMode('default' | 'dark') is called via @preset-sdk/embedded, Superset applies the chosen Ant Design theme via Emotion CSS-in-JS — there is no DOM-observable signal of which theme is active.
We are requesting that the SDK / Superset additionally set an attribute or class on the dashboard root (e.g. <body data-theme="dark">, or a class like superset-theme-dark / superset-theme-light) so custom CSS injected via the dashboard's css field can target the active theme.
We ship a design-system catalog as a single shared dashboard.css (injected into every embedded dashboard at deploy time). The catalog defines reusable component classes — badges, chips, status dots, distribution bars — used by Handlebars charts and HTML-emitting ag-grid table cells across ~all our customer-facing dashboards.
cPortal (our embedding application) lets users choose system / light / dark, and calls setThemeMode accordingly. Native Preset components (ECharts, ag-grid native renderers) adapt automatically via the Ant theme. But custom HTML in Handlebars templates and HTML metric cells cannot — they get their colors from hardcoded hex values in dashboard.css, with no way to know whether to use light or dark palette values.
The result: filled tier badges (e.g., Good / Moderate / Degraded) are rendered with text-inverse colors picked for a dark workspace; they look correct in dark mode and degrade — legible but visually off — in light mode. Our token system has light and dark hex values defined; we just can't reach the right ones at render time.
body.dark-mode / body.light-mode class selectors — empirically not applied in Superset 6 with Preset Cloud (verified 2026-05-13). Selector-based targeting from dashboard.css doesn't work.
var(--ant-color-*) CSS variables — don't resolve. Superset 6 uses Emotion CSS-in-JS, not Ant's cssVar mode, so the Ant tokens aren't accessible as CSS custom properties.
@media (prefers-color-scheme: …) — wrong signal. cPortal lets users choose a theme independent of their OS preference (a user on a dark OS can choose light cPortal), so prefers-color-scheme doesn't track the explicit setThemeMode choice.
Injecting a class from the embedding app — not possible. The Superset dashboard runs in a cross-origin iframe; the embedding app can attribute the iframe element but not its internal DOM.
When dashboard.setThemeMode('dark') resolves to a dark theme, set one of:
<body data-theme="dark"> on the dashboard document, OR
a class on the dashboard root (e.g. <body class="superset-theme-dark">), OR
a CSS custom property on :root we can read (e.g. --superset-theme-mode: dark)
…and the corresponding light variant when the mode resolves to light. For system mode, resolve to the current effective theme and update the signal when the resolved value changes.
Any of these enables CSS like:
[data-theme="dark"] .badge-tier-good { background: #27c190; color: #0e1a2e; }
[data-theme="light"] .badge-tier-good { background: #2c8a6e; color: #ffffff; }…which is the minimum needed to make custom CSS adapt cleanly to theme switching.
This affects any Preset Cloud customer who:
Embeds dashboards via @preset-sdk/embedded,
Supports more than one theme mode (light + dark, or system),
Authors any custom HTML in Handlebars charts or HTML metric/column expressions feeding ag-grid table cells.
For us specifically, it unblocks ~15+ embedded dashboards from rendering with one cohesive theme palette across native Preset components and our custom HTML.
We are currently shipping a dark-only catalog and documenting the constraint. Custom HTML renders correctly in dark mode and degrades visually (but remains functional) in light mode. We'd like to retire this workaround once a theme signal is available.
