/*
 * Consent banner theme override for vanilla-cookieconsent 3.1.0.
 *
 * Ships byte-identical in both repos: frontend/src/consent/cookieconsent-theme.css
 * and elevate-site/assets/css/cookieconsent-theme.css. Loaded after the
 * library's own dist/cookieconsent.css so these overrides win.
 *
 * Mapped from the real tokens in elevate.css (:root block) - no invented
 * colours. Every --cc-* name below was diffed against the installed
 * node_modules/vanilla-cookieconsent/dist/cookieconsent.css for 3.1.0 (see
 * 88-06-SUMMARY.md for the diff). Two names in 88-UI-SPEC.md's original block
 * do not exist in that dist and were corrected here, values unchanged:
 *   --cc-text            -> --cc-primary-color   (body/heading text colour;
 *                            #cc-main sets `color: var(--cc-primary-color)`
 *                            as its own base rule)
 *   --cc-secondary-text   -> --cc-secondary-color (category descriptions;
 *                            .cm__desc/.pm__section-desc-wrapper both read
 *                            var(--cc-secondary-color) in the dist file)
 * All 17 other property names below matched the dist file byte-for-byte on
 * first attempt. No property is unmapped/dropped in this pass.
 *
 * DO NOT convert these literal oklch(...) values to var(--denim-deep),
 * var(--orange) etc. The marketing site renders through TWO shells -
 * shell.html and shell-attend.html - and the four /attend/{bristol,chester,
 * derby,essex}/ pages load attend.css, which redefines the SAME token names
 * with inverted values (an NHS-branded light theme reusing the marketing
 * vocabulary). Referencing var(--orange) here would resolve to NHS blue on
 * those four pages and silently break contrast there while looking correct
 * on the other fifteen. See 88-UI-SPEC.md "DO NOT convert these literal
 * values to var(--token) references" for the full measured comparison.
 */
:root {
  --cc-font-family: 'Figtree', system-ui, sans-serif;
  --cc-bg: oklch(0.18 0.035 240); /* --denim-deep: same surface as .site-footer */
  --cc-primary-color: oklch(0.96 0.006 240); /* --text-1: banner/modal body text */
  --cc-secondary-color: oklch(0.72 0.02 240); /* --text-2: category descriptions */
  --cc-separator-border-color: oklch(0.33 0.03 240); /* --border */
  --cc-cookie-category-block-bg: oklch(0.3 0.042 240); /* --denim-mid */
  --cc-cookie-category-block-border: oklch(0.33 0.03 240); /* --border */
  --cc-cookie-category-expanded-block-hover-bg: oklch(0.36 0.04 240); /* --denim-raised */

  /*
   * Accept all: --denim-deep ink on --orange fill measures 5.31:1 (AA).
   * Reject all: --text-1 ink on --denim-raised fill measures 9.61:1 (AA).
   * The two buttons deliberately do NOT share an ink colour: --text-1 on
   * --orange measures only 3.15:1 (fails AA for normal text), so "tidy up"
   * by giving both buttons the same text colour would silently drop Accept
   * below AA while leaving Reject fine. Re-measure both ratios (5.31:1 and
   * 9.61:1) before changing either pairing, not just this comment's claim -
   * an unmeasured contrast claim is exactly the failure mode this project's
   * own conventions warn against. 3.15:1 is the number that would result if
   * that tidy-up were made; it must never appear in a shipped colour value.
   */
  --cc-btn-primary-bg: oklch(0.64 0.175 58); /* --orange - Accept all fill, 5.31:1 */
  --cc-btn-primary-color: oklch(0.18 0.035 240); /* --denim-deep - Accept all ink */
  --cc-btn-primary-hover-bg: oklch(0.7 0.16 60); /* --orange-light */
  --cc-btn-secondary-bg: oklch(
    0.36 0.04 240
  ); /* --denim-raised - Reject all fill (solid, not outline) */
  --cc-btn-secondary-color: oklch(0.96 0.006 240); /* --text-1 - Reject all ink, 9.61:1 */
  --cc-btn-secondary-hover-bg: oklch(
    0.4 0.025 240
  ); /* --border-light, close to the .btn-dark hover step */
  --cc-btn-border-radius: 3px; /* matches .btn / .nav-cta radius exactly */

  --cc-toggle-on-bg: oklch(0.64 0.175 58); /* --orange */
  --cc-toggle-off-bg: oklch(0.33 0.03 240); /* --border */
  --cc-toggle-readonly-bg: oklch(0.36 0.04 240); /* the locked "Essential" toggle, --denim-raised */

  --cc-overlay-bg: oklch(0.1 0.03 240 / 0.72); /* matches the hero-grad top-band scrim strength */
  --cc-modal-border-radius: 8px; /* matches --radius-md used site-wide for cards */
}

/*
 * Focus visibility: the marketing site currently has no equivalent
 * :focus-visible rule anywhere (per 88-UI-SPEC.md's "Focus order" section),
 * so this is new behaviour rather than a match to something existing.
 * Scoped to the banner/modal's own controls (#cc-main), the footer reopen
 * control on the marketing site (.footer-cookie-settings, baked into
 * renderFooter) and the reopen pill the React app still injects
 * (.consent-reopen-pill, added by initConsent.js). Uses the literal orange
 * oklch value, not var(--orange), for the same attend.css reason documented
 * above - the focus ring must stay orange on every page, including the four
 * that redefine --orange to NHS blue.
 *
 * Colour/border feedback applies unconditionally (no reduced-motion gate):
 * this rule changes no property that moves an element, only outline colour,
 * so it is exempt from the "gate anything that moves" rule below.
 */
#cc-main a:focus-visible,
#cc-main button:focus-visible,
#cc-main input:focus-visible,
.consent-reopen-pill:focus-visible,
.footer-cookie-settings:focus-visible {
  outline: 2px solid oklch(0.64 0.175 58); /* --orange, literal - see note above */
  outline-offset: 2px;
}

/* ── The reopen pill: a fallback, styled to be found and not noticed ────────
 *
 * WHERE IT APPLIES. Only the React surfaces that have no footer: the host,
 * exhibitor and event dashboards, /login, /reset-password and the two
 * /team/portal/* routes. Every surface with a footer renders
 * CookieSettingsLink instead, and mounting that suppresses this - see the
 * suppression rule at the bottom of this block. The static marketing site
 * stopped injecting it entirely when renderFooter took the job over.
 *
 * WHY IT IS DELIBERATELY QUIET. Withdrawing consent is not what anybody is
 * doing when they arrive, so this must be findable on purpose and invisible
 * the rest of the time. That means: bottom-left rather than bottom-right,
 * away from any primary action; text only, no glyph; 0.75rem; a hairline
 * border and a near-transparent ground rather than a filled button; and
 * secondary text colour, moving to primary only on hover or focus. The
 * previous version had NO appearance rules at all, so it rendered as a
 * default user-agent button in the document flow.
 *
 * COLOURS ARE LITERAL, matching App.js's palette rather than reading it.
 * This element is appended to document.body by initConsent, outside React, so
 * it can never see the MUI theme object. #253746 and #666666 are the light
 * text colours from getTheme; #e0e0e0 and #aaaaaa the dark ones. The dark
 * block is keyed on the data-theme attribute ThemeModeProvider stamps on
 * <html>, NOT on prefers-color-scheme: the app's dark mode is a stored user
 * toggle that defaults to light, so a system-preference query would darken
 * the pill for a visitor whose app is in light mode.
 *
 * The focus ring comes from the rule above and is the one loud thing about it,
 * which is correct: keyboard focus must be obvious even where hover is not.
 *
 * THE GROUND IS OPAQUE, and that is a correctness choice rather than a visual
 * one. It was rgba(...,0.82), which made the text contrast a property of
 * whatever the page put behind it rather than of this component - so it could
 * not be guaranteed on a surface nobody had looked at. Measured on
 * /reset-password the translucent version was fine (backdrop rgb(250,250,250),
 * composite rgb(254), #666 on that is 5.69:1 against the 4.5:1 needed at
 * 12px; dark mode 7.34:1). Opaque anyway: #ffffff over #fafafa is
 * imperceptible, and it makes the ratio a fact about these two declarations
 * instead of a fact about every page that might ever host the pill. */
.consent-reopen-pill {
  position: fixed;
  bottom: 1rem;
  left: 1rem;
  z-index: 2147483645; /* below #cc-main's own layer, above page content */
  appearance: none;
  padding: 0.35rem 0.7rem;
  border: 1px solid rgba(37, 55, 70, 0.18);
  border-radius: 999px;
  background: #ffffff;
  color: #666666;
  font-family: inherit;
  font-size: 0.75rem;
  line-height: 1.4;
  cursor: pointer;
}
.consent-reopen-pill:hover {
  color: #253746;
  border-color: rgba(37, 55, 70, 0.32);
}
:root[data-theme='dark'] .consent-reopen-pill {
  border-color: rgba(224, 224, 224, 0.22);
  background: #1e1e1e;
  color: #aaaaaa;
}
:root[data-theme='dark'] .consent-reopen-pill:hover {
  color: #e0e0e0;
  border-color: rgba(224, 224, 224, 0.38);
}

/* Suppression. Keyed on the marker CookieSettingsLink sets, so no ordering is
 * needed between initConsent (which runs before React mounts) and the footer
 * link (which mounts later). A DOM query at init time would always miss.
 * display:none rather than a DOM removal so it reverses itself the moment the
 * footer link unmounts - navigating from a form to a dashboard brings the pill
 * straight back. */
:root[data-consent-footer-link] .consent-reopen-pill {
  display: none;
}