/**
 * Base element styles and reset.
 */

/**
 * Manrope for display, Source Sans 3 for body — the family typefaces,
 * self-hosted.
 *
 * Self-hosted rather than loaded from a font CDN: no visitor IP leaves the
 * site to a third party, one fewer request in the critical path, and no
 * external service can restyle a healthcare site during an outage.
 *
 * Latin subset, WOFF2 only. Every browser that matters has supported WOFF2
 * since 2016, so a second format would be dead weight in every page load.
 *
 * font-display: swap paints immediately in the fallback and swaps when the
 * webfont arrives. On a medical site, text a visitor can read now beats text
 * in the right typeface a moment later.
 *
 * THREE FILES FOR TWO FACES, and the arithmetic is worth stating because it
 * is not obvious. Both families are VARIABLE, so a single file carries the
 * entire weight axis — which is why there is no separate 500/700/800. But a
 * weight axis does NOT carry italic: slant is a different axis, served as a
 * different face. Source Sans 3 therefore needs an upright AND an italic.
 * Manrope ships upright only, and nothing sets headings in italic.
 *
 * 69 KB for every weight and both slants, against the five static files this
 * replaces.
 *
 * ⚠️ THE ITALIC IS NOT OPTIONAL POLISH. Without it a browser synthesises one
 * by shearing the upright — mechanically slanted letterforms instead of the
 * different shapes a true italic draws. Fourteen El Mirage content pages use
 * emphasis, so this is live body text on the site, not a hypothetical.
 *
 * Licence: SIL Open Font License 1.1 for both families. assets/fonts/OFL.txt
 * carries every copyright notice and must travel with these files — clause 2
 * of the licence requires it.
 */
@font-face {
	font-family: "Manrope";
	font-style: normal;
	font-weight: 200 800;
	font-display: swap;
	src: url("../fonts/manrope-v20-latin-variable.woff2") format("woff2");
}

@font-face {
	font-family: "Source Sans 3";
	font-style: normal;
	font-weight: 200 900;
	font-display: swap;
	src: url("../fonts/source-sans-3-v19-latin-variable.woff2") format("woff2");
}

@font-face {
	font-family: "Source Sans 3";
	font-style: italic;
	font-weight: 200 900;
	font-display: swap;
	src: url("../fonts/source-sans-3-v19-latin-italic-variable.woff2") format("woff2");
}

*,
*::before,
*::after {
	box-sizing: border-box;
}

html {
	-webkit-text-size-adjust: 100%;
	scroll-behavior: smooth;
}

@media (prefers-reduced-motion: reduce) {
	html {
		scroll-behavior: auto;
	}

	*,
	*::before,
	*::after {
		animation-duration: 0.01ms !important;
		animation-iteration-count: 1 !important;
		transition-duration: 0.01ms !important;
	}
}

body {
	margin: 0;
	background: var(--ih-surface);
	color: var(--ih-text);
	font-family: var(--ih-font-sans);
	font-size: var(--ih-text-base);
	line-height: var(--ih-leading-normal);
	-webkit-font-smoothing: antialiased;
	text-rendering: optimizeLegibility;

	/*
	 * 🔴 NO WORD-BREAKING PROPERTY EXISTED ANYWHERE IN THIS THEME — zero
	 * occurrences of `overflow-wrap`, `word-break`, `word-wrap` or `hyphens`
	 * across every stylesheet, in core and in both child themes. So a token
	 * longer than its column could not break, and simply spilled out of it.
	 *
	 * **The Sources section on every article prints bare URLs as visible link
	 * text**, which is the sources model working as intended — a reader can
	 * check a citation without hovering. It also produces the longest
	 * unbreakable tokens on the site. Measured against a 320px viewport, which
	 * is the width WCAG reflow (1.4.10) is written against:
	 *
	 *   100% text   a 36-character URL needs 291px, 288px available   +3
	 *   200% text   the same URL needs 582px, 256px available        +326
	 *               plus a 23-character URL (+95) and two long words
	 *
	 * So it already overflows at ordinary text size, by a hair, on the
	 * narrowest supported screen — and catastrophically for anyone who has
	 * enlarged text.
	 *
	 * `break-word` rather than `anywhere`: it breaks a token ONLY when that
	 * token would otherwise overflow, so ordinary prose at ordinary widths is
	 * untouched and nothing about desktop typography changes. `anywhere` also
	 * shrinks min-content width, which would let flex and grid columns collapse
	 * further than intended — a side effect nobody asked for.
	 *
	 * Inherited from `body` on purpose. The alternative is a list of
	 * containers, and this project has now shipped the
	 * fix-the-place-instead-of-the-thing mistake three times in one night: the
	 * footer button, the header button, and the ghost button on tint. A list of
	 * places is a list somebody has to keep.
	 *
	 * Found because the mercy-grace-rebuild session hit the same absence on
	 * their own site and checked ours rather than assuming it differed.
	 */
	overflow-wrap: break-word;
}

h1,
h2,
h3,
h4 {
	margin: 0 0 var(--ih-space-4);
	font-family: var(--ih-font-display);

	/*
	 * --ih-weight-display (800), not --ih-weight-bold (700). The handoff sets
	 * headings in Manrope 800, and on Manrope that difference is visible
	 * rather than subtle — at 700 a heading reads as body text that happens
	 * to be large.
	 *
	 * A token rather than a literal: it is the same KIND of decision
	 * --ih-weight-bold represents, made once for display type, so a site that
	 * ever wants a lighter masthead changes one value instead of hunting
	 * rules.
	 */
	font-weight: var(--ih-weight-display);

	/*
	 * Negative tracking on display type, from the handoff (-0.015 to
	 * -0.02em). Large type at default tracking reads loose; this is the
	 * standard optical correction. Headings only — tightening body copy costs
	 * legibility, which is why it lives here and not on `html`.
	 */
	letter-spacing: -0.018em;

	line-height: var(--ih-leading-tight);
	color: var(--ih-ink);
	/* Prevent a single trailing word on a line in a headline */
	text-wrap: balance;

	/*
	 * `hyphens: auto` so a long word in a headline breaks at a syllable with a
	 * hyphen, rather than mid-syllable under `overflow-wrap` or not at all.
	 *
	 * The measured case: at 200% text on a 320px screen the homepage `h1`
	 * renders at 68px, and "freestanding" alone needs 380px against 256px of
	 * content width. "Emergency" in an `h2` needs 283px. Both fit comfortably
	 * at normal text size — the type scale is fluid and drops the `h1` to 34px
	 * at that width — so this is specifically the enlarged-text case.
	 *
	 * ⚠️ MEASURED AT THE RIGHT FONT SIZE ON THE SECOND ATTEMPT. My first pass
	 * measured these words at the sizes they take on a 1263px screen — 54px
	 * and 63px — and reported a breach at 100% text that does not exist. The
	 * scale is `clamp(2.125rem, 1.7rem + 2.1vw, 3.5rem)`, so the viewport is
	 * part of the answer and a word measured at the wrong size is just a wrong
	 * number. Recomputed by evaluating the clamp for a 320px viewport at both
	 * root sizes.
	 *
	 * Requires a `lang` attribute to hyphenate, and `<html lang="en-US">` is
	 * already emitted by WordPress. Nothing happens at widths where headings
	 * fit, which is every desktop.
	 */
	hyphens: auto;
}

h1 { font-size: var(--ih-text-3xl); }
h2 { font-size: var(--ih-text-2xl); }
h3 { font-size: var(--ih-text-xl); }
h4 { font-size: var(--ih-text-lg); }

p {
	margin: 0 0 var(--ih-space-4);
	text-wrap: pretty;
}

/*
 * 🔴 THE MEASURE MOVED FROM THE ELEMENTS TO THE BLOCK, and this was the
 * "misaligned and kinda disorganized" the client reported on the interior
 * pages.
 *
 * It used to read:
 *
 *     .entry-content p,
 *     .entry-content li { max-width: 68ch; }
 *
 * The intent was right — long-form medical text needs a reading measure. The
 * placement was not. Capping only `p` and `li` inside a 760px
 * `.container--narrow` means **paragraphs end at about 544px while headings,
 * tables, blockquotes and horizontal rules run the full 760px.** Every
 * heading overhangs every paragraph beneath it by roughly 200 pixels.
 *
 * Nothing is broken and nothing is off-grid, so it reads as carelessness
 * rather than as a bug: the eye sees two different right-hand edges alternating
 * down a page of a medical site.
 *
 * One measure on the container fixes it, because then every child shares both
 * edges. `margin-inline: auto` centres the block inside the wider container so
 * the leftover space is symmetrical instead of all on the right.
 */
/*
 * 🔴 THE MEASURE MOVED AGAIN — from the block to its CHILDREN — on the
 * client's 2026-09-13 report, with his old site and HonorHealth attached as
 * the standard: *"There are too many white real estate on the site and the
 * pages seem too compressed to the middle… all the other pages on that
 * staging site is squeezed into the middle."*
 *
 * He is right, and the history of this rule explains how it happened. The
 * measure started on `p`/`li` only, which gave the interior pages two ragged
 * text edges and got reported as "misaligned and kinda disorganized". The fix
 * put ONE measure on the whole `.entry-content` block — which repaired the
 * edges and quietly sentenced every VISUAL to the same 70ch column. Card
 * grids, photographs, tables, the map: all of it rendered at paragraph width
 * inside a template that had also wrapped the page in `container--narrow`.
 * Squeezed twice, then presented on a 1500px screen.
 *
 * So: the templates now use the full container, EVERY direct child defaults
 * to the centred 70ch measure — headings included, which is the lesson the
 * first version paid for — and the named VISUAL components opt out to span
 * the container, exactly as their homepage originals do.
 *
 * ⚠️ Text keeps ONE edge; visuals keep ANOTHER (the container's). Those are
 * two different edges by design and it is not the old misalignment: the old
 * defect was two competing TEXT edges. An image wider than the prose is
 * rhythm; a heading wider than its paragraph is carelessness.
 */
.entry-content {
	max-width: none;
}

/*
 * 🔴 THE PER-CHILD MEASURE IS GONE, 2026-09-14, on the client's instruction:
 * *"render it exactly as the handoff packet asked."*
 *
 * The packet is explicit — "Never artificially narrow headings or paragraphs
 * (no ch-based max-widths — text uses container width)" — and it achieves
 * reading comfort a different way: by narrowing the CONTAINER per page type.
 * 1180px for marketing pages, 980px for the FAQ, 880px for an article. Text
 * then fills whatever container it is in.
 *
 * ⚠️ I ARGUED FOR KEEPING THE MEASURE AND THE RENDERED PAGE SETTLED IT.
 * The reasoning was sound in the abstract: a 1180px line of 17px text runs
 * past 140 characters and comfortable reading is 45-75. But side by side with
 * the prototype, the measured version is visibly the narrow centred column
 * with wide empty margins that the client reported in the first place —
 * *"too many white real estate… squeezed into the middle"*. The packet's
 * answer addresses the same concern without producing that look, because the
 * long-form pages get a narrow container rather than a narrow column inside a
 * wide one.
 *
 * So the previous note above — the one explaining why the measure sat on the
 * children — describes a stage this file has now passed through: the measure
 * sat on `p`/`li`, then on the whole block, then on every child, and now
 * nowhere. The history above is kept because each move answered something
 * real that had been reported.
 */
.entry-header,
.entry-footer,
article > .post-navigation,
.post-navigation {
	max-width: none;
}

/*
 * Tables span, but a table narrower than the container should sit centred on
 * the text axis rather than hanging off the left edge. `width: 100%` keeps
 * the comparison tables reading-room they were given when this rule was
 * written for the 70ch column.
 */
.entry-content table {
	width: 100%;
}

/*
 * 🔴 THE COMPARISON TABLE PUSHED THE WHOLE PAGE SIDEWAYS ON A SMALL PHONE.
 *
 * Measured on `/er-vs-urgent-care/` by constraining the document to 320px: the
 * three-column table has a **min-content width of 368px**, so it overflowed by
 * 48 — and `.entry-content` is `overflow-x: visible`, which means the table
 * does not scroll inside itself, **it drags the entire page**. Every section
 * below it then sits 48px off, and the reader gets a horizontal scrollbar on a
 * medical page. It fits at 390px, so a modern phone is fine and a small or
 * zoomed one is not.
 *
 * 320px is the floor WCAG 2.2 reflow (1.4.10) is written against, and it is
 * also what a 390px phone becomes at 125% zoom — which is a setting plenty of
 * people who need an emergency room actually use.
 *
 * ⚠️ FIXED BY SHRINKING THE TABLE, NOT BY WRAPPING IT IN A SCROLLER. The
 * general solution is a focusable `overflow-x: auto` container, and it was the
 * first thing I wrote. It needs new markup around every table, a `tabindex`
 * that adds a tab stop even on the tables that fit, and a `role="region"` with
 * an accessible name that would be identical and meaningless on all of them.
 * Three moving parts and worse semantics, for a table that only needs to be
 * 48px narrower.
 *
 * A three-column comparison at `--ih-text-sm` on a phone is still perfectly
 * readable; a page that slides sideways is not. If a future table has longer
 * unbreakable content than this one, `overflow-wrap: anywhere` here is the
 * next step before reaching for the wrapper.
 */
@media (max-width: 480px) {
	.entry-content table {
		font-size: var(--ih-text-sm);
	}

	.entry-content th,
	.entry-content td {
		padding: var(--ih-space-2);

		/*
		 * The escalation the comment above this block promised. The
		 * comparison table fit 320px when the font/padding fix landed, then
		 * a later COPY EDIT grew a cell's longest unbreakable run and it
		 * overflowed by 6px — re-measured 2026-09-13 with the wp-admin bar
		 * excluded, because the first reading blamed the bar. A table's
		 * min-content tracks its words, so any fixed-size fix decays with
		 * editing; letting the longest word break is the one that does not.
		 * Scoped to this narrow-viewport block — at readable widths a mid-
		 * word break is worse than the problem.
		 */
		overflow-wrap: anywhere;
	}
}

a {
	color: var(--ih-accent);
	text-decoration-thickness: 1px;
	text-underline-offset: 0.15em;
	transition: color var(--ih-duration) var(--ih-ease);
}

a:hover,
a:focus-visible {
	color: var(--ih-accent-hover);
}

/**
 * Visible focus on every interactive element.
 *
 * Do not replace this with `outline: none`. Keyboard and switch-device users
 * cannot navigate the site without it.
 */
:focus-visible {
	outline: var(--ih-focus-width) solid var(--ih-focus);
	outline-offset: 2px;
	border-radius: var(--ih-radius-sm);
}

img,
picture,
svg,
video {
	display: block;
	max-width: 100%;
	height: auto;
}

svg {
	fill: currentColor;
}

/*
 * 🔴 20 OF THE 26 ICONS ARE LINE DRAWINGS AND EVERY ONE OF THEM WAS
 * RENDERING AS A SOLID SILHOUETTE. FAMILY-WIDE, EVERYWHERE, INCLUDING THE
 * HOMEPAGE.
 *
 * **A CSS declaration beats a presentation attribute.** Every line-work icon
 * carries `fill="none" stroke="currentColor"` on its root, which is exactly
 * right — and presentation attributes sit at the very bottom of the cascade,
 * below author CSS, so the `svg { fill: currentColor }` above silently
 * overrode all twenty. The strokes still painted, so the shapes were the
 * right shapes: a shield, a receipt, a doctor's bag, each flooded solid
 * white. At 22px in a badge they read as indistinguishable blobs.
 *
 * The client had just told me these pages were *"very underwhelming"* and
 * that *"nothing there makes me want to stop and read"*. This is part of why.
 * Found by zooming into a rendered badge — **the DOM said `fill="none"` and
 * the pixels said otherwise**, which no gate in the set can compare.
 *
 * The six brand marks (facebook, instagram, linkedin, pinterest, x, youtube)
 * are genuinely solid and carry no `fill="none"`, so they still want
 * `currentColor` and are untouched. That is why the guard keys on the
 * attribute rather than on a class: the attribute is already the truth about
 * which kind of icon this is, and a class would be a second list to keep in
 * step with the first.
 *
 * ⚠️ `[fill="none"]` is specificity (0,1,0) against `svg`'s (0,0,1), so it
 * wins. It has to be a real selector rather than `!important` on the rule
 * above, because a child theme with its own solid icon set must still be able
 * to override this.
 */
svg[fill="none"] {
	fill: none;
}

ul,
ol {
	padding-inline-start: var(--ih-space-5);
}

/*
 * Vertical rhythm between list items in prose.
 *
 * ⚠️ THIS LEAKS INTO EVERY HORIZONTAL LIST, AND IT HAS NOW CAUSED A DEFECT THE
 * CLIENT REPORTED. A list laid out as a flex row still matches `li + li`, so
 * items two onwards carry an 8px top margin — which under `align-items: center`
 * shifts them down by 4px and under the default alignment by the full 8.
 *
 * That was the cause of *"the social media bubbles at the top are
 * misaligned"*: five circles, identical sizes, on two different baselines.
 *
 * `.primary-nav__list li { margin: 0 }` already existed, which means the trap
 * had been hit and patched once before without being written down — so the next
 * horizontal list, `.social-links`, walked into it. **A fix applied in one
 * place and not named is a fix the next person cannot find.**
 *
 * The rule itself is correct and stays: a bulleted list in an article wants
 * breathing room. **Any list laid out as a row must zero it**, and
 * `components.css` now does that for all of them in one place rather than one
 * at a time.
 */
li + li {
	margin-top: var(--ih-space-2);
}

blockquote {
	margin: var(--ih-space-6) 0;
	padding: var(--ih-space-4) var(--ih-space-5);
	border-inline-start: 4px solid var(--ih-brand);
	background: var(--ih-surface-alt);
	font-size: var(--ih-text-lg);
}

hr {
	margin: var(--ih-space-7) 0;
	border: 0;
	border-top: 1px solid var(--ih-border);
}

table {
	width: 100%;
	border-collapse: collapse;
	margin-bottom: var(--ih-space-5);
}

th,
td {
	padding: var(--ih-space-3);
	border-bottom: 1px solid var(--ih-border);
	text-align: start;
}

/*
 * The header row takes the red tint, from the handoff.
 *
 * It was `--ih-surface-alt`, which since the re-theme is the #FDFCFB ground —
 * a two-point luminance step from the white card it sits on, and effectively
 * invisible. The tint separates the header from the body without a rule,
 * which matters most on the ER-versus-urgent-care comparison: eight rows where
 * the reader has to keep track of which column they are in.
 *
 * --ih-ink on the tint measures 12.34:1, so the header text is unaffected.
 */
th {
	font-weight: var(--ih-weight-bold);
	background: var(--ih-brand-tint);
}

code,
pre {
	font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
	font-size: 0.9em;
}

/* Screen-reader-only text that becomes visible on focus (skip link) */
.screen-reader-text {
	position: absolute !important;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip-path: inset(50%);
	white-space: nowrap;
	border: 0;
}

.skip-link:focus {
	position: fixed !important;
	top: var(--ih-space-2);
	left: var(--ih-space-2);
	z-index: 999;
	width: auto;
	height: auto;
	padding: var(--ih-space-3) var(--ih-space-4);
	margin: 0;
	clip-path: none;
	background: var(--ih-white);
	color: var(--ih-ink);
	font-weight: var(--ih-weight-bold);
	box-shadow: var(--ih-shadow);
	border-radius: var(--ih-radius);
}

/* Honour Windows High Contrast / forced-colors mode */
@media (forced-colors: active) {
	.btn {
		border: 1px solid ButtonText;
	}
}