/* GENERATED by scripts/sync-design.mjs from design/. Do not edit — edit design/. */
/* Consent banner and privacy-choices dialog — styles for design/consent.js.
 *
 * ITS OWN FILE, NOT components.css, BECAUSE THE TWO HOSTS LOAD DIFFERENT STYLESHEETS.
 * www links /assets/styles.css and /assets/components.css. The app links /assets/styles.css,
 * /app.css and /market.css — and NOT components.css. So the first version of this shipped the
 * banner to both hosts and the styles to only one, and the app showed an unstyled full-bleed bar
 * with the buttons jammed against the left edge.
 *
 * Pulling all of components.css into the app would have fixed the symptom and risked a pile of
 * collisions with app.css. One small file, linked by both, is the version that cannot go wrong
 * the same way twice. Both hosts must link it: scripts/lib/layout.mjs for www, and the four
 * hand-written pages in app/.
 */
/* ── Consent banner and privacy-choices dialog ──────────────────────────────────────────────
   Injected by design/consent.js, which ships before any advertising or analytics code because
   the privacy policy promises all three of: a cookie banner, a Do Not Sell control, and
   honouring Global Privacy Control.

   The banner is a BAR, not a modal, and does not trap focus: the corpus is the acquisition
   channel and a reader who arrived from a search should be able to read the record whether or
   not they have answered. The preferences dialog IS modal, because it is a decision the reader
   deliberately opened. */
.consent { position: fixed; inset: auto 0 0 0; z-index: 9998; display: flex; justify-content: center;
  padding: 12px; pointer-events: none; }
.consent .consent-box { pointer-events: auto; width: min(760px, 100%); background: var(--surface);
  border: 1px solid var(--border); border-radius: var(--r-lg, 14px); box-shadow: var(--shadow-xl);
  padding: 16px 18px; display: grid; gap: 12px; }
.consent-text { margin: 0; font-size: 13.5px; line-height: 1.55; color: var(--text); }
.consent-note { color: var(--text-muted); font-size: 12.5px; }
.consent-h { margin: 0; font-size: 17px; font-weight: 800; line-height: 1.25; }
.consent-row { display: grid; grid-template-columns: 18px 1fr; gap: 10px; align-items: start;
  font-size: 13.5px; line-height: 1.5; color: var(--text); cursor: pointer; }
.consent-row input { width: 18px; height: 18px; margin: 1px 0 0; accent-color: var(--accent);
  cursor: pointer; }
.consent-row input:disabled { cursor: not-allowed; opacity: .55; }

/* EQUAL PROMINENCE, DELIBERATELY. A prominent Accept beside a quiet Reject is the commonest way a
   banner is held to have collected no consent at all, so both buttons are the same size and sit
   on the same row, and Reject comes first in the source order. */
.consent-actions { display: flex; flex-wrap: wrap; gap: 8px; }
/* BOTH BUTTONS ARE DEFINED HERE, NOT INHERITED, and that is the whole point of the file — see the
   header. `.btn` and `.btn-primary` are not in components.css and not in site.css: www inlines them
   in the layout head and the app shell defines them in app.css, so the four hand-written pages in
   app/ and every partner screen have no definition for either. Styling one button and inheriting
   the other is how the prominence rule above gets broken by accident, in both directions. It has
   now happened twice: Reject fell back to UA grey beside a themed Accept, and the fix for that
   turned app/signin.html and app/signup.html the other way up, where Accept was the UA-grey one.

   flex-basis 0, NOT auto. With `auto` the two buttons grow from their own text widths and finish
   at different sizes — 351px against 286px on the app, which is exactly the unequal prominence
   this is supposed to avoid. A zero basis makes the share identical whatever the labels say, so
   the guarantee survives someone rewording a button later. */
.consent-actions .btn { flex: 1 1 0; min-width: 150px; min-height: 38px; padding: 0 14px;
  display: inline-flex; align-items: center; justify-content: center; text-align: center;
  border: 1px solid transparent; border-radius: var(--radius-sm); cursor: pointer;
  font: inherit; font-size: 13.5px; font-weight: var(--weight-bold); }
.consent-actions .btn-primary {
  background: var(--accent); border-color: var(--accent); color: var(--on-accent);
}
.consent-actions .btn-primary:hover { background: var(--accent-hover); border-color: var(--accent-hover); }
/* Equal weight, not equal styling: Accept is the filled one, Reject the outlined one, same size and
   same row.
   --text-subtle for the border and NOT --border-strong: the consent box is --surface and so is
   this button, so the border is the only thing that makes the control a control. --border-strong
   is 1.64:1 against it, which fails WCAG 1.4.11's 3:1 for a boundary you need in order to see the
   thing. --text-subtle is 3.69:1. Elsewhere --border-strong is fine because the surfaces differ. */
.consent-actions .btn:not(.btn-primary) {
  background: var(--surface); color: var(--text); border-color: var(--text-subtle);
}
.consent-actions .btn:not(.btn-primary):hover { background: var(--surface-hover); }

/* The dialog covers the page; the bar does not. */
.consent-prefs { inset: 0; align-items: center; padding: 24px; background: var(--scrim);
  pointer-events: auto; }
.consent-prefs .consent-box { width: min(520px, 100%); padding: 22px; gap: 14px;
  max-height: 90vh; overflow-y: auto; }

/* Below the wrap point they stack, and a stacked pair is equal by construction. */
@media (max-width: 560px) {
  .consent { padding: 8px; }
  .consent .consent-box { padding: 14px; }
  .consent-actions .btn { flex: 1 1 100%; }
}