UNPKG

@workday/canvas-kit-react

Version:

The parent module that contains all Workday Canvas Kit React components

github.com/Workday/canvas-kit

Workday/canvas-kit

66 lines • 3.74 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
import type { CanvasNumericalBrandTheme } from './types'; /** * Sana Canvas brand tokens for scoped `CanvasProvider` / popup forwarding. * Values are `var()` references to Sana brand variables — not merged from `defaultCanvasTheme`. * * Mirrors only what Sana's stylesheet itself defines: the `neutral` ramp, the `A300` step of * `primary`/`critical`/`caution`/`positive` (the one step Sana redefines for those families — a * stronger alpha wash on the matching hue), and the four `system.color.brand.*` tokens Sana * overrides. Every other key is intentionally omitted — Sana does not define a distinct value * for it, so writing it here would only reference the very variable being written (a `var()` * cycle that resolves to invalid, leaking the classic-theme fallback color instead of Sana's). * * `action.*` and `selected.*` are deliberately **not** set. Sana's stylesheet does not define * `--cnvs-brand-action-*` or `--cnvs-sys-color-brand-fg-selected`/`-surface-selected`; those are * derived downstream from the root theme. Forcing them here would pin values the root is meant * to own. * * Ramp values must reference `base.*` (the underlying palette), never `brand.*` of the same * name — CanvasProvider writes each entry onto the identically-named `--cnvs-brand-*` CSS * variable, so referencing `brand.*` here would create that same self-reference cycle. The * `system.color.brand.*` overrides are the exception: they target *different* CSS variables * (`--cnvs-sys-color-brand-*`) than the `brand.*` values they reference, so no cycle. * * Note this preset only covers brand tokens. The rest of Sana (shape, depth, type, non-brand * system colors) comes from the stylesheet's `[data-theme="sana-canvas"]` block — pass * `data-theme` to `CanvasProvider` alongside this preset and it is forwarded to portaled popups * so the full theme applies there too. */ export declare const sanaCanvasNumericalTheme: CanvasNumericalBrandTheme; /** * Pass to root `CanvasProvider` to forward Sana brand CSS variables onto popup containers * (menus, selects, modals, tooltips). * * **When to use it** * - **Required** when you cannot set `data-theme="sana-canvas"` on `<html>` (embedded apps, * microfrontends, third-party shells). Popups portal to `document.body` and will not inherit * a nested `data-theme` — this preset copies Sana brand vars onto the popup stack container. * - Also useful in tests without global Sana CSS, or custom popup hosts outside normal cascade. * * **When you can skip it** * - Prefer setting `data-theme="sana-canvas"` on `<html>` with Sana CSS imported. Popups then * inherit brand variables from the document and no `theme` prop is needed. * * Pass `data-theme="sana-canvas"` alongside it. That attribute is forwarded to popup stack * containers, so the rest of Sana (shape, depth, type, non-brand system colors) applies to * portaled content through the stylesheet's own `[data-theme="sana-canvas"]` block — this preset * covers brand tokens, the attribute covers everything else. * * `action.*` and selected-state tokens are not set by this preset — Sana does not define them, * and they resolve from the root theme. * * @example * ```tsx * // Preferred — control <html> * import '@workday/canvas-tokens-web/css/sana/_variables.css'; * // <html data-theme="sana-canvas"> * <CanvasProvider><App /></CanvasProvider> * * // No access to <html> — pass both for full parity, including portaled popups * <CanvasProvider theme={sanaCanvasProviderTheme} data-theme="sana-canvas"> * <App /> * </CanvasProvider> * ``` */ export declare const sanaCanvasProviderTheme: CanvasNumericalBrandTheme; //# sourceMappingURL=sanaTheme.d.ts.map