/**
 * Cookie notice banner and the two form notes.
 *
 * EVERY RULE HERE IS PALETTE-FREE, the same contract `forms.css` keeps and for
 * the same reason: `docs/deployment/wp-integration.md` forbids inline colours
 * in member-facing plugin markup, because an inline hex cannot be overridden
 * by a theme stylesheet and so silently wins on every install. A Test Runner
 * row fails on any hex in this file.
 *
 * ⚠⚠ **A FIXED BANNER IS THE ONE CASE WHERE "ASSERT NO COLOUR AT ALL" IS NOT
 * ENOUGH.** `forms.css` can get away with `color: inherit` because its forms
 * sit INSIDE the page, on the page's own background. This banner is lifted out
 * of the flow and laid over whatever is beneath it, so with no background it is
 * the page's own ink over the page's own content — illegible, which is the
 * referral panel's 2026-09 failure and the contact form's 2026-10 failure
 * arriving a third way.
 *
 * So the background comes from the THEME'S OWN TOKENS rather than from a hex:
 * `var(--rr-ground)` and `var(--rr-ink)` are the custom properties the
 * RetireRange theme defines on `:root` (`retirerange-theme/assets/css/
 * tokens.css`, enqueued as `retirerange-tokens` on every page). Naming a token
 * is not naming a colour — the theme still owns the value, and can change it
 * without touching this file, which is exactly what the contract asks for.
 * **This is therefore NOT a theme hand-off**: no new class needs styling, so
 * there is no row to append to `retirerange-theme/ROADMAP.md`.
 *
 * Each token carries a CSS-wide system colour as its `var()` fallback —
 * `Canvas` and `CanvasText` — for an install whose theme does not define the
 * tokens (plain Astra, say). Those are not a palette either: the browser
 * resolves them from the user's own light/dark preference, so the banner stays
 * legible rather than inheriting a transparent background. A hardcoded white or
 * near-black fallback would have been the banned thing.
 *
 * The OK button carries the theme's own `rr-btn rr-btn--primary`, so it gets
 * the site's green without this file mentioning green. Nothing here styles it.
 */

.rc-cookie-notice {
	position: fixed;
	inset-inline: 0;
	bottom: 0;
	z-index: 9999;
	background: var(--rr-ground, Canvas);
	color: var(--rr-ink, CanvasText);
	border-top: 1px solid var(--rr-line, currentColor);
	padding: 12px clamp(16px, 4vw, 32px);
	box-sizing: border-box;
	font-size: 0.9375rem;
	line-height: 1.5;
}

.rc-cookie-notice[hidden] {
	display: none;
}

.rc-cookie-notice__inner {
	display: flex;
	align-items: center;
	justify-content: center;
	flex-wrap: wrap;
	gap: 10px 20px;
	margin: 0 auto;
	max-width: var(--rr-max, 1200px);
}

.rc-cookie-notice__text {
	margin: 0;
	flex: 1 1 24em;
	min-width: 0;
}

/**
 * ⚠⚠ **THE LINK NEEDS ITS OWN RULE, AND THIS WAS FOUND BY LOOKING AT THE
 * RENDERED BANNER — every unit assertion passed with it broken.**
 *
 * The RetireRange theme styles NO bare `a`: every anchor rule it has is scoped
 * to a component class (`.rr-footer__list a`, `.rr-page .rc-cta a`, and so on).
 * This banner is appended at `wp_footer`, OUTSIDE every one of those
 * containers, so its link fell through to Astra's default blue — the theme's
 * own comment at `site.css` calls that out — which on this near-black ground is
 * the referral panel's 2026-09 bug and the contact form's 2026-10 bug arriving
 * a third way.
 *
 * `inherit` is the right answer rather than a token: it takes the banner's own
 * ink, which is set two rules above from the same token pair as the background,
 * so the link cannot fail to contrast with the surface it is printed on
 * whatever the theme sets those to. The underline is what keeps it reading as a
 * link once the colour no longer distinguishes it, and hover changes only the
 * underline — still naming no colour.
 */
.rc-cookie-notice a,
.rc-cookie-note a {
	color: inherit;
	text-decoration: underline;
}

.rc-cookie-notice a:hover,
.rc-cookie-notice a:focus,
.rc-cookie-note a:hover,
.rc-cookie-note a:focus {
	text-decoration-thickness: 2px;
}

/* The button must not shrink below its label when the text wraps beside it. */
.rc-cookie-notice__ok {
	flex: 0 0 auto;
}

/**
 * ⚠ The reserved space is what makes "it must not cover the footer disclaimer"
 * true, and it is LAYOUT rather than palette — the one category
 * wp-integration.md allows a plugin to assert. A bottom-fixed banner otherwise
 * sits permanently over the last ~60px of the document, which at phone width
 * is the footer disclaimer, and no amount of scrolling reveals it.
 *
 * The height is measured by the script into `--rc-cookie-notice-height`, so the
 * reservation tracks the banner's real height after the text wraps — two lines
 * at phone width, one on a desktop. The `0px` fallback means a page that never
 * showed the banner reserves nothing.
 */
body.rc-cookie-notice-open {
	padding-bottom: var(--rc-cookie-notice-height, 0px);
}

@media (max-width: 600px) {
	.rc-cookie-notice__inner {
		justify-content: flex-start;
	}

	/* Full-width tap target at phone width, where the row has already
	   wrapped the button onto its own line. */
	.rc-cookie-notice__ok {
		flex: 1 0 100%;
	}
}

/**
 * The line above the submit button on the sign-in and registration forms.
 * Inside the page, so `forms.css`'s rule applies here: assert no colour, and
 * mute with `opacity` rather than naming an ink.
 */
.rc-cookie-note {
	margin: 0 0 12px;
	font-size: 0.875rem;
	line-height: 1.45;
	opacity: 0.85;
}