/* ══ M197, 2026-08-14 ══════════════════════════════════════════════════════════════════════
   ONE JOB: no step of any booking flow may be wider than the phone it is on, and nothing in it
   may make the phone zoom.

   Why this is one sheet and not a fourth round of point fixes. Sideways scrolling in booking has
   now been reported three times and declared fixed twice. Each previous fix was correct and each
   was aimed at the single element that had been noticed: a description block on 14 August, then
   the booking panel's own body on the same day. The pattern is the fault. Every rule below is
   written for the CLASS of defect rather than for the element that happened to show it, so the
   next long word, the next added field and the next new step are covered before anybody meets
   them.

   Measured before and after with `_build-src/booking/m197-overflow.cjs`, in Chromium AND WebKit,
   at 320 / 375 / 390 / 393 px, over every step of the weekly meditation group, a residential
   retreat, a hybrid event and a class with custom fields. The detector is proved able to fail on
   each page before its reading is believed.

   NOT DONE WITH A CROP. The event templates already set `html, body { overflow-x: clip }` and
   `.frame.mobile { overflow: hidden }`, and that crop is precisely why this survived five months
   and two sweeps: it converts overflow into text silently shaved off the right edge instead of a
   scrollbar. Nothing here hides anything, and nothing here relies on that crop being present -
   which matters, because a skinned retreat page has no crop at all.
   ══════════════════════════════════════════════════════════════════════════════════════════ */


/* ── 1. THE ONE THE MEMBER ACTUALLY REPORTED. iOS Safari's zoom-on-focus. ────────────────────
   iOS Safari zooms the whole page in when a form control with a computed font-size UNDER 16px
   is focused, and it does not zoom back out afterwards. From that tap onwards the layout is
   wider than the screen and the page pans sideways.

   Measured across this flow: every text field on "Who's coming" computed 15.5px, and the card
   panel's own field 15px. So the first tap into a name or an email zoomed the page, and it was
   still zoomed - and still panning sideways - by the time the member reached the confirm button
   several steps later. That is a horizontal scroll that appears mid-booking with no visible
   cause and no obvious moment, which is exactly how it was described: "dunno when it appeared".

   It is invisible to every instrument this project has: it is not a layout overflow, so the page
   measures 375 of 375 at every step, in Chromium and in desktop WebKit alike. Only a real iPhone
   does it.

   16px is the threshold, not a preference. Half a pixel of type is the whole difference.

   Deliberately NOT fixed with `maximum-scale=1` or `user-scalable=no` on the viewport meta. That
   also stops the zoom, and it stops a member pinching to read anything on the page ever again. */
.ibk input[type="text"],  .ibk input[type="email"],  .ibk input[type="tel"],
.ibk input[type="number"], .ibk input[type="password"], .ibk input[type="search"],
.ibk input[type="url"],   .ibk input[type="date"],   .ibk input[type="time"],
.ibk select, .ibk textarea,
#retreat-booking input[type="text"],  #retreat-booking input[type="email"],
#retreat-booking input[type="tel"],   #retreat-booking input[type="number"],
#retreat-booking input[type="password"], #retreat-booking input[type="search"],
#retreat-booking input[type="url"],   #retreat-booking input[type="date"],
#retreat-booking input[type="time"],
#retreat-booking select, #retreat-booking textarea {
  font-size: 16px;
}

/* The donation amount is deliberately larger and keeps its size.
   THE SPECIFICITY HERE IS THE POINT, and v1 of this file got it wrong: the broad rule above was
   first written with three `:not()` clauses, which each add a class's worth of specificity, so it
   scored higher than this exception and silently shrank the amount field from 17px to 16px. It
   was caught by re-measuring the deployed page instead of trusting the diff - the same discipline
   the rest of this mission is about. Listing types explicitly keeps the broad rule at one class
   plus one type, and the extra class here wins cleanly. */
.ibk .bk-custom-amt input[type="number"],
#retreat-booking .bk-custom-amt input[type="number"] {
  font-size: 17px;
}

/* The "save your details for next time" panel on the confirmation screen - the last thing in the
   flow, and its password field was 15.5px, so it zoomed the page at the very end. `!important`
   because the sheet it competes with uses an identical selector, and equal specificity is
   settled by print order, which is not guaranteed between two independently enqueued sheets. */
.se-acct-offer input[type="password"],
.se-acct-offer input[type="email"],
.se-acct-offer input[type="text"] {
  font-size: 16px !important;
}


/* ── 2. THE STRUCTURAL ONE. Nothing may set a floor wider than its column. ───────────────────
   A grid or flex item's automatic minimum size is its CONTENT. A `1fr` track is
   `minmax(auto, 1fr)`, so it can never be narrower than the widest unbreakable thing inside it,
   and it grows the whole column rather than the content shrinking. That single mechanism is
   behind the description-block fault, the booking-panel fault, and the account-banner fault
   found here - three separate reports, one cause. Writing it once for the whole panel is the
   point of this sheet.

   `min-width: 0` is a no-op on anything that is not a flex or grid item, so this is broad on
   purpose and costs nothing where it does not apply. Explicit widths are untouched: a
   `width: 40px` stepper button stays 40px. */
.ibk,
.ibk *,
#retreat-booking,
#retreat-booking * {
  min-width: 0;
}

/* The event page's own mobile column, so a panel can never push the page again. This restates
   M184's rule rather than replacing it - se-event-fixes-v3.css still carries it, and that sheet
   is DROPPED on skinned retreat pages by a dependency chain that breaks there, so a page can
   have one of these and not the other. Both is correct; neither is a duplicate of the other in
   the places it matters. */
.se-scope .layout > *,
.se-scope .frame.mobile .layout > *,
.se-scope .frame.desktop.narrow .layout > * {
  min-width: 0;
}


/* ── 3. Rows of buttons wrap instead of running off the edge. ────────────────────────────────
   Found here, at 320px, on the "Who's coming" step of every class and hybrid flow: the account
   banner puts "Continue as guest" and "Log in" in one flex row, the buttons are `nowrap`, and
   281.44px of buttons in a 251px column ran the row to 340.94 against a 320px screen. The right
   half of "Log in" was simply not on the phone - and because the page crops rather than scrolls,
   there was nothing to scroll to and nothing to see. A member on a small phone could not reach
   the button that signs them in. */
.ibk .bk-alert > div,
.ibk .bk-actions,
.ibk .bk-actions > div,
.ibk .chips,
.ibk .bk-extra .chips,
#retreat-booking .bk-alert > div,
#retreat-booking .bk-actions,
#retreat-booking .bk-actions > div {
  flex-wrap: wrap;
}

/* ...and wrapping alone was NOT enough, which is worth writing down because it is the second
   time on this one element that the obvious fix did nothing.

   The row carries an INLINE `flex: 0 0 auto`, so `flex-shrink` is 0: as a flex item of the alert
   it refuses to shrink below its own content, sits at its max-content 281.44px inside a 246px
   parent, and therefore never gets narrow enough for its children to need to wrap. Measured on
   the deployed page after the wrap rule was already live: still 281.44, still +19.

   `min-width: 0` above does not reach this either - the blocker is `flex-shrink: 0`, not the
   automatic minimum size. And an inline style can only be beaten by `!important`, which is why
   there is one here; the row's markup belongs to another mission's file and is not ours to edit.

   With shrink restored the row narrows to its parent and the two buttons stack, which is what a
   320px phone wants anyway. */
.ibk .bk-alert > div,
.ibk .bk-actions > div,
#retreat-booking .bk-alert > div,
#retreat-booking .bk-actions > div {
  flex-shrink: 1 !important;
}


/* ── 4. A long unbreakable token may never become the column's floor. ────────────────────────
   An email address typed into a summary, a pasted web address in an event description, a long
   venue name: one token the browser is not allowed to break, whose width becomes min-content,
   which becomes the track width, which becomes the page width.

   `anywhere` and deliberately NOT `break-word`. Both break the token rather than let it stick
   out, so both look identical in a screenshot. Only `anywhere` is counted when the browser
   computes min-content, and min-content is the number the grid track reads. `break-word` would
   wrap the text and leave the column exactly as wide and the page exactly as broken - a fix that
   photographs perfectly and changes nothing. That distinction cost a previous mission a full
   round trip and is the single most useful line in this file. */
.ibk,
#retreat-booking {
  overflow-wrap: anywhere;
}