/*
 * Basic Hero — firsttracks-theme/hero-basic
 *
 * Solid primary-700 band, no media (surface via pattern CSS per the family
 * decision — scheme roles untouched; `.ftm-scheme-primary` resolves to
 * primary-800, and the frames measure primary-700 #0E2E7D exactly).
 *
 * `ftm/page-section` renders a bare `<section>` with no layout support, so the
 * content column's width and position are this file's job — there is no
 * constrained-layout wrapper to inherit from and no starter geometry to reach
 * for (build-knowledge §17).
 *
 * Everything dimensional here was measured off the four frames at a normalised
 * 2x scale (build-knowledge §16). Frame bands, logical px:
 *   desktop 1920x328 · tablet 768x296 · mobile 320x248
 *
 * Breakpoints written at token values (CSS vars are invalid in @media):
 *   48rem = breakpoint/md · 64rem = breakpoint/lg
 *
 * @package tonercable-2026
 */

.tc-hero-basic {
	/* Comp content column: 688px = 43rem, shared across the hero family. */
	--tc-hero-basic-column: 43rem;

	/*
	 * Band padding. Frame ink insets are 40 / 64 / 80 at base / md / lg, which
	 * the block padding reproduces once line boxes are accounted for. 64 is
	 * `xxlarge`; 40 is `xlarge`; 80 has no preset at all (the scale jumps
	 * xxlarge 64 → xxxlarge clamp(48, …, 96) — environment-facts fact 1) and is
	 * the family's documented 5rem hero rhythm, shared with hero-split.
	 */
	padding-block: var( --wp--preset--spacing--xlarge );

	/*
	 * Content column left edge, in one declaration: the wide-size edge once the
	 * viewport allows it — (100% - 1400px) / 2 = 260 at 1920, exactly where all
	 * four frames start their eyebrow bar — floored at the measured gutter, 16
	 * at 320 and 40 at 768. (Not the 22/40 the hero-overlay frames measure at
	 * the same widths: different frames, genuinely different insets.)
	 *
	 * The `100%` is correct HERE and would not be one level up. This element is
	 * a child of the full-aligned <section>, so its containing block is the
	 * section's content box — the full 1920. Put on the section itself the same
	 * percentage resolves against the 1840px constrained wrapper the section
	 * breaks out of, and the column landed at x220 instead of x260. Measured,
	 * both ways, before this comment was written.
	 */
	padding-inline: max(
		var( --wp--style--root--padding-left, 1rem ), /* the page grid: 16 at 320 -> 40 at 768 (QA batch D, V-G1) */
		( 100% - var( --ftps-max-width-wide, var( --wp--style--global--wide-size, 1400px ) ) ) / 2
	);
	background-color: var( --wp--custom--color--primary--700 );
}

.tc-hero-basic .tc-hero-basic__content {
	max-width: var( --tc-hero-basic-column );
}

@media (min-width: 48rem) { /* breakpoint/md */

	.tc-hero-basic {
		padding-block: var( --wp--preset--spacing--xxlarge );
		padding-inline: max(
			var( --wp--preset--spacing--xlarge ),
			( 100% - var( --ftps-max-width-wide, var( --wp--style--global--wide-size, 1400px ) ) ) / 2
		);
	}
}

@media (min-width: 64rem) { /* breakpoint/lg */

	.tc-hero-basic {
		padding-block: 5rem;
	}
}

/*
 * Content colour. `.ftm-scheme-primary` resolves `--color-text` to white on the
 * front end, but nothing forces it down the tree, and the editor canvas renders
 * headings navy-on-blue without this (build-knowledge §17 — the trap that hides
 * from a front-end-only check). Same `:where()` + `:not(.has-text-color)` shape
 * as hero-overlay and hero-split.
 */

.tc-hero-basic,
.tc-hero-basic :where( .wp-block-group, h1, h2, h3, h4, h5, h6, p ):not( .has-text-color ) {
	color: var( --ftps-hero-content-color, var( --wp--custom--color--base--white, #fff ) );
}

/*
 * Heading — the pattern-scoped stand-in for the inert typeStyles block, in the
 * same three parts hero-overlay documents (weight, tracking, size curve). These
 * frames measure identically to the hero-overlay ones: no-descender ink of 37.5
 * at 2x on desktop AND tablet (= 51px type), 19 on mobile (= 26px), pitch 60 at
 * 51 (= 1.176). Third build to hit the same curve — punch-list item H3.
 */

.tc-hero-basic h1 {
	font-size: clamp( 1.625rem, 0.509rem + 5.58vw, 3.1875rem );
	font-weight: 700;

	/*
	 * Frame line pitch is 60 at 51px type from md up (= 1.176, the theme's own
	 * intended value) but 32 at 26px on mobile. Two lines only accumulate 4px,
	 * which is inside tolerance on its own — it is set because everything below
	 * the heading inherits the error, not because the heading looks wrong.
	 */
	line-height: 1.23;
	letter-spacing: -0.02em;
}

@media (min-width: 48rem) { /* breakpoint/md */

	.tc-hero-basic h1 {
		line-height: 1.176;
	}
}

/*
 * Body copy. Frame body ink is 18 at desktop and tablet, 16 at mobile, against
 * a `body` preset of 18 / 16.8 / 16; frame pitch is 24 at 18 (1.333) and 20 at
 * 16 (1.25) against an emitted line-height of 1.4. Same clamp and same
 * two-step line-height as hero-overlay.
 */

.tc-hero-basic .tc-hero-basic__content p:not( .tc-eyebrow ) {
	font-size: clamp( 1rem, 0.9107rem + 0.4464vw, 1.125rem );
	line-height: 1.25;
}

@media (min-width: 48rem) { /* breakpoint/md */

	.tc-hero-basic .tc-hero-basic__content p:not( .tc-eyebrow ) {
		line-height: 1.333;
	}
}

/*
 * Inter-block spacing — measured per breakpoint, not one uniform gap. The
 * handoff's single `large` blockGap did not survive measurement here any more
 * than it did on hero-overlay: the eyebrow-to-heading gap is `normal` (16) and
 * the heading-to-body gap is `large` (24). The markup's blockGap stays as the
 * default for anything an editor adds.
 *
 * The heading-to-body gap is also NOT flat: 8 at mobile, 24 from md up —
 * exactly the step hero-overlay measured on its own frames. Left at `large`
 * the mobile body sat 14px too low.
 *
 *              eyebrow -> heading    heading -> body
 *   mobile             16                   8
 *   tablet             16                  24
 *   desktop            16                  24
 */

.tc-hero-basic .tc-hero-basic__content > * {
	margin-block-start: 0;
}

.tc-hero-basic .tc-hero-basic__content > h1 {
	margin-block-start: var( --wp--preset--spacing--normal );
}

.tc-hero-basic .tc-hero-basic__content > p:not( .tc-eyebrow ) {
	margin-block-start: var( --wp--preset--spacing--xsmall );
}

.tc-hero-basic .tc-hero-basic__content > .wp-block-buttons {
	margin-block-start: var( --wp--preset--spacing--large );
}

@media (min-width: 48rem) { /* breakpoint/md */

	.tc-hero-basic .tc-hero-basic__content > p:not( .tc-eyebrow ) {
		margin-block-start: var( --wp--preset--spacing--large );
	}
}

/*
 * CTA button. The scheme-role wiring is not optional: theme.json pins
 * core/button to `var(--color-primary)`, the one role token theme-tokens.css
 * does not remap per scheme, so without this the CTA is blue on blue.
 *
 * ⚠ CORRECTED 2026-09-06 — THE PADDING TOKENS DID NOT REPRODUCE THE FRAME BOX,
 * and the metrics ARE harvestable here after all. This comment used to open
 * "Neither frame draws one — the seeded button exists because Contact's comp
 * carries a hidden one — so its metrics are inherited from the frame-verified
 * hero-overlay/hero-split button rather than measured here." Both halves were
 * wrong. Measured on the live library page, `xsmall`/`small` block padding over
 * a 19.995px line box gives 8 + 19.995 + 8 = 35.98 at base and
 * 12 + 19.995 + 12 = 43.98 from md up — so nothing was inherited, because
 * hero-split's own box was 43.98/35.98 too until it was pinned (its CORRECTED
 * note, same defect, same arithmetic). And all four frames DO carry a Button.
 *
 * Harvested off each frame rather than assumed — User Manuals 43846:10957 /
 * 12052 / 12323 and Contact 43885:26081. All four return the SAME box: 210x48,
 * `px-16 py-12`, gap 8, radius 2, 15px label on a 24px line. 12 + 24 + 12 = 48
 * exactly, which is the frame height, and which settles the md-and-up box.
 * What it does NOT settle is the mobile box — see the quirk note below.
 *
 * ⚠ THE FRAMES DO NOT RULE ON THE MOBILE BOX, AND THIS IS WHY THE BASE VALUE
 * IS 40 RATHER THAN THE 48 THEY STATE. All four instances are `hidden`,
 * un-resized, and identical — same 210x48, same `x0 y284`, same Contact label
 * "Speak with Our Team" even on the User Manuals boards. y284 sits BELOW each
 * Content Section's own height (168/168/168/156), i.e. outside the frame's
 * laid-out bounds, because a hidden child is excluded from auto-layout. So 48
 * is the design-system Button's DEFAULT size sitting in four frames untouched,
 * not four per-breakpoint rulings — it states 48 without meaning it.
 *
 * The two patterns that DO draw a mobile CTA both draw it at 40, resized and
 * positioned inside their containers: hero-split's smartphone button
 * (43324:15934, 199x40) and hero-overlay's (43391:28219, 171x40). A measured
 * 40 from a visible instance is better evidence than a stated 48 from a hidden
 * default, so this pattern follows the family curve: 40 at base, 48 from md up.
 *
 * Designer item D-C stays OPEN. The frames do not positively rule on this
 * pattern's mobile CTA in either direction, and adopting the family number is
 * a reasoned inference, not a frame reading. The spec asserts 40 and 48
 * explicitly, so changing either later is a deliberate edit rather than drift.
 *
 * Pinned as `min-height` rather than a 14px padding, the model hero-split
 * settled on: 14 is not a preset, and a label that wraps to two lines must
 * still be allowed to grow. `border: 0` is an explicit restatement — the live
 * border-width already measured 0, so nothing here repairs a border, it stops
 * one from ever entering the arithmetic.
 *
 * The root cause is one level up and is NOT fixed here: theme.json's
 * `typeStyles.button.line-height` is 1.333, so a 15px label renders a 19.995px
 * line box where the frames' Label/Large is 24px (1.6). Changing that is a
 * theme-global type change touching every button on the site; it belongs in its
 * own decision, not in a pattern fix. Recorded in DECISIONS.
 */

.tc-hero-basic .wp-block-button__link {
	/* The Figma export of `fi-rs-arrow-right` (42222:4552), the same path in all
	   nine declarations (2026-09-28, docs/reports/icon-audit.md §7). */
	--tc-icon-arrow-right: url( "data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath d='M23.124 9.87897L18.538 5.29297L17.124 6.70697L21.386 10.97L0 11V13L21.446 12.97L17.123 17.293L18.537 18.707L23.124 14.121C23.6847 13.5575 23.9995 12.7949 23.9995 12C23.9995 11.205 23.6847 10.4425 23.124 9.87897Z'/%3E%3C/svg%3E" );

	display: inline-flex;
	gap: var( --wp--preset--spacing--xsmall ); /* 8 — Figma Button, Icon R 8 after the label (43386:22607, 43391:28219) */
	align-items: center;

	/* 40 at base, 48 from md up — the family curve. The four frames state 48
	 * here too, but from hidden un-resized defaults; hero-split's 43324:15934
	 * and hero-overlay's 43391:28219 are measured 40s. See the note above. */
	min-height: 2.5rem;
	border: 0;
	border-radius: 2px; /* G11 — component-scoped; theme.json is 4px */
	padding-block: 0;
	padding-inline: var( --wp--preset--spacing--small );

	/*
	 * The pattern markup repeats `ftm-scheme-primary` on this block, and that is
	 * why the roles resolve at all in the editor. `ftm/page-section` is a DYNAMIC
	 * block whose wrapper is built in render.php, so the scheme class it carries
	 * never reaches the editor canvas DOM; the roles then fell back to their
	 * `:root` defaults and the canvas painted this CTA primary-600 blue while the
	 * front end was correct. Measured, not reasoned about.
	 *
	 * The theme fallbacks below are belt-and-braces for the same failure mode.
	 */
	background-color: var( --ftm-scheme-accent, var( --wp--custom--color--base--white, #fff ) );
	color: var( --ftm-scheme-accent-text, var( --wp--custom--color--primary--800, #0a205b ) );
	font-size: var( --wp--custom--type-styles--button--font-size );
	line-height: var( --wp--custom--type-styles--button--line-height );
	letter-spacing: 0.2px;
}

@media (min-width: 48rem) { /* breakpoint/md */

	.tc-hero-basic .wp-block-button__link {
		min-height: 3rem; /* 48 — all four frames state a 210x48 box */
		padding-inline: var( --wp--preset--spacing--normal );
	}
}

.tc-hero-basic .wp-block-button__link::after {
	--icon: var( --ftps-icon-arrow-right, var( --tc-icon-arrow-right ) );

	content: "";
	flex: none;
	width: 1rem; /* 16 — Figma Button Icon R is 16×16 at every size; QA batch F item 9 */
	height: 1rem;
	background-color: currentcolor;
	-webkit-mask: var( --icon ) no-repeat center / contain;
	mask: var( --icon ) no-repeat center / contain;
}

/* ── WHEN THIS HERO IS THE PAGE'S LAST SECTION, IT BUTTS THE FOOTER ─────────
 *
 * QA batch D (V-4 / C-13, 2026-09-29). The 404 page is this hero and nothing
 * else, so the footer's section-rhythm margin (style.css) drew a white strip
 * between two navy bands: 48 / 58 / 112 at 320 / 390 / 768+. style.css says a
 * trailing full-bleed band wants that margin at 0 and that the rule belongs in
 * the band's own pattern; this is rep-directory.css's rule, for this hero.
 * It fires only when the hero ends `main` (User Guides opens with it, so it
 * does not fire there).
 * ────────────────────────────────────────────────────────────────────────── */

.wp-site-blocks > main:has( > .page-section:last-child > .tc-hero-basic ) + footer,
.wp-site-blocks
	> main:has( > :last-child > .page-section:last-child > .tc-hero-basic )
	+ footer {
	margin-block-start: 0;
}