/* lean-hover.css — pure-CSS reveal for the Lean hover tooltips, zero JavaScript.

   ⟦added 2026-10-11 — this sheet is now the NO-JAVASCRIPT FALLBACK, not the mechanism.
   Mario ruled "fix" on the token tooltips, whose bodies live in /-verso-docs.json and
   cannot be baked into the frozen HTML, so theme.toml again loads the archive's own
   runtime (tippy.js + popper.js + the binder, `verso-tooltips.js`). When that binder
   is live it sets `verso-tippy` on <html>, and both reveal rules below stand down via
   `:root:not(.verso-tippy)`; otherwise a baked message was shown twice, once by tippy
   and once by this sheet (observed). With scripting off, or the binder failing to
   load, nothing sets the class and this sheet reveals baked messages as before. The
   text below describes the CSS-only mechanism and is otherwise unchanged.⟧

   The live site binds these tooltips with tippy.js + popper.js + an inline binder
   script (see runbooks/site-launch.md §3). `verso-archive.css` (vendored, do-not-hand-
   edit — see its own header) carries the markup's styling but ships `.hover-info` as
   `display: none` with no rule anywhere that unsets it, which is what leaves the
   re-chromed site's tooltips inert. This file is the reveal mechanism, kept separate
   from the vendored sheet per its own instruction: "change the theme's own sheet after
   it, which is loaded later and wins" (theme.toml orders this after verso-archive.css).

   Markup this depends on (verified against all 23 `.has-info` spans across the four
   harvested archives — only the formal-logic post has any):

     <span class="has-info <severity>">
       <span class="hover-container"><span class="hover-info messages">…</span></span>
       <span class="… token">visible token text</span>
     </span>

   Always exactly these two children, `.hover-container` first. Not touched — this
   file styles it, `harvest/` still owns it.

   Tier 1 (below, unconditional): `:hover` reveal. Works in any browser with a real
   hover-capable pointer — `@media (hover: hover)` matches touch/no-hover devices to
   "no reveal," which is exactly today's inert behavior, so degradation there is
   already correct without a fallback branch. The tooltip stays `position: absolute`
   relative to `.hover-container` (verso-archive.css), so it is clipped by this
   block's own `.article-body .hl.lean { overflow-x: auto }` (chrome.css) — the exact
   clipping popper.js existed to solve. Clamped to a sane max-width; not repositioned
   away from a viewport edge.

   Tier 2 (`@supports`, below): where CSS Anchor Positioning's `anchor-scope` is
   available (Chrome/Edge 125+, Firefox 147+, Safari 26+ — Baseline 2026, ~84%
   global usage as of 2026-08), the tooltip switches to `position: fixed`, anchored
   directly to its token via `position-anchor`. `position: fixed` escapes the scroll
   container's clipping entirely — no ancestor from here to `<body>` sets `transform`,
   `filter`, `contain`, or `will-change` to re-capture it (checked against chrome.css,
   phosphor-night.css, verso-archive.css). `anchor-scope` is the load-bearing property:
   every `.has-info` reuses the same `anchor-name`, and without scoping, `position-
   anchor` binds every tooltip on the page to the *last* one in source order (MDN, CSS
   Anchor Positioning guide, "Anchor scoping"). Gating on `anchor-scope` itself, not
   the broader `anchor-name` feature, so a browser with anchor positioning but not yet
   scoping falls through to Tier 1 instead of binding every tooltip to the wrong
   token. */

@media (hover: hover) {
  :root:not(.verso-tippy) .hl.lean .has-info:hover .hover-info {
    display: block;
    max-width: min(28rem, 92vw);
  }
}

@supports (anchor-scope: --lean-hover) {
  @media (hover: hover) {
    .hl.lean .has-info {
      anchor-scope: --lean-hover;
    }

    .hl.lean .has-info > .hover-container ~ * {
      anchor-name: --lean-hover;
    }

    :root:not(.verso-tippy) .hl.lean .has-info:hover .hover-info {
      position: fixed;
      inset: auto;
      transform: none;
      position-anchor: --lean-hover;
      position-area: bottom center;
      position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
      margin-block-start: 0.35rem;
      max-width: min(28rem, 92vw);
      max-height: min(20rem, 60vh);
    }
  }
}

/* Pre-existing contrast bug this reveal is the first thing to expose:
   `--verso-warning-color` is documented in verso-archive.css's own `:root` block as
   "the raw color itself is used for the text of a message," and is `black` in the
   day-lab palette — but `.hover-info.messages > code.warning` uses it as a
   *background*, unlike the info/error variants, which both use the literal `#e5e5e5`
   that the (JS-only, now absent) `.tippy-box[data-theme~='warning']` also used for its
   own background. Black background plus this sheet's `.hover-info code { color: black }`
   is invisible text — masked before only because a tippy box existed to override
   `code.warning`'s background to `none` and supply its own `#e5e5e5` in its place.
   There is no tippy box now, so nothing does that; corrected here to the same
   `#e5e5e5` the other two severities already use, matching what the tippy box used
   to render. Same specificity as the vendored rule, later in cascade order, so no
   `!important` needed. */
.hl.lean .hover-info.messages > code.warning {
  background-color: #e5e5e5;
}