/* mobile-fullscreen.css — shared across pages (2026-07-30, per Owen).

   Every page's .shell is a fixed 375x780px "phone frame" box, centered in
   the real browser viewport via body's flex centering + padding — built
   that way so it previews nicely as a phone-shaped mockup on a desktop
   browser (useful for design/screenshot iteration). On an actual phone,
   though, that fixed box doesn't fill the real screen — it just sits as a
   small rectangle in the middle of Safari's real viewport, and the real
   page scrolls around it instead of the app behaving like a normal mobile
   site/PWA.

   parser.html already had this exact fix (@media max-width:390px, .shell
   goes full-viewport, no radius/border) — this file is that same fix
   pulled out into one shared place so every other page gets it too,
   instead of hand-duplicating it per page. parser.html itself keeps its
   own local copy of this block rather than linking this file, since it's a
   self-contained page by design elsewhere in this app — but its copy gets
   the same dvh/overflow-lock fix below applied to it directly.

   Loaded via <link> after each page's own inline <style> block, so same-
   specificity + later-source-order lets it override that page's .shell/
   body rules without needing !important.

   Breakpoint (2026-07-30 fix, per Owen): started at max-width:390px,
   matching parser.html's existing precedent — but that's only correct for
   older/smaller iPhones. Anything in the Plus/Pro Max tier (iPhone 14/15/16
   Plus and Pro Max are 428-440px wide) has a wider CSS viewport than 390px
   and was falling straight through the media query, so the fix silently
   never applied and the app kept rendering as the small centered mockup
   box. Widened to 600px, comfortably covering every realistic phone width
   (including Plus/Pro Max/Ultra models) while staying well under normal
   laptop/desktop browser window widths, which are rarely resized below
   ~700-800px.

   100vh → 100dvh (2026-07-31 fix, per Owen: "hard to navigate... wants to
   scroll instead of being locked in place"). Mobile Safari's `100vh` is
   measured against the LARGEST possible viewport (address bar collapsed),
   not what's actually visible on load (address bar still showing) — so
   both .shell and body rendered taller than the real visible area, and
   since body was never told not to overflow, the whole outer page became
   scrollable to reveal the rest, instead of staying locked with only
   .scroll-area (inside .shell) scrolling like intended. `100dvh` (dynamic
   viewport height) tracks the real, current visible viewport as browser
   chrome shows/hides, so it doesn't have this gap; kept the `100vh` line
   directly above each `100dvh` one as a fallback for any older engine that
   doesn't understand `dvh` (unsupported units are ignored, so the fallback
   simply never gets overridden there). `overflow: hidden` on body is what
   actually enforces the lock — matching heights alone doesn't stop a page
   from scrolling if something inside still overflows by a pixel or two. */

@media (max-width: 600px) {
  html, body {
    padding: 0;
    height: 100vh;
    height: 100dvh;
    overflow: hidden;
  }
  .shell {
    width: 100vw;
    height: 100vh;
    height: 100dvh;
    border-radius: 0;
    border: 0;
  }

  /* iOS Safari auto-zooms the whole page to fit any focused input/textarea
     whose font-size is under 16px — an accessibility behavior meant for
     hard-to-read fields, but it fires on this app's compact ~13-15px
     inputs (search box, tag/place fields, date/era fields, the shared
     name-modal input, etc.) too. The viewport is deliberately left
     pinch-zoomable rather than locked with maximum-scale/user-scalable=no
     (2026-07-31, per Owen: keeping room for a real pinch/tap-to-zoom
     feature on photos later), so that auto-zoomed state doesn't reset
     itself once the keyboard closes — tapping away leaves the page zoomed
     in until the user manually pinches back out, which for a first-time
     visitor reads as broken rather than intentional.

     Bumping every input/textarea/select to 16px here removes the trigger
     at the source instead of touching the viewport meta tag, so nothing
     about this fix limits adding deliberate zoom elsewhere later. Scoped
     to this mobile-only breakpoint (not name-modal.css or each page's own
     inline styles directly) so the desktop mockup preview keeps its
     original, tighter sizing — this only changes behavior on the real
     phone widths where the zoom bug actually happens. `!important` is
     needed since some of these (e.g. `.search-box input`) carry higher
     selector specificity than a bare `.shell input` rule loaded after them
     would otherwise be able to override. */
  .shell input,
  .shell textarea,
  .shell select {
    font-size: 16px !important;
  }
}

/* Keyboard-aware bottom UI (2026-07-31, per Owen: "search bar gets in the
   way of the navigation"). iOS Safari doesn't shrink the layout viewport
   (what vh/dvh and position:absolute/fixed measure against) when the
   on-screen keyboard opens — only the *visual* viewport shrinks — so
   bottom-anchored controls like the search box and the nav's popover menus
   can end up sitting behind the keyboard, or crowded right against the nav
   bar once there's no real room left above it. There's no supported CSS-only
   fix for this on iOS (env(keyboard-inset-height) isn't implemented in
   WebKit), so js/mobile-fullscreen.js measures the gap itself via the
   visualViewport API and publishes it as --keyboard-inset on <html>; this
   rule just consumes that variable to float these elements up above the
   keyboard instead of underneath/against it. Defaults to 0px (no-op) via
   the var() fallback everywhere the JS hasn't run yet or on desktop, where
   visualViewport either doesn't fire this way or there's no keyboard to
   begin with. */
.search-box,
.nav-menu,
.filter-menu,
.platform-menu,
.standard-menu,
.chapter-menu,
.expand-menu,
.media-filter-menu,
.source-menu,
.add-menu,
.top-add-menu,
.action-sheet {
  transform: translateY(calc(-1 * var(--keyboard-inset, 0px)));
  transition: transform .18s ease;
}

/* Real standalone/Home-Screen launch only (2026-07-31, per Owen: "add to
   home screen... does not properly fit my phone screen"). Every page has a
   fake mockup status-bar row (.sb — "9:41" + wifi/battery glyphs) built for
   the desktop preview, where there's no real device status bar to match
   against. Once actually installed and launched full-screen from the Home
   Screen, iOS draws a REAL status bar in that same top strip — so the fake
   one would double up with it. `display-mode: standalone` only ever matches
   in that real installed-app context (never in an ordinary browser tab or
   this desktop preview), so it's a safe switch: hide the fake row there and
   only there, and replace the clearance it used to provide with the actual
   device's safe-area inset so content doesn't render under the notch/Dynamic
   Island or the home-indicator bar at the bottom. */
@media (display-mode: standalone) {
  .sb {
    display: none;
  }
  .shell {
    padding-top: env(safe-area-inset-top);
  }
  /* padding-bottom (2026-07-31, per Owen, two rounds of feedback):
     1st round dropped the old "calc(9px + ...)" stacking, which was adding
     the base 9px ON TOP of the full ~34pt safe-area-inset-bottom. 2nd round
     ("that seems like a lot of space", then compared against Facebook's
     tab bar sitting much closer to the true edge): the full, un-shaved
     safe-area-inset-bottom is still Apple's recommended clearance for the
     home-indicator gesture zone, not a number this floating pill actually
     needs in full — shaving a chunk off it pulls the pill noticeably closer
     to the edge while `max(9px, ...)` keeps a floor so it never collapses
     back to the cramped un-adjusted amount on devices with a small (or
     zero, non-notched) inset. Kept as a capsule that floats near the edge
     rather than switching to a full-width bar whose background reaches the
     true edge (the shape Facebook's actually is) — that's a bigger visual
     change than what was asked for here. */
  .bottom-zone {
    padding-bottom: max(9px, calc(env(safe-area-inset-bottom) - 16px));
  }
  /* Full-screen inset:0 overlay headers (2026-08-01, per Owen: "a standard
     starting point for content... to avoid the bugs where the content
     gets hid by the notch") — .shell's own padding-top above doesn't reach
     these. An absolutely-positioned element's containing block is its
     ancestor's PADDING box, so anything using position:absolute;inset:0
     off of .shell (Chapters' Page Detail overlay, Edit Chapters' Chapter
     Edit view) renders right up against the shell's true top edge no
     matter what .shell's own padding-top is — the safe-area clearance
     above never reaches them. Each of these headers already carries a
     fixed top padding tuned to clear the desktop mock's fake status bar
     (.sb); this adds the real device inset on top of that same baseline
     for actual installed/standalone use, rather than replacing it.
     Baseline value (2026-08-01, per Owen, 2nd round: 54px "too far down",
     "Studio has a great middle ground for its header") — Studio's own
     header isn't an inset:0 overlay at all, it just sits in normal flow
     below .sb (~27px) plus its own 6px padding, landing around ~33px
     total. 40px here targets that same look on headers that DO have to
     fake the .sb clearance entirely on their own (a bit more than
     Studio's exact number since these rows also carry a 32px circular
     back button, not just plain text, and want a little extra breathing
     room around it). */
  .pd-hdr, .cev-hdr, .rc-hdr, .bar-editor-top, .prof-hdr, .pb-hdr {
    padding-top: calc(40px + env(safe-area-inset-top));
  }
}

/* Suppress mobile Safari's native long-press text/element selection
   (the "blue tint over everything" behaviour, 2026-07-29 per Owen) across
   the whole app shell. Long-pressing a photo cell was starting a native
   selection gesture on the surrounding page content, which iOS renders as
   a blue highlight over the pressed area/screen while it decides whether
   you're selecting text or triggering a callout/drag. Blocking select on
   .shell stops that; explicit exceptions below keep real <input>/<textarea>
   fields (the shared name-modal keyboard flow) selectable/editable as
   normal, since a blanket rule would otherwise break typing/selection
   inside those. */
.shell {
  -webkit-touch-callout: none;
  -webkit-user-select: none;
  user-select: none;
}
.shell input,
.shell textarea,
.shell [contenteditable="true"] {
  -webkit-touch-callout: default;
  -webkit-user-select: text;
  user-select: text;
}