/* rxgrab-chrome.css — styles ONLY the engine-injected header and footer.
 *
 * ⛔ WHY THIS FILE EXISTS RATHER THAN JUST LINKING styles.css.
 *   Tool pages (/tools/pharmacy-finder, /tools/report-price and others) are self-styled with their
 *   own inline CSS and deliberately do NOT load the property stylesheet. They still mount
 *   #site-header and #site-footer, so site_engine injects chrome into them with no CSS to style it.
 *   The footer links therefore rendered in the browser's default link blue, #0000ee, against the
 *   near-black footer ground: contrast 2.0, on every tool page. That is what "visually cooked"
 *   looked like from the outside.
 *
 * ⛔ AND THE OBVIOUS FIX MAKES IT WORSE, WHICH WAS MEASURED BEFORE SHIPPING ANYTHING.
 *   Injecting /styles.css into the live pharmacy-finder page took it from 32 contrast failures to
 *   35, and introduced new ones: styles.css is a LIGHT-theme base and the tool pages carry dark
 *   panels, so it painted dark text on dark surfaces. This is the same failure filmfont shipped,
 *   where loading a light base inverted every heading to contrast 1.00.
 *   ⭐ A PROPERTY STYLESHEET IS A THEME, NOT A UTILITY. A page that opted out of it opted out for a
 *     reason, and re-adding it wholesale re-themes the page rather than fixing the chrome.
 *
 * ⭐ SO THIS FILE IS SCOPED. Every selector is inside #site-header or #site-footer, which means it
 *   cannot reach a page body no matter what that body looks like. Colours are copied from the
 *   rendered chrome of a working article page and each was measured on the #0a0d0b footer ground:
 *   links #c7cdc9 = 12.09, logo #ffffff = 19.53, note #7a847e = 5.05. All clear AA.
 */

#site-footer {
  background: #0a0d0b;
  color: #c7cdc9;
  font-family: 'Inter', system-ui, -apple-system, sans-serif;
  font-size: 13.5px;
  line-height: 1.6;
  padding: 56px 24px 28px;
  margin-top: 3rem;
}
#site-footer a { color: #c7cdc9; text-decoration: none; }
#site-footer a:hover { color: #ffffff; text-decoration: underline; }
#site-footer .footer-logo,
#site-footer .footer-logo a { color: #ffffff; font-size: 22px; font-weight: 700; text-decoration: none; }
/* the wordmark's green is a logotype and is exempt from 1.4.3, but it is set here anyway so it
   matches the article pages rather than inheriting a default */
#site-footer .footer-logo span { color: #20954e; }
#site-footer .footer-note,
#site-footer .footer-disclosure { color: #7a847e; font-size: 11px; line-height: 1.6; }
#site-footer .footer-disclosure a { color: #20954e; font-weight: 600; }
#site-footer ul { list-style: none; margin: 0; padding: 0; }
#site-footer nav ul { display: flex; flex-wrap: wrap; gap: 1rem 1.25rem; }
/* ⛔ THIS RULE USED TO SAY `#site-footer > div` AND MATCHED NOTHING. site_engine injects a nested
 *   <footer>, not a <div>, so the footer content ran the full 1905px of the viewport while the page
 *   column above it is 760px. The rule was correct in every respect except that no element on the
 *   page satisfied its selector, so it silently did nothing and looked like a layout bug.
 *   ⭐ A SELECTOR THAT MATCHES NOTHING FAILS EXACTLY LIKE A RULE THAT WAS NEVER WRITTEN, and neither
 *     the stylesheet nor the build can tell you which one happened. Same shape as the chrome that
 *     mounted with no stylesheet. */
#site-footer > * { max-width: 1080px; margin: 0 auto; box-sizing: border-box; }

#site-header {
  font-family: 'Inter', system-ui, -apple-system, sans-serif;
  border-bottom: 1px solid #e8e4da;
  background: #faf6ef;
}
#site-header nav { display: flex; align-items: center; gap: 1.25rem; flex-wrap: wrap;
  max-width: 1080px; margin: 0 auto; padding: 1rem 1.5rem; }
/* ⛔ `#site-header a` IS AN ID SELECTOR (1,0,1) AND IT STEAMROLLED EVERY COMPONENT IN THE HEADER.
 *   It set the cream-ground link colour on the .ribbon links (dark band, 2.39) and on
 *   `nav.top .nav-cta` (0,2,0), which had correctly declared its own colour and lost.
 *   ⭐ A CHROME STYLESHEET SHOULD STYLE PLAIN CHROME LINKS, NOT EVERY ANCHOR THAT HAPPENS TO BE
 *     INSIDE IT. Writing it at id strength made it authoritative over components it knows nothing
 *     about, including their grounds. The exclusions below hand those anchors back to the rules
 *     that were written for them, which is what "scoped" was supposed to mean in the first place. */
#site-header a:not(.nav-cta):not(.cta-btn):not(.ribbon a) { color: #4a5450; text-decoration: none; font-size: .875rem; font-weight: 500; }
#site-header a:not(.nav-cta):not(.cta-btn):not(.ribbon a):hover { color: #0f1310; }
#site-header ul { list-style: none; margin: 0; padding: 0; display: flex; gap: 1.25rem; flex-wrap: wrap; }
#site-header strong { color: #0f1310; font-size: 1.25rem; }

/* rxg-fix:ribbon-band
 * ⛔ THE HEADER IS NOT ONE GROUND. #site-header is cream (#faf6ef), but it CONTAINS .ribbon, a dark
 *   band painted var(--ink-900) = #0f1310. The rule `#site-header a{color:#4a5450}` above was
 *   measured against the cream and then applied to every link in the header, including the ones
 *   sitting on that dark band: contrast 2.39.
 *   ⭐ I SCOPED BY CONTAINER WHEN THE THING THAT MATTERS IS THE GROUND. A container is only a valid
 *     scope for a colour if it paints exactly one background, and this one paints two.
 *
 * ⛔ AND .ribbon strong RENDERED #0f1310 ON #0f1310, INVISIBLE. `.ribbon strong{color:#fff}` lives
 *   in overhaul-v3.css, which /sponsored never loads while using its markup, so the strong fell
 *   through to the page's dark ink. .ribbon is dark by definition, so these belong here in the
 *   shared chrome rather than in a stylesheet each page has to remember to load.
 *   Measured on #0f1310: #c7cdc9 = 11.60, #ffffff = 18.73, #9aa39d = 7.23, #7f8a84 = 5.24.
 */
#site-header .ribbon, .ribbon { background: #0f1310; color: #c7cdc9; }
#site-header .ribbon a, .ribbon a { color: #c7cdc9; }
#site-header .ribbon a:hover, .ribbon a:hover { color: #ffffff; }
#site-header .ribbon strong, .ribbon strong { color: #ffffff; font-weight: 600; }
#site-header .ribbon .sep, .ribbon .sep { color: #7f8a84; }
#site-header .ribbon .right, .ribbon .right { color: #9aa39d; }

/* rxg-fix:dark-chrome
 * ⛔ The cream `#site-header{background:#faf6ef}` above is correct for the article pages and wrong
 *   for the tool pages, whose body is #0b1310. The visible result was a cream strip in the gutters
 *   with the nav's own translucent dark gradient floating in the middle of it.
 * ⭐ A SHARED STYLESHEET MUST NOT ASSUME A GROUND. Pages declare their own via .chrome-dark on
 *   <body> (see _scripts/mark-dark-chrome.mjs), so the chrome follows the page instead of the page
 *   having to fight the chrome.
 *   Measured on #0b1310: #c7cdc9 = 11.66, #ffffff = 18.84, #93a096 = 6.92. All clear AA.
 */
body.chrome-dark #site-header { background: #0b1310; border-bottom-color: #1e2a24; }
body.chrome-dark #site-header a:not(.nav-cta):not(.cta-btn) { color: #c7cdc9; }
body.chrome-dark #site-header a:not(.nav-cta):not(.cta-btn):hover { color: #ffffff; }
body.chrome-dark #site-header strong { color: #ffffff; }

/* rxg-fix:embed-offer-width
 * ⛔ #lattice-embed-offer had no width constraint, so its heading, prose and code block ran the full
 *   1855px while the page's content column is 760px. The band is meant to be full-bleed; its
 *   CONTENTS are not. */
#lattice-embed-offer > * { max-width: 1080px; margin-left: auto; margin-right: auto; }

/* rxg-fix:embed-offer-centring
 * ⛔ THE RULE ABOVE APPLIED AND STILL DID NOTHING. `max-width` clamped the boxes to 1080px, so the
 *   width looked right and the section read as fixed — but the heading and both paragraphs stayed
 *   hard left at x=25 while the code block alone centred at x=413. Measured live, not inferred:
 *   the h2 computed `margin-left: 0px` even though this sheet asks for `auto`.
 *   ⭐ THE CAUSE IS NOT SPECIFICITY BETWEEN SELECTORS. build-embed-licence-surface.mjs emits the
 *     children with INLINE `style="margin:0 0 .5rem"`, and the margin SHORTHAND resets margin-left
 *     and margin-right to 0. An inline declaration outranks every selector, so no amount of
 *     selector weight in this file could ever have won. The code block centres only because its
 *     inline style happens to set `margin-bottom` alone, leaving the auto margins standing —
 *     which is exactly why the defect looked partial and therefore looked like a width bug.
 *   ⛔ FALSIFIED FIRST: `width:100%` was the obvious reading (auto margins are inert against an
 *     auto width) and it changed nothing when canaried on the live page. Shipping it would have
 *     been a third no-op shipped as a fix.
 *   ⭐ SCOPED, NOT PUSHED TO THE GENERATOR. 58 pages across 13 properties carry this same emitted
 *     markup, but on the other 12 the section sits INSIDE the article column, where the auto
 *     margins are moot and nothing is misaligned. The defect exists only where the section is
 *     body-level and full-bleed, which is here. A generator change would churn 13 properties to
 *     repair 3 pages — the same overreach as substituting a hex that serves two grounds.
 *   `!important` is the correct instrument here and only here: the competing declaration is inline,
 *   and the markup emitting it is shared with properties that must not change. */
#lattice-embed-offer > * { margin-inline: auto !important; }

/* rxg-fix:save-controls-column
 * ⛔ #lattice-save-controls is injected by lattice-saved-state.js as a direct child of <body>, so it
 *   spanned the full 1905px while every neighbour sits in a 600-1080px centred column. Once the
 *   mount was corrected to land above the footer it became the only full-bleed element in that run.
 *   ⭐ THE SAME HALF-FIX TRAP AS THE EMBED OFFER, CAUGHT BY CANARY THIS TIME. The obvious rule,
 *     `#lattice-save-controls{max-width:1080px;margin-inline:auto}`, was measured on the live page
 *     first: max-width applied (1905 -> 1080) and the bar STAYED AT x=0. That component ships its
 *     own <style> inside its innerHTML, which lands later in the document at identical specificity,
 *     so its `margin:16px 0` shorthand won and zeroed the inline margins. The box would have looked
 *     resized and stayed left-aligned - fixed-looking, still wrong.
 *   `body #...` (1,0,1) outranks the component's own (1,0,0) rule and centres at x=413, matching the
 *   footer's inner column exactly. Verified live before shipping, not inferred from the cascade. */
body #lattice-save-controls { max-width: 1080px; margin-inline: auto; }

/* rxg-fix:footer-links-layout
 * ⛔ THE ORIGINAL DEFECT, ONE LEVEL DOWN. This stylesheet was written because engine-injected chrome
 *   was landing on pages that load no property CSS. It ported the COLOURS (`.footer-links a`) and
 *   never the LAYOUT (`.footer-links` itself), so on those pages the footer nav rendered as a bare
 *   vertical block: 9 links on 9 separate lines, 194px tall, where the component is `display:flex`
 *   on every other page in the network.
 *   ⭐ THE PAGE AUDITED 0 CONTRAST FAILURES OF 111 MEASURED WHILE LOOKING LIKE THIS. The contrast
 *     instrument cannot see layout, so a perfect score on it says nothing about whether the page
 *     renders correctly - the score was true and the page was still visibly wrong. Eyes-on is what
 *     caught this, which is exactly why that standard is not droppable.
 *   ⭐ ZERO SPECIFICITY ON PURPOSE. `:where()` gives this rule 0,0,0, so it applies ONLY where
 *     nothing else styles the component - a genuine fallback for the unstyled-chrome case. Several
 *     rxgrab pages define `.footer-links` themselves with their own gap, and an ordinary
 *     `#site-footer .footer-links` rule (1,1,0) would have silently overridden all of them to fix
 *     pages that were never broken. Canaried both directions on the live page: the fallback takes
 *     effect here (9 rows -> 1), and a competing author rule at ordinary specificity still wins. */
:where(#site-footer) :where(.footer-links) {
  list-style: none; display: flex; flex-wrap: wrap; gap: 1.5rem; padding: 0;
}

/* rxg-fix:footer-nav-ground
 * ⛔ THE RIBBON BUG, MIRRORED. #site-footer is correctly dark (#0a0d0b), but on some pages it
 *   contains a stale static-nav block painting rgba(250,246,239,.94) — a near-opaque CREAM band
 *   inside the dark footer. `#site-footer a{color:#c7cdc9}`, measured against the dark ground,
 *   then rendered on cream at 1.32 for every footer link on that page.
 *   ⭐ THIRD CONTAINER TODAY THAT PAINTS TWO GROUNDS (cream header holding a dark ribbon, dark page
 *     holding a light partner card, and now a dark footer holding a cream nav). The recurring error
 *     is not any one hex; it is treating a CONTAINER as if it were a GROUND. A footer nav has no
 *     business painting its own background over the footer, so it is cleared here rather than
 *     recolouring the links to match an artifact. */
#site-footer nav { background: transparent; }