/* ============================================================================
 * Methodology IT site overrides for Keith's hero embed.
 *
 * Kept OUT of embed.html on purpose. Keith has said the footage, chat copy and
 * cast can all still change, so his file stays byte-identical to what he ships
 * and re-applying a new version of it means re-adding one <link> line rather
 * than re-doing a merge. Everything here is a site-layout concern; nothing here
 * changes wording or timing (those live in the SCENES array in embed.html).
 *
 * THE CORE PROBLEM THIS SOLVES
 *
 * This document is framed full-bleed, so its viewport is the whole page width —
 * but the site's content is not. The header links, the hero copy and the stat
 * cards all live inside `mx-auto max-w-7xl px-4 sm:px-6 lg:px-8`, i.e. a 1440px
 * column centred in the viewport with a gutter. Anchoring the overlay to the
 * viewport (`right: 4%`) therefore pushes it well outside that column on any
 * wide screen: the message card runs to within a few px of the browser edge and
 * the diagnostics rail detaches into the far corner, aligned to nothing.
 *
 * So the overlay is anchored to the SITE CONTAINER instead, reconstructed below
 * from the same numbers Tailwind uses. Its right edge lands exactly on the
 * container's right content edge — flush with "Get a free assessment" in the
 * nav and with the last stat card — and its left edge sits on the page's centre
 * line. That makes the lane exactly half the container at every width.
 *
 * Hero.tsx's copy column is capped to match. The two constraints are a pair —
 * widening one without the other reintroduces the overlap this layout avoids.
 * ========================================================================== */

/* ---------------------------------------------------------------------------
 * LEGIBILITY SCRIM
 *
 * This lives inside the frame, not in the page, and that placement is the whole
 * point. The site's hero copy needs the footage darkened behind it, but the
 * chat thread must NOT be darkened — and the thread lives in here. A scrim in
 * the page can only ever sit above or below the entire <iframe>, never between
 * the video and the thread, because the frame is one element in the page's
 * stacking context. Putting it in the page therefore forced a choice between
 * washing the thread out and not darkening anything, and the attempt to escape
 * that by bounding the scrim's height just traded it for a hard horizontal seam
 * where the gradient stopped, cutting across the hero right above the thread.
 *
 * In here it can sit exactly where it belongs: above the footage, below the
 * thread. It spans the full height at all times, so there is no edge to see.
 *
 * `.hero-stage`'s children carry no z-index and paint in DOM order, and a
 * pseudo-element would paint last (on top of everything). Hence the explicit
 * ordering: scrim at 1, thread and scene dots at 2, footage left at auto.
 * ------------------------------------------------------------------------ */
.hero-stage::after {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 1;
  pointer-events: none;
  /* Mobile: vertical, because the copy sits above the thread rather than
     beside it. Weighted to the top where the headline is. */
  background: linear-gradient(
    180deg,
    rgba(20, 16, 12, 0.92) 0%,
    rgba(20, 16, 12, 0.66) 45%,
    rgba(20, 16, 12, 0.55) 100%
  );
}

@media (min-width: 768px) {
  .hero-stage::after {
    /* Desktop: horizontal, weighted to the headline lockup on the left and
       clearing to nothing on the right, so the thread's half stays on clean
       footage. */
    background: linear-gradient(
      90deg,
      rgba(20, 16, 12, 0.85) 0%,
      rgba(20, 16, 12, 0.55) 50%,
      rgba(20, 16, 12, 0) 100%
    );
  }
}

.chat,
.scene-dots {
  z-index: 2;
}

.chat.right {
  /* 1440px is this site's `max-w-7xl`, NOT Tailwind's default 1280px:
     `src/app/methodologyit/mit-globals.css` overrides `--container-7xl` to
     90rem. Verified by measuring the live header and hero containers, both
     1440px. Hardcoded in px rather than written as `90rem` because rem here
     resolves against THIS document's root font size, not the parent page's —
     they happen to match at 16px today, and relying on that is a trap.
     100vw is safe as the page width: this document is framed edge-to-edge and
     its own body is `overflow:hidden`, so it has no scrollbar to skew it. */
  --mit-container: min(100vw, 1440px);
  --mit-gutter: 16px;
  --mit-edge: calc((100vw - var(--mit-container)) / 2 + var(--mit-gutter));

  top: 50%;
  bottom: auto;
  /* Right edge on the container's right content edge; left edge on the page
     centre line. Width is whatever that leaves — exactly half the container. */
  left: 50vw;
  right: var(--mit-edge);
  width: auto;
  max-width: none;
  transform: translateY(-50%);
  align-items: center;

  /* Scaled to the lane rather than the viewport. The shipped 14px was sized for
     a 520px corner card; this lane is ~608px on a wide screen, and anything
     past ~17px starts forcing the message pills to wrap. */
  font-size: clamp(14px, 1.05vw, 17px);
}

@media (min-width: 640px) {
  .chat.right {
    --mit-gutter: 24px;
  }
}

@media (min-width: 1024px) {
  .chat.right {
    --mit-gutter: 32px;
  }
}

/* The messages column carried caps sized for the old narrow lane; in a
   half-container lane it should simply fill what is left after the rail. */
.chat.right .col-msgs {
  max-width: none;
  flex: 1 1 auto;
}

/* `.uline` is the progress meter under "Investigating email…" — a 2px track
   whose white fill animates to 100% while the diagnostic runs, then hides when
   the card flips to its resolved state. It is sized to the card, and widening
   the lane above widened the card with it: at ~330px the meter stops reading as
   a progress bar and starts reading as a stray horizontal rule ruled across the
   card for no reason. Bounding it restores the proportion it had in Keith's
   narrower card without touching the animation. */
.chat.right .uline {
  max-width: 180px;
}

/* ---------------------------------------------------------------------------
 * Mobile: the right half is not viable at phone widths — the headline and the
 * conversation cannot both hold a ~190px column. Below `md` the thread drops
 * to full container width, under the hero copy and its Schedule a Call button.
 * ------------------------------------------------------------------------ */
@media (max-width: 767px) {
  .chat.right {
    /* Anchored in px from the TOP of the frame, deliberately not a percentage
       and not `bottom`. The frame is as tall as the whole hero section, which
       on a phone runs past 1700px once the four stat cards stack — a
       bottom-anchored or percentage-anchored overlay lands *behind* those
       cards, which paint over it at z-10. This offset drops the thread into
       the band Hero.tsx reserves below the Schedule a Call button
       (`pb-[380px] md:pb-24`), roughly centred in it. See the MOBILE CHAT BAND
       comment there — this number, that padding and the mobile scrim height
       are a set of three. */
    top: 780px;
    bottom: auto;
    /* Same gutter as the stat cards below it, so the edges line up. */
    left: var(--mit-edge);
    right: var(--mit-edge);
    transform: none;
    align-items: flex-start;
    font-size: 15px;
  }

  /* The diagnostics rail is the first thing to go when width is scarce; the
     message thread is the part that carries the story. */
  .chat.right .col-side {
    display: none;
  }
}