pixelize-design-library 2.4.2-beta.43 → 2.4.2-beta.44

package/dist/esm/Theme/chakra/Menu.styles.js

@@ -4,21 +4,7 @@ import { listRowBackgrounds } from "../tokens/builders/rowStates.js";
 import { paletteOf } from "./paletteFromTheme.js";
 const { defineMultiStyleConfig, definePartsStyle } = createMultiStyleConfigHelpers(menuAnatomy.keys);
 const $bg = cssVar("menu-bg");
-/**
- * Chakra's own MenuList baseStyle hardcodes `--menu-bg` to "#fff" (gated behind `_dark`, which
- * this theme-swap app never triggers — see createBrandTheme's colorMode comment), so every
- * bare `<MenuList>` in every consuming app renders a white dropdown on the dark canvas. A `bg`
- * prop set by a call site only recolors the list's own box, not this var — which `MenuItem`'s
- * `_focus`/`_active`/`_expanded` states read — so both must come from the theme, not per call
- * site (already duplicated at every fix-it-locally call site: NavigationBar, ButtonGroupIcon,
- * ThemeSwitcher's BrandMenu/MenuVariant).
- *
- * Chakra's own MenuItem baseStyle then RE-hardcodes the same `--menu-bg` var on `_focus`/
- * `_active`/`_expanded` (to `colors.gray.100`/`.200`, also `_dark`-gated) — so even with `list`
- * fixed above, hovering/focusing an item snaps the var back to a near-white literal. Override
- * `item` here too, to a theme-driven hover tint, or every hover state stays white regardless of
- * the list fix.
- */
+// NOTE: fixes Chakra's MenuList/MenuItem both hardcoding --menu-bg to white via dead _dark — item needs its own var too, or hover snaps back to white.
 const $itemBg = cssVar("menu-item-bg");
 const baseStyle = definePartsStyle(({ theme }) => {
     const colors = paletteOf(theme);
@@ -27,20 +13,13 @@ const baseStyle = definePartsStyle(({ theme }) => {
     const activeBg = rowBgs.selectedActive;
     return {
         list: {
-            [$bg.variable]: colors.backgroundColor.light,
+            [$bg.variable]: colors.surfaceRaised,
             bg: $bg.reference,
             color: colors.text[900],
-            // A rule at CHROME_RULE weight, not Chakra's gray.200: that default read as a hard edge,
-            // which is why this shipped borderless. At 1.31:1 the edge defines the surface instead.
             borderWidth: "1px",
             borderStyle: "solid",
             borderColor: colors.boxborder[200],
         },
-        // Own CSS var (`--menu-item-bg`), NOT the list's `--menu-bg` — Chakra's stock item
-        // baseStyle rewrites `--menu-bg` itself on hover/focus, so reusing that same var name
-        // here for the item's resting bg risked the two colliding under the same custom
-        // property. A dedicated var keeps the item's hover/focus tint fully independent of the
-        // list's background var.
         item: {
             bg: "transparent",
             _focus: { [$itemBg.variable]: hoverBg, bg: $itemBg.reference },

package/dist/esm/Theme/chakra/Modal.styles.js

@@ -1,21 +1,23 @@
 import { paletteOf } from "./paletteFromTheme.js";
 import { createMultiStyleConfigHelpers, cssVar } from "@chakra-ui/react";
 import { modalAnatomy } from "@chakra-ui/anatomy";
+import { dialogPartStyles } from "./overlay.styles.js";
 const { defineMultiStyleConfig, definePartsStyle } = createMultiStyleConfigHelpers(modalAnatomy.keys);
 const $bg = cssVar("modal-bg");
-/**
- * Chakra's own Modal baseStyle hardcodes `--modal-bg` to "colors.white" (gated behind `_dark`,
- * which this theme-swap app never triggers — see createBrandTheme's colorMode comment), so every
- * `<ModalContent>` in every consuming app renders a white dialog on the dark canvas — the same
- * bug class `Menu.styles.ts` already fixes for dropdowns.
- */
-const baseStyle = definePartsStyle(({ theme }) => ({
-    dialog: {
-        [$bg.variable]: paletteOf(theme).backgroundColor.light,
-        bg: $bg.reference,
-        color: paletteOf(theme).text[900],
-    },
-}));
+// Chakra's stock `--modal-bg` is a literal white behind `_dark`, which this palette-swap theme never enters.
+const baseStyle = definePartsStyle(({ theme }) => {
+    const colors = paletteOf(theme);
+    const parts = dialogPartStyles(colors);
+    return {
+        ...parts,
+        dialog: {
+            ...parts.dialog,
+            [$bg.variable]: colors.surfaceRaised,
+            bg: $bg.reference,
+            borderRadius: "xl",
+        },
+    };
+});
 export const Modal = defineMultiStyleConfig({
     baseStyle,
 });

package/dist/esm/Theme/chakra/Popover.styles.js

@@ -4,23 +4,15 @@ import { paletteOf } from "./paletteFromTheme.js";
 const { defineMultiStyleConfig, definePartsStyle } = createMultiStyleConfigHelpers(popoverAnatomy.keys);
 const $popperBg = cssVar("popper-bg");
 const $arrowShadowColor = cssVar("popper-arrow-shadow-color");
-/**
- * Same bug class as Menu (Wave G): Chakra's own Popover baseStyle hardcodes `--popper-bg` to
- * "#fff" and `--popper-arrow-shadow-color` to `colors.gray.200`, both gated behind `_dark`, which
- * this theme-swap app never triggers (see Menu.styles.ts / createBrandTheme's colorMode comment).
- * Every bare `<PopoverContent>` renders a white card with a light arrow shadow on the dark canvas.
- * `--popper-arrow-bg` is left alone — Chakra's own baseStyle already points it at `$popperBg`, so
- * fixing `$popperBg` here fixes the arrow fill too.
- */
+// NOTE: fixes Chakra's Popover hardcoding --popper-bg/#fff via dead `_dark` — fixing $popperBg also fixes the arrow fill.
 const baseStyle = definePartsStyle(({ theme }) => {
     const colors = paletteOf(theme);
     return {
         content: {
-            [$popperBg.variable]: colors.backgroundColor.light,
+            [$popperBg.variable]: colors.surfaceRaised,
             bg: $popperBg.reference,
             [$arrowShadowColor.variable]: colors.boxborder[200],
             color: colors.text[900],
-            // Matches Menu: a CHROME_RULE-weight edge, not Chakra's gray.200 hard edge.
             borderWidth: "1px",
             borderStyle: "solid",
             borderColor: colors.boxborder[200],

package/dist/esm/Theme/chakra/Slider.styles.js

@@ -3,12 +3,7 @@ import { createMultiStyleConfigHelpers, cssVar } from "@chakra-ui/react";
 import { sliderAnatomy } from "@chakra-ui/anatomy";
 const { defineMultiStyleConfig, definePartsStyle } = createMultiStyleConfigHelpers(sliderAnatomy.keys);
 const $thumbBg = cssVar("slider-thumb-bg");
-/**
- * Chakra's own Slider thumb baseStyle hardcodes `bg: "white"` with no `_dark` gate at all (unlike
- * track/filledTrack, which at least have one Chakra's own colorMode never triggers here) — so
- * every bare `<SliderThumb>` renders a literal white circle on the dark canvas regardless of mode,
- * same bug class as Menu/Modal but without even the dead `_dark` branch.
- */
+// NOTE: fixes Chakra's SliderThumb hardcoding bg: "white" with no _dark gate at all.
 const baseStyle = definePartsStyle(({ theme }) => ({
     thumb: {
         [$thumbBg.variable]: paletteOf(theme).backgroundColor.light,

package/dist/esm/Theme/chakra/common.web.js

@@ -1,8 +1,4 @@
 import { space, sizes, radii, shadows, zIndices, breakpoints, lineHeights, letterSpacings, } from "../tokens/primitives/index.js";
-/**
- * Web (Chakra) assembly of the pure primitives. `config.cssVarPrefix` is a Chakra
- * concern, which is why this assembly lives here and not in `tokens/`.
- */
 const common = {
     lineHeights,
     letterSpacings,
@@ -13,9 +9,7 @@ const common = {
     radii,
     zIndices,
     config: {
-        // Chakra's default, and it must stay that way. A custom prefix silently breaks every
-        // `var(--chakra-colors-*)` an app writes in plain CSS: the variable simply does not
-        // exist, so the fallback (usually #fff) wins and the surface renders white in dark mode.
+        // NOTE: must stay "chakra" — a custom prefix breaks every var(--chakra-colors-*) an app writes in plain CSS.
         cssVarPrefix: "chakra",
     },
 };

package/dist/esm/Theme/chakra/componentStyles.js

@@ -8,22 +8,18 @@ import { Select } from "../../Components/Select/Select.styles.js";
 import { Tag } from "../../Components/Tag/Tag.styles.js";
 import { Textarea } from "../../Components/InputTextArea/InputTextArea.style.js";
 import { NumberInput } from "../../Components/NumberInput/NumberInput.styles.js";
-import { accentTextOnCanvas, isDarkCanvas, onFilled } from "../tokens/builders/accentText.js";
+import { AA_NORMAL_TEXT, accentTextOnCanvas, isDarkCanvas } from "../tokens/builders/accentText.js";
 import { labelOnFill, solidFillRung } from "../tokens/builders/filledSurface.js";
-import { contrastRatio } from "../tokens/builders/color.js";
-import { resolveHoverTint } from "../tokens/builders/outlineRung.js";
+import { liftToContrast, resolveHoverTint } from "../tokens/builders/outlineRung.js";
+import { resolveSoftTone } from "../tokens/builders/tone.js";
+import { tooltipSurface } from "../tokens/builders/tooltipSurface.js";
 import { Drawer } from "./Drawer.styles.js";
 import { Menu } from "./Menu.styles.js";
 import { Modal } from "./Modal.styles.js";
 import { Popover } from "./Popover.styles.js";
 import { Slider } from "./Slider.styles.js";
-import { Switch } from "./Switch.styles.js";
-import { Tabs } from "./Tabs.styles.js";
-import { Avatar } from "./Avatar.styles.js";
-// `colorScheme` accepts any Chakra scale, including built-ins we never themed (blackAlpha,
-// whiteAlpha) whose rungs are translucent `rgba(...)` strings, not opaque hex — our contrast
-// math (hexToRgb) throws on those on purpose (see color.ts). Guard so those scales fall back to
-// Chakra's own original fixed rung instead of computing contrast on a color it can't parse.
+import { Card } from "./Card.styles.js";
+// NOTE: guards untethemed scales (blackAlpha/whiteAlpha) whose rgba() rungs would throw in hexToRgb.
 const isHexColor = (color) => typeof color === "string" && /^#([0-9a-f]{3}|[0-9a-f]{6})$/i.test(color);
 const solidFillStyle = (palette, swatch) => {
     const rung = solidFillRung(swatch, palette.white);
@@ -33,50 +29,53 @@ const solidFillStyle = (palette, swatch) => {
         color: isHexColor(bg) ? labelOnFill(bg, palette.white, palette.black) : swatch[800],
     };
 };
-// Badge isn't its own component family (no Components/Badge/), so its style config lives here —
-// Chakra's stock `solid` variant hardcodes a white label on a variable fill, same AA gap Tag had.
+// Badge isn't its own component family (no Components/Badge/), so its style config lives here.
 const Badge = {
+    baseStyle: {
+        borderRadius: "full",
+        textTransform: "none",
+        fontWeight: 500,
+        lineHeight: 1.2,
+        display: "inline-flex",
+        alignItems: "center",
+    },
+    sizes: {
+        sm: { fontSize: "0.75rem", px: 2.5, py: 1, minH: "1.5rem" },
+        md: { fontSize: "0.8125rem", px: 3, py: 1, minH: "1.75rem" },
+    },
     variants: {
         solid: ({ theme, colorScheme = "gray" }) => {
             const palette = paletteOf(theme);
             const swatch = scaleFor(palette, colorScheme);
             return solidFillStyle(palette, swatch);
         },
-        // Chakra's stock `subtle` picks its bg/color pair via `mode()`, keyed to Chakra's own
-        // colorMode — which this app never toggles (dark mode swaps the palette object instead), so
-        // it always takes the light-mode branch. Applied to our mode-reversed dark scales, that
-        // branch's fixed rung pair (100/800) measures 4.06 in dark mode, just under AA.
         subtle: ({ theme, colorScheme = "gray" }) => {
             const palette = paletteOf(theme);
             const swatch = scaleFor(palette, colorScheme);
-            const bg = swatch[100];
-            if (!isHexColor(bg))
-                return { bg, color: swatch[800] };
-            // accentTextOnCanvas keeps brand hue by trying this scale's own rungs first, but some
-            // narrow-gamut hues (e.g. yellow) don't reach far enough at either end to clear AA against
-            // every bg they can land on in dark mode (measured 4.42 for a reversed-yellow badge) — its
-            // own doc admits it falls back to "the most extreme rung" rather than guaranteeing AA. Verify
-            // the candidate actually clears AA; if not, drop brand hue for the guaranteed white/black ink
-            // (onFilled is provably >=4.5 against any bg) rather than ship a near-miss.
-            const accent = accentTextOnCanvas(swatch, bg);
-            if (contrastRatio(accent, bg) >= 4.5)
-                return { bg, color: accent };
-            return { bg, color: onFilled(bg, palette.white, palette.black) };
+            if (!isHexColor(swatch[100]))
+                return { bg: swatch[100], color: swatch[800] };
+            const tone = resolveSoftTone(palette, swatch);
+            return { bg: tone.bg, color: tone.fg };
+        },
+        outline: ({ theme, colorScheme = "gray" }) => {
+            const palette = paletteOf(theme);
+            const swatch = scaleFor(palette, colorScheme);
+            const canvas = palette.backgroundColor.main;
+            const ink = isHexColor(swatch[500])
+                ? liftToContrast(accentTextOnCanvas(swatch, canvas), canvas, AA_NORMAL_TEXT)
+                : swatch[500];
+            return { bg: "transparent", color: ink, boxShadow: `inset 0 0 0 1px ${ink}` };
         },
     },
     defaultProps: {
         variant: "subtle",
         colorScheme: "gray",
+        size: "sm",
     },
 };
-// Chakra's stock FormErrorMessage hardcodes `colors.red.500` (our own `red[500]`, since
-// `createBrandTheme` sets `theme.colors = palette`) — same AA gap as our own ErrorMessage/
-// ErrorComponent, fixed the same way rather than leaving Chakra's raw usage (e.g. FeedbackForm)
-// unfixed.
+// NOTE: fixes Chakra's FormErrorMessage/Icon hardcoding red.500 — same AA gap as our ErrorComponent.
 const FormError = {
     baseStyle: ({ theme }) => {
-        // `icon` (FormErrorIcon) shares the same AA gap as `text` — both must be fixed together or
-        // the icon stays on Chakra's raw `red.500`.
         const palette = paletteOf(theme);
         const color = accentTextOnCanvas(palette.red, palette.backgroundColor.main);
         return {
@@ -90,6 +89,21 @@ const $alertBg = cssVar("alert-bg");
 const { defineMultiStyleConfig: defineAlertStyles, definePartsStyle: defineAlertParts } = createMultiStyleConfigHelpers(alertAnatomy.keys);
 const Alert = defineAlertStyles({
     variants: {
+        subtle: defineAlertParts(({ theme, colorScheme = "blue" }) => {
+            const palette = paletteOf(theme);
+            const swatch = scaleFor(palette, colorScheme);
+            if (!isHexColor(swatch[100]))
+                return { container: { borderRadius: "xl" } };
+            const tone = resolveSoftTone(palette, swatch);
+            return {
+                container: {
+                    [$alertBg.variable]: tone.bg,
+                    [$alertFg.variable]: tone.fg,
+                    color: tone.fg,
+                    borderRadius: "xl",
+                },
+            };
+        }),
         solid: defineAlertParts(({ theme, colorScheme = "gray" }) => {
             const palette = paletteOf(theme);
             const swatch = scaleFor(palette, colorScheme);
@@ -107,33 +121,26 @@ const Alert = defineAlertStyles({
 });
 const $tooltipBg = cssVar("tooltip-bg");
 const $tooltipFg = cssVar("tooltip-fg");
-/**
- * Chakra's own Tooltip baseStyle hardcodes `--tooltip-bg`/`--tooltip-fg` to `colors.gray.700`/
- * `colors.whiteAlpha.900` (gated behind `_dark`, which this theme-swap app never triggers — see
- * Menu.styles.ts / createBrandTheme's colorMode comment). Our reversed dark gray ramp makes
- * `gray.700` LIGHT (~L79), so every bare `<Tooltip>` renders a near-white bubble with near-white
- * text on the dark canvas — invisible. A tooltip floats over arbitrary content in either mode, so
- * unlike Menu/Modal/Drawer (which follow the canvas) it needs a FIXED high-contrast chip that
- * doesn't invert with the palette — `black`/`white` are exactly the two tokens `buildDarkPalette`
- * deliberately never remaps, so they stay a stable dark-bg/white-text pair in both modes.
- */
+// One tooltip look, shared with the ToolTip component through `tooltipSurface`.
 const Tooltip = {
-    baseStyle: ({ theme }) => ({
-        [$tooltipBg.variable]: theme.colors.black,
-        [$tooltipFg.variable]: theme.colors.white,
-    }),
+    baseStyle: ({ theme }) => {
+        const { bg, fg } = tooltipSurface(paletteOf(theme));
+        return {
+            [$tooltipBg.variable]: bg,
+            [$tooltipFg.variable]: fg,
+            fontSize: "0.8125rem",
+            fontWeight: 400,
+            lineHeight: 1.5,
+            borderRadius: "lg",
+            px: 2.5,
+            py: 1.5,
+            maxW: "18.75rem",
+        };
+    },
 };
 const $skeletonStart = cssVar("skeleton-start-color");
 const $skeletonEnd = cssVar("skeleton-end-color");
-/**
- * Chakra's own Skeleton baseStyle hardcodes `--skeleton-start-color`/`--skeleton-end-color` to
- * `colors.gray.100`/`colors.gray.400` the same `_dark`-gated way Menu/Popover did (Wave G/H), so
- * every bare `<Skeleton>` shimmers between two near-white tones on the dark canvas. Fixed at the
- * theme level rather than in `Skeletons.tsx`: Chakra's `Skeleton` only writes these vars from its
- * `startColor`/`endColor` PROPS when a caller actually passes them (`useToken` on an empty string
- * resolves to `undefined`, so the prop-driven `cssVarStyles` object stays empty) — an explicit
- * prop still wins via that mechanism, this only supplies the default the base style already owns.
- */
+// NOTE: fixes Chakra's Skeleton hardcoding gray.100/.400 via `_dark` (dead here) — an explicit startColor/endColor prop still wins.
 const Skeleton = {
     baseStyle: ({ theme }) => ({
         [$skeletonStart.variable]: paletteOf(theme).gray[100],
@@ -142,29 +149,13 @@ const Skeleton = {
         borderColor: $skeletonEnd.reference,
     }),
 };
-// Chakra's `extendTheme` does not REPLACE a component's stock baseStyle when ours is also a
-// function — it calls BOTH and deep-merges the two returned plain objects, key by key. Chakra's
-// own stock Radio (@chakra-ui/theme radio.mjs) writes its checked dot with the shorthand style
-// props `bg`/`w`/`h`/`pos`; an earlier version of this override used the full CSS property names
-// (`background`/`width`/`height`/`position`). A deep merge treats those as DIFFERENT keys, so
-// both survived into the final style object instead of one cleanly overwriting the other — and
-// in practice Chakra's own `bg: "currentColor"` rung won, leaving a hardcoded-black dot. Using
-// the exact same keys Chakra's stock style uses makes every one of ours a scalar overwrite, and
-// `!important` on the two colour-bearing declarations removes any remaining doubt about which
-// value survives serialization — verified against the actual rendered cascade, not just this
-// function's return value (see componentStyles.radioDotMerge.test.ts, which asserts the merge
-// behavior directly rather than only the function output).
+// NOTE: uses Chakra's own shorthand style keys (bg/w/h/pos) + !important — extendTheme deep-merges by key, so mismatched keys let Chakra's stock value win.
 const Radio = {
     baseStyle: ({ theme, colorScheme }) => {
         const palette = paletteOf(theme);
         const swatch = scaleFor(palette, colorScheme);
         const fill = swatch[solidFillRung(swatch, palette.white)];
         const dot = labelOnFill(fill, palette.white, palette.black);
-        // A browser probe found the checked radio's hover repeating its own resting `fill` —
-        // Chakra's stock checked._hover (inherited from checkbox) lands on the SAME `bg`/`borderColor`
-        // keys we do, so extendTheme's merge is a scalar overwrite here, not a coexisting selector;
-        // ours must supply a value that actually differs from resting, same fix shape as
-        // NavigationBar/OrgSwitcher's "hand a fill its own resting bg as the backdrop" pattern.
         const hoverFill = resolveHoverTint(fill, fill);
         return {
             control: {
@@ -190,16 +181,7 @@ const Radio = {
     defaultProps: { colorScheme: "primary" },
 };
 const $closeButtonBg = cssVar("close-button-bg");
-/**
- * Chakra's stock CloseButton hover/active wash (`blackAlpha.100`/`.200`) only swaps to
- * `whiteAlpha.100`/`.200` under `_dark` — dead in this app (see createBrandTheme's colorMode
- * comment) — so a CloseButton on a dark canvas keeps the light-mode blackAlpha wash, which reads
- * as almost no affordance against a dark surface. The light-mode values themselves also measure
- * borderline against `background[50]` (1.14/1.19, under `MIN_PERCEPTIBLE_STEP`). Branch on the
- * palette's own actual canvas (`isDarkCanvas`), not Chakra's dead colorMode, and step one rung up
- * each scale (`.200`/`.300`) — verified >=1.19 across all 9 brands x both modes
- * (closeButtonHover.test.ts).
- */
+// NOTE: branches on isDarkCanvas, not Chakra's dead `_dark` — its own blackAlpha wash was near-invisible on a dark canvas.
 const CloseButton = {
     baseStyle: ({ theme }) => {
         const palette = paletteOf(theme);
@@ -222,15 +204,13 @@ export const componentStyles = {
     Textarea,
     NumberInput,
     Badge,
+    Card,
     FormError,
     Drawer,
     Menu,
     Modal,
     Popover,
     Slider,
-    Switch,
-    Tabs,
-    Avatar,
     Skeleton,
     Tooltip,
     CloseButton,

package/dist/esm/Theme/chakra/createBrandTheme.js

@@ -5,16 +5,7 @@ import { componentStyles } from "./componentStyles.js";
 import { resolveFilledSurface } from "../tokens/builders/filledSurface.js";
 import { globalScrollbarStyles } from "../tokens/builders/scrollbar.js";
 import { focusRingShadow } from "./focusRing.styles.js";
-/**
- * Builds a Chakra theme from a pure brand palette.
- *
- * Replaces the seven byte-identical `<Brand>/theme.ts` files — they differed only in
- * which palette they imported.
- *
- * Dark mode works by swapping which palette the theme carries: `componentStyles` variants
- * are functions of `({ theme })` and `useCustomTheme()` reads `theme.colors`, so both follow
- * the palette automatically without any per-component `_dark` overrides.
- */
+// Builds a Chakra theme from a pure brand palette — dark mode works by swapping which palette it carries.
 export const createBrandTheme = (palette, options = {}) => {
     var _a;
     const colorMode = (_a = options.colorMode) !== null && _a !== void 0 ? _a : "light";
@@ -22,54 +13,28 @@ export const createBrandTheme = (palette, options = {}) => {
         colors: palette,
         ...fonts,
         ...common,
-        // `shadows.outline` is what Chakra's stock `_focusVisible` reaches for on EVERY component it
-        // themes. The primitive ships one hardcoded blue (`rgba(66,153,225,.6)`), which measured
-        // 1.83:1 on the lavender canvas and 1.38:1 on a primary button — below 1.4.11's 3:1 on all
-        // nine brands, in both modes. A primitive cannot know the palette; this is the first place
-        // that does, so the palette-derived ring is bound here and every stock focus state inherits it.
+        // NOTE: binds the palette-derived ring to shadows.outline — Chakra's stock one failed 1.4.11 on every brand.
         shadows: { ...common.shadows, outline: focusRingShadow(palette) },
     };
     return extendTheme({
         ...brand,
         config: {
             ...common.config,
-            // Deliberately ALWAYS "light", even for the dark theme — this is not a bug.
-            //
-            // Dark works by swapping the palette, so the palette is ALREADY mode-adapted by the time
-            // Chakra sees it. Telling Chakra it is in dark mode makes it adapt a second time: its
-            // built-ins carry `_dark` blocks that reach for `gray.700`/`gray.800` assuming a scale where
-            // those rungs are dark. Our dark gray ramp runs dark -> light, so those rungs are LIGHT —
-            // producing a light Card/Skeleton/Menu on a dark canvas. Adapting twice cancels out.
-            //
-            // Keeping Chakra on its `_light` branch is what makes the swap work: those defaults are
-            // gray-RUNG references (`gray.100`, `gray.200`, `gray.600`), and our reversed ramp already
-            // maps each rung to the right value per mode. `semanticTokens` below patches the one default
-            // that hardcodes a literal color instead of a rung.
+            // NOTE: always "light" on purpose, even for the dark theme — Chakra's own `_dark` blocks would adapt an already-adapted palette a second time.
             initialColorMode: "light",
             useSystemColorMode: false,
         },
-        // `chakra-body-bg` is the only stock semantic token that resolves to a LITERAL (`white`)
-        // rather than a gray rung, so it is the only one the palette swap cannot correct on its own —
-        // it is what paints a white Card/Modal/Menu on the dark canvas. `background[50]` is the
-        // canvas-following equivalent: byte-identical `#ffffff` in light, the canvas in dark.
-        // `chakra-inverse-text` is the same literal-`white` problem in text form.
         semanticTokens: {
             colors: {
                 "chakra-body-bg": palette.background[50],
                 "chakra-inverse-text": palette.background[50],
             },
         },
-        // Light themes intentionally declare no global styles — that is the pre-existing
-        // behavior, and adding any would shift every consuming app's light rendering.
-        // Dark needs a canvas, otherwise the page stays white behind the components.
+        // NOTE: light declares no global styles (pre-existing behavior); dark needs one or the page stays white behind components.
         ...(colorMode === "dark"
             ? {
                 styles: {
                     global: {
-                        // Native widgets the page cannot style — the `<select>` dropdown list and the
-                        // time/date picker popups — are painted by the browser, which defaults to light
-                        // and produced white popups on the dark canvas. `color-scheme` is the only way to
-                        // tell it otherwise.
                         html: {
                             colorScheme: "dark",
                         },
@@ -77,11 +42,7 @@ export const createBrandTheme = (palette, options = {}) => {
                             bg: palette.backgroundColor.main,
                             color: palette.text[900],
                         },
-                        // Text selection is another browser-painted surface `color-scheme` doesn't cover —
-                        // the UA default `::selection` stays a light highlight regardless of theme, so
-                        // selecting text anywhere (e.g. a table cell) shows a stray white/lavender patch on
-                        // the dark canvas. Brand it instead, with WCAG-safe ink via the same `onFilled` math
-                        // used for buttons/badges.
+                        // NOTE: ::selection isn't covered by color-scheme — branded here with the same onFilled math as buttons.
                         "::selection": (() => {
                             const solid = resolveFilledSurface(palette.primary, palette);
                             return {
@@ -96,13 +57,8 @@ export const createBrandTheme = (palette, options = {}) => {
                                 color: solid.color,
                             };
                         })(),
-                        // `color-scheme: dark` gives WebKit/Blink a dark scrollbar by default, but it's the
-                        // OS's generic dark gray, not brand-aware.
                         ...globalScrollbarStyles(palette),
-                        // Chrome/Edge autofill paints its own opaque yellow/white fill behind the input
-                        // text via `-webkit-box-shadow` (not `background`), so a plain `bg` override never
-                        // reaches it — a bright light box survives on every dark autofilled field unless
-                        // overridden with the same trick.
+                        // NOTE: autofill paints its own fill via -webkit-box-shadow, so a plain `bg` override can't reach it.
                         "input:-webkit-autofill, input:-webkit-autofill:hover, input:-webkit-autofill:focus": {
                             WebkitBoxShadow: `0 0 0px 1000px ${palette.backgroundColor.secondary} inset`,
                             WebkitTextFillColor: palette.text[900],

package/dist/esm/Theme/chakra/focusRing.styles.js

@@ -1,33 +1,14 @@
-/**
- * WEB binding for the `focusRing` token pair. The colours are derived in
- * `tokens/builders/focusRing.ts` (pure, shared with the mobile library); the CSS shape —
- * box-shadow bands, the forced-colors outline — is web-only and lives here.
- */
+// Web binding for the focusRing token pair — colors come from tokens/builders/focusRing.ts; CSS shape is web-only.
 /** Inner band, in the surface tone: separates the ring from the control's own fill. */
 export const FOCUS_HALO_WIDTH = 2;
 /** Outer edge of the brand band. The band itself is the 2px between halo and ring. */
 export const FOCUS_RING_WIDTH = 4;
-/**
- * The two-tone ring as a single `box-shadow`. Drawn OUTSIDE the border box, so it costs no
- * layout and never resizes the control — the reason this is a shadow and not an outline.
- */
+// NOTE: a box-shadow, not an outline — drawn outside the border box so it never resizes the control.
 export const focusRingShadow = (colors) => `0 0 0 ${FOCUS_HALO_WIDTH}px ${colors.focusRing.halo}, ` +
     `0 0 0 ${FOCUS_RING_WIDTH}px ${colors.focusRing.ring}`;
-/**
- * `:hover`, `:active` and `:focus-visible` all score the same specificity, so which one paints
- * comes down to source order — and in the merged style object Chakra's own Button baseStyle
- * registers `_focusVisible` BEFORE `_hover`. A focused button that is also hovered would then
- * drop the ring for `_hover`'s `boxShadow: "sm"`. Stacking the pseudo-classes raises the
- * specificity above both, so the ring survives whatever else the state repaints.
- */
+// NOTE: stacked pseudo-classes raise specificity above Chakra's _hover, so a hovered+focused button keeps its ring.
 export const FOCUS_VISIBLE_OVER_STATE = "&:hover:focus-visible, &:active:focus-visible, &[data-active]:focus-visible";
-/**
- * `:focus-visible`, never `:focus` — a mouse click must not draw a ring.
- *
- * The transparent outline is not decoration: in Windows High Contrast / `forced-colors` mode
- * box-shadows are dropped entirely, and a transparent outline is the one thing the OS repaints
- * in its own focus colour. Without it, forced-colors users get no indicator at all.
- */
+// NOTE: transparent outline isn't decorative — forced-colors mode drops box-shadow but repaints an outline.
 export const focusVisibleRing = (colors) => ({
     outline: "2px solid transparent",
     outlineOffset: "2px",

package/dist/esm/Theme/chakra/fonts.web.js

@@ -1,10 +1,6 @@
 /** Self-hosted Inter Variable (wght 100–900); required for theme fontWeights to render correctly. */
 import "@fontsource-variable/inter/index.css";
 import typography from "../tokens/primitives/typography.js";
-/**
- * Web font binding: loads the Inter font face (CSS side-effect) and re-exports the pure
- * typography tokens. The CSS import lives here rather than in `tokens/` so the token
- * layer stays portable to mobile.
- */
+// Web font binding: loads Inter (CSS side-effect) and re-exports typography tokens, kept out of tokens/ for portability.
 const fonts = typography;
 export default fonts;

package/dist/esm/Theme/chakra/motion.js

@@ -0,0 +1,22 @@
+import { useEffect, useState } from "react";
+export const REDUCED_MOTION_QUERY = "@media (prefers-reduced-motion: reduce)";
+const MEDIA = "(prefers-reduced-motion: reduce)";
+// NOTE: jsdom has no matchMedia; Chakra's hook throws there and breaks consumer test suites.
+const hasMatchMedia = () => typeof window !== "undefined" && typeof window.matchMedia === "function";
+const readPreference = () => hasMatchMedia() && window.matchMedia(MEDIA).matches;
+export const usePrefersReducedMotion = () => {
+    const [reduced, setReduced] = useState(readPreference);
+    useEffect(() => {
+        if (!hasMatchMedia())
+            return;
+        const query = window.matchMedia(MEDIA);
+        const onChange = () => setReduced(query.matches);
+        query.addEventListener("change", onChange);
+        return () => query.removeEventListener("change", onChange);
+    }, []);
+    return reduced;
+};
+/** Spread into `sx`: drops transitions and animations when the user asks for less motion. */
+export const reducedMotionSx = (overrides = {}) => ({
+    [REDUCED_MOTION_QUERY]: { transition: "none", animation: "none", ...overrides },
+});

package/dist/esm/Theme/chakra/overlay.styles.js

@@ -0,0 +1,43 @@
+import { overlayScrim } from "../tokens/builders/scrim.js";
+import { raisedRule } from "../tokens/builders/surfaceRaised.js";
+export const OVERLAY_BLUR = "blur(4px)";
+/** The one Modal/Drawer backdrop; reuse it for any custom full-screen scrim. */
+export const overlayScrimStyles = (colors) => ({
+    bg: overlayScrim(colors),
+    backdropFilter: OVERLAY_BLUR,
+});
+/** Shared dialog chrome for Modal and Drawer: surface, header/body/footer rhythm, close button. */
+export const dialogPartStyles = (colors) => ({
+    overlay: overlayScrimStyles(colors),
+    dialog: {
+        color: colors.text[900],
+        borderWidth: "1px",
+        borderStyle: "solid",
+        borderColor: colors.boxborder[200],
+        boxShadow: "lg",
+    },
+    header: {
+        px: 5,
+        py: 4,
+        pe: 12,
+        fontSize: "1rem",
+        fontWeight: 600,
+        lineHeight: 1.5,
+        color: colors.header[900],
+        borderBottomWidth: "1px",
+        borderBottomStyle: "solid",
+        borderBottomColor: raisedRule(colors),
+    },
+    closeButton: { top: 3, insetEnd: 4 },
+    body: { px: 5, py: 4 },
+    footer: {
+        px: 5,
+        py: 4,
+        display: "flex",
+        justifyContent: "flex-end",
+        gap: 3,
+        borderTopWidth: "1px",
+        borderTopStyle: "solid",
+        borderTopColor: raisedRule(colors),
+    },
+});

package/dist/esm/Theme/chakra/paletteFromTheme.js

@@ -2,8 +2,5 @@ import { assertPixelizePalette } from "../assertPalette.js";
 /** Chakra hands style functions an untyped theme; this is the boundary that makes it typed. */
 export const paletteOf = (theme) => assertPixelizePalette(theme);
 const asScale = (value) => typeof value === "object" && value !== null ? value : undefined;
-/**
- * `colorScheme` is a consumer-supplied Chakra scale name, so this lookup is genuinely dynamic —
- * it can name a built-in we never themed. An unknown name resolves to the neutral ramp.
- */
+// NOTE: colorScheme is consumer-supplied and can name a built-in we never themed — unknowns resolve to gray.
 export const scaleFor = (palette, colorScheme) => { var _a; return (_a = asScale(palette[colorScheme])) !== null && _a !== void 0 ? _a : palette.gray; };