/* About Me page -- page-specific section styles. Header, footer, buttons,
   .section/.page-wrap and generic h1-h3/p rules already live in
   public/css/site.css (shared, loaded before this file) -- not repeated
   here. Loaded on aboutme.html only.

   FLUID-ENGINE GRID (Phase 7 tablet fix, 17.09.26)
   -------------------------------------------------
   REPLACES the fix-loop-1 build (hand-measured 1440-px column widths,
   fixed phone/desktop breakpoint values for padding and cluster
   positions -- correct at 375/1440 only, +1840px too long at 820 and
   +1206px too long at 1024 per the Phase 7 tablet scan). Both sections on
   this page are live Squarespace "fluid engine" grids: a fixed row count,
   11px row/column gaps, two flexible gutter columns, and an explicit
   grid-area per block, at two breakpoints (<768px: 8 columns, rows
   minmax(24px, auto); >=768px: 24 columns, rows minmax(container-width *
   0.0215, auto)). Row counts and every block's grid-area below are read
   straight from the raw capture's own inline <style> (claude-workspace/
   working-files/website-netlify-migration/wayfinder/raw/aboutme.html,
   .fe-64a5aea0b579f320e8f70260 for section 1, .fe-64aec1b6411faa545ff936cf
   for section 2) -- not tuned. Same method as home.css / bray-new-
   student-offer.css.

   Site variables live uses: --sqs-site-gutter 2vw, --sqs-mobile-site-
   gutter 6vw, --sqs-site-max-width 1400px. Both sections here are
   background-width--full-bleed (not inset), so the plain (non-inset)
   --container-width formula applies to both.

   Section padding (confirmed via a fresh Playwright sweep of LIVE at 12
   widths from 375 to 1920, not just the two reference breakpoints --
   the previous 135.6/216.4px and 76/190px fixed values were themselves
   two samples of this exact formula, which is why they only matched at
   375/1440):
     Section 1 (About Me, this page's first section, section-height--
     medium, one wavy divider at its own bottom edge):
       padding-top    = header-height-formula(width) + 6.6vmax
       padding-bottom = 6.6vmax + 6vw (divider space)
     Section 2 (My Journey, section-height--medium, no divider, not the
     first section so no header term):
       padding-top = padding-bottom = 6.6vmax
   Header-height-formula is site.css's shared fluid formula (<800px:
   37px + 12vw; 800-875.98px: 54.34375px + 2.20052vw; >=876px:
   48.96875px + 2.20052vw) -- reproduced here as literal breakpoints
   since this page needs its own top-padding, same pattern as
   bray-new-student-offer.css's .offer-hero.

   Type: live's own Squarespace 7.1 formulas -- phone (portrait, <768px)
   font size scales with viewport HEIGHT, capped at 900px:
       (X - 1) * 0.012 * min(100vh, 900px) + 1rem
   desktop/landscape:
       min((X - 1) * 1.2vw + 1rem, max((X - 1) * 0.012 * 1400px + 1rem, X * 1rem))
   X = 2.8 for both h2 headings (matches home.css's about-heading exactly:
   33.5392px/46.24px at 375/1440, confirmed against the previous build's
   own hand-measured values); X = 1.4 for every paragraph on this page
   (matches home.css's hero-copy/about-copy: 19.8976px/22.72px). Confirmed
   both widths share one paragraph size and one heading size on this page
   (unlike home's per-section sizes) -- unchanged finding from the
   original build. */

/* ---------- The grid ---------- */
.fe {
  --grid-gutter: calc(6vw - 11px);
  --cell-max-width: calc((1400px - 11px * 7) / 8);
  display: grid;
  position: relative;
  grid-template-columns:
    minmax(var(--grid-gutter), 1fr)
    repeat(8, minmax(0, var(--cell-max-width)))
    minmax(var(--grid-gutter), 1fr);
  row-gap: 11px;
  column-gap: 11px;
  overflow-x: hidden;
  overflow-x: clip;
}
@media (min-width: 768px) {
  .fe {
    --grid-gutter: calc(2vw - 11px);
    --cell-max-width: calc((1400px - 11px * 23) / 24);
    --container-width: min(1400px, calc(100vw - 2vw * 2));
    grid-template-columns:
      minmax(var(--grid-gutter), 1fr)
      repeat(24, minmax(0, var(--cell-max-width)))
      minmax(var(--grid-gutter), 1fr);
  }
}

.fe-block {
  position: relative;
  display: flex;
  flex-direction: column;
  justify-content: flex-start;
  min-width: 0;
}
.fe-block > * { margin: 0; }
/* .fe-content is a NESTED div inside .fe-block (matches live's own
   sqs-html-content wrapper) -- .fe-block > * above only zeroes the
   fe-content wrapper's own (already-zero) margin, not the paragraphs
   inside it. Live's own rich-text paragraph margin here is 16px top +
   bottom (Playwright-measured against live, NOT site.css's global 24px
   used by ordinary page copy elsewhere on the site) -- confirmed
   against live at 375: fixed a Phase 7 defect where combining the
   fe-block/fe-content classes onto one element let the `> *` reset
   above zero every paragraph's margin, collapsing 3-4 paragraph blocks
   down to single-spaced text and understating every section's height. */
.fe-content { flex: 0 0 auto; }
.fe-content > :first-child { margin-top: 0; }
.fe-content > :last-child { margin-bottom: 0; }
.fe-content p { margin: 16px 0; }

/* ---------- Section wrap padding (3.3vmax "small" isn't used on this
   page -- both sections are section-height--medium, 6.6vmax) ---------- */
.fe-wrap { padding: 6.6vmax 0; }

.about-me-section {
  position: relative;
  overflow: visible;
  background: var(--hero-cream);
  padding: calc(37px + 12vw) 0 6vw;
  /* 66vh floor (fix loop 1, 17.09.26): live's raw HTML carries
     `section-height--medium` on BOTH sections on this page (About Me
     AND Journey -- confirmed by reading the class list directly off
     each <section> in the raw capture, not inferred from a height
     sweep), and live's own site.css (fetched directly from
     static1.squarespace.com, bypassing the in-page CORS block on
     document.styleSheets) carries the static rule
     `.page-section.section-height--medium{min-height:66vh}` plus a
     base `.page-section{display:flex;align-items:center;box-sizing:
     border-box}`. Reproduced here as flex-direction:column (not row)
     so the single .fe-wrap child stretches full-width via the default
     cross-axis stretch, while justify-content:center does the same job
     as live's align-items:center along the (here vertical) main axis --
     visually identical result, no risk to the existing horizontal
     grid-width math. min-height is a FLOOR only: at ordinary viewport
     heights the section's real content (padding + .fe-wrap) is already
     taller than 66vh, so this has zero effect there -- confirmed
     against a live-vs-build viewport-HEIGHT sweep to 5000px, see the
     phase report. */
  min-height: 66vh;
  display: flex;
  flex-direction: column;
  justify-content: center;
}
/* site.css's shared .wave primitive is in normal flow by default; here it
   must straddle the section's bottom edge instead (as live, where the
   divider is a clip-path overlay that reserves no layout space of its
   own) so it doesn't ADD its own 6vw on top of the 6vw already folded
   into this section's padding-bottom above -- same fix home.css already
   applies to its own wavy dividers. Found via a build_compare regression
   (About Me ran exactly one extra 6vw too tall, 86.375px at 1440) while
   rebuilding this section onto the fluid-engine grid. */
.about-me-section .wave {
  position: absolute;
  left: 0;
  right: 0;
  bottom: -20px;
  z-index: 2;
}
@media (min-width: 800px) {
  .about-me-section { padding-top: calc(48.96875px + 2.20052vw); }
}
/* Header's own 800-875.98px real live wrap band -- see site.css's
   .header-inner comment; offer/contact/application-form pages already
   carry this same adjustment. */
@media (min-width: 800px) and (max-width: 875.98px) {
  .about-me-section { padding-top: calc(54.34375px + 2.20052vw); }
}

/* site.css's shared `.section` class (every top-level section on the
   site carries it, for build_compare) sets its own default
   `padding: 40px 22.5px` (86px 28.8px from 768px) -- About Me overrides
   ALL four sides with its own header/divider formula above, but Journey
   has no header/divider term of its own (padding is 6.6vmax top+bottom
   only, from `.fe-wrap`, with the grid's own gutter columns providing
   the horizontal margin) so it must explicitly zero the shared default
   rather than silently add 22.5-28.8px of extra width-narrowing padding
   plus 40-86px of extra height on top of `.fe-wrap`'s own 6.6vmax. Found
   the same way as the About Me wave fix -- a build_compare regression
   while rebuilding this section onto the fluid-engine grid. */
.journey-section {
  position: relative;
  overflow: visible;
  padding: 0;
  /* 66vh floor: Journey also carries `section-height--medium` on live
     (confirmed the same way as About Me's, above) -- same fix, same
     reasoning. */
  min-height: 66vh;
  display: flex;
  flex-direction: column;
  justify-content: center;
}

/* ---------- Type ---------- */
.about-me-heading,
.journey-heading {
  font-family: var(--font-heading);
  font-weight: 700;
  letter-spacing: normal;
  line-height: 1.1136;
  font-size: calc(1.8 * 0.012 * min(100vh, 900px) + 1rem);
  margin: 0;
}
@media (min-width: 768px), (orientation: landscape) {
  .about-me-heading,
  .journey-heading {
    font-size: min(calc(1.8 * 1.2vw + 1rem), max(calc(1.8 * 0.012 * 1400px + 1rem), 2.8rem));
  }
}
.journey-heading { text-align: center; }

.fe-content p {
  line-height: 1.5;
  font-size: calc(0.4 * 0.012 * min(100vh, 900px) + 1rem);
}
@media (min-width: 768px), (orientation: landscape) {
  .fe-content p {
    font-size: min(calc(0.4 * 1.2vw + 1rem), max(calc(0.4 * 0.012 * 1400px + 1rem), 1.4rem));
  }
}
/* Two real (empty) <p> elements on this page carry live's own
   data-rte-preserve-empty content (About Me col's trailing paragraph --
   also this block's own last-child, so its bottom margin is already
   zeroed by the `.fe-content > :last-child` rule above -- and Journey
   row 3's mid-block paragraph, which keeps its normal 16px top+bottom
   margin like any other paragraph). Both still render one line's worth
   of height on live; a completely empty <p> collapses to 0px in
   Chromium without this. min-height in em resolves off the paragraph's
   own fluid font-size, so it scales instead of using a fixed px number
   tuned to only one breakpoint. */
.fe-content p:empty { min-height: 1.5em; }
/* Journey row 3's mid-block empty <p> is the one exception: live's own
   markup gives it class="" (NOT class="sqsrte-large" like every other
   paragraph on this page), so it renders at the page's plain base size
   (16px, line-height 1.5 = a flat 24px at every width, confirmed against
   live at 375/820/1440), not the fluid large-text formula. Same
   convention as bray-new-student-offer.css's `.fe-empty`. */
.fe-content .fe-empty { font-size: 16px; }

/* ---------- Section 1: About Me (section_id 64a5aea0b579f320e8f70261)
   Mobile: 59 rows. Desktop (>=768px): 29 rows. ---------- */
.fe-s0 { grid-template-rows: repeat(59, minmax(24px, auto)); }
@media (min-width: 768px) {
  .fe-s0 { grid-template-rows: repeat(29, minmax(calc(var(--container-width) * 0.0215), auto)); }
}

.b-am-photo   { grid-area: 1/2/15/10; z-index: 1; }
.b-am-heading { grid-area: 15/2/19/10; z-index: 2; }
.b-am-col     { grid-area: 18/2/39/10; z-index: 3; }
.b-am-full    { grid-area: 38/2/60/10; z-index: 4; }
@media (min-width: 768px) {
  .b-am-photo   { grid-area: 2/15/18/26; }
  .b-am-heading { grid-area: 1/3/4/14; }
  .b-am-col     { grid-area: 4/3/22/14; }
  .b-am-full    { grid-area: 21/3/30/25; }
}

/* The live "About Me" photo is the one image on this page with
   data-is-image-stretched="true" -- Squarespace crops it to fill its
   grid box on BOTH axes (not a fixed aspect ratio). position:absolute
   inside the (already position:relative) .fe-block guarantees a true
   fill regardless of flex quirks, same technique as home.css's
   .about-photo. */
.b-am-photo img {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
  border-radius: 4px;
}

/* ---------- Section 2: My Journey (section_id 64aec1b6411faa545ff936d0)
   Mobile: 201 rows. Desktop (>=768px): 100 rows. ---------- */
.fe-s1 { grid-template-rows: repeat(201, minmax(24px, auto)); }
@media (min-width: 768px) {
  .fe-s1 { grid-template-rows: repeat(100, minmax(calc(var(--container-width) * 0.0215), auto)); }
}

.b-jn-heading { grid-area: 1/2/5/10; z-index: 1; }
.b-jn-intro   { grid-area: 5/2/55/10; z-index: 2; }
/* The opening 3-photo cluster: 3 independent grid items whose row/column
   spans genuinely overlap on live (not a hand-built collage) -- the
   staggered look falls out of the grid itself. z-index from live's own
   values: culture lowest, teacher middle, school highest. */
.b-jn-img1    { grid-area: 55/3/61/8; z-index: 1; }  /* culture */
.b-jn-img2    { grid-area: 62/2/68/8; z-index: 2; }  /* teacher */
.b-jn-img3    { grid-area: 58/6/64/10; z-index: 3; } /* school, on top */
.b-jn-row1    { grid-area: 69/2/98/10; z-index: 4; }
.b-jn-video1  { grid-area: 99/1/106/11; z-index: 5; }
.b-jn-row2    { grid-area: 107/2/126/10; z-index: 6; }
.b-jn-video2  { grid-area: 127/1/134/11; z-index: 7; }
.b-jn-row3    { grid-area: 135/2/162/10; z-index: 8; }
.b-jn-img4    { grid-area: 163/1/175/11; z-index: 9; }
.b-jn-row4    { grid-area: 176/2/199/10; z-index: 10; }
.b-jn-button  { grid-area: 200/3/202/9; z-index: 11; justify-content: center; }
@media (min-width: 768px) {
  .b-jn-heading { grid-area: 1/5/4/23; }
  .b-jn-intro   { grid-area: 5/3/27/25; }
  .b-jn-img1    { grid-area: 27/2/33/8; }
  .b-jn-img2    { grid-area: 37/3/43/9; }
  .b-jn-img3    { grid-area: 31/6/39/11; }
  .b-jn-row1    { grid-area: 27/12/47/25; }
  .b-jn-video1  { grid-area: 49/14/59/26; }
  .b-jn-row2    { grid-area: 48/3/61/16; }
  .b-jn-video2  { grid-area: 66/1/76/13; }
  .b-jn-row3    { grid-area: 62/12/82/25; }
  .b-jn-img4    { grid-area: 84/18/95/25; }
  .b-jn-row4    { grid-area: 83/3/98/17; }
  .b-jn-button  { grid-area: 99/5/101/11; }
}

/* DEFECT FIX (fix loop 1, 17.09.26) -- the prior comment here (deleted)
   claimed all 4 of these "stretched=false" images fill their FULL
   grid-area box via object-fit:cover, generalised from ONE matching
   pair (culture+teacher both 233.3125px at 1440) that turned out to be
   a coincidence of their two particular row-spans, not a real rule.

   What's actually true on live, confirmed by walking the <img>'s own
   parentElement chain with Playwright (getBoundingClientRect on each
   ancestor) at every test width (375/768/820/900/1024/1200/1440/1920)
   and by reading each ancestor's inline `style` attribute directly:
     - The GRID CELL itself (`.fluid-image-component-root` /
       `.sqs-block-content`, the true grid item) fills its FULL grid-
       area box on BOTH axes, exactly like the stretched photo -- e.g.
       culture's cell is 337.34 x 233.31px at 1440, matching this
       page's own grid-area column/row-track maths exactly.
     - `.fluid-image-animation-wrapper`, one level in
       (`display:flex; justify-content:center; align-items:center`),
       is ALSO full-cell-size and shrinks NOTHING -- it only centres
       whatever it contains.
     - The smaller box is a separate div one level further in,
       `.fluid-image-container`. Its width is set by a JS-computed
       inline CSS custom property --
       `--image-component-container-width: 286.12px` for culture at
       1440, read straight off `root.getAttribute('style')` -- derived
       at runtime from `--image-component-native-aspect-ratio` against
       a fixed `--image-component-container-height: 100%`. The <img>
       then exactly fills that already-sized container
       (`position:absolute; top:0; left:0`), so its own
       `object-fit:contain` never does any work: the sizes already
       match 1:1 by the time the browser paints it.
     - Net effect: each image's own aspect ratio decides which axis of
       the CELL binds (contain-style) -- height for culture/school
       (narrower aspect than the cell), width for teacher/expert
       (wider) -- which is exactly why the 4 render at 4 DIFFERENT
       heights despite several sharing the same row-span. The ratio
       maths is the same as "object-fit:contain on the cell"; live
       just reaches it via a JS-sized container div instead of CSS
       alone.

   Two things were tried and rejected before landing on the rule below:
     1. width:100%/height:auto on the block (shrink the CELL itself to
        the image's aspect ratio) -- read from live's CSS bundle
        (`--image-component-object-fit:contain`, `.content-fit img{
        width:auto}`, fetched directly from static1.squarespace.com to
        bypass the in-page CORS block on document.styleSheets) and
        wrongly generalised into "the cell shrink-wraps". It let each
        image's aspect-derived height OVERFLOW its assigned row-span at
        this page's actual per-column width (Journey grew +174px at
        1440, build_compare went red) -- CSS class/property names alone
        don't tell you which element in a multi-wrapper chain they
        resolve on; only walking the live DOM caught this.
     2. object-fit:contain on the previous inset:0/width:100%/
        height:100% rule (same technique as cover, object-fit swapped).
        Also wrong: forcing width:100%;height:100% makes
        getBoundingClientRect() always report the FULL cell size
        regardless of object-fit -- object-fit only changes how the
        image's PIXELS are drawn inside a fixed box, it never shrinks
        the box's own rect, so it can't reproduce live's real, smaller
        <img> box.
   The rule below instead leaves the CELL (.fe-block, this img's
   position:absolute containing block) untouched -- still full grid-
   area size on both axes, so no row-track growth risk at all -- and
   sizes the <img> itself with max-width/max-height:100% (of that full-
   size cell) + width/height:auto, letting the browser compute the
   image's own rendered box from its intrinsic aspect ratio constrained
   to fit inside the cell on whichever axis binds. Centred via
   top/left:50%+transform, standing in for live's flex-centring
   wrapper.

   This is a CSS EQUIVALENT of live's mechanism, not a structural copy
   of it -- there is no JS-sized container div here, just pure CSS on
   the <img> itself. It produces the same numbers because the two
   things live's JS actually varies (cell size, image aspect ratio)
   are both fixed at build time for this page, so max-width/max-
   height:100% + width/height:auto lands on the same contain-style box
   the JS container would have computed. If a future maintainer is
   reconciling this against a live DOM change, don't expect to find a
   `.fluid-image-container` equivalent here -- there isn't one, by
   design. */
.b-jn-img1 img,
.b-jn-img2 img,
.b-jn-img3 img,
.b-jn-img4 img {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  max-width: 100%;
  max-height: 100%;
  width: auto;
  height: auto;
  object-fit: contain;
  border-radius: 4px;
}
/* No explicit per-image aspect-ratio here (removed 18.09.26) -- a
   verifier re-tested the earlier claim that Chromium won't resolve the
   width/height HTML-attribute hint for a width:auto/height:auto,
   loading="lazy" image before it has loaded. Forcing
   `aspect-ratio:auto !important` on these 4 images and re-measuring
   before and after scrolling into view gave IDENTICAL boxes with and
   without the explicit ratio at every width from 375 to 1920 (largest
   diff 0.45px, this page's own width/height attributes already
   supplying the same ratio the browser needs). The explicit values
   were dead weight that would silently go stale if a photo were ever
   swapped for one with a different intrinsic ratio -- removed rather
   than kept as a redundant safety net. */

/* Both videos: live forces aspect-ratio:16/9 on its player regardless of
   the source's own (portrait) native ratio -- object-fit:cover crops to
   match, same as home.css's fluid video blocks. */
.fe-block video {
  display: block;
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
  object-fit: cover;
  border-radius: 4px;
  background: #000;
}

/* Live's own button block markup carries `sqs-stretched` -- the button
   fills its whole grid box on BOTH axes (matches home.css's fe-btn-block
   pattern), rendering at exactly the assigned row-track height (44.84px
   at 820) rather than its own intrinsic content height (56px, using the
   sitewide .btn's 16px padding + normal body line-height) -- the extra
   ~11px was a real build_compare/tablet-scan regression this fixes. */
.b-jn-button .btn {
  flex: 1 1 auto;
  display: flex;
  align-items: center;
  justify-content: center;
  width: 100%;
  height: auto;
  padding: 0 20.8px;
  line-height: normal;
  text-align: center;
}