/*
 * CHAG SPORTS responsive system: mobile-first, and governed by Design
 * System V1.0 §18's rule: COLLAPSE, DON'T SHRINK - recompose structures
 * for tablet/mobile rather than squeezing the desktop layout narrower
 * (see e.g. desktop_navigation.html/mobile_navigation.html: two distinct
 * navigation components, not one nav shrunk down).
 *
 * Breakpoint reference (Design System V1.0 §18 "BEHAVIOUR"):
 *   320px+   minimum supported layout (unqueried base below)
 *   480px+   large mobile
 *   768px+   tablet
 *   1024px+  desktop
 *   1280px+  wide desktop
 *   1440px+  XL
 * Grouped into the three composition categories §06 "PAGE COMPOSITION"
 * uses for prediction-heavy layouts: mobile (<768), tablet (768-1023),
 * desktop (>=1024). Future components with a genuinely different
 * tablet-vs-desktop composition (e.g. the Prediction Slip sidecar) key
 * their tablet-only rules off `(min-width: 768px) and (max-width: 1023px)`
 * and their desktop rules off `(min-width: 1024px)` - that's a
 * component-by-component judgment, not a fixed rule that every
 * component switches at the same breakpoint.
 *
 * Task 1.72A Phase 1 final repair: the header's own nav/auth-action/
 * menu-trigger switch (below, in the 1024px+ block) used to fire at
 * 768px - a horizontal nav "fits" a 768px viewport in isolation, but
 * the REAL header also carries the logo, search/slip/theme icons, and
 * two auth buttons, and that complete set only clears ~770px of
 * absolute content width (confirmed by bisection: Log In/Sign Up wrap
 * to two lines at 768-769px, recover by 770-771px) - a 1-3px margin,
 * not a real fit. Moved to the already-established 1024px "desktop"
 * tier instead (matching the Prediction Slip's own tablet/desktop
 * boundary above), which measured a genuinely comfortable ~300px of
 * slack. 768-1023px now keeps the mobile header composition
 * (hamburger + offcanvas) throughout, exactly like every other
 * component in this "tablet" tier already does.
 */

/* ---- 320px+ (base) ----
 * Nothing extra needed here beyond base.css - body has min-width: 320px
 * and .container-page uses fluid padding, so nothing overflows at the
 * smallest supported width. Mobile header/nav (hamburger/offcanvas) is
 * the default; desktop header/nav is hidden until the 1024px
 * breakpoint below (see that block's own comment for why not 768px). */

/* ---- 480px+: a little breathing room ---- */
@media (min-width: 480px) {
  .container-page {
    padding-inline: var(--space-24);
  }
}

/* ---- 768px+ (tablet): type scale opens up slightly. The header/nav
   stays in its mobile (hamburger + offcanvas) composition through the
   whole tablet tier - see the 1024px+ block below for why. ---- */
@media (min-width: 768px) {
  .site-footer__grid {
    grid-template-columns: repeat(2, 1fr);
  }

  :root {
    --font-size-display: 3.25rem; /* 52px - top of the 42-52px mobile range */
    --font-size-h1: 2.25rem; /* 36px */
    --font-size-h2: 2rem; /* 32px */
  }
}

/* ---- 1024px+ (desktop): footer goes to full column layout, wider
   container padding, type scale reaches the desktop ranges ---- */
@media (min-width: 1024px) {
  /* Header/nav switches to its desktop composition here, not at 768px
     - see this file's own header comment for the measured reasoning.
     `.site-header__auth-action` (My Account, or Log In + Sign Up) and
     `.site-header__menu-trigger` (the mobile hamburger button) replace
     the former Bootstrap `d-none d-md-inline-flex` / `d-md-none`
     utility-class pair, which was tied to Bootstrap's own fixed 768px
     `md` breakpoint - a second, independent breakpoint system that
     could silently drift out of sync with `.desktop-nav`'s own custom
     one (exactly how this defect happened). All three now switch
     together, off this exact same breakpoint, permanently. */
  .desktop-nav {
    display: flex;
  }

  .site-header__auth-action {
    display: inline-flex;
  }

  .site-header__menu-trigger {
    display: none;
  }

  .container-page {
    padding-inline: var(--space-32);
  }

  .site-footer__grid {
    grid-template-columns: 2fr repeat(3, 1fr);
  }

  /* Desktop: brand/logo/tagline returns to sharing one column alongside
     Product/Company/Content instead of spanning the full row (mobile/
     tablet-only treatment, see components.css). */
  .site-footer__brand {
    grid-column: auto;
  }

  :root {
    --font-size-display: 4rem; /* 64px - bottom of the 64-88px desktop range */
    --font-size-h1: 3rem; /* 48px - bottom of the 48-64px desktop range */
    --font-size-h2: 2.25rem; /* 36px - bottom of the 36-48px desktop range */
    --font-size-h3: 1.625rem; /* 26px - bottom of the 26-32px desktop range */
    --font-size-h4: 1.25rem; /* 20px - bottom of the 20-24px desktop range */
    --font-size-stat: 1.75rem; /* 28px */
  }

  /* Prediction Slip: the sticky sidecar takes over from the mobile
     trigger+bottom-sheet exactly here (Task 1.16) - tablet (768-1023)
     stays on the mobile pattern (see prediction-slip.css). */
  .prediction-slip--desktop {
    display: flex;
  }

  .prediction-slip__mobile-trigger {
    display: none;
  }

  .prediction-slip--mobile {
    /* Bootstrap's offcanvas JS toggles its own display/.show state;
       force-hidden here so a sheet left open before a resize past this
       breakpoint can't sit on top of the now-visible sidecar. */
    display: none !important;
  }

  /* The sidecar is a fixed-position island (see prediction-slip.css) -
     reserve space for it so it doesn't sit over page content.
     `.site-footer` needs the exact same reservation as `.site-main`:
     the slip is `position: fixed` from `top` all the way to `bottom`
     (prediction-slip.css), so it stays on screen for the ENTIRE scroll
     range of the page, not just while `.site-main` is in view - without
     this, the footer's own grid (a sibling of `.site-main`, outside its
     padding) extends its columns under the fixed slip once the page is
     scrolled far enough for the footer to reach that same viewport
     band, hiding its rightmost column(s) (found during the Task 1.72A
     Phase 1 consolidation review - confirmed pre-existing on `master`,
     not introduced by the redesign). */
  .site-main,
  .site-footer {
    padding-right: calc(var(--slip-width) + var(--space-24));
  }
}

/* ---- 1280px+ (wide desktop): type scale opens up further ---- */
@media (min-width: 1280px) {
  :root {
    --font-size-display: 4.75rem; /* 76px */
    --font-size-h1: 3.5rem; /* 56px */
    --font-size-h2: 2.5rem; /* 40px */
    --font-size-stat: 2rem; /* 32px - top of the 20-32px range */
  }
}

/* ---- 1440px+ (XL): display/H1/H2 reach the top of their desktop
   ranges, container padding grows to its widest step. `.container-page`'s
   `max-width: var(--container-xxl)` cap itself is already set
   unconditionally in base.css (Task 1.72A Phase 1 repair: the former
   restatement here was harmless in isolation, but having the same cap
   declared in two files invited exactly the cascade bug fixed below -
   base.css is now the one place that owns it). ---- */
@media (min-width: 1440px) {
  .container-page {
    padding-inline: var(--space-48);
  }

  :root {
    --font-size-display: 5.5rem; /* 88px - top of the 64-88px desktop range */
    --font-size-h1: 4rem; /* 64px - top of the 48-64px desktop range */
    --font-size-h2: 3rem; /* 48px - top of the 36-48px desktop range */
  }
}

/* ---- Overflow safety net at every size ----
 * Deliberately `html` only, never also `body` - setting overflow-x:hidden
 * on BOTH simultaneously breaks `position: sticky` for any descendant
 * (confirmed directly: .site-header's sticky header stopped sticking on
 * scroll the moment both were set). `html` alone still fully prevents
 * horizontal page scroll/bounce, since it's the root scrolling element -
 * this is not a weaker guard, just a differently-targeted one.
 *
 * Task 1.72A Phase 1 repair: this section used to ALSO force
 * `.container-page, .site-header__bar, .site-footer__grid { max-width:
 * 100%; }` here, unconditionally. `.site-header__bar`/`.site-footer__grid`
 * are never independent elements - both are always the exact same DOM
 * node as a `.container-page` div (header.html/footer.html put both
 * classes on one element), so all three names refer to one width
 * mechanism, not three. That single mechanism already declares
 * `width: 100%; max-width: var(--container-xxl); margin-inline: auto;`
 * once, unconditionally, in base.css - a block element with an explicit
 * `max-width` and `width: 100%` of its own can never overflow its
 * parent, so this second, later, same-specificity `max-width: 100%`
 * rule was never protecting against real overflow. Its only actual
 * effect was silently CANCELLING the intended 1440px+ `--container-xxl`
 * cap for every element that carried one of these three classes (a
 * later same-specificity declaration always wins, regardless of which
 * of the three selector names matched) - confirmed and repaired during
 * the Task 1.72A Phase 1 consolidation review; `--container-xxl` is
 * now genuinely enforced (and the container genuinely re-centers via
 * `margin-inline: auto`) at every width, including 1920px+, with
 * `html { overflow-x: hidden }` above remaining the one horizontal-
 * overflow backstop for anything else on the page. */
html {
  overflow-x: hidden;
}