@hanzo/ui 8.0.46 → 8.0.48

package/dist/backends/gui/glass.cjs

@@ -10,22 +10,31 @@ const jsx_runtime_1 = require("react/jsx-runtime");
  *
  * It is a surface, not a layout: it composes AROUND content and adds nothing
  * but the material. The component itself is a solid raised panel; the
- * translucency + blur live in theme.css under `@supports (backdrop-filter)`,
- * keyed by [data-slot="glass"] — so a platform that cannot blur (older
- * engines, native without a blur view) keeps the solid panel and content
- * never becomes illegible over a busy backdrop. One material, declared once.
+ * translucency + blur live in glass.css under `@supports (backdrop-filter)`,
+ * keyed by [data-slot="glass"] — so a platform that cannot blur (older engines,
+ * native without a blur view) keeps the solid panel and content never becomes
+ * illegible over a busy backdrop. One material, declared once.
+ *
+ * The look comes from `glass(level)` in `@hanzo/ui/glass`, not from a `styled`
+ * of its own. It used to be both, and they disagreed: the frame's stand-in
+ * ground was `$color2` while the material is 72% of `--background`, so a
+ * browser that could blur and one that could not showed two different colours
+ * of menu. A component and a recipe describing the same material in two places
+ * is how they end up describing two materials. This is the component FORM of
+ * that value — it exists so a surface built from scratch does not have to reach
+ * for an `XStack` and remember to spread. Every surface the library already
+ * names (dialog, popover, select, dropdown, tooltip) is glass by slot and needs
+ * neither.
  *
  * Page sections never wear glass; they sit on the surface ladder ($color2/3).
  */
 const gui_1 = require("@hanzo/gui");
+const glass_1 = require("../../glass.cjs");
 const slot_1 = require("./slot.cjs");
-const GlassFrame = (0, gui_1.styled)(gui_1.YStack, {
-    name: 'Glass',
-    borderWidth: 1,
-    borderColor: '$borderColor',
-    // The stand-in ground; theme.css swaps it for the blurred material where
-    // backdrop-filter is real.
-    bg: '$color2',
-});
-const Glass = (props) => (0, jsx_runtime_1.jsx)(GlassFrame, { ...(0, slot_1.slot)('glass'), ...props });
+/**
+ * The border WIDTH is geometry and belongs to the component, not to the
+ * material — a sticky bar cut from the same glass wants one edge, not four —
+ * so the recipe states only the colour and this states the default width.
+ */
+const Glass = ({ level = 2, ...props }) => ((0, jsx_runtime_1.jsx)(gui_1.YStack, { ...(0, slot_1.slot)('glass'), borderWidth: 1, ...(0, glass_1.glass)(level), ...props }));
 exports.Glass = Glass;

package/dist/backends/gui/glass.d.ts

@@ -1,9 +1,40 @@
+/**
+ * Glass — the ONE frosted material, for FLOATING chrome only (menus, dialogs,
+ * popovers, docked toolbars). macOS/iOS vibrancy: a translucent ground the
+ * backdrop blurs through, sealed with a hairline border.
+ *
+ * It is a surface, not a layout: it composes AROUND content and adds nothing
+ * but the material. The component itself is a solid raised panel; the
+ * translucency + blur live in glass.css under `@supports (backdrop-filter)`,
+ * keyed by [data-slot="glass"] — so a platform that cannot blur (older engines,
+ * native without a blur view) keeps the solid panel and content never becomes
+ * illegible over a busy backdrop. One material, declared once.
+ *
+ * The look comes from `glass(level)` in `@hanzo/ui/glass`, not from a `styled`
+ * of its own. It used to be both, and they disagreed: the frame's stand-in
+ * ground was `$color2` while the material is 72% of `--background`, so a
+ * browser that could blur and one that could not showed two different colours
+ * of menu. A component and a recipe describing the same material in two places
+ * is how they end up describing two materials. This is the component FORM of
+ * that value — it exists so a surface built from scratch does not have to reach
+ * for an `XStack` and remember to spread. Every surface the library already
+ * names (dialog, popover, select, dropdown, tooltip) is glass by slot and needs
+ * neither.
+ *
+ * Page sections never wear glass; they sit on the surface ladder ($color2/3).
+ */
+import { YStack } from '@hanzo/gui';
 import type { ComponentProps } from 'react';
-declare const GlassFrame: import("@hanzogui/web").GuiComponent<import("@hanzogui/web").TamaDefer, import("@hanzogui/web").GuiElement, import("@hanzogui/core").RNGuiViewNonStyleProps, import("@hanzogui/web").StackStyleBase, {
-    elevation?: number | import("@hanzogui/web").SizeTokens | undefined;
-    fullscreen?: boolean | undefined;
-}, import("@hanzogui/web").StaticConfigPublic>;
-export type GlassProps = ComponentProps<typeof GlassFrame>;
-declare const Glass: (props: GlassProps) => import("react/jsx-runtime").JSX.Element;
+import { type Lift } from '../../glass.js';
+export type GlassProps = ComponentProps<typeof YStack> & {
+    /** 2 is anchored — a menu, a toast, a bar. 3 floats free over the page. */
+    level?: Lift;
+};
+/**
+ * The border WIDTH is geometry and belongs to the component, not to the
+ * material — a sticky bar cut from the same glass wants one edge, not four —
+ * so the recipe states only the colour and this states the default width.
+ */
+declare const Glass: ({ level, ...props }: GlassProps) => import("react/jsx-runtime").JSX.Element;
 export { Glass };
 //# sourceMappingURL=glass.d.ts.map

package/dist/backends/gui/glass.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"glass.d.ts","sourceRoot":"","sources":["../../../src/backends/gui/glass.tsx"],"names":[],"mappings":"AAiBA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,OAAO,CAAA;AAG3C,QAAA,MAAM,UAAU;;;8CAOd,CAAA;AAEF,MAAM,MAAM,UAAU,GAAG,cAAc,CAAC,OAAO,UAAU,CAAC,CAAA;AAE1D,QAAA,MAAM,KAAK,GAAI,OAAO,UAAU,4CAAiD,CAAA;AAEjF,OAAO,EAAE,KAAK,EAAE,CAAA"}
+{"version":3,"file":"glass.d.ts","sourceRoot":"","sources":["../../../src/backends/gui/glass.tsx"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,OAAO,EAAE,MAAM,EAAE,MAAM,YAAY,CAAA;AACnC,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,OAAO,CAAA;AAE3C,OAAO,EAAE,KAAK,IAAI,EAAS,MAAM,aAAa,CAAA;AAG9C,MAAM,MAAM,UAAU,GAAG,cAAc,CAAC,OAAO,MAAM,CAAC,GAAG;IACvD,2EAA2E;IAC3E,KAAK,CAAC,EAAE,IAAI,CAAA;CACb,CAAA;AAED;;;;GAIG;AACH,QAAA,MAAM,KAAK,GAAI,qBAAyB,UAAU,4CAEjD,CAAA;AAED,OAAO,EAAE,KAAK,EAAE,CAAA"}

package/dist/backends/gui/glass.js

@@ -7,23 +7,32 @@ import { jsx as _jsx } from "react/jsx-runtime";
  *
  * It is a surface, not a layout: it composes AROUND content and adds nothing
  * but the material. The component itself is a solid raised panel; the
- * translucency + blur live in theme.css under `@supports (backdrop-filter)`,
- * keyed by [data-slot="glass"] — so a platform that cannot blur (older
- * engines, native without a blur view) keeps the solid panel and content
- * never becomes illegible over a busy backdrop. One material, declared once.
+ * translucency + blur live in glass.css under `@supports (backdrop-filter)`,
+ * keyed by [data-slot="glass"] — so a platform that cannot blur (older engines,
+ * native without a blur view) keeps the solid panel and content never becomes
+ * illegible over a busy backdrop. One material, declared once.
+ *
+ * The look comes from `glass(level)` in `@hanzo/ui/glass`, not from a `styled`
+ * of its own. It used to be both, and they disagreed: the frame's stand-in
+ * ground was `$color2` while the material is 72% of `--background`, so a
+ * browser that could blur and one that could not showed two different colours
+ * of menu. A component and a recipe describing the same material in two places
+ * is how they end up describing two materials. This is the component FORM of
+ * that value — it exists so a surface built from scratch does not have to reach
+ * for an `XStack` and remember to spread. Every surface the library already
+ * names (dialog, popover, select, dropdown, tooltip) is glass by slot and needs
+ * neither.
  *
  * Page sections never wear glass; they sit on the surface ladder ($color2/3).
  */
-import { YStack, styled } from '@hanzo/gui';
+import { YStack } from '@hanzo/gui';
+import { glass } from '../../glass.js';
 import { slot } from './slot.js';
-const GlassFrame = styled(YStack, {
-    name: 'Glass',
-    borderWidth: 1,
-    borderColor: '$borderColor',
-    // The stand-in ground; theme.css swaps it for the blurred material where
-    // backdrop-filter is real.
-    bg: '$color2',
-});
-const Glass = (props) => _jsx(GlassFrame, { ...slot('glass'), ...props });
+/**
+ * The border WIDTH is geometry and belongs to the component, not to the
+ * material — a sticky bar cut from the same glass wants one edge, not four —
+ * so the recipe states only the colour and this states the default width.
+ */
+const Glass = ({ level = 2, ...props }) => (_jsx(YStack, { ...slot('glass'), borderWidth: 1, ...glass(level), ...props }));
 export { Glass };
 //# sourceMappingURL=glass.js.map

package/dist/backends/gui/glass.js.map

@@ -1 +1 @@
-{"version":3,"file":"glass.js","sourceRoot":"","sources":["../../../src/backends/gui/glass.tsx"],"names":[],"mappings":"AAAA,YAAY,CAAA;;AAEZ;;;;;;;;;;;;;GAaG;AACH,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,YAAY,CAAA;AAE3C,OAAO,EAAE,IAAI,EAAE,MAAM,QAAQ,CAAA;AAE7B,MAAM,UAAU,GAAG,MAAM,CAAC,MAAM,EAAE;IAChC,IAAI,EAAE,OAAO;IACb,WAAW,EAAE,CAAC;IACd,WAAW,EAAE,cAAc;IAC3B,yEAAyE;IACzE,2BAA2B;IAC3B,EAAE,EAAE,SAAS;CACd,CAAC,CAAA;AAIF,MAAM,KAAK,GAAG,CAAC,KAAiB,EAAE,EAAE,CAAC,KAAC,UAAU,OAAK,IAAI,CAAC,OAAO,CAAC,KAAM,KAAK,GAAI,CAAA;AAEjF,OAAO,EAAE,KAAK,EAAE,CAAA"}
+{"version":3,"file":"glass.js","sourceRoot":"","sources":["../../../src/backends/gui/glass.tsx"],"names":[],"mappings":"AAAA,YAAY,CAAA;;AAEZ;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,OAAO,EAAE,MAAM,EAAE,MAAM,YAAY,CAAA;AAGnC,OAAO,EAAa,KAAK,EAAE,MAAM,aAAa,CAAA;AAC9C,OAAO,EAAE,IAAI,EAAE,MAAM,QAAQ,CAAA;AAO7B;;;;GAIG;AACH,MAAM,KAAK,GAAG,CAAC,EAAE,KAAK,GAAG,CAAC,EAAE,GAAG,KAAK,EAAc,EAAE,EAAE,CAAC,CACrD,KAAC,MAAM,OAAK,IAAI,CAAC,OAAO,CAAC,EAAE,WAAW,EAAE,CAAC,KAAM,KAAK,CAAC,KAAK,CAAC,KAAM,KAAK,GAAI,CAC3E,CAAA;AAED,OAAO,EAAE,KAAK,EAAE,CAAA"}

package/dist/glass.cjs

@@ -0,0 +1,256 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.screen = exports.accent = exports.selected = exports.row = exports.rows = exports.panel = exports.scrim = exports.glass = void 0;
+/**
+ * The chrome, as values — `@hanzo/ui/glass`.
+ *
+ *   import { glass, panel, scrim } from '@hanzo/ui/glass'
+ *   import '@hanzo/ui/glass.css'   // or '@hanzo/ui/theme.css', which inlines it
+ *
+ * Eight recipes, because eight things were being spelled out by hand on every
+ * page and drifting apart every time: what a floating surface is made of, what
+ * a resting one is made of, what dims the page under a modal, how a set of
+ * rows is grouped, what one of those rows looks like, which item in a set is
+ * the current one, which control is the loud one, and what it means to fill the
+ * screen. Each is ONE value here and nowhere else.
+ *
+ * They are plain objects, spread onto any `@hanzo/gui` element:
+ *
+ *   <YStack {...panel}>…</YStack>
+ *   <XStack {...glass(2)} borderBottomWidth={1}>…</XStack>
+ *
+ * A recipe rather than a component or a variant, because a variant only reaches
+ * the one component that declares it and half of what wants these is an
+ * `XStack`, a `SizableText` or a `Link`. One value that spreads onto any
+ * element beats N spellings of it.
+ *
+ * The material and the ladder live in `glass.css`; these name them. Nothing
+ * here restates a colour, a shadow or a blur radius — see that file for where
+ * the values come from (`@hanzo/design`).
+ */
+const slot_1 = require("./backends/gui/slot.cjs");
+/**
+ * Glass — the material floating chrome is made of, and only floating chrome.
+ *
+ * Menus, dialogs, popovers, toasts, sticky bars: things with page under them.
+ * Vibrancy is a lens, so a surface covering nothing but the flat canvas has
+ * nothing to soften — an in-flow card wearing this is not glass, it is the page
+ * with extra steps, one shade off what it sits on and harder to find than
+ * `panel`. Over content -> `glass`, in the flow -> `panel`. No third case.
+ *
+ * The library's own dialogs, popovers, selects, dropdowns and tooltips are
+ * already glass BY SLOT — `glass.css` attaches the material to what a thing IS,
+ * so they need nothing from a call site and cannot fall out of step. This is
+ * for the surfaces no slot names: a hand-rolled bar, a custom menu, a docked
+ * toolbar.
+ *
+ * MATERIAL ONLY, no geometry. What glass is made of does not tell you what
+ * shape it was cut into: a menu is rounded on four sides, a sticky bar is
+ * full-bleed with one hairline along its bottom. Baking `borderRadius` and
+ * `borderWidth` in here would make every bar undo them, so edges stay at the
+ * call site — which only ever needs to say WHICH ones (`borderBottomWidth={1}`),
+ * never what colour, because the material already knows.
+ *
+ * The level is the one thing that genuinely varies, so it is the argument
+ * (`selected(on)` is shaped the same way). 2 is anchored — a menu, a toast, a
+ * bar, lifted off the page but tied to it. 3 is a modal, floating free over
+ * everything with a scrim under it.
+ *
+ * `backgroundColor` is the opaque fallback, and it is load-bearing rather than
+ * belt-and-braces: the material lives inside `@supports (backdrop-filter)`, so
+ * a browser that cannot blur gets no rule at all — and a menu with no
+ * background is a menu you read the page through.
+ */
+const glass = (level = 2) => ({
+    className: `glass elevation-${level}`,
+    backgroundColor: '$background',
+    borderColor: '$borderColor',
+});
+exports.glass = glass;
+/**
+ * The scrim under anything modal — the dim that makes a floating panel read as
+ * floating rather than as more page.
+ *
+ * Hand-rolled modals reach for `backgroundColor="black"`, with no alpha. That
+ * does not dim the page behind them, it DELETES it — and a glass panel over a
+ * solid black wall has nothing left to be translucent about, so the scrim
+ * cancels the very material it exists to make read.
+ *
+ * The value is a design token, not a literal, because both languages need it
+ * and only one of them can hold the copy: `[data-slot="dialog-overlay"]` reads
+ * `--surface-scrim` in `glass.css` and this reads the same token, so the dim
+ * behind a library dialog and the dim behind a hand-rolled one are the same dim
+ * by construction rather than by two people remembering a number.
+ */
+exports.scrim = { backgroundColor: 'var(--surface-scrim, rgb(0 0 0 / .8))' };
+/**
+ * A panel: the quiet surface content in the FLOW sits on.
+ *
+ * `$color2` is a step off the page, so the fill alone separates the panel from
+ * the page and the hairline only finishes the edge. Panels are otherwise
+ * variously `$background` (a border with nothing behind it), `$color3` (which
+ * is the ACTIVE-item fill — a state, not a surface) and as many radii as there
+ * are authors.
+ *
+ * Rung 1 on the ladder, which is NOT the same claim as "this floats". A cast
+ * shadow does say "above the page", and that stays false for a panel in the
+ * flow — so rung 1 spends almost nothing on shadow and buys its depth from the
+ * lit top edge instead. On a near-black canvas that is the only half that reads
+ * at all.
+ */
+exports.panel = {
+    backgroundColor: '$color2',
+    borderWidth: 1,
+    borderColor: '$borderColor',
+    borderRadius: '$6',
+    className: 'elevation-1',
+};
+/**
+ * A group of rows — the settings card, and the reason a settings page ends up
+ * with four cards where it wanted one.
+ *
+ * Four toggles as four separate panels reads as four unrelated decisions, each
+ * with its own four edges; the same four inside one card, parted by hairlines,
+ * reads as one set and drops twelve edges of noise. That is the macOS settings
+ * group, and it is the shape every settings surface reaches for by hand.
+ *
+ * `overflow: hidden` is not decoration — the separators are drawn by the card
+ * (`[data-slot="rows"] > * + *`), and without the clip the topmost one runs
+ * straight through the rounded corner and out the side.
+ *
+ * It spreads `panel` WHOLE, so moving the panel up or down the ladder moves its
+ * groups with it. The separator hangs off a slot rather than a second class
+ * name for the same reason: there is no string to keep in step.
+ */
+exports.rows = {
+    ...exports.panel,
+    ...(0, slot_1.slot)('rows'),
+    overflow: 'hidden',
+};
+/**
+ * One line inside a `rows` card: name on the left, control hard right.
+ *
+ * The rhythm, so it stops being re-decided per file. Pair it with a label at
+ * `fontSize="$3"` in `$color` and any explanation under it at `$1` in
+ * `$color11` — both halves matter, because a row whose label is written at
+ * `$color11` (the SECONDARY colour) gives the name of the setting and the
+ * footnote about it the same weight of grey, and the row has no first thing to
+ * read.
+ *
+ * No border here. A row that draws its own top hairline is a row that has to
+ * know whether it is first, and the card already knows — see `rows`.
+ */
+exports.row = {
+    flexDirection: 'row',
+    alignItems: 'center',
+    justifyContent: 'space-between',
+    gap: '$4',
+    paddingHorizontal: '$4',
+    paddingVertical: '$3',
+};
+/**
+ * Selected — the ONE "you are here" look, wherever a set offers a choice: nav
+ * rows, tabs, a filter chip.
+ *
+ * `$color3` fill with a full-strength label, one step above the panel it sits
+ * on. The alternatives in the wild are a pure-white lozenge, and — far more
+ * often — no answer at all: an unstyled `TabsTrigger` paints a selected tab
+ * exactly like its neighbours, so the page simply does not say which one you
+ * are on. Nothing in the markup looks wrong; the state has no picture.
+ *
+ * The label is `$color12`, not `$color`, and that is a measured distinction
+ * rather than a preference. Themes NEST: at the page scope `--color` is
+ * hsl(0 0% 100%), but inside a sidebar's scope it is re-based to hsl(0 0% 80%)
+ * — the SAME value as `--color11`. So a selected row asking for `$color` gets
+ * exactly its neighbours' colour, and had been doing so all along; the markup
+ * said "highlight this" and the token quietly collapsed underneath. `$color12`
+ * is the theme's full-strength foreground in every scope, so the state survives
+ * nesting.
+ */
+const selected = (on) => on
+    ? { backgroundColor: '$color3', color: '$color12' }
+    : { backgroundColor: 'transparent', color: '$color11' };
+exports.selected = selected;
+/**
+ * The primary control — the ONE loud thing a page is allowed.
+ *
+ * `$color5` on `$color6` is a raised pushbutton: legible, quiet, monochrome.
+ *
+ * Under-emphasis is the failure mode, and it leaves no mark on a screenshot,
+ * which is exactly why it needs a rule rather than an eye. `Button`'s `default`
+ * variant is a QUIET control on the surface ladder (`$color2`, the same fill
+ * `panel` uses), so a dialog whose only action is an unnamed `<Button>` paints
+ * its single ask as another surface. Name a variant on every control, and when
+ * one is the primary action, spread this. Never `variant="default"`.
+ *
+ * Not `variant="primary"` either, even though it paints the same pixels — a
+ * variant only reaches a `Button`, and half the loud controls in a real app are
+ * an `XStack`, a `SizableText` or a `Link`.
+ */
+exports.accent = {
+    backgroundColor: '$color5',
+    borderWidth: 1,
+    borderColor: '$color6',
+    /**
+     * The foreground is part of the recipe, not an afterthought.
+     *
+     * Spell the fill by hand and you own the label too, and that half is the one
+     * people drop: a hand-spelled `color="$color1"` (4% grey) on a fill that has
+     * since moved to `$color2` (8%) paints a label at 1.07:1 — measured in the
+     * browser, not guessed. The sign-in modal's only button was invisible.
+     *
+     * And it only reaches a label the BUTTON paints. This is the half that is
+     * easy to miss: `<Button {...accent}><SizableText>…</SizableText></Button>`
+     * puts a second component between the recipe and the text, and that component
+     * resolves its own colour from the theme scope the Button just mounted —
+     * where `--color` is re-based to 80%. Measured: fill rgb(51,51,51) and border
+     * rgb(69,69,69), correct, with the label at rgb(204,204,204) — `$color11`,
+     * the QUIET foreground, on the loudest control in the dialog.
+     *
+     * Two guesses about the cure are both WRONG, and each was measured:
+     *
+     *   - "Just don't name a colour." A bare `<SizableText>` inside the Button
+     *     still measures rgb(204,204,204). Silence is not neutral here; the
+     *     nested scope answers for you. The rule is to SAY `$color12`, not to say
+     *     nothing.
+     *   - "Hoist the size to the Button and drop the wrapper." `fontSize="$1"` on
+     *     the Button does not reach the label — still the `size` default. So a
+     *     control that genuinely wants a smaller label keeps its wrapper.
+     *
+     * Which leaves two honest shapes. No size of your own -> hand the string
+     * straight to the Button and let its text host paint it. A deliberate size or
+     * `numberOfLines` -> keep the wrapper and give it `color="$color12"`.
+     *
+     * BUTTON ONLY. A plain `XStack` mounts no theme scope, so a label inside one
+     * that asks for `$color` measures rgb(255,255,255) — correct, and not to be
+     * "fixed". The ban is exactly as wide as the re-basing.
+     */
+    color: '$color12',
+    hoverStyle: { backgroundColor: '$color6', color: '$color12' },
+};
+/**
+ * A state that owns the whole screen: a loading gate, a 404, a crash screen, an
+ * OAuth callback, a receipt. It stands alone — no shell above it — so it must
+ * MEASURE the screen itself.
+ *
+ * `minHeight="100%"` does not measure it, and that is the bug this value ends.
+ * A percentage resolves against the parent's computed height; every ancestor up
+ * to `<body>` is `height: auto`, and `@hanzo/gui`'s provider span is
+ * `display: contents`, so there is no box in between either. The percentage
+ * resolves to auto, the stack shrink-wraps its content, and `justifyContent:
+ * center` then centres inside THAT — perfectly, and invisibly, in a box the
+ * height of the content. Measured: a brand mark at y=0 of a 903px viewport with
+ * 860px of black under it, across ten states carrying the identical line.
+ *
+ * `dvh`, not `vh`: on a phone the URL bar collapses and `100vh` overflows by
+ * its height.
+ *
+ * The centring travels WITH the measure because the two are one decision — a
+ * state that fills the screen holds a paragraph of content — and half of this
+ * recipe is what produced the defect in the first place.
+ */
+exports.screen = {
+    minHeight: '100dvh',
+    alignItems: 'center',
+    justifyContent: 'center',
+};

package/dist/glass.css

@@ -0,0 +1,140 @@
+/* Glass — the material floating chrome is made of, and the ladder it stands on.
+ *
+ *   import '@hanzo/ui/glass.css'      // this slice alone
+ *   import '@hanzo/ui/theme.css'      // the whole sheet; this is inlined in it
+ *
+ * Menus, dialogs, popovers, toasts, sticky bars: things with page UNDER them.
+ * That last clause is the whole rule. Vibrancy is a lens — translucent ground
+ * plus a backdrop blur — so it shows a softened version of whatever it covers,
+ * and covering nothing but the flat canvas it has nothing to soften. An in-flow
+ * card wearing this is not glass; it is the page with extra steps. So: over
+ * content -> glass, in the flow -> the surface ladder. There is no third case.
+ *
+ * ── Values come from @hanzo/design ──────────────────────────────────────────
+ * Every colour, shadow and light below is a design token. The fallbacks are
+ * design's OWN published values, present so a host that imports this file
+ * without design's sheet still gets a ladder instead of a silently-dropped
+ * declaration (an undefined var() invalidates the whole property). They are a
+ * mirror, not a second opinion — glass.test.ts reads @hanzo/design/styles.css
+ * and fails if any of them stops matching, so the copy cannot drift.
+ */
+
+/* ── The material ───────────────────────────────────────────────────────────
+   Applied BY SLOT, not by call site. Every surface below is floating chrome by
+   construction — a popover is over the page or it is nothing — so which of them
+   is glass was never a decision a call site should get to make. It was making
+   it anyway: in the console, of 135 floating surfaces exactly ONE had reached
+   for the material by hand and a dozen dialogs had gone the other way and
+   pinned an opaque fill. Reaching them one by one is 134 edits that agree today
+   and drift apart on the next one somebody adds. A new dialog is glass because
+   it is a dialog.
+
+   `.glass` is here for the same reason `glass()` exists in the recipes module:
+   a hand-rolled bar or a custom menu is floating chrome that no slot names.
+
+   The ground is derived from --background rather than fixed, so the material
+   follows the theme instead of assuming a dark one.
+
+   The opaque `background-color` outside the @supports block is load-bearing
+   rather than belt-and-braces: a browser that cannot blur gets no rule at all
+   from inside it, and a menu with no background is a menu you read the page
+   through. !important beats the compiled atomic background class, which lands
+   in an inline <style> a bundler orders after this sheet, and it beats the call
+   sites that pin a fill by hand — those become no-ops instead of holes. */
+@supports (backdrop-filter: blur(8px)) {
+  .glass,
+  [data-slot="glass"],
+  [data-slot="dialog-content"],
+  [data-slot="popover-content"],
+  [data-slot="select-content"],
+  [data-slot="dropdown-menu-content"],
+  [data-slot="dropdown-menu-sub-content"],
+  [data-slot="tooltip-content"] {
+    background-color: color-mix(in oklab, var(--background) 72%, transparent) !important;
+    -webkit-backdrop-filter: blur(20px) saturate(1.8);
+    backdrop-filter: blur(20px) saturate(1.8);
+  }
+}
+
+/* ── Depth — three rungs, and the lit edge is the load-bearing half ──────────
+   A cast shadow is how a light page shows lift. On a near-black canvas it is
+   nearly free of information: black on near-black moves no pixels, so a raised
+   panel wearing only a shadow reads exactly as flat as one wearing none. What
+   says "this surface is above that one" in a dark UI is the LIT EDGE — the top
+   lip catching light, which is why every macOS/iOS glass panel has one. Design
+   spends the same two tokens for the same reason and zeroes --edge-highlight in
+   `.light`, where a white line on a white card is nothing and the drop does all
+   the work: one composition, both themes, no branch here.
+
+   Levels are a LADDER, not a palette — 1 rests in the flow, 2 lifts off it, 3
+   floats over the page. Nothing needs a fourth; if something seems to, it is
+   sitting at the wrong level.
+
+   Anchored chrome — a menu pinned to the control that opened it, a tooltip to
+   its target — is rung 2. A modal has no anchor and a scrim of its own, so it
+   floats free at 3. Those slots share the rung's rule rather than restating its
+   value, so the ladder cannot come apart from the surfaces standing on it.
+
+   Glass over glass (a select opened inside a dialog) is deliberately left to
+   stack: two 72% grounds land near 92%, so the nested surface reads as MORE
+   solid than its parent, which is the right answer and the one macOS gives. */
+.elevation-1 {
+  box-shadow:
+    var(--edge-highlight, inset 0 1px 0 0 rgb(255 255 255 / .10)),
+    var(--shadow-sm, 0 1px 2px 0 rgb(0 0 0 / .40)) !important;
+}
+
+.elevation-2,
+[data-slot="popover-content"],
+[data-slot="select-content"],
+[data-slot="dropdown-menu-content"],
+[data-slot="dropdown-menu-sub-content"],
+[data-slot="tooltip-content"] {
+  box-shadow:
+    var(--edge-highlight, inset 0 1px 0 0 rgb(255 255 255 / .10)),
+    var(--shadow-lg, 0 10px 15px -3px rgb(0 0 0 / .55), 0 4px 6px -4px rgb(0 0 0 / .55)) !important;
+}
+
+.elevation-3,
+[data-slot="dialog-content"] {
+  box-shadow:
+    var(--edge-highlight, inset 0 1px 0 0 rgb(255 255 255 / .10)),
+    var(--shadow-floating, 0 24px 60px -16px rgb(0 0 0 / .75)) !important;
+}
+
+/* ── The scrim ──────────────────────────────────────────────────────────────
+   The dim that makes a floating panel read as floating rather than as more
+   page. gui's overlay dims TWICE — a translucent ground under a further
+   `opacity` — landing at about a quarter black. Opaque chrome gets away with
+   it; glass does not, because the blur behind a translucent panel only reads as
+   depth when the ground behind it is genuinely darker.
+
+   One value, in one place: the recipes module reads the same token, so the dim
+   behind a component dialog and the dim behind a hand-rolled one are the same
+   dim by construction rather than by two people remembering a number. */
+[data-slot="dialog-overlay"] {
+  opacity: 1;
+  background-color: var(--surface-scrim, rgb(0 0 0 / .8));
+}
+
+/* ── Grouped rows ───────────────────────────────────────────────────────────
+   One card, hairlines between its rows — the macOS settings group. Four
+   separate cards for four toggles reads as four unrelated decisions, each with
+   its own four edges; the same four inside one card reads as one set and drops
+   twelve edges of noise.
+
+   The separator is drawn by the PARENT, because only the parent knows which
+   child is last. Every by-hand version either left a trailing hairline sitting
+   against the card's own bottom border (two parallel lines, 1px apart) or made
+   each row take a `first` flag it should never have needed. `> * + *` has
+   neither failure mode and needs nothing from the call site.
+
+   Pair with `overflow: hidden` on the card (the `rows` recipe does) so the
+   separators stop at the radius instead of poking through the rounded corner.
+
+   --borderColor first: that is the variable the gui theme scope re-bases, and
+   it is what a card's own edge is drawn with. Falling through to --border keeps
+   a host that has design's tokens but no gui scope from losing the line. */
+[data-slot="rows"] > * + * {
+  border-top: 1px solid var(--borderColor, var(--border));
+}