* {
	box-sizing: border-box;
}
body {
	margin: 0;
	background: var(--rdm-white);
	font-family: var(--rdm-font-sans);
	color: var(--rdm-ink-900);
	line-height: 1.6;
	overflow-x: clip;
}
a {
	text-decoration: none;
	color: var(--rdm-blue-600);
}
a:hover {
	color: var(--rdm-navy-800);
}
a:focus-visible,
button:focus-visible,
input:focus-visible,
[tabindex]:focus-visible {
	outline: 3px solid var(--rdm-gold-500);
	outline-offset: 3px;
	border-radius: 4px;
}
::selection {
	background: var(--rdm-gold-500);
	color: var(--rdm-gold-ink);
}
html {
	scroll-behavior: smooth;
	scroll-padding-top: 84px;
}
@media (prefers-reduced-motion: reduce) {
	* {
		animation-duration: .01ms !important;
		transition-duration: .01ms !important;
		scroll-behavior: auto !important;
	}
}

/*
 * Core's edit-post "classic" editor bundle (wp-includes/css/dist/edit-post/
 * classic.css) sets a blanket 840px cap via `html :where(.wp-block)`.
 * theme.json's contentSize/wideSize never touches this rule (it only
 * generates layout CSS for blocks that opt into `supports.layout`, which our
 * full-bleed section blocks don't use). The `html` element prefix gives this
 * rule specificity (0,0,1) despite the zero-specificity :where() — a bare
 * `:where(.wp-block)` override loses to it. Match the `html` prefix so our
 * override actually wins on source order, no !important needed.
 */
html :where(.wp-block) {
	max-width: none;
}