@mkbabb/glass-ui 3.9.0 → 3.10.1

package/dist/styles/glass/material.css

@@ -0,0 +1,238 @@
+/* glass/material.css
+   The unified .glass-material atom (AW.W22) + the shared ::before grain/specular wiring across the glass family — ONE source for the three material atoms.
+   Carved from the glass.css cascade root; @import-ed by glass.css in cascade
+   order, each in its own @layer components (isomorphic to the monolith).
+   See docs/precepts/design-idioms.md §cohesion-aware partials. */
+@layer components {
+    /* ── The unified glass material (AW.W22) ──────────────────────────────
+       ONE source for the three material atoms that AV.W15 scattered onto
+       opt-in classes + single tiers:
+         (a) the moving-specular `::before` catch-light (folded here from
+             glass-specular-track.css — that file now keeps only the thin
+             `.glass-specular-track` ALIAS + the brackets that point HERE),
+         (b) the `--glass-edge-light` full-perimeter rim (moved off the
+             floating-only block so EVERY rung carries it),
+         (c) the pointer interaction-light hooks (the `--specular-*`
+             `@property` channel mapped from the consumer's --mouse-x/--mouse-y
+             write).
+       The five ladder rungs + `.glass-card` + the `.dock-icon-button` CONTROL
+       compose `.glass-material`, so a Switch thumb, a glass Button, a Dialog,
+       and a Sheet all read as the SAME material without per-component wiring.
+
+       The `.glass-dock` SHELL is OUT of this group BY DESIGN — it hand-rolls a
+       parallel surface (its own `--glass-*-dock` family + a local rim + an
+       instrument-strip `::before`) the dock arm owns. The COHESION CONSEQUENCE is
+       DELIBERATE: the dock shell carries NO shared edge-gleam / moving-specular
+       `::before` (its only `::before` is the `variant-instrument-strip` engraved
+       bezel, dock/shell.css — a different effect). The dock's catch-light lives on
+       its CONTROLS (`.dock-icon-button` et al., listed below + in the opt-in
+       transition block), which ARE in the material group — NOT on the shell plate.
+       Adding a shell gleam would re-introduce glass-on-glass over the controls, so
+       the shell-without-gleam is a NAMED EXEMPTION, gated as `dock-shell-exempt` in
+       proof:glass-cohesion (the only exemption beside the legibility allowlist).
+
+       The selector GROUP is the single source. Adding a surface to the band
+       material is one comma-entry here, not a new opt-in class string. */
+    .glass-material,
+    .glass-wash,
+    .glass-quiet,
+    .glass-resting,
+    .glass-floating,
+    .glass-overlay,
+    .glass-card,
+    .glass-specular-track,
+    .dock-icon-button,
+    .dock-tab-button,
+    .dock-select-trigger,
+    .dock-dropdown-trigger {
+        position: relative;
+    }
+
+    /* (b) The rim — UNIFORM across all rungs (ONE `--glass-edge-light` token,
+       not a per-rung family). The floating/overlay tiers previously wired it
+       into their box-shadow stack; it now rides the material group as a
+       dedicated `::after` inset ring so it composes alongside (not inside) each
+       tier's own shadow recipe. The `::after` grain overlay already claims the
+       five rungs' `::after`; the rim is folded INTO that same overlay's
+       box-shadow below (the grain `::after` gets the rim inset ring) so no
+       pseudo-element collides. */
+
+    /* (a)+(c) The moving-specular `::before` catch-light — the iOS-26
+       illuminate-from-within behaviour. A masked radial-gradient glow rides the
+       surface at the pointer position (--mouse-x/--mouse-y → the typed
+       --specular-* channel). Folded VERBATIM from glass-specular-track.css so
+       there is exactly ONE specular source. */
+    .glass-material::before,
+    .glass-wash::before,
+    .glass-quiet::before,
+    .glass-resting::before,
+    .glass-floating::before,
+    .glass-overlay::before,
+    .glass-card::before,
+    .glass-specular-track::before,
+    .dock-icon-button::before,
+    .dock-tab-button::before,
+    .dock-select-trigger::before,
+    .dock-dropdown-trigger::before {
+        content: "";
+        position: absolute;
+        inset: 0;
+        border-radius: inherit;
+        pointer-events: none;
+        z-index: 1;
+        /* Map the consumer's pointer write onto the typed properties, ON THE
+           PSEUDO. The `--mouse-x/--mouse-y` write lands on the HOST (inline
+           style) as UNREGISTERED props that inherit down to this `::before`;
+           the registered `--specular-*` props are `inherits: false`, so the
+           mapping is declared HERE where the pseudo owns its typed value. The
+           `var(--mouse-x, 50%)` floor is the centred fallback. */
+        --specular-x: var(--mouse-x, 50%);
+        --specular-y: var(--mouse-y, 50%);
+        /* The catch-light intensity at REST — reads the token cohort
+           (tokens.css §specular-intensity), default 0 so a static, unwired
+           surface is CLEAN and the @property `initial-value: 0` dormancy is no
+           longer defeated by a floor. Hover/active lift it through the same
+           cohort (the interaction-light state machine below). */
+        --specular-intensity: var(--glass-specular-intensity-rest, 0);
+        /* AX.W52 D19 — a thin, BOUNDED, pointer-anchored EDGE gleam (not the prior
+           full-plate central disc that washed small tiles muddy). The geometry is an
+           EXPLICIT-radius circle bounded by `--glass-specular-size` (36% of the
+           plate) whose falloff reaches `/0` well INSIDE the plate (70%) — a tracked
+           catch-light reading the surface near the lit edge, NEVER a whole-surface
+           wash. The core is genuinely WARM-CREAM (L < 100% so the warm hue survives;
+           the prior `hsl(40 30% 100%)` blew out to white). The `--specular-intensity`
+           multiplier drives the layer `opacity`, NOT a per-stop alpha (a
+           registered-`@property` var() nested in an hsl() alpha computes to 0 in
+           Chromium — the cross-engine-safe path); the per-stop alphas are literals so
+           even the lifted hover/active states read as a lens, not a flash. */
+        background: radial-gradient(
+            circle var(--glass-specular-size, 36%) at var(--specular-x, 50%) var(--specular-y, 50%),
+            hsl(40 35% 92% / 0.5) 0%,
+            hsl(40 35% 92% / 0) 70%,
+            transparent 100%
+        );
+        opacity: var(--specular-intensity, 0);
+        /* Clip the gleam to ITS OWN radius (not the whole plate) so it stays a
+           bounded glint. `mask-image` Baseline 2023-12-07; a non-supporting engine
+           ignores it and the `inset: 0` + radius-inherit + the in-paint falloff
+           already bound the gleam to the surface. */
+        mask-image: radial-gradient(
+            circle var(--glass-specular-size, 36%) at var(--specular-x, 50%) var(--specular-y, 50%),
+            black 0%,
+            black 60%,
+            transparent 100%
+        );
+        /* AX.W52 D19 — `plus-lighter` (additive but HDR-clamped, Safari 16.4+) over
+           the prior `screen` (a non-linear lightener that lifted the whole tile
+           toward white — the muddy-card defect). A non-supporting engine degrades to
+           a plain low-alpha warm overlay (the gleam composes normally — no blend, no
+           blowout), the no-workaround floor; NOT a `screen` fallback. */
+        mix-blend-mode: plus-lighter;
+        /* The moving-specular TRANSITION is NOT declared here. An idle/unwired
+           `::before` is STATIC (no interpolation track), so a bare glass rung / an
+           un-armed Card / a glass Button at rest attaches ZERO animation tracks (the
+           keyframes.js runtime counts 0 idle tracks, not 19). The transition rides
+           ONLY the WIRED + interactive surfaces — the opt-in scoped block below. */
+    }
+
+    /* AY.W-GLASS — the moving-specular transition is OPT-IN (the Card wire-or-omit
+       pattern, generalized). It attaches ONLY to a WIRED surface
+       (`.glass-specular-track` — Card emits it conditionally, the dock controls + the
+       Slider thumb compose it) OR to any glass surface under `:hover`/`:active` (the
+       pointer is present, so the interpolation is legitimately live). An idle/unwired
+       `.glass-floating` / `.glass-wash` / bare-rung `::before` carries NO transition
+       and thus NO keyframes.js track. The §6 register is PRESERVED (still
+       `--ease-standard` on the position-tracked + surface-opacity legs — H-motion §6
+       "position-tracked → --ease-standard"; only the SELECTOR scope changes). The dock
+       controls keep the always-on transition (they are interactive controls; their rest
+       intensity is 0 so they paint nothing at rest, but a control legitimately carries
+       the transition). */
+    .glass-specular-track::before,
+    .glass-material:hover::before,    .glass-material:active::before,
+    .glass-wash:hover::before,        .glass-wash:active::before,
+    .glass-quiet:hover::before,       .glass-quiet:active::before,
+    .glass-resting:hover::before,     .glass-resting:active::before,
+    .glass-floating:hover::before,    .glass-floating:active::before,
+    .glass-overlay:hover::before,     .glass-overlay:active::before,
+    .glass-card:hover::before,        .glass-card:active::before,
+    .dock-icon-button::before,
+    .dock-tab-button::before,
+    .dock-select-trigger::before,
+    .dock-dropdown-trigger::before {
+        /* Smooth the position + intensity between pointer samples (the typed
+           @property regs make the percentage stops interpolable). */
+        transition:
+            --specular-x var(--duration-fast, 150ms) var(--ease-standard, ease-out),
+            --specular-y var(--duration-fast, 150ms) var(--ease-standard, ease-out),
+            opacity var(--duration-normal, 240ms) var(--ease-standard, ease-out);
+    }
+
+    .dark .glass-material::before,
+    .dark .glass-wash::before,
+    .dark .glass-quiet::before,
+    .dark .glass-resting::before,
+    .dark .glass-floating::before,
+    .dark .glass-overlay::before,
+    .dark .glass-card::before,
+    .dark .glass-specular-track::before,
+    .dark .dock-icon-button::before,
+    .dark .dock-tab-button::before,
+    .dark .dock-select-trigger::before,
+    .dark .dock-dropdown-trigger::before {
+        /* Softer over the deep canvas — `plus-lighter` still lifts on dark, so the
+           `.dark` cohort runs a lower hover/active rung (tokens.css §specular-
+           intensity `.dark` arm); the rest rung is already 0 so the dark arm only
+           softens hover/active via the cohort. The rest rung re-reads the (dark)
+           token here so a dark `:root` override resolves. */
+        --specular-intensity: var(--glass-specular-intensity-rest, 0);
+    }
+
+    /* (c) Interaction-light lockstep — hover/active lift the intensity in the
+       SAME rungs the scale-press squish keys off, so material-light fires in
+       lockstep with the press across every glass surface. Settles back on leave
+       via the opacity transition above. */
+    .glass-material:hover::before,
+    .glass-wash:hover::before,
+    .glass-quiet:hover::before,
+    .glass-resting:hover::before,
+    .glass-floating:hover::before,
+    .glass-overlay:hover::before,
+    .glass-card:hover::before,
+    .glass-specular-track:hover::before,
+    .dock-icon-button:hover::before,
+    .dock-tab-button:hover::before,
+    .dock-select-trigger:hover::before,
+    .dock-dropdown-trigger:hover::before {
+        --specular-intensity: var(--glass-specular-intensity-hover, 0.1);
+    }
+    .glass-material:active::before,
+    .glass-wash:active::before,
+    .glass-quiet:active::before,
+    .glass-resting:active::before,
+    .glass-floating:active::before,
+    .glass-overlay:active::before,
+    .glass-card:active::before,
+    .glass-specular-track:active::before,
+    .dock-icon-button:active::before,
+    .dock-tab-button:active::before,
+    .dock-select-trigger:active::before,
+    .dock-dropdown-trigger:active::before {
+        --specular-intensity: var(--glass-specular-intensity-active, 0.16);
+    }
+
+    /* AX.W45-TUNE C5 — the SELECTED dock control reads as the keyframes-dock glass
+       register: a glass-tier active fill (`--dock-control-active-bg` → the floating
+       plate, tokens.css) WITH the specular gleam waking over it, not a flat ink
+       stamp. The CSS `:active` pseudo above only fires on press-down; a SELECTED tile
+       (`.is-active` / `[aria-pressed]` / `[aria-expanded]` / `[aria-current]`) holds
+       the gleam lit so the selected element reads as a lit glass tier the substrate
+       shows through (the model the user named, `pass-3:13`). Family-scoped addition
+       on the dock-control `::before`, line-disjoint from the shared recipe above. */
+    .dock-icon-button:is(.is-active, .active, [aria-pressed="true"], [aria-expanded="true"], [aria-current="page"])::before,
+    .dock-tab-button:is(.is-active, .active, [aria-pressed="true"], [aria-expanded="true"], [aria-current="page"])::before,
+    .dock-select-trigger:is(.is-active, .active, [aria-pressed="true"], [aria-expanded="true"], [aria-current="page"])::before,
+    .dock-dropdown-trigger:is(.is-active, .active, [aria-pressed="true"], [aria-expanded="true"], [aria-current="page"])::before {
+        --specular-intensity: var(--glass-specular-intensity-active, 0.16);
+    }
+
+}

package/dist/styles/glass/progress-rail.css

@@ -0,0 +1,78 @@
+/* glass/progress-rail.css
+   The @utility glass-progress-rail — restyles <Progress variant=default> into the deck-position rail. A @utility (not @layer components) so it outranks the variant's baked h-4/rounded-pill utilities.
+   Carved from the glass.css cascade root; @import-ed by glass.css in cascade
+   order, each in its own @layer components (isomorphic to the monolith).
+   See docs/precepts/design-idioms.md §cohesion-aware partials. */
+/* ── Deck-position rail (AW.W16 · AX.W24) ───────────────────────────────────
+   A Tailwind `@utility` that RESTYLES the shipped `<Progress variant="default">`
+   (the reka-ui ProgressRoot track + its indicator child) into the thin
+   bottom-of-deck position rail. It composes the EXISTING fill — it does NOT
+   re-author a second track/range mechanic. Every visual axis is a
+   `--progress-rail-*` token, so a consumer/dark-flip re-tints with zero library
+   edit (`:root { --progress-rail-fill: … }`). The viewport-pinned chrome
+   (`position: fixed`, `env(safe-area-inset-bottom)`, the z-index) is CONSUMER-
+   supplied — this recipe owns only the LOOK.
+
+   AX.W24 — WHY `@utility`, not `@layer components`. The rail RESTYLES the default
+   Progress: it must override the `h-4` height + `rounded-pill` radius utilities the
+   variant bakes. Those utilities live in `@layer utilities`, which ALWAYS outranks
+   `@layer components` regardless of source order, so the prior `@layer components`
+   recipe's `height: 3px` was a silent no-op (the rail painted as a 16px bar). An
+   `@utility` lands the recipe IN `@layer utilities` alongside `h-4`, where a single-
+   class selector wins the geometry by source order — the idiomatic Tailwind-v4 way
+   to author a restyle-class that out-ranks base utilities (the `btn-audacious` /
+   `cartoon-surface` pattern).
+
+   The COLOUR fix is the SEPARATE token-read-at-source path (NOT a layer-juggle):
+   `ProgressDefault` reads `--progress-fill`/`--progress-track` and dropped its
+   `bg-secondary`/`bg-primary` utilities, so this recipe FEEDS those tokens rather
+   than fighting a utility colour. The `--progress-fill` set on the rail root cascades
+   to the indicator child (a CSS custom property inherits), so the indicator reads the
+   override hue. */
+@utility glass-progress-rail {
+    /* The track hairline + zero radius — the rail reads as a thin square sliver, not
+       the variant's 16px `rounded-pill` bar. A single-class @utility ties `h-4`/
+       `rounded-pill` on SPECIFICITY (both 0,1,0) and Tailwind's utility sort can emit
+       `h-4` later, so the bare tie loses. The doubled-class self-reference (`&&` →
+       `.glass-progress-rail.glass-progress-rail`, specificity 0,2,0) wins the geometry
+       DETERMINISTICALLY over the base utilities regardless of emit order — the precise,
+       contained way to out-rank a base utility without `!important`. */
+    && {
+        height: var(--progress-rail-h, 3px);
+        border-radius: 0;
+    }
+    /* Feed the token-read default variant — these route the consumer's
+       `--progress-rail-*` axes into the `--progress-fill`/`--progress-track` tokens
+       the variant reads at source (the cascade-correct colour path). */
+    --progress-track: var(
+        --progress-rail-track,
+        color-mix(in srgb, var(--foreground) 8%, transparent)
+    );
+    --progress-fill: var(--progress-rail-fill, var(--primary));
+
+    /* The fill — the shipped ProgressIndicator child. The indicator paints the
+       inherited `--progress-fill`; the leading-edge glow is re-authored (AX.W24 F2)
+       as a TRAILING right-edge INSET box-shadow that lives INSIDE the indicator's
+       own box. The prior `4px 0 8px` OUTSET rightward shadow extended PAST the fill
+       boundary into the ProgressRoot's load-bearing `overflow-hidden` clip and was
+       eaten — invisible at every value. An `inset` shadow offset leftward
+       (`inset -Npx 0 …`) brightens just inside the indicator's right (leading) edge
+       — the moving position head — and never crosses the fill boundary, so the clip
+       cannot eat it (the clip is never lifted; that would re-break the default
+       Progress look for every other consumer). `box-shadow` is a separate property
+       from `background`, so it composes cleanly over the token-read fill. */
+    && > * {
+        border-radius: 0;
+        box-shadow:
+            inset
+            calc(-1 * var(--progress-rail-glow-x, 4px))
+            0
+            var(--progress-rail-glow-blur, 8px)
+            calc(-1 * var(--progress-rail-glow-spread, 2px))
+            color-mix(
+                in srgb,
+                hsl(0 0% 100%) var(--progress-rail-glow-strength, 55%),
+                transparent
+            );
+    }
+}

package/dist/styles/glass/squircle.css

@@ -0,0 +1,66 @@
+/* glass/squircle.css
+   The AX.W56 rounded-vs-squircle policy + the @supports (corner-shape: superellipse(2)) squircle coupling onto the overlay-band glass. After the base ladder (overrides it).
+   Carved from the glass.css cascade root; @import-ed by glass.css in cascade
+   order, each in its own @layer components (isomorphic to the monolith).
+   See docs/precepts/design-idioms.md §cohesion-aware partials. */
+/* ── AX.W56 — the rounded-vs-squircle POLICY (re-homes AW.W23's squircle) ─────
+   Cards, glass buttons, and pills stay ROUND. The earlier AW.W23 block applied
+   `corner-shape: squircle` to `.glass-card`/`.glass-btn`/`.btn-pill`, which
+   inverted the design intent — the superellipse is imperceptible at a 16px card
+   radius or a stadium pill, so the squircle on those surfaces was visual cost
+   without read. The squircle is RE-HOMED onto the one surface where it reads: the
+   big-dock card shell (`dock.css` → `var(--corner-shape-bigdock)` under
+   `@supports (corner-shape: superellipse(2))`). This is a clean break — no alias,
+   no `--corner-shape-card` decl here (it resolves `round`, the default, so a
+   `corner-shape` rule would be a no-op). The `--corner-shape-*` token axis lives
+   in `theme.css`; a consumer who WANTS a squircle card opts in by re-pointing
+   `--corner-shape-card` at `superellipse(var(--corner-k-squircle))`. Do NOT
+   re-add a squircle rule to the card/button/pill surfaces — they are round by
+   policy. */
+
+/* ── AX.W56(R1) + W56b — squircle coupling onto the large-radius glass FAMILY ───
+   W54 makes GLASS the default for the overlay-band surfaces; W56(R1)+W56b couple
+   the SQUIRCLE onto the whole LARGE-RADIUS glass family — Dialog + Sheet content
+   (`.glass-floating.{rounded-dialog,sheet-animate}`), the Configurator/floating
+   PANEL (`.configurator`, `.floating-panel`), and the glass HERO overlay
+   (`.glass-hero`, the thin opt-in utility the page-redesign hero reads). Every one
+   sits AT or ABOVE the ~--radius-xl threshold where the superellipse READS — the
+   same iOS-26 idiom the big-dock card shell carries (the backdrop-filter blur halo
+   + the cartoon under-shadow follow the shape). Each surface reads its OWN
+   tokenized `var(--corner-shape-<surface>)` (theme.css) so it is independently
+   overridable — never a blanket `.glass-floating` rule (data cards + pills stay
+   round by policy; the compound selectors scope to the named surface only). Mirrors
+   the big-dock idiom EXACTLY: an `@supports`-gated ENHANCEMENT (Chrome 139+, no
+   FF/Safari 2026) over the `border-radius` round CONTRACT — the squircle is the
+   better tier, NOT a degraded fallback. The `@supports` condition tests the LITERAL
+   `superellipse(2)` (a `var()` is not evaluable in an `@supports` query) — the same
+   Chrome-139 feature the token resolves to. */
+@layer components {
+    @supports (corner-shape: superellipse(2)) {
+        .glass-floating.rounded-dialog {
+            corner-shape: var(--corner-shape-dialog);
+        }
+        .glass-floating.sheet-animate {
+            corner-shape: var(--corner-shape-sheet);
+        }
+        .configurator,
+        .floating-panel {
+            corner-shape: var(--corner-shape-panel);
+        }
+        .glass-hero {
+            corner-shape: var(--corner-shape-hero);
+        }
+    }
+}
+
+/* ── The glass HERO opt-in utility (W56b fold 7) ────────────────────────────────
+   A thin large-radius editorial glass OVERLAY — distinct from a data Card (which
+   stays round by policy). It is the surface the page-redesign hero (W60) reads;
+   minting it here (with its consumer) keeps the squircle off every `.glass-card`.
+   The corner-shape squircle rides the `@supports` block above; the un-gated
+   `border-radius` here is the cross-engine round CONTRACT. */
+@layer components {
+    .glass-hero {
+        border-radius: var(--radius-2xl);
+    }
+}