/* ---------- Case study pages ----------
   Built 2026-08-17 against Chloe's three reference mockups
   (CaseStudyRefBirthdayBoy.png, CaseStudyRefCaboAirbnb.png, Case Study
   Cruising Premier.png). One static page per project (case-study-*.html),
   sharing this stylesheet + js/case-study.js.

   Per Chloe: the reference mockups themselves aren't one consistent
   layout — Cabo Air BnB and Cruising Premiere show a full-width photo
   below the nav with the title/blurb overlaid bottom-left ("horizontal"
   layout below), while Birthday Boy shows a split-screen with a black
   info column on the left and the photo on the right ("vertical" layout
   below). Her call: which layout shows is driven by the CURRENT PHOTO'S
   OWN ORIENTATION, not a fixed per-project choice — landscape photos get
   the horizontal treatment, portrait photos get the vertical one, and a
   single project's gallery can flip between the two as you click through
   its thumbnails (confirmed against real photo dimensions: Birthday Boy
   and Hotel Per LA happen to be all-portrait so they stay vertical
   throughout, Cabo Air BnB and Cruising Premiere are mixed and do
   actually flip). The nav chrome (.cs-chrome) never changes regardless.
   See js/case-study.js for the orientation-swap logic.

   2026-08-18 additions (Chloe): photo frame height reduced in both
   layouts so its bottom edge sits higher on the page; .cs-nav-prev/next
   manual controls added (reusing the old homepage carousel's round
   button style); gallery auto-progresses on a timer, pausing/restarting
   on manual interaction, matching the old carousel's behavior; video is
   now a possible item type mixed into the same rotation (see .cs-video,
   and js/case-study.js's items/type handling) — currently only Birthday
   Boy has real video footage (bts-clip.mp4). */

/* 2026-08-18 (Chloe): un-pinned — this used to be position:sticky, but
   case study pages now let the header scroll away with the rest of the
   page like any other content, rather than staying pinned at the top. */
.cs-chrome {
  position: static;
  background: var(--ink);
}

/* Opts out of style.css's global fixed/hidden/scroll-reveal header
   (added the same day) — case study pages keep a plain, always-visible,
   in-flow bar instead of the floating blurred overlay used elsewhere. */
.cs-chrome .site-header {
  position: static;
  transform: none;
  background: transparent;
  backdrop-filter: none;
  -webkit-backdrop-filter: none;
}

.cs-chrome .wordmark {
  color: var(--cream);
}

/* ---------- project sub-nav (3 category columns) ---------- */

.cs-subnav {
  display: flex;
  gap: clamp(1.5rem, 5vw, 4rem);
  padding: 0 var(--edge) clamp(1rem, 3vw, 1.75rem);
}

.cs-subnav-group {
  display: flex;
  flex-direction: column;
  gap: 0.3rem;
}

.cs-subnav-label {
  font-family: var(--font-copy);
  font-weight: 700;
  font-size: 0.62rem;
  text-transform: uppercase;
  letter-spacing: 0.08em;
  color: var(--pink);
}

.cs-subnav-link {
  font-family: var(--font-copy);
  font-weight: 300;
  font-size: 0.78rem;
  text-decoration: none;
  color: rgba(255, 255, 255, 0.45);
}

.cs-subnav-link.is-active {
  font-weight: 700;
  color: var(--cream);
}

.cs-subnav-link:hover {
  color: var(--cream);
}

/* ---------- stage: the photo + title/blurb + thumbnails ----------
   .cs-stage's own height isn't fixed — it's driven by the photo frame's
   aspect-ratio (landscape) or a min-height (portrait split-screen), so it
   naturally grows/shrinks as data-orientation flips between photos. */

.cs-stage {
  position: relative;
  /* Shared between landscape's aspect-ratio and portrait's height calc
     below (2026-08-18: Chloe's call that both layouts should render at
     the same content block size) — one number, so they can't drift out
     of sync if it's ever changed. Lowered from 2.2 to 1.8 same day, also
     per Chloe, to make both layouts taller (a lower width:height ratio
     means a taller frame at any given viewport width). */
  --cs-frame-ratio: 1.8;
}

.cs-photo-frame {
  overflow: hidden;
  background: var(--ink);
}

.cs-photo,
.cs-video {
  display: block;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.cs-photo[hidden],
.cs-video[hidden] {
  display: none;
}

/* ---------- prev/next controls ----------
   Same round semi-transparent button used for the old homepage carousel
   (.partner-nav in this file's history) — sit within .cs-photo-frame
   itself (not .cs-stage), so in split-screen/portrait mode they stay
   confined to the photo half rather than spanning the black info column
   too. .cs-photo-frame is position:relative in both orientations
   already (see below), so no extra positioning context needed here. */
.cs-nav {
  position: absolute;
  top: 50%;
  z-index: 3;
  transform: translateY(-50%);
  width: 2.75rem;
  height: 2.75rem;
  display: flex;
  align-items: center;
  justify-content: center;
  border: none;
  border-radius: 50%;
  background: rgba(0, 0, 0, 0.35);
  color: var(--cream);
  cursor: pointer;
  transition: background-color 0.2s ease;
}

.cs-nav:hover {
  background-color: rgba(0, 0, 0, 0.65);
}

.cs-nav svg {
  width: 1.1rem;
  height: 1.1rem;
}

.cs-nav-prev {
  left: 1rem;
}

.cs-nav-next {
  right: 1rem;
}

/* .cs-info is the positioned box (full content-block size, inset from
   the frame edges); .cs-info-block is the actual h1+p group, anchored
   inside it — see the desktop rules below for why the anchor lives on
   the inner block rather than .cs-info itself. */
.cs-info {
  position: relative;
  color: var(--cream);
}

/* Shared top:% anchor (not orientation-specific) is the actual fix for
   "header always same spot" — .cs-info is the same total height in both
   layouts now (see the two orientation-specific rules below), so one
   percentage lands the h1 at the same pixel offset regardless of which
   layout is showing. Mobile resets this back to per-orientation behavior
   (see the media query at the bottom) since the two layouts don't stay
   side-by-side-comparable at that width anyway. */
.cs-info-block {
  position: absolute;
  /* The horizontal inset lives here (not on .cs-info) so it applies
     consistently in both orientations: .cs-info itself spans a
     different WIDTH per orientation (full stage width in landscape,
     the 40% flex column in portrait), but padding on an absolutely
     positioned element's containing block does NOT shift it inward —
     the containing block is the padding box's own outer edge (confirmed
     via measurement: an earlier version of this rule put a matching
     padding on .cs-info instead and it was silently ignored). left/right
     here measure from that outer edge directly, correctly landing at
     var(--edge) in from whichever box .cs-info actually is. */
  left: var(--edge);
  right: var(--edge);
  top: 60%;
  /* h1/p font-size is identical in both orientations (confirmed via
     direct measurement — the earlier "font changes" report turned out
     to be this instead): without a shared cap, landscape's block can
     stretch to ~940px wide at a modest desktop width while portrait's
     stays ~330px (its 40% column), so the SAME font-size wraps totally
     differently — cramped/multi-line in portrait, one sprawling line in
     landscape — which reads as a size change even though no size
     actually changed. Capping both to the same measure fixes that:
     landscape gets reined in to match portrait's natural column width
     instead of using its full available band. */
  max-width: 33rem;
}

.cs-info h1 {
  font-family: var(--font-display);
  font-weight: 700;
  text-transform: uppercase;
  margin: 0 0 0.6rem;
  line-height: 1;
  /* Shared size (not orientation-specific) is part of the same
     same-spot fix — a size that differed by layout would still read as
     "jumping" even at an identical position. */
  font-size: clamp(1.8rem, 3.6vw, 3.6rem);
}

.cs-info p {
  font-family: var(--font-copy);
  font-weight: 300;
  line-height: 1.4;
  margin: 0;
  max-width: 32em;
  /* Shared size (not orientation-specific), same reasoning as h1 above —
     it was two slightly different clamps before (landscape vs portrait),
     close enough to not obviously mismatch at any single width but still
     a real, visible size change when a thumbnail click flips the layout
     at a fixed viewport width. */
  font-size: clamp(0.8rem, 1.4vw, 1rem);
}

.cs-thumbs {
  position: absolute;
  z-index: 2;
  display: flex;
  gap: 0.4rem;
}

.cs-thumb {
  width: clamp(2.4rem, 5vw, 3.4rem);
  aspect-ratio: 1;
  padding: 0;
  border: 2px solid transparent;
  cursor: pointer;
  overflow: hidden;
  opacity: 0.6;
  transition: opacity 0.2s ease, border-color 0.2s ease;
}

.cs-thumb img {
  display: block;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.cs-thumb:hover {
  opacity: 0.85;
}

.cs-thumb.is-active {
  opacity: 1;
  border-color: var(--cream);
}

/* ---------- horizontal layout: landscape photo, full width, title
   overlaid bottom-left over a gradient scrim (matches CaboAirbnb /
   CruisingPremiere refs) ---------- */

.cs-stage[data-orientation="landscape"] {
  display: block;
}

.cs-stage[data-orientation="landscape"] .cs-photo-frame {
  width: 100%;
  /* --cs-frame-ratio (defined on .cs-stage above), not a hardcoded
     number — this is what portrait's height:calc(100vw/--cs-frame-ratio)
     is kept in sync with, so the two layouts stay the same content
     block size as that ratio gets tuned. */
  aspect-ratio: var(--cs-frame-ratio) / 1;
  position: relative;
}

.cs-stage[data-orientation="landscape"] .cs-photo-frame::after {
  content: "";
  position: absolute;
  inset: 0;
  background: linear-gradient(0deg, rgba(0, 0, 0, 0.65) 0%, rgba(0, 0, 0, 0) 45%);
  pointer-events: none;
}

/* Full content-block height (top:0/bottom:0), not just an auto-height
   box pinned to the bottom — needed so .cs-info-block's shared top:%
   anchor (below) resolves against the SAME height in both orientations,
   which is what actually keeps the header in the same spot. */
.cs-stage[data-orientation="landscape"] .cs-info {
  position: absolute;
  left: 0;
  right: 0;
  top: 0;
  bottom: 0;
  z-index: 1;
}

.cs-stage[data-orientation="landscape"] .cs-thumbs {
  right: var(--edge);
  bottom: clamp(1.5rem, 4vw, 3rem);
}

/* ---------- vertical layout: split screen, black info column + portrait
   photo (matches BirthdayBoy ref) ---------- */

/* `height`, not the aspect-ratio-driven auto value landscape uses —
   .cs-photo-frame has no aspect-ratio of its own here, so its <img>
   (height:100%) needs a DEFINITE parent height to resolve against and
   actually crop via object-fit:cover. Without one, the browser falls
   back to stretching the frame to the image's own intrinsic aspect
   ratio instead — for a 2:3 portrait photo at a 960px-wide frame that's
   1440px tall, taller than most viewports outright (a real bug, found
   via measurement when this was still `min-height`).
   The height itself is calc(100vw / --cs-frame-ratio) — the exact same
   formula landscape's aspect-ratio produces — rather than an independent
   vh value, per Chloe's 2026-08-18 call that both layouts should render
   at the same content block size. */
.cs-stage[data-orientation="portrait"] {
  display: flex;
  height: calc(100vw / var(--cs-frame-ratio));
  background: var(--ink);
}

/* .cs-photo-frame comes first in the markup (so the photo is the first
   thing in reading/DOM order), but the BirthdayBoy ref puts the black
   info column on the LEFT and the photo on the RIGHT — reordered
   visually here rather than in the HTML. */
.cs-stage[data-orientation="portrait"] .cs-photo-frame {
  order: 2;
}

.cs-stage[data-orientation="portrait"] .cs-info {
  order: 1;
  flex: 0 0 40%;
}

.cs-stage[data-orientation="portrait"] .cs-photo-frame {
  flex: 1 1 60%;
  position: relative;
}

.cs-stage[data-orientation="portrait"] .cs-thumbs {
  right: clamp(1.25rem, 3vw, 2rem);
  bottom: clamp(1.25rem, 3vw, 2rem);
}

@media (max-width: 860px) {
  .cs-subnav {
    gap: 1.5rem;
    flex-wrap: wrap;
  }

  .cs-stage[data-orientation="portrait"] {
    flex-direction: column;
    /* Reset the desktop-only fixed `height` (see base rule above) — at
       mobile the photo and info stack vertically instead of stretching
       side by side, and each gets its own real height (aspect-ratio on
       the frame, natural content height on the info block), so the
       stage's total height should just be whatever the sum of those is. */
    height: auto;
  }

  .cs-stage[data-orientation="portrait"] .cs-photo-frame {
    order: 1;
    flex-basis: auto;
    /* Shorter than 4:5 per Chloe's call to raise the photo's bottom
       edge up the page. */
    aspect-ratio: 1 / 1;
  }

  .cs-stage[data-orientation="portrait"] .cs-info {
    order: 2;
    flex-basis: auto;
    padding: 1.5rem var(--edge);
  }

  /* Below 860px, portrait's .cs-info-block goes back to normal document
     flow (stacked under the photo, not overlaid on it) — the shared
     top:60% anchor above is a desktop-only trick for keeping the header
     in the same spot across both layouts; at mobile the two layouts
     already look completely different (stacked column vs. full-bleed
     overlay) so there's nothing to keep in sync, and static positioning
     is what lets .cs-info's own padding-based box actually size to its
     content instead of collapsing (an absolutely-positioned child
     contributes no height to its parent). */
  .cs-stage[data-orientation="portrait"] .cs-info-block {
    position: static;
  }

  .cs-stage[data-orientation="landscape"] .cs-photo-frame {
    /* Shorter than 4:5 per Chloe's call to raise the photo's bottom edge
       up the page. */
    aspect-ratio: 1 / 1;
  }

  /* Landscape mode keeps its title+blurb overlaid on the photo even at
     mobile widths, but reverts from the shared desktop top:60% anchor
     back to the original bottom-anchored overlay (same reasoning as the
     portrait override above — mobile doesn't need the two layouts to
     match, and bottom-anchoring is what the Cabo/Cruising mockups show).
     .cs-info-block's own bottom edge is pinned via `bottom:`, same as
     .cs-thumbs — so a taller paragraph pushes its TOP up, not its
     bottom, meaning a 2-line clamp alone doesn't stop text from reaching
     the thumbnail row (confirmed via testing: the bottom of both sits in
     the same band regardless of copy length). What actually caused the
     overlap is horizontal: .cs-info-block spans almost the full width,
     so a wrapped line can reach nearly as far right as .cs-thumbs' own
     inset. Reserving right-padding fixes it IF the reservation actually
     matches .cs-thumbs' real width — first attempt reserved a guessed
     4.5rem, but the thumbnail row's real width scales with photo count
     (4-5 thumbs + gaps ≈ 11-14rem, confirmed via measurement), so the
     fixed reservation below only works paired with capping .cs-thumbs
     itself to that same width (see .cs-thumbs rule further down — it
     becomes a small horizontally-scrollable strip on mobile rather than
     growing with photo count). The line-clamp still caps runaway copy
     length as a second safeguard. */
  .cs-stage[data-orientation="landscape"] .cs-info-block {
    top: auto;
    bottom: clamp(1.5rem, 4vw, 3rem);
    /* var(--edge) + the extra reserve, not just the reserve alone —
       .cs-info-block's own right is var(--edge) by default (see base
       rule), so replacing it with a bare 4.5rem actually SHRUNK the
       reservation and let text run back into the thumbnail strip again
       (a regression caught by re-running the same overlap check that
       originally caught this bug). */
    right: calc(var(--edge) + 4.5rem);
  }

  .cs-stage[data-orientation="landscape"] .cs-info p {
    display: -webkit-box;
    -webkit-line-clamp: 2;
    -webkit-box-orient: vertical;
    overflow: hidden;
  }

  .cs-stage[data-orientation="landscape"] .cs-info h1,
  .cs-stage[data-orientation="portrait"] .cs-info h1 {
    font-size: clamp(1.8rem, 8vw, 2.6rem);
  }

  /* Below ~860px .cs-info drops out of flex positioning into normal
     document flow (see above), so .cs-thumbs can no longer stay
     absolutely pinned to the bottom of .cs-stage as a whole — that would
     land it on top of whatever text happens to be the last flow content
     (confirmed via a real overlap bug during testing: the thumbnail row
     sat directly over the blurb). Fix: drop out of absolute positioning
     and let it sit in flow as its own row, after the info block.
     Landscape mode is deliberately NOT included here — .cs-info there
     stays absolutely overlaid on the photo (title bottom-left, thumbs
     bottom-right, same band, matching the Cabo/Cruising refs even at
     mobile widths); adding a static row would grow .cs-stage taller and
     drag .cs-info's own bottom-anchored offset down with it, since that
     offset is relative to .cs-stage, not just the photo — pushing the
     title down into the thumbnail row instead of stopping at the photo's
     bottom edge. */
  .cs-stage[data-orientation="portrait"] .cs-thumbs {
    order: 3;
    position: static;
    padding: 0 var(--edge) 1.5rem;
    overflow-x: auto;
  }

  /* Landscape mode's thumbnail row stays absolutely overlaid on the
     photo (see .cs-info comment above), capped to the same width its
     sibling reserves room for — otherwise a 4-5-photo project's full
     thumbnail row is wider than the reservation and runs back into the
     text. Scrolls horizontally to reach the rest. */
  .cs-stage[data-orientation="landscape"] .cs-thumbs {
    max-width: 4.5rem;
    overflow-x: auto;
    scrollbar-width: none;
  }

  .cs-stage[data-orientation="landscape"] .cs-thumbs::-webkit-scrollbar {
    display: none;
  }
}