/* ---------------------------------------------
   FAQ page
--------------------------------------------- */

.faq {
  max-width: 1137px;
  margin: 0 auto;
  padding: 3rem 1.5rem 4rem;
}

.faq__label {
  margin: 0 0 1.5rem;
  font-weight: 400;
  font-size: clamp(2rem, 5vw, 3.5rem);
  letter-spacing: 0.12em;
  text-transform: uppercase;
  text-align: center;
  color: var(--color-cream);
}

/* Matches faq-border.json's comp size (2111x738) so the box outline
   doesn't distort. The border itself is a Bodymovin/Lottie draw-on
   export (js/faq.js), not a hand-coded SVG path. */
.faq-box {
  position: relative;
  max-width: 1137px;
  aspect-ratio: 2111 / 738;
  margin: 0 auto;
}

.faq-border {
  position: absolute;
  inset: 0;
  pointer-events: none;
}

.faq-border svg {
  display: block;
  width: 100%;
  height: 100%;
}

/* Inset enough to clear the box outline's two cut/rounded corners
   (top-right and bottom-left) at any box size. Clips (rather than
   natively scrolls) the track below — a native scrollTo() gets
   clamped to the *current* scrollHeight, which hasn't grown yet on
   the very first frame after opening a row (before its answer's
   grid-rows transition has actually added any height), so it'd
   silently no-op. A transform on the track isn't bound by that. */
.faq-list {
  position: absolute;
  inset: 10% 9%;
  overflow: hidden;
}

/* translateY(0) — the +30px hand-tuned offset from the old flex
   single-column layout over-shifted the shorter 3-row grid content
   downward, since .faq-list ul's own align-content:center (above)
   already centers it correctly on its own now. */
.faq-list__track {
  height: 100%;
  transition: transform 0.5s ease;
  transform: translateY(0px);
}

/* Two columns of three on desktop — grid-auto-flow:column fills
   column 1 (rows 1-3) before column 2 (rows 4-6), matching DOM order
   1:1, so js/faq.js's index-based before/after logic needs no changes
   despite the visual rearrangement. .faq-box.has-open below swaps
   this back to a single flex column (the pre-grid layout) once a row
   opens — "always flex-start" only applies in that state, see there. */
.faq-list ul {
  height: 100%;
  display: grid;
  grid-template-columns: 1fr 1fr;
  grid-template-rows: repeat(3, auto);
  grid-auto-flow: column;
  column-gap: 2rem;
  row-gap: 2.25rem;
  align-content: center;
  list-style: none;
  margin: 0;
  padding: 0;
}

/* Left column (rows 1-3) reads left-aligned, right column (rows 4-6)
   right-aligned — an inward-facing frame around the box's open middle,
   matching the reference layout. .faq-row__cities's Lottie SVG is an
   inline-block inside the button, so it right-aligns right along with
   the rest of the right column's text automatically. */
.faq-row:nth-child(-n+3) .faq-row__q {
  text-align: left;
}

.faq-row:nth-child(n+4) .faq-row__q {
  text-align: right;
}

/* Hand-tuned per-row nudges (desktop grid only) aligning each question
   with the box border's hand-drawn, non-rectangular edge — measured
   directly against the rendered border curve in Firefox DevTools.
   min-width keeps these out of the mobile single-column layout;
   :not(.has-open) keeps them from skewing the open row's centered
   text (see .faq-box.has-open .faq-row__q below). */
@media (min-width: 701px) {
  .faq-box:not(.has-open) .faq-row:nth-child(1) .faq-row__q {
    margin-left: 10px;
  }

  .faq-box:not(.has-open) .faq-row:nth-child(2) .faq-row__q {
    margin-top: 5px;
  }

  .faq-box:not(.has-open) .faq-row:nth-child(3) .faq-row__q {
    margin-left: -10px;
  }

  .faq-box:not(.has-open) .faq-row:nth-child(4) .faq-row__q {
    margin-left: 10px;
  }

  .faq-box:not(.has-open) .faq-row:nth-child(6) .faq-row__q {
    margin-left: -10px;
  }
}

/* Reverts the grid above to a single flex column once any row opens.
   gap:0 and justify-content:flex-start both have to be reset
   explicitly — display/flex-direction are the only properties the
   grid rule above and this one don't share, so row-gap and
   align-content stay inherited from it otherwise. row-gap in
   particular was the real bug behind opened rows landing at
   inconsistent heights: flexbox honors row-gap same as grid does, so
   it was adding real space between every one of the (zero-height,
   collapsed) before/after siblings too — accumulating to a bigger
   push the more siblings came before the opened row, rather than
   actually collapsing to nothing. flex-start (not center) pins every
   open row to the same top position regardless of its own height,
   matching the mobile behavior above. */
.faq-box.has-open .faq-list ul {
  display: flex;
  flex-direction: column;
  justify-content: flex-start;
  gap: 0;
}

.faq-box.has-open .faq-row__q {
  text-align: center;
}

/* Matches the center-aligned video/cities3.json js/faq.js swaps in
   once the cities row opens (see loadCities there) — narrower than
   the right-aligned comp the closed grid uses, so the aspect-ratio
   has to follow the same open/closed switch or the art distorts. */
.faq-box.has-open .faq-row__cities {
  aspect-ratio: 1524 / 327;
}

.faq-row {
  position: relative;
  transition: opacity 0.35s ease, transform 0.35s ease;
}

.faq-row:last-child {
  border-bottom: none;
}

/* The open row keeps its natural (question + answer) height — no
   stretching to fill the box — so the two stay together as one
   compact block. js/faq.js re-centers .faq-list__track against that
   block's actual height once it's open, the same way it centers the
   closed question list. */
.faq-row.is-open {
  flex: 0 0 auto;
}

/* Rows before/after the open one exit in opposite directions (up vs.
   down) instead of just sitting there — applied via JS alongside the
   .faq-list__track shift, using each row's *pre-cached* closed-state
   offset rather than a live offsetTop read, since offsetTop taken
   mid-transition (e.g. right as a previously-open row is collapsing)
   would be stale and throw the whole shift off. flex:0 0 0 so they
   don't compete with the open row (above) for space. */
.faq-row--before,
.faq-row--after {
  flex: 0 0 0;
  min-height: 0;
  overflow: hidden;
  opacity: 0;
  pointer-events: none;
}

.faq-row--before {
  transform: translateY(-16px);
}

.faq-row--after {
  transform: translateY(16px);
}

.faq-row__q {
  all: unset;
  display: block;
  box-sizing: border-box;
  width: 100%;
  cursor: pointer;
  text-align: center;
  font-family: inherit;
  font-weight: inherit;
  color: var(--color-cream);
  font-size: clamp(0.8rem, 1.5vw, 1.15rem);
  letter-spacing: 0.05em;
  padding: 0.32rem 2rem;
  opacity: 0.85;
  transition: opacity 0.2s ease;
}

.faq-row__q:hover,
.faq-row.is-open .faq-row__q {
  opacity: 1;
}

/* Bodymovin/Lottie export cycling through city names mid-sentence
   (see js/faq.js) in place of plain text — two lines, already
   tracked/sized to match the other questions in the source file, so
   this just needs to land at the same effective font-size rather
   than following the comp's own native 1524x327 pixel dimensions. */
.faq-row__q--cities {
  padding-top: 0.05rem;
  padding-bottom: 0.05rem;
}

/* Width in em (not a %/px cap) so it tracks .faq-row__q--cities's own
   font-size — inherited from the same clamp() every other question
   uses — 1:1. A min(%, px) cap here would hold this block at a fixed
   pixel size across the whole viewport range where the px cap wins,
   while the text keeps scaling continuously via vw, so the two drift
   out of sync as the window resizes. 13em lands at ~240px, matching
   this block's previous fixed-cap size at the clamp's upper bound. */
/* aspect-ratio matches video/cities-right-align.json's comp (desktop
   default — js/faq.js loads that file at this breakpoint); mobile
   overrides back to video/cities3.json's own, slightly narrower comp
   (1524 vs 1574 wide, same 327 height) below. */
.faq-row__cities {
  display: inline-block;
  width: 13em;
  max-width: 100%;
  aspect-ratio: 1574 / 327;
  vertical-align: middle;
}

.faq-row__cities svg {
  display: block;
  width: 100%;
  height: 100%;
}

/* Close button, styled after .site-header__toggle's hamburger-to-X
   (same two rotated bars) rather than a text glyph. Positioned against
   .faq-box itself (not the open row) so it stays put in the box's
   top-right corner regardless of where the open row lands — shown via
   .faq-box's own .has-open state (js/faq.js), not a per-row class. */
.faq-close {
  display: none;
  position: absolute;
  top: 2.1rem;
  right: 63rem;
  width: 18px;
  height: 18px;
  padding: 0;
  background: none;
  border: 0;
  cursor: pointer;
  z-index: 2;
}

.faq-box.has-open .faq-close {
  display: block;
}

.faq-close-line {
  position: absolute;
  top: 50%;
  left: 0;
  width: 100%;
  height: 2px;
  background: var(--color-cream);
}

.faq-close-line:nth-child(1) {
  transform: translateY(-50%) rotate(45deg);
}

.faq-close-line:nth-child(2) {
  transform: translateY(-50%) rotate(-45deg);
}

/* Hidden entirely (no layout footprint) until the row opens. The fade
   itself is a plain opacity transition on .faq-row__a-inner, triggered
   a beat after .is-open lands (double-rAF, same pattern as
   js/page-transition.js's revealMain) — .faq-row__a's own
   display:none -> block swap happens in the same tick as .is-open, so
   there's no "from" state for a transition to animate out of until
   the very next paint. */
.faq-row__a {
  display: none;
}

.faq-row.is-open .faq-row__a {
  display: block;
  padding-top: 1.5rem;
}

/* -webkit-transform/will-change force the compositing layer to exist
   (and get painted transparent) the instant display:block lands, ahead
   of the opacity transition that starts a beat later via the double-rAF
   in js/faq.js — without this, iOS Safari has been seen to paint this
   layer's backing store black for a frame before the italic web-font
   text rasterizes into it, flashing a black rectangle the size of the
   answer on first open. */
.faq-row__a-inner {
  opacity: 0;
  transition: opacity 0.4s ease;
  -webkit-transform: translateZ(0);
  will-change: opacity;
}

.faq-row__a-inner.is-visible {
  opacity: 1;
}

.faq-row__a-inner p {
  margin: 0 1rem;
  font-style: italic;
  font-size: clamp(0.95rem, 1.5vw, 1.25rem);
  line-height: 1.6;
  text-align: center;
  color: var(--color-cream);
}

.faq-link {
  color: var(--color-cream);
  text-decoration-thickness: 1px;
  text-underline-offset: 0.15em;
}

@media (max-width: 700px) {
  /* min-height in rem, not vh — the question list's height is fixed
     (rem-based text, not viewport-relative), so sizing the box off
     viewport height meant it came up short on shorter phone screens,
     clipping the last question or two. 27rem comfortably fits all 6
     rows with some margin. */
  .faq-box {
    aspect-ratio: auto;
    min-height: 27rem;
  }

  .faq-border {
    display: none;
  }

  /* overflow:visible (not the shared rule's hidden) — .faq-box's
     min-height above is a floor, not a ceiling: nothing inside pushes
     it taller since .faq-list is absolutely positioned, so open
     answers longer than that fixed height used to get silently
     clipped by the hidden overflow. Harmless now that there's no
     visible box outline for content to spill past. */
  .faq-list {
    inset: 1.25rem;
    overflow: visible;
  }


  /* flex-start, not center — with no visible box outline, an open
     row centered against .faq-box's fixed (invisible) min-height read
     as floating in arbitrary empty space instead of occupying a
     deliberate spot. flex-start pins the open row (before/after
     siblings collapse to zero height either way) to exactly where the
     first question already sits in the closed list, so opening any
     question lands its baseline in the same place every time. The
     closed list's own position barely shifts from this — it was
     already a near-exact fit for the box, with minimal centering
     slack to begin with. ul needs height:auto so it shrinks to its
     content instead of stretching to fill the track. */
  .faq-list__track {
    display: flex;
    flex-direction: column;
    justify-content: flex-start;
    transform: translateY(0px);
  }

  /* Undoes the desktop 2-column grid (and its left/right text-align
     split) entirely — mobile keeps the original single centered
     column regardless of open/closed state. Same selector specificity
     as the rules being overridden, so this has to stay textually
     after them to win. */
  .faq-list ul {
    display: flex;
    flex-direction: column;
    height: auto;
  }

  .faq-row:nth-child(-n+3) .faq-row__q,
  .faq-row:nth-child(n+4) .faq-row__q {
    text-align: center;
  }

  /* text-stroke, not font-weight — the Typekit kit only loads minion-3
     at weight 400, so font-weight:bold has no real intermediate face
     to fall back on and just triggers the browser's synthetic bold
     (a big jump, not a gradual one). A thin stroke nudges the glyphs
     just heavy enough to match .faq-row__cities's baked-in Lottie
     weight without going that far. */
  .faq-row__q {
    font-size: 1.12rem;
    /*! padding: 0.85rem 0.5rem; */
    -webkit-text-stroke: 0.4px currentColor;
  }

  .faq-row__a-inner p {
    margin: 0 0.25rem 1rem;
    /* Matches .bio-copy's own mobile font-size (about.css) — the
       shared clamp() this inherits from tops out at 1rem well before
       mobile widths, reading noticeably smaller than the About page's
       body copy. */
    font-size: 1rem;
  }

  /* video/cities3.json (loaded at this breakpoint by js/faq.js) is a
     narrower comp than the desktop file the base rule's ratio matches. */
  .faq-row__cities {
    aspect-ratio: 1524 / 327;
  }
  
  .faq-close {
    top: 1.8rem;
    right: 1rem;
    
  }
}