/* ============================================================
   HealthCompass - sticky offset below the nav.
   v2.33.0

   THE BUG
   `.hcnav` is `position:sticky; top:0; z-index:9000; height:60px`, so it
   is pinned to the viewport top permanently. Nine page-level sticky bars
   ALSO declared `top:0`, with z-index between 50 and 350 - all far below
   9000. So each of them pinned to the same 0px line and the navbar
   painted straight over it. On six guide pages the pillar/tab bar
   (~50px tall) was therefore COMPLETELY hidden behind the 60px nav once
   you scrolled; on three others the filter/search bar was hidden too.

   Found by a stacking audit while fixing the drawer close button, not by
   any test - jsdom does no layout, so nothing in the suite could see it.
   This is pre-existing (not introduced by the elevation work), but it is
   real and it is the class of bug Mike was reporting.

   THE FIX
   One token for the nav height, and every page-level sticky bar offsets
   by it. Nobody should hardcode 60px again: if the nav height changes,
   this is the single place that needs to know.

   LOAD ORDER: these `top:0` rules live in each page's inline <style>,
   which on guide pages closes AFTER the first stylesheet links. So this
   file MUST be linked after the final </style> - it is wired next to
   css/type.css and css/hero.css, which are already verified to sit
   there. See the comment in css/type.css.
   ============================================================ */

:root {
  /* Must track .hcnav's height in css/nav.css. */
  --hc-nav-h: 60px;
}

/* ------------------------------------------------------------------
   THE NAV WAS NEVER ACTUALLY STICKY ON 24 PAGES.

   js/nav.js mounts into <div id="hc-nav">, and `position:sticky` can
   only stick WITHIN ITS PARENT'S BOX. That wrapper is exactly as tall
   as the nav it contains (60px) and sits at the top of the document,
   so .hcnav had a sticky range of zero and scrolled away like static
   content. Only index.html escaped it, because there the nav is
   rendered by React inside the tall #root.

   The wrapper was completely unstyled - its only mention anywhere is a
   print rule in foodfirst.html - so nothing was holding it up.

   Fixing this is also what makes the --hc-nav-h offsets below correct:
   they assume a 60px band at the top of the viewport is occupied by the
   nav. Before this rule that band was empty, so offsetting the sticky
   bars by 60px opened a visible window of page content scrolling
   through above them. That is the bug Mike screenshotted on
   supplements.html - my v2.33.0 offset made a pre-existing bug visible
   rather than causing it, but the two must ship together.

   The wrapper carries the sticky/z-index and .hcnav keeps its own
   declarations harmlessly. .hcmenu inside is position:fixed and sticky
   does NOT create a containing block for fixed descendants, so the
   mobile menu still anchors to the viewport. v2.34.0
   ------------------------------------------------------------------ */
#hc-nav {
  position: sticky;
  top: 0;
  z-index: 9000;
}

/* Pillar / tab bars - brain, gut, heart, longevity, stress, water */
.br-pillars,
.gt-pillars,
.ht-pillars,
.lg-pillars,
.st-pillars,
.wt-pillars,
/* Filter / search / control bars - supplements, blood, food */
.ctrl,
.bl-controls,
.fg-controls {
  top: var(--hc-nav-h);
}

/* Anchor targets must clear BOTH the nav and any sticky bar beneath it,
   or an in-page jump link lands with its heading hidden underneath them.
   `scroll-margin-top` is the correct mechanism - it does not affect
   layout, only where the browser stops when scrolling to a target. */
:target {
  scroll-margin-top: calc(var(--hc-nav-h) + 3.5rem);
}

/* Section ids used by the guide jump-link rows. */
[id]:is(section, div, h2, h3) {
  scroll-margin-top: calc(var(--hc-nav-h) + 3.5rem);
}