/* ═══════════════════════════════════════════════════════════
   SHARED RESPONSIVE FOUNDATION — site-wide, linked from every page.
   ───────────────────────────────────────────────────────────
   Why this file exists: #nav / .hamburger / .nav-menu / #site-footer
   are the same shared, persisted component on every page (see
   js/transitions.js PERSISTENT_BODY_IDS) — their mobile behavior is
   SUPPOSED to be byte-identical everywhere. In practice it had drifted:
   fonts.html was missing the 480/340px tiers entirely (nav never
   shrank on real phones), support.html/orbat.html/admin.html had no
   nav mobile treatment at all, baza.html/who.html/index.html were
   missing the hamburger-menu shrink. Each page used to carry its own
   copy of these rules inline — easy to skip, easy to drift. Now there
   is exactly one copy. Link this file on every page (after buttons.css/
   auth.css, near nav-dark.css) and DELETE the page's own inline
   versions of the rules below — don't keep both, that just reintroduces
   the "which copy is the real one" problem this file exists to end.

   Canonical breakpoint tiers used site-wide, in order of how content
   actually needs to change (not arbitrary device widths):
     960px — tablet: multi-column grids start dropping a column
     768px — small tablet / large phone: nav padding tightens, page-hero
             top padding shrinks, single-column layouts begin
     480px — phone: nav logo/bird/hamburger/auth-button shrink for real
     340px — small phone (~320-360px CSS width): nav padding/logo drop
             one size further
   Page-specific CSS should reuse THESE four values for anything that
   needs its own breakpoint, instead of picking a new arbitrary number —
   one shared vocabulary makes it obvious when two rules are meant to
   fire together.
   ═══════════════════════════════════════════════════════════ */

/* ─── STICKY FOOTER — applies at every viewport size, not just mobile.
   #site-footer was never actually pinned to the bottom of anything: it's
   a plain in-flow element, so on any page whose content is shorter than
   the viewport (support.html, orbat.html, or really any page on a tall
   phone/monitor) it rendered directly after the short content — partway
   down the screen, with the page's own background visible below it all
   the way to the viewport edge. That's the "з'являється зарано, і під
   нею білий простір" symptom — not a rendering bug, just a missing CSS
   pattern.

   Fix: body becomes a column flexbox spanning at least a full viewport,
   and the footer gets margin-top:auto — the flexbox equivalent of
   "push me to the end, absorb all the leftover space above me." This
   needs no HTML restructuring (works regardless of how many sibling
   sections/divs come before the footer — each keeps its own natural
   height, only the last item's auto margin grows) and both the
   overflow-when-there's-no-space and don't-overflow-when-there-is cases
   fall out of ordinary flexbox math: short content → footer sits flush
   at the bottom with the gap closed; long content → the auto margin
   collapses to 0 and the footer just sits right after it, same as
   before, no dead space either way.

   100vh first (universal fallback), 100dvh after it (browsers that
   don't recognize `dvh` simply ignore that whole declaration and keep
   the 100vh one). dvh tracks the ACTUAL visible viewport as mobile
   Chrome/Safari show/hide their address bar on scroll — 100vh alone is
   fixed at page-load time and can end up taller than what's really
   visible once the browser UI collapses, which is the likeliest source
   of the OTHER symptom ("обрізає, не видно повністю"): a section sized
   off a since-changed 100vh pushing the footer partly under the
   dynamically-resized viewport edge.

   #nav is position:fixed, so it's already out of normal flow and takes
   no part in this — nothing here changes how it renders. */
body {
  display: flex;
  flex-direction: column;
  min-height: 100vh;
  min-height: 100dvh;
}
#site-footer {
  flex-shrink: 0;
  margin-top: auto;
}

@media(max-width:768px){
  #nav{padding:0 28px;}
  #site-footer{padding:0 28px;}
  .footer-copy{font-size:12px;}
  .nav-menu{padding:80px 28px;}
  .menu-link{font-size:clamp(28px,10vw,56px);}
}

/* Nav at phone widths — #nav-auth-btn's font-size/height are set inline
   per-page (style="font-size:1.55rem;height:50px;..."), which only
   !important can out-rank regardless of selector specificity.

   Sizing here isn't just "smaller" — it's measured against actual
   available width. At a 375px phone (nav padding 12px × 2 = 351px
   content box): the logo+bird cluster on the left runs ≈186px
   (image aspect ratios, not text). That leaves ≈165px for the whole
   right side. Logged-out (auth button + hamburger) fits with room to
   spare. Logged-in is the tight case — token count + name (clamped to
   60px) + hamburger — sized to fit with a real margin, not exactly to
   the edge (the previous 16px padding / 8px gap / 72px name-clamp
   version measured out to ~343-348px needed against 343px available:
   correct on paper, zero margin for font-rendering rounding, and
   overflowed outright in the logged-in case — which is what was
   actually happening on real phones). */
@media(max-width:480px){
  #nav{padding:0 12px}
  .nav-logo{font-size:20px;white-space:nowrap;flex-shrink:0}
  .nav-logo-img{height:20px}
  .nav-bird-img{height:29px}
  .nav-right{gap:6px}
  #nav-auth-btn{font-size:1rem !important;height:38px !important;padding:0 1em !important}
  .hamburger{height:38px;padding:0 6px;flex-shrink:0}
  .hamburger span{width:38px}
  /* Open-state "X" offsets are half the (container height − span
     height) — tuned for the base 50px/16px sizing above (17px). Must
     recompute for the shrunk 38px container or the two bars miss the
     center and cross at an angle instead of a clean X. */
  .hamburger.open span:nth-child(1){transform:translateY(11px) rotate(45deg)}
  .hamburger.open span:nth-child(2){transform:translateY(-11px) rotate(-45deg)}
  /* Logged-in state — token count + first name next to the logo. Both
     are sized for a roomy desktop nav on the page's own inline style —
     on a phone that's more text than the space can hold, so the token
     count wraps mid-word and the name gets clipped without this.
     max-width dropped 72px → 60px — see the width-budget note above,
     the name is the one element here that can afford to lose a little
     more before it stops being legible. */
  .nav-token-count{font-size:15px}
  #nav .nav-right .nav-user-name{font-size:14px;max-width:60px}
  .nav-user-icon{display:none}
}

@media(max-width:340px){
  #nav{padding:0 10px}
  .nav-logo{font-size:17px}
  .nav-logo-img{height:17px}
  .nav-bird-img{height:24px}
  .nav-right{gap:6px}
}