/*
  ── CORRECTIONS TO THE DELIVERED STYLESHEET ─────────────────────────────────────────────────
  assets/css/site.min.css is Ironside's site as it was delivered, and it stays byte-for-byte
  that file: when a page looks wrong the first question is always "is this the design or is
  this us", and that question only has an answer while the delivered file is untouched.

  So corrections live here, loaded after it. Every rule states what it fixes and at which
  viewport it was measured, because a rule with no measurement behind it is the thing that
  gets reverted six weeks later by somebody who cannot tell whether it ever did anything.
*/

/*
  THE HERO CUTOUT SHOWED ONE OF THE TWO PARTNERS ON A PHONE.

  Measured at 390x844: `.cut` is 294px wide, and `.cut img` renders 464px wide at
  left:-184px. Sloan is the left 184px of that image, so he was entirely outside the
  viewport and `body { overflow-x: hidden }` quietly removed him. 179px of overflow at
  430, 48px at 768. Reported as "the header's hero image cuts off Sloan" -- from a phone,
  which is the only place it is this bad.

  TWO DELIVERED RULES, NEITHER WRONG ALONE.

    @media(max-width:860px) .hero[class*="hero-cutout"].cs-left .cut   { position: static }
    @media(max-width:860px) .hero.hero-fill[class*="hero-cutout"] .cut img
        { position:absolute; left:50%; transform:translateX(-50%); height:100%;
          max-height:min(42vh,360px) }

  The image is absolutely positioned and centred with `left:50%` -- which is measured
  against its nearest POSITIONED ancestor, and the first rule has just made `.cut` static.
  So it centres on the hero instead of on its own column, and sizes itself from height
  (360px tall at this 1.286 ratio is 463px wide) in a column only 294px wide. `max-width`
  never entered into it.

  Width leads here instead, which cannot overflow, and the image gets the whole viewport to
  lead with (`margin-inline: calc(50% - 50vw)`, the standard full-bleed escape from an
  ancestor's padding) so that sizing by width does not also mean sizing it small. 390x303
  rather than a clipped 464x360: both partners, no crop.

  The selectors below match the delivered ones' specificity and win on order, deliberately:
  a specificity race that this file wins by being cleverer is one it loses the next time
  somebody edits it.
*/
@media (max-width: 860px) {
  .hero.hero-fill[class*="hero-cutout"].cs-left .cut {
    /* Positioned again, so the caption below still centres on the image, not on the hero. */
    position: relative;
    width: 100vw;
    max-width: 100vw;
    margin-inline: calc(50% - 50vw);
  }

  .hero.hero-fill[class*="hero-cutout"] .cut img {
    position: static;
    transform: none;
    width: 100%;
    height: auto;
    /* The height cap is what drove the overflow. Width leads now; height follows it --
       capped, because on a 768px tablet an uncapped full-bleed width makes the cutout
       596px tall and pushes the credit strip off the first screen. 560px holds it near
       the ~360px the delivered rule intended, and is above every phone width, so the
       narrow case this whole block exists for is untouched: 390 stays 390x303. */
    max-width: min(100%, 560px);
    margin-inline: auto;
    max-height: none;
  }
}

/*
  THE "NEW CLIENT / EXISTING CLIENT" PAIR HAD AN EMPTY THIRD COLUMN AND NO CARDS.

  Measured on /contact/ at 1600x1000: `.fgrid3` is 1280px wide holding two `.fcard`
  children, each 389px. `repeat(3, minmax(0,1fr))` is hardcoded, so a third of the band
  -- about 430px -- is empty, and the two choices sit off to the left of a gap rather
  than reading as a pair.

  AND THEY ARE NOT CARDS. The delivered stylesheet styles `.hero-card .fcard` -- a
  background, padding, a radius -- and nothing at all for a bare `.fcard`. This band
  type was used on the contact page in a context the design never covered, so what
  renders is a heading, a paragraph and a button loose on the ground. (Easy to miss:
  grepping for `.fcard{` matches the tail of `.hero-card .fcard{` and looks like a
  rule that applies everywhere.)

  Three corrections, all of them generic -- a grid with two children anywhere on the
  site gets two columns, not this page specifically:

  1. TWO CHILDREN, TWO COLUMNS. `:has(> :last-child:nth-child(2))` matches a grid whose
     second child is also its last. Three-card grids -- every other one on the site --
     keep the delivered three columns untouched.
  2. A PANEL, in the language the site already has. `.fcard2` is the delivered dark
     panel (bg3, a radius, that padding scale); this borrows it rather than inventing a
     card, so the pair matches the form panel it sits under.
  3. THE BUTTONS LINE UP. The two cards carry different amounts of text, so the calls to
     action sat 50px apart -- which reads as one option being secondary when the whole
     point is that they are two doors into the same firm. Equal-height cards with the
     button pushed to the bottom.
*/
/*
  ABOVE THE DELIVERED BREAKPOINT ONLY. `@media(max-width:900px) .fgrid3` collapses this
  grid to a single column, and that rule is (0,1,0) while `.fgrid3:has(> :last-child:nth-child(2))`
  is (0,3,0) -- `:has()` takes the specificity of its argument, and a media query adds
  none. So an unscoped version of this wins on a PHONE too, and measured at 390px it
  turned one full-width card into two 161px slivers. Matching the delivered breakpoint
  keeps the mobile rule the only one in play where it should be.
*/
@media (min-width: 901px) {
  .fgrid3:has(> :last-child:nth-child(2)) {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

.s-dark .fgrid3 > .fcard,
.s-dark2 .fgrid3 > .fcard {
  background: var(--bg3);
  border: 1px solid var(--hair-l);
  border-radius: 4px;
  padding: clamp(1.75rem, 3vw, 2.75rem);
  /* Equal height comes from the grid's default `stretch`; this makes the button the
     thing that takes up the slack, so both sit on the same line. */
  display: flex;
  flex-direction: column;
  align-items: flex-start;
}

.s-dark .fgrid3 > .fcard > .btn,
.s-dark2 .fgrid3 > .fcard > .btn {
  margin-top: auto;
}

/* The paragraph already has `margin:.55rem 0 0` from the delivered rule; this only adds
   breathing room before a button that is now pinned to the bottom of a taller card. */
.s-dark .fgrid3 > .fcard > p,
.s-dark2 .fgrid3 > .fcard > p {
  margin-bottom: 1.6rem;
}

/*
  THE MAP PLACEHOLDER READ AS AN EMPTY GREY BOX.

  Measured on the homepage at 1440x900: `.mapwrap` is 604x578 and the content inside it
  -- pin, address, two actions, the cookie note -- is about 250px tall and 395px wide.
  `.mapface` centres that vertically (`justify-content:center`) but pins it LEFT
  (`align-items:flex-start`), so roughly 160px of dead ground runs down the right side
  and 160px more sits above and below. The panel looks like a mistake rather than a
  placeholder.

  THE RESERVED HEIGHT IS NOT THE BUG, so this does not touch it. `min-height:
  clamp(380px,40vw,560px)` holds the real map's area so the page does not jump when a
  visitor consents and the iframe loads. Collapsing the panel would trade a cosmetic
  problem for a layout shift on the one interaction this band has.

  Centring it in both axes is the whole change: the reserved space then reads as a
  panel waiting for a map, with the pin as its anchor, instead of content shoved into a
  corner. The same band draws on /contact/, so both get it.
*/
.mapwrap > .mapface {
  align-items: center;
  text-align: center;
}

/* The note is `max-width:42ch` and left-aligned by default; centred it needs its own
   auto margins or it sits off-axis under centred content. */
.mapwrap > .mapface > .mapnote {
  margin-inline: auto;
}

.mapwrap > .mapface > .mapacts {
  justify-content: center;
}

/* ONE FOCAL POINT for the reserved space, rather than more decoration in it. The pin is
   the only thing in this panel that says "a map belongs here"; at its inherited size it
   is a 20px afterthought above the address. Chanel's rule -- take one thing off, make
   the thing that stays do the work. */
.mapwrap > .mapface > svg {
  width: 38px;
  height: 38px;
  opacity: .85;
}