/* Manual additions layered on top of the self-hosted Webflow bundle. Kept in a separate file so
   ineedacopilot.webflow.shared.*.min.css stays an unedited, auditable copy of what shipped from
   Webflow.

   The rule below exists because a heading-hierarchy fix (closing a level-skip — see
   src/pages/works/[slug].astro) retagged the "Services"/"Client"/"Year"/"Website" labels from
   <h3 class="bold-title"> to <h2 class="bold-title">, to bridge the page's h1 -> h2 body-copy
   heading sequence. `.bold-title` sets margin-bottom/font-style/font-weight explicitly (so
   those are already identical between h2 and h3), but leaves font-size/line-height to the bare
   tag rule, which does differ between h2 and h3 (verified empirically with Playwright against
   the real CSS bundle — the minified bundle has more layered/overriding selectors than are safe
   to reverse-engineer by reading the text, e.g. .footer-title turned out to already fully
   self-contain font-size/line-height regardless of heading level, so no override was needed
   there at all; this one genuinely needs it). Confirmed identical at both a 1440px and a 393px
   (Pixel 5) viewport, so no @media breakpoint variant is needed here either. */
.bold-title.heading-as-h3 {
  font-size: 28px;
  line-height: 30px;
}

/* /contact-us "Our Studios" maps: Webflow's map widget (public/js/webflow.js, a vendored
   bundle we do not edit) hardcodes Webflow's own shared Google Maps API key and injects a
   billed maps.googleapis.com script at runtime on any `.w-widget-map` element. That key
   belongs to Webflow, this client is no longer a Webflow customer, and the request fails with
   BillingNotEnabledMapError — a hidden runtime dependency on Webflow that survived the static
   export. Fixed by replacing both widget divs with keyless `output=embed` iframes (see
   src/pages/contact-us.astro) and removing the `.w-widget-map` class entirely so webflow.js
   has nothing left to scan for.
   The `.map` class alone (Webflow's own rule, not touched here) already sets the container to
   100% width / 330px height with no border-radius or box-shadow — verified empirically with
   Playwright (javaScriptEnabled: false, so only CSS applies, no widget JS) against the same
   markup at both 1440px and Pixel-5 (393px) viewports, matching the original widget's rendered
   box exactly. What .map does NOT account for is that an <iframe> is a replaced element with
   its own browser-default UA styles that a <div> never had: default `display: inline` and a
   default `border: 2px inset`. Left alone, the border draws a visible frame around the map
   that the original never had, and the inline display adds a baseline-alignment gap that grew
   the two-map container from 730px to 748px (verified the same way, isolating each property).
   Both overrides below are required together to reproduce the original 730px footprint
   exactly; either alone is insufficient (confirmed by testing them individually). */
.map-container iframe.map {
  display: block;
  border: 0;
}

/* ---------------------------------------------------------------------------
   WCAG 2.1 AA remediation. See docs/40-initiatives/01-site-build/
   02-accessibility-visual-spec.md for measurements and rationale.
   No brand color changes: the palette already passes AA in every rendered use.
   --------------------------------------------------------------------------- */

/* 1. Inline links in CMS rich text -----------------------------------------
   Fixes axe `link-in-text-block`. Midnight #2E294E on Refined Charcoal #3A3F52
   body copy is 1.30:1 -- indistinguishable by color, and the element had no
   hover state at all. The 1px Midnight rule is the site's own interactive
   signature (.underline-hover, height:1px, background-color:var(--midnight)),
   made persistent because an inline link has no adjacency cue to make a
   hover-only affordance discoverable. 0.18em offset chosen by rendering
   against Cormorant Garamond's descenders. */
.w-richtext a:not(.w-button):not(.button) {
  text-decoration: underline;
  text-decoration-color: var(--midnight);
  text-decoration-thickness: 1px;
  text-underline-offset: 0.18em;
  text-decoration-skip-ink: auto;
  transition: color .2s, text-decoration-color .2s, text-decoration-thickness .2s;
}
.w-richtext a:not(.w-button):not(.button):hover,
.w-richtext a:not(.w-button):not(.button):focus-visible {
  color: var(--blacklight);              /* 16.42:1 on #fff; the bundle's own hover token */
  text-decoration-color: var(--blacklight);
  text-decoration-thickness: 2px;
}

/* 2. Focus indicators -------------------------------------------------------
   The bundle ships `.w-nav-button:focus{outline:0}` and `.w-tab-link:focus{
   outline:0}`, leaving the mobile nav toggle and all three /our-approach tabs
   with no visible focus indicator at all (WCAG 2.4.7). The site's own CSS
   declares no :focus rules anywhere, so everything else inherits Chrome's UA
   ring -- browser-dependent, and weak on the Midnight surfaces.

   Two tones because no single color clears 3:1 on both #FFFFFF and #2E294E.
   Worst case across every surface the site uses is 10.41:1.

   Deliberately no border-radius: outline and box-shadow both follow the
   element's own radius, so the 25px pill buttons stay pills and the 50%
   go-up button stays a circle. */
:where(a, button, [role="button"], input, select, textarea, summary, [tabindex]):focus-visible,
.w-nav-button:focus-visible,
.w-tab-link:focus-visible {
  outline: 2px solid var(--midnight);
  outline-offset: 2px;
  box-shadow: 0 0 0 2px #fff;
}

/* Nav items are exactly 60px tall inside a 60px position:fixed navbar pinned
   to the viewport top, so an outside ring is clipped by the viewport edge and
   renders as two disconnected vertical strokes. Inset instead. */
.navlink:focus-visible,
.brand:focus-visible {
  outline-offset: -3px;
  box-shadow: none;
}

/* Always on Midnight -- put the high-contrast tone on the outside.
   DEVIATION FROM SPEC (docs/40-initiatives/01-site-build/02-accessibility-visual-spec.md
   3.3): the spec groups `.go-up-button` into this swapped-layer exception alongside
   `.button-3`, on the premise that both "always sit on Midnight." Verified directly
   (pixel-sampled a real focused render): true for `.button-3` -- it only ever appears
   inside `.content-section-purple` / `.hero-section-home`, both `background-color:
   var(--midnight)` -- but false for `.go-up-button`, which is `position: fixed;
   bottom: 0; right: 0` and is never a descendant of a Midnight-filled section on any
   route. Its real backdrop is whatever page content sits behind that viewport corner,
   which on this predominantly white/near-white site is white in every case checked. With
   the swap applied there, the outline (white, offset) sits on white page background and
   the box-shadow (midnight, hugging) sits on the button's own midnight fill -- both
   layers blend to invisible, a live WCAG 2.4.7/1.4.11 focus-indicator failure, confirmed
   by sampling rendered pixels around a focused go-up-button on /forces-assessment (no
   ring visible at all). The spec itself calls this exception "optional polish" and notes
   the base (unswapped) rule is "already compliant" on every surface in its own contrast
   table -- so dropping `.go-up-button` from the swap costs nothing and fixes a real
   invisible-focus bug. Left `.button-3` in, exactly as specified, since its always-Midnight
   premise checks out. */
.button-3:focus-visible {
  outline-color: #fff;
  box-shadow: 0 0 0 2px var(--midnight);
}