/* Privacy Policy page -- Phase 4 item 3 (plain content page, legal text).

   Phase 7 tablet-fidelity rebuild (17.09.26): live's own page-section for
   this content is `full-bleed-section background-width--full-bleed`
   (raw capture) -- it spans the full viewport width itself and gets its
   reading column entirely from its own fluid-engine grid formula (below),
   not from any generic centred/padded wrapper. The Phase 4 build had
   wrapped it in site.css's generic `.page-wrap` (max-width + 22.5-28.8px
   side padding, meant for simple pages that don't carry their own grid)
   -- fine when the whole page used one flat "1266.3px" fixed column, but
   it silently double-gutters the real fluid grid built below (the grid's
   own vw-based gutter formula assumes it owns the full viewport, same as
   live). `.page-wrap` is dropped from this page's HTML entirely as part
   of this rebuild -- `.section.privacy-content` sits directly under
   `<main>`, matching live's actual DOM shape; not used by
   tools/build_compare.py or tools/box_compare.py (checked: neither
   references .page-wrap), so nothing else in the toolchain depends on it. */

/* Header overlay: now site.css's shared default (Phase 4 shared cleanup,
   17.09.26) -- see site.css's own comment on .site-header. This page
   only needs its own first-section top padding below. */

/* section-height--medium (this page's own preset, raw capture
   data-current-styles) is a STATIC rule in live's own site.css bundle --
   `.page-section.section-height--medium{min-height:66vh}` -- confirmed
   by curling the bundle directly (static1.squarespace.com/.../site.css,
   linked from this page's own <head>), not runtime JS as an earlier
   brief guessed. It only binds when the section's own content-driven
   height falls below that floor; this page's content is ~5700-6800px
   tall at every checked width, always far past 66vh of any real
   viewport (max ~800px), so it never binds here -- confirmed, not
   assumed. */
body.page-privacy-policy .section.privacy-content {
  padding-left: 0;
  padding-right: 0;
  padding-top: calc(37px + 12vw); /* live's fluid header-height formula, see site.css's header-formula comment */
  padding-bottom: 0; /* Phase 7 tablet fix, 17.09.26: live's own computed
    section paddingBottom is 0px at every width (confirmed via
    Playwright) -- the "gap after the last paragraph" the previous phase
    hardcoded here (37.58/417.47px) is really leftover Squarespace
    fluid-engine row space, reproduced fluidly on .pp-text below instead
    of two fixed pixel numbers that only matched live at 375/1440. */
}
@media (min-width: 800px) {
  body.page-privacy-policy .section.privacy-content { padding-top: calc(48.96875px + 2.20052vw); }
}
/* Header's own 800-875.98px real live wrap band (Phase 7 tablet-fidelity
   pass) -- see site.css's .header-inner comment for the measurement;
   contact.css and bray-new-student-application-form.css already carry
   this same adjustment. */
@media (min-width: 800px) and (max-width: 875.98px) {
  body.page-privacy-policy .section.privacy-content { padding-top: calc(54.34375px + 2.20052vw); }
}

/* ---------- Reading column (Phase 7 tablet-fidelity rebuild, 17.09.26) ----------
   Live runs this page's content as ONE Squarespace fluid-engine section
   (raw capture: claude-workspace/working-files/website-netlify-migration/
   wayfinder/raw/privacy-policy.html, section 65263fb9f0265574d3f8c71a)
   holding two blocks -- the H2 heading (grid-area columns 4/24) and one
   big text block for the rest of the policy (grid-area columns 3/25) on
   a 24-column grid (8 columns under 768px, both blocks full-width there,
   raw capture columns 2/10 both). This reproduces live's own
   grid-column formula verbatim (same technique as home.css's .fe /
   bray-new-student-offer.css) instead of the single fixed "1266.3px"
   desktop number the previous phase measured, which was live's DESKTOP
   column at 1440 only and didn't scale below/above it (Phase 7 tablet
   scan: this page ran +424/+448px too long at 820/1024). Copying the
   real column formula instead of the one measured number was checked
   against live with Playwright at 768/820/900/1024/1200/1250/1300/1350/
   1380/1400/1420/1440/1460/1500/1600/1700/1800/1900/1920: both the H2's
   and the text block's box x + width matched live to within 0.3px at
   every one of those widths (a plain CSS Grid computes the same track
   sizes live's own fluid-engine grid does, given the same formula -- no
   hand-solved px approximation involved). */
.pp-grid {
  --grid-gutter: calc(6vw - 11px);
  --cell-max-width: calc((1400px - 11px * 7) / 8);
  display: grid;
  grid-template-columns:
    minmax(var(--grid-gutter), 1fr)
    repeat(8, minmax(0, var(--cell-max-width)))
    minmax(var(--grid-gutter), 1fr);
  column-gap: 11px;
  row-gap: 0;
  /* Content-wrapper's own real padding-bottom (site.css bundle, quoted
     verbatim below the desktop block's comment) -- unconditional, so it
     applies at every width including mobile, replacing the old
     .pp-text margin-bottom fit (fix loop 1, 18.09.26 -- see below). */
  padding-bottom: 6.6vmax;
}
.pp-h2 { grid-column: 2 / 10; }
.pp-text { grid-column: 2 / 10; }
/* Live's own last paragraph in this block carries margin-bottom: 0,
   while every paragraph before it carries 16px -- read directly off
   live with getComputedStyle (verified 18.09.26). This rule reproduces
   that, and that is the whole reason it is here.

   An earlier version of this comment claimed the fix worked because
   grid auto-track sizing ignores an item's last child's trailing
   margin. That is FALSE and was falsified by an isolated test: a grid
   item's auto-sized height DOES include its child's bottom margin
   (20px content + 16px margin measured as a 36px item). The old
   explanation was also self-contradicting -- it claimed zeroing the
   margin "removed a 16px shortfall", which only makes sense if the
   margin was being counted all along.

   The rule is right, the old reason was wrong. Keep the fact, not the
   theory: live has no margin on its last paragraph, so neither do we.

   Known fragility: this targets p:last-child rather than deriving from
   a general rule. If live's content ever gains a trailing element after
   the last <p>, live's zero-margin paragraph stops being the last child
   and this would silently diverge. Re-read live before trusting it
   after any content change. */
.pp-text p:last-child {
  margin-bottom: 0;
}

/* ---------- Fix loop 1 (18.09.26) -- literal fluid-engine ROWS ----------
   Read straight from the curled bundle (static1.squarespace.com/.../
   site.css, linked from this page's head) and the raw capture's own
   inline <style> for this page's fluid-engine block. Two different live
   ids are involved and an earlier version of this comment conflated
   them: 65263fb9f0265574d3f8c71a is the wrapping data-section-id, while
   the fluid-engine class itself is .fe-65263fb9f9e5d22721c70f3e. Both
   are real attributes on live; the grid rules below belong to the
   second one.

     .fe-...{ grid-template-rows: repeat(4,minmax(24px, auto)); row-gap: 11.0px; }
     @media (min-width:768px) {
       .fe-...{
         --row-height-scaling-factor: 0.0215;
         --container-width: min(var(--sqs-site-max-width,1500px),
           calc(100vw - var(--sqs-site-gutter,4vw)*2 - var(--inset-padding)));
         grid-template-rows: repeat(136, minmax(calc(var(--container-width)
           * var(--row-height-scaling-factor)), auto));
       }
     }
     .fe-block-...33009 (H2)   { grid-area: 1/2/3/10; }   desktop: 1/4/7/24
     .fe-block-...35096 (text) { grid-area: 3/2/5/10; }   desktop: 7/3/137/25

   --sqs-site-max-width resolves to --maxPageWidth (1400px) and
   --sqs-site-gutter to --pagePadding (2vw), both literal in the bundle
   (curled directly, confirmed 18.09.26) -- matching the column formula's
   own already-verified 1400px/2vw constants exactly, as expected since
   it's the same fluid-engine instance.

   Previously (rebuild 55fe233) the H2-to-paragraph gap and the trailing
   gap were each REBUILT as a standalone margin formula backed out from
   measurements, requiring a hand-guessed breakpoint (1100px) for which
   line-count the H2 was on -- wrong by 52px against live's real
   1152/1153px crossover (fix-loop brief, defect 1). Fix: give the H2 and
   text blocks the SAME grid-row placement live gives them, on the SAME
   136-row track list, and let the browser's own text-wrap + grid track
   sizing compute the leftover space -- it needs no line-count guess at
   all, because it IS live's real mechanism, not an approximation of it,
   so the crossover lands whatever width the H2's own real text wrap
   lands at (verified against live below). This also reproduces
   defect 2's true row-count step function in the 1300-1440 band for
   free, instead of a third fitted constant -- the trailing "gap" is
   simply .pp-grid's padding-bottom (6.6vmax minus the 16px the last
   paragraph's own un-collapsed margin already contributes, same
   reasoning as the removed .pp-text comment below) PLUS whatever
   leftover space the text block's own grid stretch leaves once its 130
   rows' floor exceeds its actual (content-driven) height -- exactly
   live's own two-part mechanism, not a fit through two anchors. */
@media (min-width: 768px) {
  .pp-grid {
    --grid-gutter: calc(2vw - 11px);
    --cell-max-width: calc((1400px - 11px * 23) / 24);
    --container-width: min(1400px, calc(100vw - 2vw * 2));
    --row: calc(var(--container-width) * 0.0215);
    --h2-fs: min(calc(1.8 * 1.2vw + 1rem), max(calc(1.8 * 0.012 * 1400px + 1rem), 2.8rem));
    grid-template-columns:
      minmax(var(--grid-gutter), 1fr)
      repeat(24, minmax(0, var(--cell-max-width)))
      minmax(var(--grid-gutter), 1fr);
    grid-template-rows: repeat(136, minmax(var(--row), auto));
    row-gap: 11px;
    padding-top: 6.6vmax; /* content-wrapper's real padding-top, moved off
      the H2's own margin (see below) so it sits OUTSIDE the grid, same as
      live's DOM (content-wrapper wraps the whole fluid-engine grid) --
      keeping it on the H2 item itself would have counted it towards the
      H2 grid-item's own intrinsic size for row-track sizing, which live
      does not do. */
  }
  .pp-h2 { grid-column: 4 / 24; grid-row: 1 / 7; }
  .pp-text { grid-column: 3 / 25; grid-row: 7 / 137; }
}

.privacy-content h2.pp-h2 {
  text-align: center;
  font-family: var(--font-heading);
  font-weight: 700;
  /* X=2.8 Squarespace type-scale heading -- live's own formula, matches
     home.css's about-heading/podcast-heading exactly. Confirmed against
     live with Playwright at 768/820/900/1024/1200/1440/1920: font-size
     matched live's own computed value to within 0.01px at each one
     (this formula, not the two old fixed 33.5392px/46.24px numbers,
     which only held at exactly 375 and >=1435 -- everywhere between
     768 and 1435 they were wrong, e.g. live is 38.12px at 1024 vs the
     fixed 46.24px the old CSS used). */
  line-height: 1.1136;
  font-size: calc(1.8 * 0.012 * min(100vh, 900px) + 1rem);
  /* Top gap above the H2 (live's own computed margin-top, "53.58px"
     mobile / "95.03px" desktop in the old fixed-number version) is a
     REAL CSS vmax value on live, not a min(vh,900)-style clamp --
     confirmed exactly against live at 13 width/height combinations
     (768-1920 wide x 768-1200 tall): live's margin-top always equals
     0.066 * max(viewport width, viewport height) in px, to within
     0.1px, at every combination tested (a plain `vmax` unit resolves to
     exactly that CSS-spec definition, so this needs no calc() at all). */
  margin: 6.6vmax 0 11px;
}
@media (min-width: 768px) {
  .privacy-content h2.pp-h2 {
    font-size: var(--h2-fs);
    /* Fix loop 1 (18.09.26): the H2-to-paragraph gap is no longer a
       margin formula that has to guess the H2's own line count via a
       hardcoded breakpoint (the old --h2-h / 1100px switch was 52px off
       against live's real 1152/1153px crossover -- see the fix-loop
       brief's defect 1). The H2 is now a real grid item on the literal
       136-row track list above (.pp-grid's grid-row: 1/7), so the
       browser's own text wrap + grid track sizing leaves exactly the
       right leftover space, whichever line count the H2 actually
       renders at, at every width -- no guess needed. margin-top/bottom
       are zeroed here because live's own top gap (content-wrapper's
       padding-top) and the row-gap between tracks 6/7 already supply
       that space; adding the H2's own margin on top would double-count
       it against the grid's row-track sizing. */
    margin: 0;
  }
}

.privacy-content p {
  margin: 0 0 16px;
}

/* Trailing gap after the last paragraph, before the section ends -- fix
   loop 1 (18.09.26). Previously two fitted formulas (6.6vmax-16px below
   1440, a two-point vw fit at/above 1440) that were exact at their own
   anchors (1300, 1440, 1920) and wrong by up to 284px in between (see
   the fix-loop brief's defect 2) -- the real relationship is live's own
   row-count step function, not a curve to fit through more points.
   Read from source: the text block reserves 130 rows on the same
   136-row track list as the H2 (grid-row: 7/137 above) -- dramatically
   more than the ~20-40 rows its own wrapped text needs once the reading
   column is wide enough (>=~1300px) to fit more words per line. Below
   that, the text's own content height already exceeds the 130-row
   floor, so the grid gives it exactly its content height (no leftover)
   and the only visible trailing space is .pp-grid's own padding-bottom
   (content-wrapper's real 6.6vmax -- see that comment on .pp-grid
   above). Above ~1300px the text's content height drops below the
   130-row floor and the grid's own stretch (default align-items:
   stretch) adds the difference automatically -- this is what
   previously needed a fitted vw formula; now it's just how CSS grid
   track sizing actually works, matching live because it's the same
   mechanism, not an approximation of it. .pp-text itself carries no
   margin/padding of its own -- only its last paragraph's own
   margin-bottom is zeroed (below) so the grid's stretch measures
   against .pp-text's real visible content, not content-plus-a-trailing-
   margin the grid's own auto-track-sizing pass doesn't count anyway
   (confirmed empirically, 18.09.26: the H2 above carries no margin of
   its own and matched live exactly at every width tested; giving
   .pp-text the same shape removed a flat, width-independent 16px
   shortfall against live in this band). */

/* Live page renders inline content links underlined (screenshots);
   site.css's global `a { text-decoration: none }` covers nav links, so
   this scopes the underline back on for the policy body's own links
   only. */
.privacy-content a {
  text-decoration: underline;
}