/* v62 — two mobile fixes, loaded unbundled for the same reason as
   patches-v46/v59: no build tooling here to fold these into dist/*, and
   /assets and /dist are served immutable for a year (see _headers), so a
   fix has to arrive as a brand-new file rather than an edit to a cached one.

   1. THE BLACK-ON-SCROLL BUG.
      `body.has-crt .screen` is both the barrel-warp filter target
      (`filter: url(#crt-barrel)`) AND the fixed, internally-scrolling
      container (`position: fixed; overflow-y: auto;
      -webkit-overflow-scrolling: touch`) for the entire page. That exact
      combination — an SVG filter on the element that is also its own
      momentum-scrolling viewport — is a known iOS/WebKit rendering fault:
      content scrolled into view is not repainted and shows solid black
      until something forces a recomposite, which scrolling back over it
      does. That is exactly "scroll down, it's black underneath; scroll up
      and the image is there." CRT mode is on by default, so this hits most
      phone visitors, most of the time.

      It is also already documented as the single most expensive CRT layer
      (see the frame-rate comment in <head>: ~13.4fps with the warp off
      against ~7.4fps with it on) — removing it on handheld widths is a
      performance win as well as the actual bug fix. The scanlines,
      vignette, edge and bezel are separate non-filtered fixed overlays and
      are untouched, so CRT mode still reads as CRT mode on a phone.

   2. LANGUAGE BUTTONS, OUT OF THE HEADER ON A PHONE.
      js/i18n.js now builds the EN/NL/DE/FR switcher twice: once into
      .site-head (unchanged — desktop keeps it there) and once into a new
      .menu__lang section at the bottom of the hamburger menu. This just
      hides the header copy below the site's own phone breakpoint and
      styles the menu copy to match the menu's existing settings-style
      sections (see .menu__screen, the CRT toggle, in css). */

@media (max-width: 1099px) {
  body.has-crt .screen { filter: none; }
}

@media (max-width: 639px) {
  .site-head .lang-select { display: none; }
}

.menu__lang {
  margin-top: 16px;
  padding-top: 14px;
  border-top: 1px solid rgba(0, 0, 0, .12);
}
.menu__lang .lang-select {
  flex-wrap: wrap;
}

/* v63 — product page, size/buy buttons unresponsive to taps on some mobile
   browsers. No blocking overlay or handler was found (pointer events land on
   the button itself; the hologram's own drag listeners are scoped to its own
   element and release cleanly). The one real gap: these buttons never
   declared touch-action, so a touchscreen's default gesture handling (which
   includes double-tap-to-zoom detection and up to a ~300ms delay deciding
   whether a tap is the start of a zoom/scroll gesture) is left to guess on
   every tap instead of being told plainly "this is a tap target". Also
   widens the gap between size chips slightly on narrow screens so adjacent
   36-44px buttons are less likely to catch a miss-tap on their neighbour. */
.product__size,
.product__buy,
.product__view-key {
  touch-action: manipulation;
}

@media (max-width: 480px) {
  .product__sizes { gap: 10px; }
}

/* v71 — Language + Elsewhere (social) sat stranded near the very bottom of
   the hamburger menu, "too far into the bottom-left" on desktop. Root cause:
   .menu__frame forces height:100% of the full-viewport-height .menu drawer,
   and .menu__panel's flex-grow always stretches to fill whatever is left —
   so a short tab (Artists, 3-4 rows) leaves a large empty gap above
   Language/Elsewhere, shoving both down to the literal bottom edge. Same
   flex math runs identically at every width — desktop, tablet and phone all
   showed the same stranding when checked.

   Fix: let the visible bordered terminal box size to its own content
   instead of forcing full height, so Language/Elsewhere follow immediately
   after whatever tab content is showing. The outer .menu drawer is
   untouched (still full height, still the click target/backdrop). The
   active tab panel keeps a generous cap plus its own scroll for genuinely
   long lists (the Artists tab already runs to 8 rows and will keep
   growing), so nothing can overflow past .menu's own edge (.menu has
   overflow: hidden). Downloads/Merch are just a short callout each, well
   under the cap either way. */
.menu__frame {
  height: auto;
  max-height: 100%;
}
.menu__panel {
  flex: 0 1 auto;
  max-height: min(52vh, 460px);
}

/* v73 — Language + Elsewhere still read as "too far to the left" after v71
   fixed the vertical stranding. Real cause: .menu__lang and .menu__social
   have no horizontal padding at all (only padding-top, from the original
   v62 rule), so their text/buttons sit flush against .menu__frame's inner
   edge — while .menu__panel (everything above them: the artist list,
   downloads/merch callouts) has 14px of padding on every side. That 14px
   gap is what makes the rest of the menu look properly inset; Language and
   Elsewhere were the only two sections missing it, so they visibly stick
   out to the left of everything above them. Match the panel's padding. */
.menu__lang,
.menu__social {
  padding-left: 14px;
  padding-right: 14px;
}

/* v74 — EQ bands read as "glitchy, fights with scroll" on touch. Root cause:
   the 10 EQ faders (.tone-band input, real vertical <input type=range>) had
   no touch-action set at all, so on a touchscreen the browser has to guess
   mid-drag whether a vertical drag means "move the slider" or "scroll the
   page", and can change its mind partway through — read as glitchy/hard to
   hit. Same fix already used for the volume/rec-level knob (.knob, above,
   already has touch-action:none) and the v63 product-page buttons.
   NOTE: this rule was originally (and uselessly) added to css/tone.css —
   tone.css is only a *source* for the frozen dist/style-*.css bundle (see
   the big comment on js/shelf-patch.js for why there's no build tooling
   here to regenerate that bundle), so it never reached the live page. This
   patch file is what's actually <link>-ed after the bundle, so this is the
   copy that counts. */
.tone-band input {
  touch-action: none;
}

/* v76 — GG asked for the volume/rec-level knobs to click through 11 fixed
   positions (0-10) instead of moving freely, with the full 0-10 scale
   printed around the knob (like a real stepped hardware dial) rather than
   just reported to assistive tech. The interactive/detent half of this is
   js/knob-patch.js (new, unbundled, loaded from index.html) — same "frozen
   bundle, patch from outside it" situation as the touch-action rule just
   above; js/utils.js/deckControls.js/main.js were updated too, for
   whenever this site's bundle is next rebuilt, but knob-patch.js is what
   actually runs today. This half is just the printed scale's appearance:
   11 <span>s (0-10, index.html's #volumeKnobTicks/#recordVolumeKnobTicks,
   built into the page already) arranged in a circle around the dial.
   --knob-r is each tick's distance from the knob's own center, kept as a
   custom property so it can be tuned per breakpoint below as .knob itself
   changes size. Each tick's angle exactly matches one of makeKnob's 11
   possible pointer rotations -- KNOB_MIN_DEG=-90 to KNOB_MAX_DEG=90, in
   steps of 18deg: a clean left/9-o'clock -> top/12 -> right/3-o'clock
   sweep (v78 -- the original -132/132 range let 0 and 10 dip down past
   horizontal at each end, which read as "numbers running along the
   bottom") -- so the pointer always ends up aimed straight at whichever
   number is current. The gap between the two knobs was widened
   from 12px so their scales don't collide (verified via screenshot at
   desktop, 760px and 639px widths — 12px put "8" and "2" on top of each
   other). js/knob-patch.js toggles .is-active on whichever tick is current. */
.knobs {
  gap: 44px;
}
.knob-dial {
  position: relative;
  --knob-r: 40px;
}
.knob-dial__ticks {
  position: absolute;
  inset: 0;
  pointer-events: none;
}
.knob-dial__tick {
  position: absolute;
  left: 50%;
  top: 50%;
  width: 1.4em;
  margin-left: -.7em;
  text-align: center;
  font: 700 9px/1 monospace;
  color: #6b6d63;
  transform: rotate(var(--tick-angle)) translateY(calc(-1 * var(--knob-r))) rotate(calc(-1 * var(--tick-angle)));
}
.knob-dial__tick.is-active {
  color: #174e23;
}
@media (max-width: 860px) {
  .knobs { gap: 40px; }
}
@media (max-width: 760px) {
  .knob-dial { --knob-r: 37px; }
}
/* v127 -- phone: the 0-10 numbers were printing ON the knob, not around it.
   The knob stays 58px wide on phones (radius 29px), but this rule had pulled
   the numbers in to a 28px radius, so every number sat on the knob's own
   edge. Measured live at 390px and 320px wide. The fix:
   - radius back to 37px, the same clearance as tablet
   - 8px type
   - 14px top margin, so "4"/"5" clear the REC button above
   - 16px side padding: .deck__meters is flex-end, and without it REC LEVEL's
     "10" ran past the deck's right edge and was clipped
   Verified at 390, 360 and 320px wide: no tick on the knob face, 14px clear
   of REC, 15px between the two scales, and every tick inside the deck. */
@media (max-width: 639px) {
  .knob-dial { --knob-r: 37px; }
  .knob-dial__tick { font-size: 8px; }
  .knobs { margin-top: 14px; padding: 0 16px; }
}

/* v79 -- desktop/tablet: the "5" tick (top of the 0-10 arc, closest to the
   transport row above) was touching/overlapping the REC button -- confirmed
   live (0px gap between the REC LEVEL knob's "5" tick and REC's bottom
   edge at 900px-1440px+, where the transport buttons + REC sit on their own
   row above .knobs). The tick sits --knob-r above the knob's own center,
   which is a few px taller than half of .knob-dial's own box, so the tick
   was already poking out above .knob-dial before this -- .knobs just had
   zero margin to absorb that. Below ~870px the transport row and .knobs
   share one row instead (see the merch/downloads-style single-row layout),
   where this doesn't apply and margin-top would only add unwanted space. */
@media (min-width: 900px) {
  .knobs { margin-top: 24px; }
}

/* v92 -- mobile landscape: the hamburger menu (.menu) is a fixed-height,
   full-viewport drawer with `overflow: hidden` (see the v71 note above --
   that's deliberate there, to stop the active tab panel's own scroll from
   also scrolling the whole drawer). At a short landscape height like
   812x375 the drawer is only ~371px tall but its content -- tab strip, the
   active tab panel, then the Language and Elsewhere (social) block below
   it -- runs to ~475px. With no scroll on the drawer itself, that last
   ~104px (Language + social links) is simply clipped off and unreachable.
   Confirmed live via an iframe at 812x375: menu.scrollHeight (475) >
   menu.clientHeight (371), overflow-y: hidden.

   Fix: let the drawer scroll, but only in the cramped landscape case --
   portrait phones are already tall enough that this never triggers, and
   leaving overflow: hidden everywhere else keeps the v71 behavior intact. */
@media (max-width: 900px) and (orientation: landscape) {
  .menu {
    overflow-y: auto;
    -webkit-overflow-scrolling: touch;
  }
}

/* Pre-launch audit (Oct 2026): iPhones zoom the whole page in when a text
   field smaller than 16px gets focus — sign-in, fan sign-up, artist portal,
   basket discount code. 16px on touch screens stops that. */
@media (pointer: coarse) {
  input:not([type=checkbox]):not([type=radio]):not([type=range]):not([type=file]),
  select, textarea { font-size: max(16px, 1em) !important; }
}

/* 6 Nov 2026: header logo mask (webp) — the dist/style-*.css rule points at the 90 KB png;
   this later rule wins, so only the 45 KB webp is downloaded. */
.site-head__home-logo{-webkit-mask-image:url(../assets/brand/lifelong-logo-official-black-transparent-600.webp);mask-image:url(../assets/brand/lifelong-logo-official-black-transparent-600.webp)}