/* Surface: the glass theming axis. Glass is NOT a per-component look: it is a
   theming-level surface mode (`solid` | `glass`), the same kind of switch as the
   light/dark scheme.

     <html data-surface="glass">          <!-- force glass -->
     <html>                               <!-- solid (the default) -->
     <html class="dark" data-surface="glass">

   A surface's role and context choose its material: content and reading panes
   use stable frost; functional floating shells and controls can use Liquid
   Glass. Labels, chart marks, unfilled variants, and layout-only wrappers inherit
   the surrounding surface instead of gaining their own pane. Custom motion is
   separate from the material and is never implied by a tint token.

   Tint density is independent of that choice. Functional shells use
   `--glass-tint`, content panes use `--glass-tint-content`, surfaced controls use
   `--glass-tint-control`, and reading overlays use `--glass-tint-dense`. Dense
   menus retain enough coverage to separate their rows from the page behind.
   Internal state fills retain their semantic meaning and readable contrast.

   The mode still swaps NO semantic color token: `--popover` and `--card` are the
   same opaque colors under `data-surface="glass"` as without it, and a surface
   that opts out of the material keeps its opaque fill. (Glass once worked by
   overriding `--popover` translucent here, which dragged every popover-filled
   surface into a see-through state with no material behind it.) Nothing takes
   glass per instance either: there is no per-component `glass` prop, in the CSS
   or in the kit.

   The material itself (`--glass-tint*`, `--glass-frost`, `--glass-specular`) lives in
   colors.css. This file only decides WHEN it is on. The page behind the frost is the
   app's own: the kit ships no page backdrop and leaves the body's background alone
   (the Dark Factory direction keeps page looks in the app). */
[data-surface="glass"]{
  --surface-mode:glass /* @kind other */;
}

/* Accessibility and media fallbacks. Translucency is decorative: it drops the
   moment it would cost legibility, and it means nothing on paper.

   Pointing every `--glass-tint*` at an opaque token is what turns the material
   OFF here: the functional and dense layers read the opaque `--popover`, the
   content and control layers the opaque `--card`, so with the frost set to none
   each glass pane collapses to a flat, fully opaque card, the web
   counterpart of the accessibility rungs GlassSurface applies natively
   (src/style/glass-surface). While glass swapped `--popover` translucent, this
   line resolved to that translucent value and the "reduce transparency" panel
   stayed see-through. A scheme or palette wrapper inside the glass root (`.dark`,
   `data-palette`) declares its own tints, which would otherwise win over the
   fallback inherited from the root, so each rule names those wrappers too. */
@media (prefers-reduced-transparency:reduce){
  [data-surface="glass"],[data-surface="glass"] :is(.dark,[data-palette]){--glass-tint:var(--popover);--glass-tint-content:var(--card);--glass-tint-control:var(--card);--glass-tint-dense:var(--popover);--glass-frost:none /* @kind other */;--glass-edge:var(--border);--glass-specular:var(--shadow-lg) /* @kind shadow */}
}
@media (prefers-contrast:more){
  [data-surface="glass"],[data-surface="glass"] :is(.dark,[data-palette]){--glass-tint:var(--popover);--glass-tint-content:var(--card);--glass-tint-control:var(--card);--glass-tint-dense:var(--popover);--glass-frost:none /* @kind other */;--glass-edge:var(--input);--glass-specular:var(--shadow-lg) /* @kind shadow */}
}
@media print{
  [data-surface="glass"],[data-surface="glass"] :is(.dark,[data-palette]){--glass-tint:var(--popover);--glass-tint-content:var(--card);--glass-tint-control:var(--card);--glass-tint-dense:var(--popover);--glass-frost:none /* @kind other */;--glass-edge:var(--border);--glass-specular:none /* @kind shadow */}
}