/* ============================================================================
   LUSKI ARCADE — Nav Bar (.arc-nav)

   Persistent top bar for the arcade UI: Main Menu / Stock / Garage / Archives
   / Guide. One of four pieces (nav bar, item-card, dialogue-box, quest-log)
   being built in parallel — this file styles ONLY through the shared
   /arcade/tokens.css custom properties (--arc-*). No colors or fonts are
   invented here; anything that looks like a magic number below (radii,
   spacing, sizes) is layout, not palette, and tokens.css doesn't scope those.

   Conventions carried over from the rest of the site, not invented fresh:
   - .arc-nav__strip is the ONLY element that scrolls horizontally, the same
     pattern as garage/garage.css's .g-tabs — a hidden native scrollbar, not
     a hamburger, for a strip that outgrows a narrow viewport.
   - "Current" is signalled three ways at once (color + weight + underline),
     never color alone — the same rule garage.css documents for .g-tab--active.
   - Gold is used only for the decorative shoulder badges, never for the
     current-section highlight, so the two can never be confused for each
     other — current stays exclusively on the ruby/accent tokens.
   - Every transition is also gated directly by prefers-reduced-motion here
     (not only via the token collapse in tokens.css), so this file behaves
     correctly even if nothing else on the page adds a motion-reduction class.
   ============================================================================ */

.arc-nav {
  position: sticky;
  top: 0;
  z-index: 40;
  display: flex;
  align-items: stretch;
  gap: 8px;
  min-height: 52px;
  padding: 0 10px;
  font-family: var(--arc-font-display);
  /* Still "no bar, no container" per the note below -- this is a frosted-
     glass legibility pass, not a background chip. Without it, a dense card
     (arcade/dossier.css's .dos-file, e.g. a car's Case File) scrolling
     directly under the sticky bar shows its own text/borders visibly
     overlapping the nav's own labels -- readable as a confusing double
     exposure rather than "the nav floats above everything." Blur keeps the
     nav genuinely transparent over plain grounds (nothing to blur when
     there's nothing detailed right behind it) while smoothing exactly the
     busy-content case. Falls back to fully transparent, unchanged, on any
     browser without backdrop-filter support -- no separate fallback rule
     needed since that's just the pre-existing look. */
  backdrop-filter: blur(10px) saturate(1.1);
  -webkit-backdrop-filter: blur(10px) saturate(1.1);
}

/* No bar, no container -- the labels float directly over the page, like the
   boot sequence's own game-menu buttons. Current-page is still colour +
   weight + underline (three signals), just without a background chip
   underneath it now that there's no bar to sit it on. */

/* Homepage-only: the nav sits directly above the hero photo, which is
   darkest right where the nav lives (deliberately, so the hero's own white
   heading reads against the car photo). The default dark-ink-on-light-chrome
   tokens below go unreadable the instant the sticky nav scrolls over that
   dark scrim, so index.html's own <nav> carries this extra modifier to swap
   to the dark-ground token pair instead -- every other page (all light
   chrome backgrounds) keeps the plain .arc-nav tokens untouched. */
/* Soft top-down fades, not bars: no edge, no border, no solid fill, so the
   labels still read as floating over the page rather than sitting in chrome.
   Both are applied only while scrolled (nav.js adds --scrolled past 4px), so
   the bar is genuinely transparent at rest -- which is the state anyone
   arriving on a page sees first, and the one the design is about.
   --scrolled is the light-ground case: page content passing under a fully
   transparent bar collided with the labels outright.
   --on-dark is the photo case: the hero's own scrim covers the bar at rest,
   but scroll the white M3's bodywork up under it and light ink on light paint
   drops below 2:1, so the fade guarantees a dark ground wherever it lands. */
.arc-nav--scrolled:not(.arc-nav--on-dark) {
  /* v2.1: this used to be the light-chrome fade (rgba(233,235,237,...)) for
     every page that wasn't the homepage hero photo. Now that chrome is gone
     sitewide, every page's ground is dark, so this fade uses the exact same
     dark values as --on-dark below rather than keeping a separate "light
     ground" case that no page actually has anymore. */
  background: linear-gradient(to bottom, rgba(7, 7, 7, .62) 0%, rgba(7, 7, 7, .34) 55%, rgba(7, 7, 7, 0) 100%);
}
.arc-nav--on-dark {
  background: linear-gradient(to bottom, rgba(7, 7, 7, .62) 0%, rgba(7, 7, 7, .34) 55%, rgba(7, 7, 7, 0) 100%);
}
.arc-nav--on-dark .arc-nav__link {
  color: var(--arc-ink);
}
.arc-nav--on-dark .arc-nav__link:hover {
  color: var(--arc-ink);
  opacity: .7;
}
.arc-nav--on-dark .arc-nav__link:focus-visible {
  color: var(--arc-ink);
}
.arc-nav--on-dark .arc-nav__link.arc-nav__link--current {
  color: var(--arc-accent);
  border-bottom-color: var(--arc-accent);
}
.arc-nav--on-dark .arc-nav__link.arc-nav__link--current:hover {
  color: var(--arc-accent);
}

/* ── shoulder buttons ──────────────────────────────────────────────────────
   Markup (the L/R spans) stays in every page for now rather than a sitewide
   HTML edit across ~80 files -- hidden here instead, in the one shared
   stylesheet every page already links, so removing them again later is a
   one-line revert instead of another sitewide sweep. */

.arc-nav__shoulder {
  display: none;
}

.arc-nav__shoulder--l {
  border-radius: 4px 10px 10px 4px;
}

.arc-nav__shoulder--r {
  border-radius: 10px 4px 4px 10px;
}

/* ── scrollable strip ────────────────────────────────────────────────────── */

.arc-nav__strip {
  display: flex;
  align-items: stretch;
  /* Centred rather than hugging the left edge -- the shoulder badges are
     hidden (see .arc-nav__shoulder below), so this is centred within
     whatever space the strip itself occupies, not measured against the HUD
     block on the right.

     Centring is done with AUTO MARGINS on the end links, not
     justify-content:center, and that distinction is load-bearing. An earlier
     version of this rule used justify-content:center along with a comment
     asserting that centred flex content stays "fully reachable by scroll in
     every evergreen browser". That is simply false, and it shipped a real bug:
     when a centred flex container overflows, the excess spills past the START
     edge, and scrollLeft cannot go negative, so the overflow is unreachable by
     any amount of scrolling. Measured on a 375px viewport: scrollWidth 517 vs
     clientWidth 240, scrollLeft stuck at 0, with "Main Menu" at left:-271 and
     "THE COLLECTION" at left:-172 -- two links, one of them the main
     commercial page, permanently unreachable on a phone.

     Auto margins have neither failure: they absorb free space when there is
     any (so the group centres exactly as before on desktop) and collapse to
     zero when there is none (so a narrow viewport starts at the first link and
     every link is scroll-reachable). Universally supported, no markup change,
     and no reliance on `safe` alignment keyword support. */
  justify-content: flex-start;
  flex: 1 1 auto;
  min-width: 0;
  gap: 2px;
  overflow-x: auto;
  overscroll-behavior-x: contain;
  scrollbar-width: none;
  -webkit-overflow-scrolling: touch;
}

.arc-nav__strip::-webkit-scrollbar {
  display: none;
}

/* The centring half of the mechanism described on .arc-nav__strip above. Every
   child of the strip is an .arc-nav__link (the L/R shoulder badges are siblings
   of the strip, not children), so first/last-child are the end links. */
.arc-nav__strip > :first-child { margin-inline-start: auto; }
.arc-nav__strip > :last-child  { margin-inline-end: auto; }

.arc-nav__link {
  flex: none;
  display: inline-flex;
  align-items: center;
  min-height: 44px; /* touch target */
  padding: 0 16px;
  border-radius: calc(var(--arc-radius) * 2);
  border-bottom: 2px solid transparent;
  color: var(--arc-ink-solid-dim);
  font-family: var(--arc-font-display);
  font-size: 12px;
  font-weight: 700;
  line-height: 1;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  text-decoration: none;
  white-space: nowrap;
  /* Same overshoot curve brand.js's cookie banner already uses for its own
     slide-in -- reused rather than inventing a second "bounce" feel
     sitewide. Held separate from the color/border/background group below:
     those settle at --arc-transition's plain linear-ish pace, this one is
     deliberately springier and slower so the motion itself reads. */
  transition:
    color var(--arc-transition) var(--arc-ease),
    background-color var(--arc-transition) var(--arc-ease),
    border-color var(--arc-transition) var(--arc-ease),
    transform 0.3s cubic-bezier(0.34, 1.56, 0.64, 1);
}

/* Colour (already matched the site's own chrome nav) plus a small lift that
   holds for as long as the pointer stays -- the reticle's lock-on brackets
   are deliberately skipped for these links (see arcade/cursor.js's
   onMouseOver) so this transform IS the hover feedback, not an addition to
   another one. Keyboard focus gets the same lift so Tab-ing through the bar
   moves the same way hovering does; its own outline + colour below (an
   existing, separate accessibility signal from hover, not something this
   change touches) still wins on colour since it's declared after this. */
.arc-nav__link:hover,
.arc-nav__link:focus-visible {
  color: var(--arc-accent-deep);
  transform: translateY(-4px);
}

.arc-nav__link:focus-visible {
  outline: 2px solid var(--arc-accent);
  outline-offset: -2px;
  color: var(--arc-ink-solid);
}

/* Current section: colour + weight + underline together, per the "colour is
   never the only signal" rule this site already applies to .g-tab--active.
   Text uses --arc-accent-deep (~4.75:1 on chrome, see tokens.css) rather than
   the plain --arc-accent used for the underline -- that one is a decorative
   border, not text, so it only needs the 3:1 floor and reads as the same
   ruby either way. */
.arc-nav__link.arc-nav__link--current {
  border-bottom-color: var(--arc-accent);
  color: var(--arc-accent-deep);
  font-weight: 800;
}

/* ── HUD (Stars + mute) ──────────────────────────────────────────────────
   v2 addition (Aug 2026): the two persistent widgets the rebuild plan calls
   for alongside bay navigation. Sits opposite the scrollable strip, never
   inside it -- these aren't destinations, they're status/controls, and the
   strip's own overflow-x:auto would otherwise be free to scroll them out of
   view on a narrow viewport, which a persistent control must never do.
   flex:none on the whole block keeps it that fixed width regardless of how
   long the strip's content gets. */
.arc-nav__hud {
  display: flex;
  align-items: center;
  gap: 4px;
  flex: none;
}

/* Stars: a real number or the plain word -- see arcade/hud.js for exactly
   when each renders. Sized and coloured like a nav link (same font-family,
   same uppercase-label treatment) so it reads as part of the same control
   family, not a separate widget bolted on. */
.arc-nav__stars {
  display: inline-flex;
  align-items: center;
  gap: 6px;
  height: 44px;
  padding: 0 12px;
  border-radius: calc(var(--arc-radius) * 2);
  color: var(--arc-ink-solid-dim);
  font-family: var(--arc-font-display);
  font-size: 12px;
  font-weight: 700;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  text-decoration: none;
  white-space: nowrap;
  transition: color var(--arc-transition) var(--arc-ease);
}
.arc-nav__stars:hover,
.arc-nav__stars:focus-visible {
  color: var(--arc-accent-deep);
}
.arc-nav__stars-icon {
  width: 13px;
  height: 13px;
  flex: none;
  fill: currentColor;
}
/* Tabular numerals: once a real count is in, it must not reflow the HUD's
   width every time the digit count changes (9 -> 10 -> 100 Stars) -- see
   tokens.css's --arc-font-mono role, used sitewide anywhere a number can
   change under the user without warning. */
.arc-nav__stars-count {
  font-variant-numeric: tabular-nums;
}

/* Mute: icon-only, no visible label -- aria-label carries it. Two icons
   layered in the same box and toggled by opacity/display rather than
   swapping innerHTML on click, so there is nothing for a slow click handler
   to visibly lag behind. */
.arc-nav__mute {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 44px;
  height: 44px;
  flex: none;
  padding: 0;
  border: none;
  background: none;
  border-radius: calc(var(--arc-radius) * 2);
  color: var(--arc-ink-solid-dim);
  cursor: pointer;
  transition: color var(--arc-transition) var(--arc-ease);
}
.arc-nav__mute:hover,
.arc-nav__mute:focus-visible {
  color: var(--arc-accent-deep);
}
.arc-nav__mute:focus-visible {
  outline: 2px solid var(--arc-accent);
  outline-offset: -2px;
}
.arc-nav__mute-icon-on,
.arc-nav__mute-icon-off {
  width: 18px;
  height: 18px;
  fill: currentColor;
}
/* Default (unmuted) state: the "on" glyph shows, "off" is hidden. */
.arc-nav__mute-icon-off {
  display: none;
}
.arc-nav__mute--muted .arc-nav__mute-icon-on {
  display: none;
}
.arc-nav__mute--muted .arc-nav__mute-icon-off {
  display: block;
}

.arc-nav--on-dark .arc-nav__stars,
.arc-nav--on-dark .arc-nav__mute {
  color: var(--arc-ink);
}
.arc-nav--on-dark .arc-nav__stars:hover,
.arc-nav--on-dark .arc-nav__mute:hover {
  color: var(--arc-accent);
}

/* Muted state colour. Until this rule existed, hitting mute changed exactly
   one thing: an 18px glyph swapped shape, same colour, same weight, in the
   corner of the bar. That is a single signal, and a shape-only one at that --
   .arc-nav__link--current higher up this file gets three (colour + weight +
   underline) for less consequential information than "the site is silent now."
   --arc-ink-faint rather than a newly invented colour: fading is what "muted"
   means in every other piece of UI a visitor has used, so it needs no
   learning. Measured, not assumed: the ground actually painted behind the bar
   on /cars/ and / samples rgb(10,10,10), over which .38 alpha composites to
   rgb(98,97,98) for 3.21:1 -- clear of the 3:1 floor WCAG SC 1.4.11 sets for a
   non-text control, and the exact same margin interact.css already documents
   and ships for ruby on parchment. Against the two default inks it is a real
   step, not a nudge: 7.19:1 unmuted on the plain bar, 17.35:1 on --on-dark.
   Do not swap this for --arc-ink-dim; at .62 alpha it lands on top of the
   plain bar's own resting ink and the state becomes invisible again.
   SPECIFICITY, the trap this rule exists to avoid: `.arc-nav--on-dark
   .arc-nav__mute` immediately above is 0-2-0, so the obvious
   `.arc-nav__mute--muted` (0-1-0) would lose on the homepage and quietly work
   everywhere else -- the worst kind of half-fix. Keyed off [aria-pressed] and
   not the --muted class because hud.js sets the attribute on the same line it
   toggles the class, the accessibility tree already carries it, and the two
   can never drift apart. The --on-dark case is spelled out at 0-3-0 rather
   than left to source order. */
.arc-nav__mute[aria-pressed="true"],
.arc-nav--on-dark .arc-nav__mute[aria-pressed="true"] {
  color: var(--arc-ink-faint);
}

/* Hover/focus restated on top of the muted colour, at 0-3-0 and 0-4-0, so
   muting a button does not cost it the pointer and keyboard feedback every
   other control in the bar has. Same two colours the unmuted button uses --
   --arc-accent-deep on the plain bar, --arc-accent on the dark one -- so
   "muted" changes the resting colour only, never the interaction language. */
.arc-nav__mute[aria-pressed="true"]:hover,
.arc-nav__mute[aria-pressed="true"]:focus-visible {
  color: var(--arc-accent-deep);
}
.arc-nav--on-dark .arc-nav__mute[aria-pressed="true"]:hover,
.arc-nav--on-dark .arc-nav__mute[aria-pressed="true"]:focus-visible {
  color: var(--arc-accent);
}

/* ── companion slot (structural only, no new art) ────────────────────────
   A single reserved "a character will stand here" anchor, trailing the HUD.
   Reuses the EXACT dashed-ring + SVG-icon "art pending" language already
   shipped twice: dialogue-box.css's .dlg-portrait/--pending/-icon (Torque's
   portrait in the Guide FAQ) and index.html's own re-tokenized
   .boot-portrait/--pending/-icon pair on the boot menu scene. Same ring,
   same inset dash, same wrench glyph -- just named into this component's own
   arc-nav__ vocabulary and sized down to sit inside the nav's fixed HUD
   column instead of a full portrait. This is what makes the persistent nav
   read as the same "hub with a waiting NPC slot" as the boot menu right
   above it, on every page that adopts this markup -- no behaviour change,
   no new class vocabulary, no invented colour: every value below is either
   copied from .dlg-portrait/--pending or an existing --arc-* token.
   Self-contained opaque chip (chrome fill + accent ring), so it stays
   legible over both the plain chrome ground and the --on-dark hero band
   without needing its own --on-dark override, the way .arc-nav__stars/mute
   (icon-only, no fill of their own) do. Decorative only -- aria-hidden,
   not a control, adds nothing to the tab order. */
.arc-nav__companion {
  position: relative;
  flex: none;
  align-self: center;
  width: 36px;
  height: 36px;
  border-radius: 50%;
  border: 2px solid var(--arc-accent);
  background: radial-gradient(circle at 35% 30%, var(--arc-chrome-1) 0%, var(--arc-chrome-2) 60%, var(--arc-chrome-1) 100%);
  display: flex;
  align-items: center;
  justify-content: center;
  overflow: hidden;
}
.arc-nav__companion::after {
  content: '';
  position: absolute;
  inset: 4px;
  border-radius: 50%;
  border: 1px dashed var(--arc-border-chrome-strong);
  pointer-events: none;
}
.arc-nav__companion-icon {
  position: relative;
  z-index: 1;
  width: 44%;
  height: 44%;
  color: var(--arc-ink-solid-dim);
}

/* ── narrow viewports ────────────────────────────────────────────────────
   Nothing hides behind a hamburger — the strip just scrolls, same pattern as
   garage/garage.css's .g-tabs. Padding tightens so more of the bar reads
   before the scroll-fade edge. Verified down to 320px. */
@media (max-width: 480px) {
  .arc-nav {
    gap: 6px;
    padding: 0 6px;
    min-height: 48px;
  }

  /* The scroll-fade edge the comment above promised but never actually
     shipped: scrollbar-width:none above hides the one native cue a visitor
     would otherwise get that this strip scrolls at all, so the last link
     (currently "Guide") reads as clipped/broken instead of "swipe for
     more." Right edge only, not both -- a fade on the left at rest
     (scrollLeft always 0 on first load) would hint at hidden content that
     doesn't exist yet, which is worse than no hint at all. A mask, not a
     background color, so it works unchanged against every page's own
     background (dark hero, light chrome, whatever). Small enough (20px) to
     be imperceptible on a strip that already fits without overflowing. */
  .arc-nav__strip {
    -webkit-mask-image: linear-gradient(to right, black calc(100% - 20px), transparent 100%);
            mask-image: linear-gradient(to right, black calc(100% - 20px), transparent 100%);
  }

  .arc-nav__shoulder {
    width: 26px;
    height: 18px;
  }

  .arc-nav__link {
    padding: 0 12px;
    font-size: 11px;
  }

  /* Stars keeps its number but drops the "STARS" wordmark's breathing room;
     the icon alone plus a number is unambiguous at this width, and every
     pixel here is competing with the strip for room to show more bays. */
  .arc-nav__stars {
    padding: 0 8px;
    font-size: 11px;
  }
  .arc-nav__mute {
    width: 38px;
  }

  /* Same judgment call the boot menu's own two portrait slots already make
     at their own narrow-viewport breakpoint (768px there; 480px is this
     component's own existing line, see .arc-nav above): a decorative circle
     is real crowding risk next to a HUD that's already tightening every
     other pixel, so it steps out here and the HUD reverts to just Stars +
     mute, exactly as it was before this slot existed. */
  .arc-nav__companion {
    display: none;
  }
}

@media (prefers-reduced-motion: reduce) {
  .arc-nav__link {
    transition: none;
  }
}