/* ==========================================================================
   THE SCOPE BRIEFING — one component, three placements.

   The newsletter has always shared its BUSINESS logic: every placement posts to
   `Newsletter_Signup`, and both the consent notice and the result message come
   from `Newsletter_Band`, so the surfaces cannot make different promises.

   What was duplicated was the STYLING. The white-in-all-states field, the
   autofill treatment, the focus ring and the 16px mobile size existed verbatim
   in both blocks.css and article.css, and that duplication is not theoretical:
   a focus-ring fix written into article.css left the homepage band unchanged,
   because an article never loads that stylesheet. One of the two copies is
   always the one you did not edit.

   So this file holds what the placements MUST agree on — tokens, field, button,
   consent, focus — and each placement keeps only its own composition:

     .tsp-sb--home      two columns, pitch left, form right   (blocks.css)
     .tsp-sb--article   centred editorial interruption        (article.css)

   Loaded as a DEPENDENCY of tsp-editorial-blocks and tsp-aperture-article, so
   it prints only where a placement can appear, and always before the sheet that
   varies it.

   The SIDEBAR rail is deliberately NOT part of this. It renders on category
   archives as well as articles, where category.css gives it a different panel
   entirely — a red card with a translucent white border — and the shared
   `border-color: transparent` here would out-specify and erase that border. It
   is the same product, but it is not the same component, and pretending
   otherwise would break a third page to tidy up two.
   ========================================================================== */

/* --------------------------------------------------------------- tokens */
.tsp-sb {
	--tsp-sb-field: #fff;
	--tsp-sb-ink: #16181F;
	--tsp-sb-muted: #676E7B;
	/* One control height across placements: a field and a button that differ by
	   4px between two pages read as two different products. */
	--tsp-sb-h: 48px;
	--tsp-sb-radius: 8px;
	/* Field and button belong to one another, so the gap between them is
	   tighter than the gap between the form and anything around it. */
	--tsp-sb-gap: 8px;
	/* Consent is secondary, not decorative. On #C8102E, 88% white is ~4.8:1 —
	   the .78 it used to carry measured ~3.97:1, under AA for 12px text. */
	--tsp-sb-consent: rgba(255, 255, 255, .88);
	--tsp-sb-ring: #fff;
	/* A quiet edge that defines the field without drawing a line on the band.
	   Ink at 12% reads as a soft grey against the white fill and disappears
	   into the red at the field's outer corners. */
	--tsp-sb-edge: rgba(22, 24, 31, .12);
}

/* --------------------------------------------------- where the jump lands */
/*
 * The header's Subscribe button points at /#subscribe, and both placements
 * carry that id. Two things were wrong with where it landed.
 *
 * First, the band's own `scroll-margin-top: 24px` never applied when it was
 * actually targeted: Blocksy ships `:target { scroll-margin-top: calc(...) }`,
 * a (0,1,0) pseudo-class that ties a single class and loads later, and it
 * resolves to 0. Measured on staging, the targeted band computed 0px.
 *
 * Second, 24px was the wrong number on a phone anyway. Below 782 the masthead
 * pins itself with `position: fixed` at a condensed 56px, so the jump parked
 * the band's top edge underneath it — measured 55-67px of the band covered at
 * 600, 390 and 360, with the headline itself partly hidden at 360. A reader
 * pressing Subscribe arrived at a band whose first line they could not read.
 *
 * `.tsp-sb:target` is (0,2,0), so it wins. The mobile value is the measured
 * condensed height plus 12px of clearance; the `.admin-bar` variant allows for
 * the 46px WordPress bar, which sits above the masthead for signed-in editors.
 */
.tsp-sb,
.tsp-sb:target {
	scroll-margin-top: 24px;
}

@media (max-width: 782px) {
	.tsp-sb,
	.tsp-sb:target {
		scroll-margin-top: 68px;
	}

	.admin-bar .tsp-sb,
	.admin-bar .tsp-sb:target {
		scroll-margin-top: 114px;
	}
}

/* ---------------------------------------------------------------- field */
/*
 * White in EVERY state, including focus.
 *
 * Blocksy ships `input:is([type="url"],[type="tel"],[type="email"],…):focus`,
 * which computes to (0,2,1) — one element selector more specific than a
 * two-class selector. So a placement's own rule won while the field was idle
 * and the THEME won the moment it was focused: the background fell to
 * transparent and the red band showed through, with the text repainted in the
 * theme's slate blue. Measured on staging: bg rgba(0,0,0,0), colour
 * rgb(58,79,102) — on a #C8102E field.
 *
 * These selectors are (0,3,2), so they win in every state without !important.
 *
 * -webkit-text-fill-color is set as well as `color` because it OVERRIDES
 * colour on Blink, and it was the property actually painting the text.
 */
.tsp-sb form input[type="email"],
.tsp-sb form input[type="email"]:hover,
.tsp-sb form input[type="email"]:focus,
.tsp-sb form input[type="email"]:focus-visible,
.tsp-sb form input[type="email"]:active {
	background-color: var(--tsp-sb-field);
	color: var(--tsp-sb-ink);
	-webkit-text-fill-color: var(--tsp-sb-ink);
	caret-color: var(--tsp-sb-ink);
	/* A subtle edge on the white field. Held CONSTANT across every state on
	   purpose: box-sizing is border-box, so a border that appears or thickens
	   on focus would shift the text inside the field by a pixel. The focus
	   indicator is the outline ring, which sits outside the box and moves
	   nothing. */
	border: 1px solid var(--tsp-sb-edge);
}

.tsp-sb form input[type="email"]::placeholder {
	color: var(--tsp-sb-muted);
	-webkit-text-fill-color: var(--tsp-sb-muted);
	opacity: 1;
}

/* Autofill is handled the only way it can be: Chrome paints its own background
   outside the cascade and ignores `background-color`, so a large inset shadow
   covers the field instead, and the long transition delay stops the yellow
   flash before it is repainted. */
.tsp-sb form input[type="email"]:-webkit-autofill,
.tsp-sb form input[type="email"]:-webkit-autofill:hover,
.tsp-sb form input[type="email"]:-webkit-autofill:focus,
.tsp-sb form input[type="email"]:-webkit-autofill:active {
	-webkit-box-shadow: inset 0 0 0 100px var(--tsp-sb-field);
	box-shadow: inset 0 0 0 100px var(--tsp-sb-field);
	-webkit-text-fill-color: var(--tsp-sb-ink);
	caret-color: var(--tsp-sb-ink);
	transition: background-color 100000s ease-in-out 0s;
}

/* A ring that can be seen on what the control actually sits on. The global
   focus ring is brand red, which is invisible on a brand-red band; white on
   that red is ~4.9:1, and on the ink rail it is higher still. */
.tsp-sb form input[type="email"]:focus-visible,
.tsp-sb form button:focus-visible {
	outline: 3px solid var(--tsp-sb-ring);
	outline-offset: 2px;
}

/* ------------------------------------------------- field + button, shared */
/*
 * The two red placements share one field and one CTA. The rail is excluded on
 * purpose: it is a narrow stacked sidebar card whose controls are full-width by
 * design, and it sits on ink, where a red button is the correct contrast.
 */
/* No `border: 0` here. This rule is (0,2,2) for the article placement, exactly
   tying the state rule above and winning on source order — so a reset here
   would quietly delete the field's edge on one placement and keep it on the
   other. The border belongs to the state block, which sets it once for every
   state. */
.tsp-sb--home .tsp-newsletter-band__input,
.tsp-sb--article form input[type="email"] {
	height: var(--tsp-sb-h);
	padding: 0 16px;
	border-radius: var(--tsp-sb-radius);
	font-family: var(--ts-ui);
	font-size: 14px;
	box-sizing: border-box;
}

/* iOS Safari zooms into any input under 16px, so tapping Subscribe threw the
   reader into a viewport they then had to pinch back out of. Applied where the
   form stacks; above that the field sits in a sized slot and 14px is the
   deliberate size for that composition.
 *
 * v1.10.644 — THIS BLOCK MUST STAY BELOW THE SHARED FIELD RULE ABOVE.
 * It used to sit above it and did nothing on an article. Both selectors are
 * (0,2,2) — `.tsp-sb form input[type="email"]` here, and
 * `.tsp-sb--article form input[type="email"]` there — so the tie broke on
 * source order and the later 14px won at every width. Measured at 390px: the
 * rail and the homepage band were 16px and the article band was 14px, which is
 * the one placement a phone reader meets at the end of a story. The homepage
 * half was never affected: `.tsp-sb--home .tsp-newsletter-band__input` is
 * (0,2,0) and already lost to this rule from either position.
 *
 * The comment on the shared rule above reasons about exactly this tie for
 * `border` and stops there; the font-size that rides along with it was missed.
 */
@media (max-width: 900px) {
	.tsp-sb form input[type="email"] {
		font-size: 16px;
	}
}

/*
 * A white button beside a white field, both on red, gave the site's primary CTA
 * no visible shape — the two controls read as one white slab. The dark navy the
 * homepage band already used is the design system's answer, so the article band
 * adopts it rather than inventing a third treatment.
 *
 * `.tsp-sb--article form button` is (0,1,2), which clears both Blocksy's
 * `[type="submit"]` at (0,1,0) and the placement's own `.tsp-art__band button`
 * at (0,1,1) — the rule that used to paint it white.
 */
.tsp-sb--home .tsp-newsletter-band__btn,
.tsp-sb--article form button {
	height: var(--tsp-sb-h);
	padding: 0 24px;
	border: 0;
	border-radius: var(--tsp-sb-radius);
	background: var(--tsp-sb-ink);
	color: #fff;
	font-family: var(--ts-ui);
	font-size: 14px;
	font-weight: 700;
	line-height: 1;
	cursor: pointer;
	box-sizing: border-box;
	transition: background-color .15s ease;
}

.tsp-sb--home .tsp-newsletter-band__btn:hover,
.tsp-sb--article form button:hover {
	background: #000;
}

@media (prefers-reduced-motion: reduce) {
	.tsp-sb--home .tsp-newsletter-band__btn,
	.tsp-sb--article form button {
		transition: none;
	}
}

/* ------------------------------------------------------ result message */
/*
 * What the reader is told after submitting, in one voice on both placements.
 *
 * The article's message had no styling at all. It rendered `flex: 0 1 auto`,
 * so it stayed off the control row only by being LONGER than the space left
 * beside the field — measured 426px against a 520px row. Shorten the copy, or
 * translate it, and it drops onto the row and squeezes the field, which is the
 * v1.10.408 defect the consent line already caused once. `1 0 100%` makes that
 * unavailable rather than unlikely.
 *
 * It also could not tell a reader apart from an error: the homepage bolds
 * `is-error` and the article had no weight rule, so "we could not save your
 * subscription" and "check your inbox" looked identical.
 */
.tsp-sb .tsp-newsletter-band__msg,
.tsp-sb .tsp-art__band__msg {
	flex: 1 0 100%;
	margin: 6px 0 0;
	font-family: var(--ts-ui);
	font-size: 13px;
	line-height: 1.5;
	color: #fff;
}

.tsp-sb .tsp-newsletter-band__msg.is-error,
.tsp-sb .tsp-art__band__msg.is-error {
	font-weight: 600;
}

/* The article placement is centred, message included. */
.tsp-sb--article .tsp-art__band__msg {
	text-align: center;
}

/* -------------------------------------------------------------- consent */
/*
 * The sentence that tells a reader what their address is for. Listed by class
 * rather than matched by suffix so it is obvious which two elements this is,
 * and so a third placement has to opt in deliberately.
 *
 * `flex: 1 0 100%` is load bearing. Without it the notice becomes a THIRD flex
 * child on the control row and takes its share of the width: measured at 1366
 * and 1920 the article band's email field collapsed to 32px — a field nobody
 * could type an address into — while the button stretched to 74px tall against
 * a 40px input.
 */
.tsp-sb .tsp-newsletter-band__consent,
.tsp-sb .tsp-art__band__consent {
	flex: 1 0 100%;
	margin: 10px 0 0;
	font-family: var(--ts-ui);
	font-size: 12px;
	line-height: 1.5;
	color: var(--tsp-sb-consent);
}

.tsp-sb .tsp-newsletter-band__consent a,
.tsp-sb .tsp-art__band__consent a {
	color: #fff;
	text-decoration: underline;
}

/* ------------------------------------------------- iPadOS focus zoom, part 2 */
/*
 * v1.10.658 — the tablet band, for the newsletter this time.
 *
 * The `max-width: 900px` guard above stops at 900, because 14px is the
 * deliberate density where the field sits in a sized slot. But the zoom follows
 * the INPUT METHOD, not the viewport: an iPad in landscape is 1180 CSS px AND a
 * touch device, so Safari still zooms the page the moment a reader taps the
 * field, and they have to pinch back out.
 *
 * Measured on the deployed site at v1.10.657, both editions, with an iPad UA and
 * touch enabled — 390/768/820/900: 16px, then 901/1024/1180/1440: 14px, i.e.
 * identical to the mouse column. The header search was given exactly this guard
 * in v1.10.657 and reads 16px on touch at every width; this is the same defect
 * one component over, and the same fix.
 *
 * Only the two band placements need it. The rail unit (`tsp-news-rail`) already
 * renders 16px on category, search and Latest Stories.
 *
 * MUST STAY LAST IN THIS FILE. Both selectors deliberately repeat the ones in
 * the 14px rule above — (0,2,0) and (0,2,2) — so specificity ties exactly and
 * the tie breaks on source order. That is what makes `!important` unnecessary,
 * and it is also why moving this block up would silently disable it, which is
 * precisely how the v1.10.644 version of this bug survived.
 */
@media (pointer: coarse) {
	.tsp-sb--home .tsp-newsletter-band__input,
	.tsp-sb--article form input[type="email"] {
		font-size: 16px;
	}
}