/**
 * The iOS keyboard, and what it does to the reading.
 *
 * Reported by Chris, reading in the PWA on an iPhone: tap the "Share with
 * Pastor Pauly" box and the page zooms, the textarea and "Bury this Word in my
 * Heart" jam into the strip above the keyboard, the placeholder clips mid-word,
 * and Safari's domain chip appears over the content.
 *
 * That is FOUR symptoms of two causes, and only one of them is the famous one.
 *
 * ── CAUSE 1: the page is being ZOOMED, and it is our fault ──────────────────
 *
 * iOS Safari magnifies the page whenever a control it is about to focus has a
 * computed font-size under 16px. #bread-ask-input carries an INLINE
 * `font-size:15px` (ui-daily-dew-template.blade.php:144), and an inline
 * declaration beats a stylesheet one of equal weight — so nld-reading.css:195,
 * which already asks for 16px, never lands. The reading has been zooming on
 * every iPhone since that textarea shipped.
 *
 * The zoom is what produces three of the four symptoms. A zoomed page is wider
 * than the window, so the placeholder runs off the right edge and clips
 * mid-word; the layout is pushed around; and Safari re-shows its domain chip
 * because the page is no longer at scale 1. Fix the font size and those go
 * without anything else being touched.
 *
 * And no, `user-scalable=no` in the viewport meta does not stop it. iOS has
 * ignored that key since iOS 10 for accessibility reasons. It still suppresses
 * pinch-zoom on Android, which is why it is left alone here, but it has never
 * suppressed the focus zoom on the phone this bug was reported from.
 *
 * ── CAUSE 2: the keyboard does not shrink the layout viewport ───────────────
 *
 * On iOS the software keyboard shrinks the VISUAL viewport and leaves the
 * LAYOUT viewport at full height. Everything CSS positions — `position:fixed`,
 * `100vh`, `bottom:0` — is measured against the layout viewport, so it keeps
 * sizing and docking to a screen edge that is now behind the keyboard.
 *
 * Three things here are laid out against that stale height:
 *   .modal-backdrop  fixed, inset:0, scrolls          (nld.css:412)
 *   .modal-box       max-height 85vh, scrolls         (nld.css:424)
 *   .nav             fixed, bottom:0                  (nld-nav-light.css:40)
 *
 * What this file can honestly do about that, and what it cannot, is written at
 * each rule. The short version: dvh fixes the browser-chrome half of the
 * problem, real scroll room fixes the jammed-against-the-keyboard half, and
 * neither one is the keyboard resizing the viewport, because CSS cannot make
 * iOS do that. See the closing note.
 *
 * Loaded UNCONDITIONALLY, not behind a light-surface flag: the 15px is in the
 * template and zooms whether the reading is forest or light. Every rule is
 * still scoped to the reading modal (or to the nav only while a control inside
 * that modal has focus), so nothing else in the app can feel it.
 */

/* ── The zoom. This is the one that fixes Chris's screenshot ─────────────────
   !important is not decoration here — it is the only weight that beats the
   template's inline 15px. If a future control inside the reading is given an
   inline size under 16px, IosKeyboardReadingTest fails rather than shipping
   another zooming field. */
#dew-modal-content #bread-ask-input {
    font-size: 16px !important;
}

/* #bread-journal is deliberately NOT in that rule. It has no inline size, so it
   resolves to 18px from `.input` (nld.css:337) with the reading forest, or 16px
   from nld-reading.css:195 with it light. Both clear the threshold, and forcing
   16px here would silently shrink the forest one. */

/* ── Height measured against what is actually visible ────────────────────────
   `vh` first as the fallback for anything older than iOS 16 / Safari 15.4, then
   `dvh`, which tracks the browser chrome collapsing and expanding as you scroll.
   Declaration order IS the fallback mechanism: a browser that cannot parse dvh
   drops that line and keeps the vh above it.

   Scoped with :has() to the backdrop holding THIS reading — .modal-backdrop is
   shared by every modal in the app and several are short, centred things that
   have no business being told they are a screen tall. */
.modal-backdrop:has(#dew-modal-content) {
    height: 100vh;
    height: 100dvh;
}

.modal-backdrop:has(#dew-modal-content) .modal-box {
    max-height: calc(100vh - var(--s-36));
    max-height: calc(100dvh - var(--s-36));
}

/* ── Room to scroll the focused field clear ──────────────────────────────────
   scroll-padding-bottom tells the browser's scroll-into-view to stop short of
   the container's bottom edge, so the field it just focused does not land flush
   against it — which, with a keyboard up, means behind the keyboard.

   Both containers get it because both scroll: the backdrop (overflow-y:auto,
   nld.css:421) when the box is taller than the screen, and the box itself
   (overflow-y:auto, nld.css:443) for the reading's own length.

   clamp() rather than a flat number: a fixed 300px is most of a small iPhone
   and a rounding error on an iPad. */
.modal-backdrop:has(#dew-modal-content),
.modal-backdrop:has(#dew-modal-content) .modal-box {
    scroll-padding-bottom: clamp(180px, 45vh, 360px);
}

/* And the same distance asked for from the input's side. scroll-padding is the
   container's request and scroll-margin is the element's; browsers honour the
   larger, and quirks in which one a given engine applies during a focus scroll
   are exactly why both are here. */
#dew-modal-content #bread-journal,
#dew-modal-content #bread-ask-input,
#dew-modal-content #bread-btn {
    scroll-margin-bottom: clamp(180px, 45vh, 360px);
}

/* ── The thing scroll-padding alone cannot fix ───────────────────────────────
   THIS is why the textarea and the button ended up jammed together above the
   keyboard rather than merely low.

   #bread-ask-input and #bread-btn are the last two things in the reading. A
   scroll container cannot scroll past its own content, so when the focused
   field is at the very bottom there is nothing underneath to scroll INTO —
   scroll-padding-bottom asks for clearance that does not exist and the field
   stays where it is, under the keyboard, with the button crushed beside it.

   So while something in the reading has focus, the reading grows a false floor.
   :has() keeps it to exactly that moment: no dead space at rest, and it appears
   and disappears with the keyboard because that is when focus arrives and
   leaves. (:has() is already load-bearing in nld-reading.css:53, so this is not
   a new dependency for this codebase.) */
#dew-modal-content:has(textarea:focus, input:focus) {
    padding-bottom: clamp(240px, 48vh, 420px);
}

/* ── The nav, out of the way while they type ─────────────────────────────────
   The nav is fixed to bottom:0 of the layout viewport, so with a keyboard up it
   is docked behind it and its top edge crowds whatever the reading has managed
   to lift into view. It is also useless in that moment: nobody changes tab
   mid-sentence, and every tab is one keyboard-dismiss away.

   The condition has to be read on the BODY, because the nav is a sibling of the
   modal, not an ancestor of the focused field — `:has()` on an ancestor of both
   is the only way CSS can express "something over there has focus".

   Bare `.nav` covers the forest bar and `.nav.nav-light` alike; !important is
   for the light bar, which sets display:grid at equal specificity. */
body:has(#dew-modal-content textarea:focus) .nav,
body:has(#dew-modal-content input:focus) .nav {
    display: none !important;
}

/* ── What is still not fixed, and cannot be from here ────────────────────────
 *
 * None of the above makes iOS resize the layout viewport when the keyboard
 * opens. It does not do that, and there is no CSS that asks it to:
 *
 *   - `dvh` responds to browser chrome, NOT to the keyboard. It is the right
 *     unit and it fixes the collapsing-URL-bar half of the problem, but a
 *     100dvh box with a keyboard up is still a box whose bottom is behind the
 *     keyboard.
 *   - `interactive-widget=resizes-content` in the viewport meta is the real
 *     answer to this, and Chromium honours it — but WebKit does not implement
 *     the key at all, so it does nothing on the phone this was reported from.
 *     It is set anyway (new-life-daily.blade.php:43): unknown viewport keys are
 *     ignored, it costs nothing, and it fixes the same bug for Android PWA
 *     users today.
 *
 * The complete fix is JS: read visualViewport.height on the `resize` event and
 * write it to a custom property the rules above consume. That is a change to
 * word.js, which this pass was scoped out of. Everything here is the CSS-only
 * portion, and the zoom fix at the top is the one that accounts for most of
 * what Chris actually saw.
 */