/* ════════════════════════════════════════════════════════════
   ORIGAMI — the section backgrounds fold themselves into place

   The homepage alternates three flat colours (--bone, --warm-mid,
   --near-black) separated by ANGULAR slant dividers. Those colours
   were simply *there*: every divider arrived fully drawn, so a page
   built entirely out of hard diagonal edges had no moment where the
   edge itself did anything.

   This layer gives each of those coloured panels an entrance: it
   hinges in from one edge like a sheet of paper being unfolded, and
   the hinge edge alternates down the page (left → top → right →
   bottom → …) so it reads as folding rather than as one repeated
   trick.

   NOTHING in here applies on its own. js/origami.js builds the
   .eh-origami-panel element and adds .eh-origami-host at runtime, and
   it bails out before its first DOM write when GSAP is missing or the
   visitor asked for reduced motion — so in either case the page is
   byte-for-byte the stylesheet's own rendering, slants included.

   Revert = remove the two origami tags from the page.
   ════════════════════════════════════════════════════════════ */

/* ── THE PANEL ────────────────────────────────────────────────
   A leaf. Never a wrapper.

   js/s3d.js moves a section's children into a transformed .s3d__in
   wrapper, and a transformed ANCESTOR distorts the rect ScrollTrigger
   measures for everything nested inside it — motion.js's cards,
   .section-header, gallery.js's stage all cache start/end on refresh
   and would fire hundreds of pixels off. So the thing that rotates
   here is a sibling of the content with no descendants of its own,
   and the only element this file's transform can possibly distort is
   itself.

   Geometry (top/right/bottom/left/clip-path/background) is written
   inline by the script, copied live from the ::before that the
   stylesheet uses to paint this exact section. Nothing about the
   slant is restated here — restating it would mean two sources of
   truth for the divider angle, and they would drift the first time
   --slant changed.

   z-index: -1 rather than the ::before's 0. Every host this script
   accepts is position:relative + z-index:2, i.e. its own stacking
   context with a transparent background of its own, so -1 puts the
   panel behind ALL of the section's content — including in-flow text
   that carries no z-index at all, which a positioned z-index:0 box
   would otherwise paint straight over.

   pointer-events: none so a folded panel can never eat a click on the
   link underneath it. */
.eh-origami-panel {
  position: absolute;
  z-index: -1;
  pointer-events: none;
}

/* ── THE ORIGINAL BACKGROUND ──────────────────────────────────
   The panel reproduces the ::before exactly, so the ::before must
   stop painting or every colour is drawn twice and the slant gets a
   seam along its edge.

   visibility, not `background: transparent`: the script re-reads this
   pseudo-element's computed background-color and clip-path on every
   resize (--slant is a clamp() and the ≤768px block rewrites the
   polygon outright), and a transparent background would have erased
   the value it needs to read. Hidden, the box still resolves — it
   just costs nothing to paint. */
.eh-origami-host::before {
  visibility: hidden !important;
}

/* ── HOSTS THAT PAINTED THEMSELVES ────────────────────────────
   The other kind of host: .stat-ticker puts the colour AND the
   clip-path on the element rather than on a ::before. Both are the
   panel's job now.

   The clip is the important half. A clip-path on the element clips its
   children, so the panel would be sliced off as it rotated — that is
   exactly why this class of section used to be refused a fold. Moving
   the polygon to the panel (which is inset 0, so its percentages
   resolve identically) and clearing it here is what makes the fold
   possible. Safe only because .stat-ticker's clip crops nothing but
   background: its 80px of bottom padding keeps every stat clear of the
   28px corner bevel. js/origami.js carries the allowlist and the note.

   !important because the element's own `background`/`clip-path` are
   shorthand declarations of equal specificity in a stylesheet that may
   grow media queries later; the class is only ever added by the script
   to an element whose paint it has already taken over, so it cannot
   reach anything else. */
.eh-origami-host--own {
  background-color: transparent !important;
  clip-path: none !important;
}

/* ── .areas-strip BOTTOM CLEARANCE ────────────────────────────
   Not a motion rule — a layout fix, which is why it is unconditional
   rather than gated behind the script the way everything else in this
   file is. It is wrong with the fold, without the fold, and with
   reduced motion on.

   The FAQ section below is `.section--warm.slant-top`, so it carries
   `margin-top: calc(-1 * var(--slant))` and is pulled up over the last
   var(--slant) (52–112px) of .areas-strip. The strip's own
   `padding: 48px 0` was measured against its box, not against that
   overlap, so the second row of .area-card sat inside it: at 1440px the
   warm panel's edge crossed the "Rotonda West" card 38px above its
   bottom border and sliced the corner off.

   Adding var(--slant) to the bottom padding restores the 48px the
   stylesheet intended — measured to the FAQ's diagonal instead of to a
   box edge that nothing actually draws. The strip gets taller (the one
   deliberate layout change here); the seam geometry is untouched,
   because the FAQ's negative margin is unchanged and still lands on the
   strip's new bottom edge.

   This is also the whole of the "bottom glitches" report: origami fades
   that warm panel 0.12 → 1 as it folds, so the overlap band swept from
   transparent to opaque across live card content and the card bottoms
   appeared and disappeared. With nothing but background in the band,
   the fold sweeps over empty near-black like every other seam. */
.areas-strip {
  padding-bottom: calc(48px + var(--slant));
}

/* ── COMPOSITOR LAYER, ONLY WHILE FOLDING ─────────────────────
   will-change is a standing request for a layer, and these panels are
   full-viewport-width — ten of them held for the whole visit is real
   memory on a phone for an effect that runs once. The script adds
   this class when the tween starts and drops it on complete, the same
   bargain .s3d__in/.is-s3d-done already makes. */
.eh-origami-panel--live {
  will-change: transform, opacity;
}