/* 40-nav — THE NAV BAR, REBUILT. One file owns every painted property.
   ══════════════════════════════════════════════════════════════════════════
   OWNER, 2026-09-03: "our nav bar is extremely messed up - especially on
   mobile. can we start the nav design from scratch and re wire everything up
   from scratch... i want this invisible looking nav that blends into sections
   until you scroll - just ensure that wording is still clearly visible."

   WHY IT WAS MESSED UP, measured before anything was written: 195 rules were
   painting this one bar — 45 in nav-fit.css, 35 in sf-refresh.css, 20 in
   theme.css, 12 in mobile.css, 6 in sf-base.css, and 63 more in eleven inline
   <style> blocks in the BODY of every page. The inline ones beat any linked
   sheet at equal specificity, which is why nine consecutive nav passes each
   escalated their selectors instead of fixing the cause, and why the bar ended
   up carrying contradictory answers from four different lanes at once:

     · background rgba(16,41,74,.88) — TRANSLUCENT, while nav-fit.css's entire
       stated purpose was `#site-nav { background:#10294A }`, flat and opaque,
       because the owner's 08-26 complaint was "you can see the site scrolling
       behind". A later lane put the alpha back and nothing noticed.
     · a 2px border-bottom AND a cyan 1px box-shadow, stacked — the double seam
       under the bar.
     · the logo centred on the VIEWPORT while the controls flanking it are
       different widths (burger 44px, actions 97px), so it sat 66px from one
       side and 15px from the other. That is the "not proportioned properly"
       the owner has now reported twice.

   THE FIX IS NOT ANOTHER LAYER OF OVERRIDES. This sheet declares every property
   the bar paints — background, border, shadow, geometry, ink — so nothing is
   inherited from a rule that survives elsewhere. `html body #site-nav` is not
   specificity theatre: the template's own nav CSS is in a <style> in the body,
   and that is the weight required to answer it.

   ── THE TWO STATES ──────────────────────────────────────────────────────────
   `.ccnav-top`     transparent, over the home hero. The bar is not there.
   (default solid)  opaque chrome, from the first scroll and on every other page.

   ONLY index.html gets the overlay. Measured: it is the ONLY page with a hero —
   every other page's content begins directly under the bar, so a transparent
   nav there would drop white ink onto whatever the page happens to start with.
   The class is written into the MARKUP at build time, not decided by script, so
   there is no flash of the wrong state and no page depends on JS to look right.

   ── THE SCRIM IS SOLVED, NOT PICKED ─────────────────────────────────────────
   The hero is a VIDEO. Sampling the top band of both the poster and a mid-clip
   frame, the average luminance is 0.0148 — essentially black — but the MAXIMUM
   is 0.9918, a near-white pixel (252,255,251): the bright filaments. So white
   ink over a bare transparent bar is white-on-white for as long as a filament
   drifts under a word. That is precisely the risk the owner named.

   Solve for the scrim alpha `a` that keeps the ink legible against the WORST
   pixel, not the average:

     ink  --sf-chrome-ink #F0F6FA          L = 0.9135
     want contrast >= 4.5:1
       (0.9135 + 0.05) / (Lbg + 0.05) >= 4.5   ->   Lbg <= 0.1641
     black scrim at alpha a over a 255 channel composites to (1-a)*255
       L((1-a)*255) = 0.1641   ->   (1-a)*255 = 112.6   ->   a = 0.558

   This sheet holds >= 0.62 across the whole bar height, so the worst case is
   5.69:1 and the typical case (a near-black frame) is ~19:1. The gradient then
   falls to nothing over another 1.6 bar-heights, so it reads as a vignette on a
   dark hero rather than an edge — it has no bottom line to see.

   TWO INK DECISIONS FALL OUT OF THAT ARITHMETIC, and both are why the top state
   is not simply the solid state with the background removed:
     · nav links use the FULL ink in the top state, never --sf-chrome-ink-dim.
       The dim tone measures 3.11:1 over the solved scrim — it fails. It is a
       solved second colour for an opaque bar, and this bar is not opaque.
     · the accent is not used for text in the top state: #3FB6C9 measures
       2.58:1 there. It is 7.30:1 on the solid bar, where it is allowed back.

   ── WHAT IS DELIBERATELY NOT DONE ───────────────────────────────────────────
   The nav keeps `id="site-nav"` and every `snav-*` class. Renaming it to escape
   the legacy rules was the first instinct and it is wrong: 32 checks in qa.mjs
   address this bar by those exact selectors, and a rename would leave them
   matching nothing — passing loudly while measuring air. The contract stays;
   only the authority over it moves here. */


/* NO HALO BEHIND THE LOGO — and it is NOT turned off in this file.
   `theme.logoGlow: false` in client.json does it, as the §2i row always said it
   should. That pin was documentation only until 2026-09-04: it died twice over,
   once in build.mjs's theme whitelist and once in a solve that computed the glow
   unconditionally, so a client stating the pin got the halo anyway. Fixed at the
   source in 210eb24. This client carried a `:root { --sf-logo-glow: 0 0 0
   transparent; }` override here for exactly as long as that was broken, and it
   was deleted once the pin was proved on a real build rather than a unit test.
   If a halo ever reappears, the pin has regressed — fix it there, not here. */


/* ══ 1. THE BAR ════════════════════════════════════════════════════════════ */

html body #site-nav {
  position: fixed;
  top: 0; left: 0; right: 0;
  z-index: 9995;
  height: var(--sf-nav-h, 60px);
  margin: 0;
  padding: 0;

  /* Opaque by default and on every page but the home hero. The bar is a
     surface, not a filter: an alpha bar composites whatever scrolls under it
     and no contrast gate can measure that. */
  background-color: var(--sf-chrome-bg, #0B1A2C);
  background-image: none;

  /* ONE hairline. Not a 2px border, and not a border plus a coloured shadow —
     that pair was the seam. */
  border: 0;
  border-bottom: 1px solid rgba(240, 246, 250, 0.10);
  box-shadow: none;

  transition: background-color .28s ease, border-color .28s ease;
}

/* The scrim. Present only on the overlay nav, faded out once the bar is solid,
   and never interactive. */
html body.ccnav-overlay-page #site-nav::after {
  content: "";
  position: absolute;
  top: 0; left: 0; right: 0;
  height: calc(var(--sf-nav-h, 60px) * 3.2);
  pointer-events: none;
  z-index: 0;
  opacity: 0;
  transition: opacity .28s ease;
  background: linear-gradient(
    to bottom,
    rgba(0, 0, 0, 0.70) 0,
    rgba(0, 0, 0, 0.62) var(--sf-nav-h, 60px),
    rgba(0, 0, 0, 0.30) calc(var(--sf-nav-h, 60px) * 1.6),
    rgba(0, 0, 0, 0) 100%
  );
}

/* ── THE TOP STATE: the bar is not there ──────────────────────────────────
   BOTH STATE CLASSES LIVE ON <body>, NEVER ON THE <nav>, and that is a hard
   constraint rather than a style choice. qa.mjs's chrome-identity and
   chrome-shell families compare the nav element's outerHTML BYTE-FOR-BYTE
   across every non-exempt page: one nav, identical everywhere. Marking the home
   page's nav with the overlay class put "ccnav-overlay ccnav-top" into that
   comparison and failed both families at char 32 — 2 failures in 1331 checks,
   and they were right to fail. The body tag is not part of the nav's outerHTML,
   and body classes already differ per page (checkout and my-account carry
   cc-app), so the state belongs there. */
html body.ccnav-overlay-page.ccnav-top #site-nav {
  background-color: transparent;
  border-bottom-color: transparent;
}
html body.ccnav-overlay-page.ccnav-top #site-nav::after { opacity: 1; }

/* Content rides above the scrim. */
html body #site-nav .sf-nav-inner { position: relative; z-index: 1; }

@media (prefers-reduced-motion: reduce) {
  html body #site-nav,
  html body.ccnav-overlay-page #site-nav::after { transition: none; }
}


/* ══ 2. THE LAYOUT ═════════════════════════════════════════════════════════
   A three-column grid, which is the whole proportion fix. `1fr auto 1fr` gives
   the logo its natural width and splits the remainder EQUALLY, so the logo is
   centred in the space it actually has instead of being centred on the viewport
   and crowded by the wider of the two control clusters. */

html body #site-nav .sf-nav-inner {
  height: var(--sf-nav-h, 60px);
  max-width: var(--sf-container, 1200px);
  margin: 0 auto;
  padding: 0 14px;
  display: grid;
  grid-template-columns: auto 1fr auto;   /* desktop: logo | links | actions */
  align-items: center;
  gap: 0;
  box-sizing: border-box;
}

html body #site-nav #snav-mob-left-btn { display: none; }

html body #site-nav .snav-logo {
  grid-column: 1;
  justify-self: start;
  display: inline-flex;
  align-items: center;
  min-width: 0;
  margin: 0; padding: 0;
  text-decoration: none;
}
html body #site-nav .snav-logo img {
  display: block;
  /* 0.68 of the bar. The owner asked for it bigger on 09-03 having asked for
     it SMALLER on 08-26, and both are right: 77% was the old broken value and
     read as crowding, 56% read as timid. 68% is 41px of artwork in a 60px bar. */
  height: calc(var(--sf-nav-h, 60px) * 0.68);
  width: auto;
  max-width: 100%;
  filter: none;
}

html body #site-nav .snav-links {
  grid-column: 2;
  justify-self: center;
  display: flex;
  align-items: center;
  gap: clamp(1.5rem, 3.2vw, 2.75rem);
  min-width: 0;
}

html body #site-nav .snav-right {
  grid-column: 3;
  justify-self: end;
  display: flex;
  align-items: center;
  gap: 2px;
  margin: 0;
}


/* ══ 3. THE INK ════════════════════════════════════════════════════════════ */

html body #site-nav .snav-link {
  display: inline-flex;
  align-items: center;
  height: var(--sf-nav-h, 60px);
  color: var(--sf-chrome-ink-dim, #A6BACB);   /* 8.77:1 on the solid bar */
  font-size: 0.875rem;
  font-weight: 600;
  letter-spacing: 0.01em;
  text-decoration: none;
  white-space: nowrap;
  background: none;
  border: 0;
  transition: color .18s ease;
}
html body #site-nav .snav-link:hover,
html body #site-nav .snav-link:focus-visible { color: var(--sf-chrome-ink, #F0F6FA); }

/* .snav-right IS IN THE SELECTOR ON PURPOSE. sf-refresh.css carries
   `#site-nav .snav-right .snav-icon-btn { width:46px }` — (0,1,2,0). The obvious
   `html body #site-nav .snav-icon-btn` is (0,1,1,2), and IDs tie, so the class
   count decides and 46px wins: measured, the actions block stayed 101px wide and
   left the logo 13px from the cart. Stacking more ELEMENTS on the front never
   fixes a class-count loss. */
html body #site-nav .snav-right .snav-icon-btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  /* 40 wide, 44 tall. The pair sits flush, so the combined touch area clears
     44x44 in the direction a thumb actually misses, while 2x44 wide was what
     pushed the logo to 22px from the actions and 78px from the burger. */
  width: 40px; height: 44px;
  color: var(--sf-chrome-ink, #F0F6FA);
  background: none;
  border: 0;
  border-radius: 10px;
  text-decoration: none;
}
html body #site-nav .snav-right .snav-icon-btn svg { width: 20px; height: 20px; display: block; }
html body #site-nav .snav-right .snav-icon-btn:hover { background: rgba(240, 246, 250, 0.07); }

/* THE TOP STATE TAKES THE FULL INK, on the arithmetic in the header: the dim
   tone measures 3.11:1 over the solved scrim and may not be used here. */
html body.ccnav-overlay-page.ccnav-top #site-nav .snav-link,
html body.ccnav-overlay-page.ccnav-top #site-nav .snav-right .snav-icon-btn,
html body.ccnav-overlay-page.ccnav-top #site-nav #snav-mob-left-btn {
  color: var(--sf-chrome-ink, #F0F6FA);    /* 5.69:1 worst case, ~19:1 typical */
}

/* The cart badge keeps its own solved pair in both states. */
html body #site-nav .snav-cart-badge {
  position: absolute;
  top: 4px; right: 2px;
  min-width: 16px; height: 16px;
  padding: 0 4px;
  border-radius: 999px;
  background: var(--sf-accent, #3FB6C9);
  color: #04121A;
  font-size: 0.625rem;
  font-weight: 800;
  line-height: 16px;
  text-align: center;
}


/* ══ 4. THE PHONE ══════════════════════════════════════════════════════════
   Burger | logo | actions, with the side columns equal so the logo is centred
   between them. Measured before: logo 66px from the burger and 15px from the
   actions. After: symmetric, with the logo at 52% of the bar height. */

@media (max-width: 860px) {
  html body #site-nav .sf-nav-inner {
    grid-template-columns: 1fr auto 1fr;
    padding: 0 10px;
  }

  html body #site-nav #snav-mob-left-btn {
    grid-column: 1;
    justify-self: start;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    width: 44px; height: 44px;
    margin: 0;
    padding: 0;
    color: var(--sf-chrome-ink, #F0F6FA);
    background: none;
    border: 0;
    border-radius: 10px;
  }
  html body #site-nav #snav-mob-left-btn svg { width: 22px; height: 22px; display: block; }

  html body #site-nav .snav-links { display: none; }

  html body #site-nav .snav-logo {
    grid-column: 2;
    justify-self: center;
  }
  html body #site-nav .snav-logo img {
    height: calc(var(--sf-nav-h, 60px) * 0.60);
  }

  html body #site-nav .snav-right {
    grid-column: 3;
    justify-self: end;
    gap: 0;
  }
}


/* ══ 5. THE HOME HERO RUNS UNDER THE BAR ═══════════════════════════════════
   The hero carried `margin-top: 60px`, which is what put it BELOW the fixed nav
   — there was nothing behind the bar to blend into. The margin becomes padding
   of the same size: the background now starts at the top of the page while the
   headline stays exactly where it was.

   THE SELECTOR HAS TO CARRY AN ID AND THIS IS NOT PREFERENCE. The rule holding
   the hero down is `body:not(.layout-default) #hero { margin-top: var(--sf-nav-h) }`
   in the page's own inline block — (0,1,1,1). A class-only selector, however
   many elements are stacked in front of it, loses to it: the first version of
   this rule read `html body.ccnav-overlay-page .sf-hero` (0,0,2,2), linked
   correctly, matched the element, and changed nothing at all. Measured
   margin-top after it: still 60px. */

html body.ccnav-overlay-page #hero,
html body.ccnav-overlay-page .sf-hero {
  margin-top: 0;
  padding-top: var(--sf-nav-h, 60px);
}

/* ══ 6. THE SENTINEL ═══════════════════════════════════════════════════════
   A 1px marker at the very top of the page. The nav is transparent while it is
   on screen and solid once it is not — see the note in 40-nav.mjs for why this
   is an IntersectionObserver and not a scroll handler. It paints nothing and
   catches no pointer. */
#ccnav-sentinel {
  position: absolute;
  top: 0; left: 0;
  width: 1px;
  height: 8px;
  pointer-events: none;
  visibility: hidden;
}