/* ==========================================================================
 * theauto.css -- design tokens + base stylesheet for theauto.page
 *
 * server-configs#374 item 2 / woodzgit/theauto#23 item 2.
 *
 * AUTHORITY. Every number in this file was measured from the live-site capture
 *   clients/tchjozi/reference/theauto-live-2026-08-11/
 * in tch-ops/server-configs, taken 2026-08-11 before theauto.page expires
 * 2026-09-02. The per-selector getComputedStyle dumps in that capture's
 * computed/ folder are the authority; this file is their transcription. There
 * is no design file and no mockup. If a value here looks wrong, re-measure
 * against computed/home.desktop.json and computed/home.mobile.json -- do not
 * guess, and do not "improve" it.
 *
 * FONTS. The body font is WORK SANS, not Roboto. #374's own body recorded the
 * fonts the retired wp.com "patch" theme ENQUEUED; that is not what rendered.
 * Measured: Work Sans on body / nav / .entry-meta / .entry-content--short /
 * .site-description; Oswald on .site-title / .entry-title / headings; Roboto
 * on h5 and nowhere else. The wp.com Global Styles override
 * body{font-family:"Work Sans",sans-serif} beat the theme's own enqueue.
 * Self-hosting "Roboto + Oswald" as item 2 literally says would make every
 * paragraph, nav item and excerpt on the site visibly wrong.
 *
 * The eight woff2 files in /fonts/ were copied from the capture and each one
 * is sha256-verified against its manifest.tsv row. fonts-api.wp.com and
 * fonts.wp.com die with the domain, so nothing here may reference them.
 *
 * All three families are VARIABLE fonts and every weight of a family/subset
 * resolves to the SAME woff2, so one file per subset covers the whole axis.
 * THAT DOES NOT MEAN THE AXIS MAY BE DECLARED AS A RANGE, and reading it that
 * way was woodzgit/theauto#31 -- the single defect behind every "3px residual"
 * logged on items 3 to 8. See section 1. Live declares the same bytes at fixed
 * weights and gets the FIXED-weight instances; a `font-weight: 100 900` range
 * over the same bytes gets genuine 300 and 500 instances live never renders.
 *
 * WHAT THIS REPLACES. /colorschemes/default.css was motorsportmedia's
 * colourscheme, inherited with the seed from motorsportmedia@b382ca8; it is
 * unlinked from header.asp by this change rather than layered over. The
 * external Google Fonts link (Droid Sans / Lato / Droid Serif) goes with it --
 * wrong families, and an off-site dependency this site must not carry.
 * /css/base.css and /css/components.css stay for now: the page templates are
 * still motorsportmedia markup and items 3-8 replace them template by
 * template. This file loads LAST so it wins in the meantime.
 * /css/wp-blocks.css (#364 item 11) loads after this one, by design -- it
 * carries the Gutenberg column CSS the imported static pages need.
 *
 * BREAKPOINT. The live theme switches at 900px: the desktop left rail lives in
 * @media only screen and (min-width:900px) and .mobile-header turns on below
 * it. Refinements at 1000 / 1200 / 1260 / 1360 / 1440 / 1450 / 1700 exist in
 * the source bundle and belong to items 3, 4 and 8, not here.
 * ==========================================================================*/


/* --------------------------------------------------------------------------
 * 1. Self-hosted faces
 *
 * EVERY WEIGHT LIVE DECLARES, DECLARED FIXED. NEVER A RANGE. This is
 * woodzgit/theauto#31 and it is the whole of it -- no file here changed, no
 * file was re-downloaded, and all eight are still byte-identical to the
 * capture's manifest.tsv. Only these declarations changed.
 *
 * WHY. The files ARE variable fonts, so `font-weight: 100 900` is a legal and
 * even tempting way to declare them: one download, any weight. Live does not
 * do that. Live declares the same bytes once per weight it wants, and CSS font
 * matching then resolves everything else DOWN to a declared weight instead of
 * instancing the axis:
 *
 *   family     live declares          so this theme's weights resolve to
 *   Work Sans  400, 700               300 -> 400,  500 -> 400,  700 -> 700
 *   Oswald     300, 400, 700          300 -> 300,  500 -> 400,  700 -> 700
 *   Roboto     300, 400, 500          400 -> 400
 *
 * Declared as a range, this build instanced a GENUINE 300 for running text and
 * a GENUINE 500 for links and card titles -- weights the live site never put on
 * screen. Every text box was then the wrong width, and every box below it the
 * wrong y. Measured on DEV before the fix:
 *
 *   .site-branding   371.08 vs live 374.08   .footer-menu a  74.27 vs 77.70
 *   .entry-meta      292.58 vs live 295.38   .byline        139.67 vs 145.56
 *   .entry-title a (Oswald 500) ran ~4.5% WIDE -- +13 to +16px on 19 of 20
 *   cards on one archive, which re-wrapped titles and so moved whole cards.
 *
 * The Oswald half was not in #31's body when it was written: #31 enumerated
 * the wp.com override sheet (Work Sans only) and the theme's own sheet
 * declares Oswald at 300/400/700 and Roboto at 300/400/500. Both were found by
 * measuring, not by reading. Same defect, same section, fixed together.
 *
 * SUBSETS. Live serves latin, latin-ext AND vietnamese for Work Sans and
 * Oswald (plus cyrillic and cyrillic-ext for Oswald). Only latin and latin-ext
 * are self-hosted here. THAT IS DELIBERATE, NOT AN OMISSION: this publication
 * is English-only motoring copy, no captured page contains a codepoint in any
 * of those ranges, and a `unicode-range` block that never matches is a file the
 * browser never fetches. Dropping them costs nothing and saves three requests'
 * worth of declarations. If Vietnamese or Cyrillic copy is ever published, the
 * files are in the capture's fonts/ and this is where they go back.
 *
 * Roboto italic is likewise not self-hosted -- live declares it, and h5, the
 * only element on the site that renders Roboto at all, is never italic.
 *
 * font-display: swap is ours; live sets nothing and so gets `auto`. Kept,
 * because a self-hosted face on an IIS origin should not block paint for 3s.
 * It changes when text appears, never its metrics, so it is invisible to
 * ops/measure.py, which waits on document.fonts.ready.
 * ------------------------------------------------------------------------*/

/* Work Sans -- body, nav, meta, excerpts, footer. Live: 400 and 700. */
@font-face {
	font-family: "Work Sans";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/work-sans-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Work Sans";
	font-style: normal;
	font-weight: 700;
	font-display: swap;
	src: url("/fonts/work-sans-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Work Sans";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/work-sans-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Work Sans";
	font-style: normal;
	font-weight: 700;
	font-display: swap;
	src: url("/fonts/work-sans-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Work Sans";
	font-style: italic;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/work-sans-italic-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Work Sans";
	font-style: italic;
	font-weight: 700;
	font-display: swap;
	src: url("/fonts/work-sans-italic-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Work Sans";
	font-style: italic;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/work-sans-italic-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Work Sans";
	font-style: italic;
	font-weight: 700;
	font-display: swap;
	src: url("/fonts/work-sans-italic-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

/* Oswald -- site title, entry titles, headings. Live: 300, 400 and 700.
 * The 500 that .entry-title a asks for is NOT declared here, deliberately:
 * live does not declare it either, and so resolves that link to the 400 face.
 * Adding a 500 block would put back the 4.5%-wide card titles this item
 * removed. */
@font-face {
	font-family: "Oswald";
	font-style: normal;
	font-weight: 300;
	font-display: swap;
	src: url("/fonts/oswald-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Oswald";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/oswald-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Oswald";
	font-style: normal;
	font-weight: 700;
	font-display: swap;
	src: url("/fonts/oswald-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Oswald";
	font-style: normal;
	font-weight: 300;
	font-display: swap;
	src: url("/fonts/oswald-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Oswald";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/oswald-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Oswald";
	font-style: normal;
	font-weight: 700;
	font-display: swap;
	src: url("/fonts/oswald-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

/* Roboto -- renders on h5 ONLY, measured. Carried so that one element does not
 * silently fall back; it is deliberately not in any other stack. Live: 300,
 * 400 and 500. h5 asks for 400 and gets it either way, so unlike the two
 * families above this one is transcribed for faithfulness rather than to fix a
 * measured box -- but a range here would be the same latent trap. */
@font-face {
	font-family: "Roboto";
	font-style: normal;
	font-weight: 300;
	font-display: swap;
	src: url("/fonts/roboto-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Roboto";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/roboto-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Roboto";
	font-style: normal;
	font-weight: 500;
	font-display: swap;
	src: url("/fonts/roboto-latin.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

@font-face {
	font-family: "Roboto";
	font-style: normal;
	font-weight: 300;
	font-display: swap;
	src: url("/fonts/roboto-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Roboto";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("/fonts/roboto-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

@font-face {
	font-family: "Roboto";
	font-style: normal;
	font-weight: 500;
	font-display: swap;
	src: url("/fonts/roboto-latin-ext.woff2") format("woff2");
	unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF;
}


/* --------------------------------------------------------------------------
 * 2. Tokens
 * ------------------------------------------------------------------------*/

:root {
	/* Families. Quoted exactly as the live computed style reported them. */
	--ta-font-body: "Work Sans", sans-serif;
	--ta-font-display: Oswald, sans-serif;
	--ta-font-h5: Roboto, sans-serif;

	/* Palette. Measured; the live theme is monochrome -- the only red on the
	 * site is inside the AUTO. logo image, never in CSS. The #cc1818 in the
	 * source bundle is Gutenberg editor chrome, not a theme accent. */
	--ta-c-page: #fff;              /* html background */
	--ta-c-text: #3e3f40;           /* body, p, .entry-meta, excerpts */
	--ta-c-heading: #171617;        /* h1-h6, .site-title, .entry-title */
	--ta-c-link: #000;              /* a, .main-navigation a */
	--ta-c-card: #fff;              /* .hentry background */
	--ta-c-rule: #e2e3e3;           /* .mobile-header-wrapper bottom border */
	--ta-c-footer-bg: #bfbfbf;      /* .site-footer */
	--ta-c-footer-text: #474747;    /* .site-footer, .site-info */
	--ta-c-footer-link: #b5b5b5;    /* .footer-menu a */
	--ta-c-invert-bg: #000;         /* input[type=submit] */
	--ta-c-invert-text: #fff;
	/* #374 item 5. The theme's source paints .cat-links and the comment submit
	 * #ffde00; wp.com's custom-colors layer flattens both to #d1d1d1 and that
	 * is what the capture measured, so the yellow is not reproduced -- it
	 * survives only on the social-icon hover in section 8. */
	--ta-c-chip: #d1d1d1;           /* .cat-links, .comment-form .submit */
	--ta-c-muted: #b5b5b5;          /* .posted-on, .tags-links a, hairlines */

	/* Type scale. Sizes in px because that is how the live site computes;
	 * line-heights in px for the same reason, except .site-title, whose 1.25
	 * ratio reproduces 45px at desktop and 37.5px at mobile from one value. */
	--ta-fs-site-title: 36px;       /* mobile override below */
	--ta-lh-site-title: 1.25;
	--ta-ls-site-title: 0.04em;     /* 1.44px @36, 1.2px @30 -- both measured */

	--ta-fs-entry-title: 26px;
	--ta-lh-entry-title: 37.7px;
	--ta-ls-entry-title: 0.04em;    /* 1.04px @26 */

	--ta-fs-nav: 24px;
	--ta-lh-nav: 34px;
	--ta-ls-nav: 0.06em;            /* 1.44px @24 */

	--ta-fs-h2: 24px;
	--ta-lh-h2: 30px;

	--ta-fs-body: 16px;
	--ta-lh-body: 26px;             /* body / a */
	--ta-lh-copy: 24px;             /* p / .entry-content--short */

	--ta-fs-small: 13px;            /* .site-description, footer */
	--ta-lh-small: 21.125px;

	--ta-fs-meta: 11px;             /* .entry-meta, h5 */
	--ta-lh-meta: 17.875px;

	--ta-fs-button: 20px;
	--ta-lh-button: 32.5px;
	--ta-ls-button: 0.1em;          /* 2px @20 */

	--ta-fs-submit: 14px;
	--ta-lh-submit: 26px;
	--ta-ls-submit: 0.1em;          /* 1.4px @14 */

	/* Weights. The live site uses 300 for running text and 500 for links --
	 * an inversion of the usual defaults, and easy to lose. */
	--ta-w-light: 300;
	--ta-w-normal: 400;
	--ta-w-medium: 500;
	--ta-w-bold: 700;

	/* Spacing. The theme's rhythm is a 12px base; every measured margin and
	 * padding on the page is a multiple of it. */
	--ta-sp-1: 4px;
	--ta-sp-2: 8px;
	--ta-sp-3: 12px;
	--ta-sp-4: 24px;
	--ta-sp-5: 48px;
	--ta-sp-6: 60px;
	--ta-sp-7: 96px;

	/* Layout. Measured at a 1440px viewport. */
	--ta-outer-gutter: 18px;        /* body -> .site-content inset */
	--ta-w-content: 1404px;         /* .site-content */
	--ta-p-content: 60px;           /* .site-content left/right padding */
	--ta-p-content-grid: 24px;      /* ... but 24 on a grid page below 1360 (#39) */
	--ta-w-main: 1284px;            /* .site-main = content - 2 * padding */
	--ta-w-rail: 420px;             /* .site-header, desktop left rail */
	--ta-rail-inset: 24px;          /* .site-branding / nav ul margin-left */
	--ta-rail-inner: 300px;         /* .site-branding width */
	--ta-w-card: 396px;             /* .hentry */
	--ta-gutter: 48px;              /* .hentry margin-right */
	--ta-mobile-header-h: 50px;     /* .mobile-header, fixed */
	--ta-mobile-gutter: 24px;       /* .entry-* margins at 390px */
	--ta-mobile-rail-inset: 48px;   /* .site-header margin at 390px */

	/* The logo has no source above 567x567 (Auto-1-copy.jpg, 84,740 B). Do
	 * not upscale past this -- a retina masthead needs the asset re-made. */
	--ta-logo-max: 567px;
}


/* --------------------------------------------------------------------------
 * 3. Base elements
 * ------------------------------------------------------------------------*/

html {
	background-color: var(--ta-c-page);
	box-sizing: border-box;
	/* Measured: html itself keeps a serif family and 16/24 -- the theme sets
	 * type on body, not html. Reproduced rather than tidied, because a
	 * stylesheet that skips this inherits differently inside the imported
	 * Gutenberg markup on the static pages.
	 *
	 * THE FAMILY IS DECLARED HERE FOR A REASON, #33 item 9 task 4. Stating the
	 * intent in this comment and then setting only font-size did not achieve
	 * it: bootstrap.min.css loads FIRST and carries `html{font-family:
	 * sans-serif}`, so the root element measured sans-serif against live's
	 * "Times New Roman" on all 14 captured page/width combinations. That is the
	 * FOURTH measured defect from that sheet, after items 3 and 5 and #31.
	 * font-size escaped only because this block already set it explicitly.
	 *
	 * `revert`, NOT a font stack. Live declares NOTHING on html -- its
	 * "Times New Roman" is the browser's own default coming through. Naming a
	 * stack here reproduces the pixels but not the reading: it computed
	 * `"Times New Roman", Times, serif` against the capture's `"Times New
	 * Roman"` and left a permanent false positive in ops/capturediff.py, which
	 * is how a gate stops being believed. `revert` rolls this property back to
	 * the user-agent origin, which is precisely what live has. */
	font-family: revert;
	font-size: 16px;
	line-height: 24px;
	-webkit-text-size-adjust: 100%;
}

/* THE UNIVERSAL BORDER-BOX RULE, RESTATED -- woodzgit/theauto#72, 2026-08-18.
 *
 * *** THIS IS THE FIFTH AND LARGEST ENTRY ON THE BOOTSTRAP LEDGER, AND IT IS
 * *** THE ONE THE LEDGER PREDICTED. ***
 *
 * The `html { box-sizing: border-box }` eleven lines above is NOT what made
 * this site border-box, because box-sizing DOES NOT INHERIT. The only
 * `*, *:before, *:after { box-sizing: border-box }` on the site lived inside
 * vendor/bootstrap/css/bootstrap.min.css, so EVERY element other than <html>
 * was border-box purely because that sheet was linked.
 *
 * woodzgit/theauto#59 found this and fixed exactly one selector -- .grid__item,
 * section 9 -- because that was the box its sidebar insets depended on. Its
 * comment states the general case in as many words: "the day bootstrap comes
 * out, a content-box cell would take that padding as EXTRA width". #72 is that
 * day, and the general case is everything else on the site.
 *
 * HOW IT WAS CAUGHT, which is the part worth keeping: ops/measure.py refuses to
 * measure a page whose body is not border-box, and on the first run after the
 * deletion it refused ALL FOURTEEN page/width dumps. Nothing rendered visibly
 * broken; every route still answered 200 and crawl.py passed 52/52. Without
 * that guard this would have shipped as a silent, site-wide geometry change --
 * which is precisely the failure mode #33 described when it said "every rule
 * this build does not explicitly restate is quietly Bootstrap's".
 *
 * BORDER-BOX AND NOT INHERIT. `inherit` pairs neatly with the html rule and is
 * the modern idiom, but it propagates any content-box an ancestor picks up,
 * whereas bootstrap's literal behaviour was border-box on every element
 * regardless. The requirement here is "same computed value as before the
 * deletion", not "nicest rule", so this is the faithful restatement. Proved by
 * measurement: the 14 before-dumps were taken with bootstrap still linked and
 * the after-dumps match them. */
*,
*:before,
*:after {
	box-sizing: border-box;
}

/* --------------------------------------------------------------------------
 * 3a. The rest of the bootstrap ledger, restated -- woodzgit/theauto#72.
 *
 * WHAT THIS BLOCK IS. #72 deleted bootstrap.min.css. Every page/width pair was
 * measured before and after the deletion; 46 (selector, property) families
 * moved. This is the subset that was a LOSS -- rules this build had been
 * borrowing and never restated. It is not a compatibility shim and it is not
 * all of bootstrap: each rule below is here because a measurement said so.
 *
 * *** THE THINGS THAT MOVED AND ARE DELIBERATELY *NOT* RESTATED ***
 *
 *   .nav > li > a { position: relative }  -- .footer-menu a and .nav--footer a
 *     went relative -> static. THE CAPTURE SAYS LIVE IS static, on all 18
 *     dumps. Bootstrap was the divergence; the deletion FIXED it. Restating it
 *     would re-break a box that is now correct, and it is a near relative of
 *     the padding on the same selector that cost #374 items 3 and 5 a cycle
 *     each. Nothing from `.nav > li > a` comes back.
 *
 *   #secondary .widget, .widget_google_translate_widget,
 *   .widget_facebook_likebox heights -- these moved on ONE dump each, and both
 *     widgets render from a THIRD-PARTY script (Google Translate builds its
 *     <select> after load; the likebox is a Facebook iframe). That is embed
 *     timing, the same class as the flap sweep.py's header warns about on
 *     /auto-test-records/, not a rule this file ever owned. Re-measured and it
 *     did not reproduce.
 *
 *   .entry-content img width/height -- the capture reads 342/196/163px across
 *     its dumps, i.e. it varies per page, which is the `querySelectorAll[0]`
 *     artefact ops/capturepath.py exists for rather than one number to hold.
 * ------------------------------------------------------------------------*/

/* Bootstrap's `p { margin: 0 0 10px }`. Without it every paragraph on the site
 * took the user-agent's `1em 0` and gained 16px of TOP margin -- measured on 6
 * of the 14 dumps, and it is what pushed the article template's #primary from
 * 9744.77 to 9854.28px, +110px on one page. The capture reads margin-top 0px on
 * `p` and on `.entry-content p` across all 18 dumps, so restating this is what
 * matches live; leaving it out was the regression. */
p {
	margin: 0 0 10px;
}

/* Bootstrap's list margins, for the same reason and found the same way:
 * `.entry-content ul` went margin-bottom 10px -> 16px and margin-top 0 -> 16px
 * on the imported Gutenberg pages. The capture reads 0px for both. */
ul,
ol {
	margin-top: 0;
	margin-bottom: 10px;
}

ol ol,
ol ul,
ul ol,
ul ul {
	margin-bottom: 0;
}

/* *** THE ONE WITH REACH BEYOND THE BOX IT WAS FOUND ON. ***
 *
 * Found as `.overlay__close` measuring font-weight 700 -> 400 on 9 of the 14
 * dumps. That element is a <b> (footer.asp), and the mechanism generalises to
 * every <b> and <strong> on the site: the user agent styles them `bolder`,
 * which is RELATIVE, and this build's body weight is 300 -- so `bolder` of 300
 * computes 400, not 700. Bootstrap's normalize carried an absolute
 * `b, strong { font-weight: bold }` and that is what was doing the work.
 *
 * The search overlay's close mark is the box that revealed it. The box that
 * MATTERS is article body copy: the 1,156 imported posts carry WordPress
 * <strong> throughout, and without this rule every one of them renders emphasis
 * at 400 against 300 body text -- a difference too small to notice as a bug and
 * too small to be emphasis, which is the worst of both. */
b,
strong {
	font-weight: bold;
}

/* Bootstrap's normalize carried `figure { margin: 0 }`, and nothing in
 * theauto.css, base.css, components.css or wp-blocks.css restates it. Without
 * it every <figure> falls back to the user agent's `margin: 1em 40px`.
 *
 * FOUND BY ARITHMETIC, WHICH IS WHY IT IS WORTH RECORDING. The article template
 * measured `.entry-content img` at 580px wide before the deletion and 500px
 * after. 580 - 500 = 80, which is exactly two 40px margins - so the image had
 * not been resized, its FIGURE had been indented. The same three figures each
 * gained 1em top and bottom, which is most of the +109.52px that .entry-content
 * put on, and the `.entry-content ul` that appeared to shrink is the gallery
 * grid inside `figure.wp-block-gallery`, i.e. the same fact reported twice.
 *
 * The imported posts use <figure> for every image and gallery block, so this is
 * 1,156 article pages, not one. It survived the first restatement pass because
 * the p and ul margins accounted for the OTHER pages' growth and made the
 * article's look explained; the 80px on the image width is what showed it was
 * not. */
figure {
	margin: 0;
}

/* Bootstrap's `.pagination { display: inline-block }`. Ours is live's markup
 * and live's classes, but live HIDES the whole rail (body.infinite-scroll, and
 * the capture reads display:none on all 6 archive dumps) -- so live cannot
 * adjudicate this and the before-state is the reference instead. Without it the
 * nav became a full-width block: 480px -> 1284px at 1440, and .nav-links picked
 * up 172px auto-margins trying to centre inside it.
 *
 * `padding-left: 0` comes with it because the rail is a <div>, not a <ul>, on
 * this build -- harmless where it lands, and kept so the pair matches what was
 * measured rather than a trimmed version of it. The 4px border-radius bootstrap
 * also set is NOT restated: nothing here has a background or a border for it to
 * round, so it was never visible. */
.pagination {
	display: inline-block;
	padding-left: 0;
}

body {
	background-color: transparent;
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-light);
	line-height: var(--ta-lh-body);
	letter-spacing: normal;
	margin: 0;
	text-transform: none;
}

a {
	color: var(--ta-c-link);
	font-family: var(--ta-font-body);
	font-size: inherit;
	font-weight: var(--ta-w-medium);
	line-height: var(--ta-lh-body);
	text-decoration: none;
}

p {
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-light);
	line-height: var(--ta-lh-copy);
}

h1, h2, h3, h4, h6 {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-weight: var(--ta-w-normal);
	text-transform: uppercase;
}

h1 {
	font-size: var(--ta-fs-site-title);
	letter-spacing: var(--ta-ls-site-title);
	line-height: var(--ta-lh-site-title);
}

h2 {
	font-size: var(--ta-fs-h2);
	letter-spacing: normal;
	line-height: var(--ta-lh-h2);
}

/* h5 is the one place Roboto renders. Measured, and the reason a Roboto face
 * is self-hosted at all. */
h5 {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-h5);
	font-size: var(--ta-fs-meta);
	font-weight: var(--ta-w-normal);
	letter-spacing: 0.02em;         /* 0.22px @11 */
	line-height: var(--ta-lh-meta);
	text-transform: uppercase;
}


/* --------------------------------------------------------------------------
 * 4. Theme type -- the classes the live markup carries
 *
 * Type and colour only. Geometry for these belongs to items 3 (masthead),
 * 4 (card grid), 5 (article) and 6 (footer), which is why there is no
 * position/width here.
 * ------------------------------------------------------------------------*/

/* *** CLIENT REVIEW 2026-08-16, woodzgit/theauto#87 -- DELIBERATE, PAST LIVE.
 * "The AUTO font under the logo, maybe bold or black font." ***
 *
 * That is this element: the logo is an image (/img/auto-logo-500.jpg, alt
 * empty) and the word `Auto.` beneath it is .site-title, rendering SITE_NAME
 * from _site.asp. The tagline one line below is .site-description and is NOT
 * what moved.
 *
 * BOLD (700), NOT BLACK (900), AND THAT IS NOT A PREFERENCE. Section 2
 * declares Oswald at 300/400/700 only -- deliberately, because live does, and
 * declaring the variable axis as a range instanced weights live never rendered
 * and made every Oswald box the wrong width. With 300/400/700 declared, CSS
 * font matching resolves a requested 900 DOWN to the 700 face: `900` and `700`
 * would paint identical pixels, so `900` would be a claim the file cannot
 * honour. 700 is the heaviest weight this site actually has.
 *
 * Live is 400 here. This is a departure, and ops/adjudicate.py says so.
 *
 * *** ASKED AGAIN ON 2026-08-17 -- "maybe bolder on the AUTO?" -- AND 700 IS
 * THE CEILING. woodzgit/theauto#95. ***
 *
 * This is not a judgement call and it is not a limit of this stylesheet. It is
 * the font file. Read directly out of webapp/fonts/oswald-latin.woff2 with
 * fontTools, 2026-08-17:
 *
 *     oswald-latin.woff2   VARIABLE, axes: wght 200 .. 400 .. 700
 *     work-sans-latin.woff2  VARIABLE, axes: wght 100 .. 400 .. 900
 *
 * Oswald's weight axis STOPS AT 700. There is no 800 and no 900 to ask for --
 * upstream Oswald has never shipped one. `font-weight: 900` here would clamp
 * to the same 700 face and paint identical pixels, which is why #87 shipped
 * 700 and said so.
 *
 * SO THE EXTRA WEIGHT COMES FROM THE STROKE, NOT FROM THE AXIS. 0.5px of
 * `-webkit-text-stroke` in the same colour thickens every stem by 1px total
 * (half in, half out) without touching the metrics the rest of the masthead is
 * measured against -- the box stays 302.953 x 45 and .site-description below it
 * does not move. It degrades to plain 700 where the property is unsupported,
 * which is the correct failure.
 *
 * IF THIS IS STILL NOT ENOUGH the honest options are a different typeface for
 * the wordmark or a wordmark IMAGE, and both are the client's call, not a
 * number to nudge. Do not "fix" it by raising the stroke past ~0.6px: past
 * that the counters in the A and the O start to fill in and it reads as a
 * smudge rather than as a bolder Oswald. */
.site-title {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-site-title);
	font-weight: var(--ta-w-bold);
	letter-spacing: var(--ta-ls-site-title);
	line-height: var(--ta-lh-site-title);
	-webkit-text-stroke: 0.5px currentColor;
	text-transform: uppercase;
}

.site-description {
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-small);
	font-weight: var(--ta-w-light);
	letter-spacing: normal;
	line-height: var(--ta-lh-small);
	text-transform: none;
}

/* SCOPED TO .nav--main, NOT .main-navigation. Both nav lists live inside
 * .main-navigation, and the social one is 18px with normal tracking -- a rule
 * on `.main-navigation a` sizes the social icons at 24px too. The capture's
 * `.main-navigation a` row reads 24px because getComputedStyle sampled the
 * first match, which is a primary-nav link; the live rule itself is on
 * `.nav--main`. Caught by re-measuring DEV in item 3. */
.nav--main a {
	color: var(--ta-c-link);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-nav);
	font-weight: var(--ta-w-medium);
	letter-spacing: var(--ta-ls-nav);
	line-height: var(--ta-lh-nav);
	text-transform: uppercase;
}

.entry-title {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-entry-title);
	font-weight: var(--ta-w-normal);
	letter-spacing: var(--ta-ls-entry-title);
	line-height: var(--ta-lh-entry-title);
	text-transform: uppercase;
}

/* The link inside a card title is 500 where the h1 around it is 400. */
.entry-title a {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-entry-title);
	font-weight: var(--ta-w-medium);
	letter-spacing: var(--ta-ls-entry-title);
	line-height: var(--ta-lh-entry-title);
	text-transform: uppercase;
}

.entry-meta,
.entry-meta a {
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-meta);
	font-weight: var(--ta-w-normal);
	letter-spacing: normal;
	line-height: var(--ta-lh-meta);
	text-transform: uppercase;
}

/* The LINK inside the meta is #000 at weight 500 where the block around it is
 * #3e3f40 at 400 -- measured on home.desktop, home.mobile and the article, so
 * it is not template-specific. #374 item 5, correcting item 4, which folded
 * the anchor in with the block above and lost both values. */
.entry-meta a {
	color: var(--ta-c-link);
	font-weight: var(--ta-w-medium);
}

.entry-content--short {
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-light);
	letter-spacing: normal;
	line-height: var(--ta-lh-copy);
	text-transform: none;
}

.site-footer,
.site-info {
	color: var(--ta-c-footer-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-small);
	font-weight: var(--ta-w-light);
	letter-spacing: normal;
	line-height: var(--ta-lh-small);
	text-transform: none;
}

.site-footer {
	background-color: var(--ta-c-footer-bg);
}

.footer-menu a {
	color: var(--ta-c-footer-link);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-small);
	font-weight: var(--ta-w-light);
	line-height: var(--ta-lh-small);
	text-transform: none;
}


/* --------------------------------------------------------------------------
 * 5. Form controls
 * ------------------------------------------------------------------------*/

button {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-button);
	font-weight: var(--ta-w-light);
	letter-spacing: var(--ta-ls-button);
	line-height: var(--ta-lh-button);
	text-transform: uppercase;
}

input[type="submit"] {
	background-color: var(--ta-c-invert-bg);
	color: var(--ta-c-invert-text);
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-submit);
	font-weight: var(--ta-w-medium);
	letter-spacing: var(--ta-ls-submit);
	line-height: var(--ta-lh-submit);
	text-transform: uppercase;
}

input[type="text"],
input[type="email"],
textarea {
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-light);
	line-height: var(--ta-lh-body);
}


/* --------------------------------------------------------------------------
 * 6. Layout scaffolding
 *
 * The containers only. The desktop left rail and the card grid inside them are
 * items 3 and 4; this establishes the boxes they measure against so both are
 * built on one set of numbers.
 * ------------------------------------------------------------------------*/

/* THE 1404px BOX IS A BODY BORDER, not a max-width -- corrected in #374 item
 * 6, and it is the mechanism, not a detail.
 *
 * Items 2 and 3 produced the measured 1404 at x=18 with
 * `max-width:1404px; margin:0 auto` here, plus 78px of padding on #page. That
 * lands .site-content and the whole grid on the right pixels and is wrong
 * about WHY, with two consequences that only showed up when the footer
 * arrived: .site-footer is a SIBLING of .site-content, so it got no such
 * max-width and spanned the full 1440; and live's own literal rule for a
 * single, `.single .site{padding-top:0}`, had to be fudged to 18px because the
 * 18 was being supplied from the wrong place.
 *
 * Live's actual rule, from the bundle and confirmed by the capture's `body`
 * dump (border-top/right/left 18px, border-bottom 0, colour rgb(191,191,191)):
 *
 *     @media (min-width: 900px) {
 *       body { border: 18px solid black; border-bottom: 0 }
 *       body:before { background: black; content: ""; height: 18px;
 *                     left: 0; position: fixed; top: 0; width: 100%;
 *                     z-index: 9999 }
 *     }
 *
 * `black` is the theme's; the capture measures #bfbfbf, the footer grey --
 * wp.com's custom-colors layer flattening it, for the fourth time in this
 * stylesheet. So the page sits in an 18px grey FRAME, open at the bottom
 * because the footer's own grey continues it, and the :before is a fixed strip
 * that keeps the top edge of that frame in place while the page scrolls. The
 * 1404 and the x=18 then fall out of it for .site-content, .site-footer and
 * everything else, and #page's padding drops to live's own 60px.
 *
 * Below 900px there is no frame at all -- measured, .site-content is 390 wide
 * at x=0 -- and #page's 72px is what clears the fixed .mobile-header (item 8).
 */
.site-content {
	padding: 0;
	width: 100%;
}

.site-main {
	padding-bottom: var(--ta-sp-6);
	width: 100%;
}

@media only screen and (min-width: 900px) {
	body {
		border: var(--ta-outer-gutter) solid var(--ta-c-footer-bg);
		border-bottom: 0;
	}

	body:before {
		background: var(--ta-c-footer-bg);
		content: "";
		height: var(--ta-outer-gutter);
		left: 0;
		position: fixed;
		top: 0;
		width: 100%;
		z-index: 9999;
	}

	.site-content {
		padding-left: var(--ta-p-content);
		padding-right: var(--ta-p-content);
	}
}


/* ==========================================================================
 * 8. Masthead + primary nav -- server-configs#374 item 3
 *
 * The live desktop masthead is a 420px-wide LEFT RAIL, not a top bar: logo,
 * title, tagline, nav and social links stacked in a column at x=102 with the
 * card grid to its right. Measured, screenshots/home.desktop.fold.png.
 *
 * WHAT THE LIVE SITE DID THAT WE DELIBERATELY DO NOT. The theme ships
 * `.site-header{opacity:0}` and a JS pass that adds `.is-visible` to fade it
 * in; the captured markup already carries the class. This rebuild has no such
 * JS, so `is-visible` is written into the markup statically and the opacity:0
 * default is NOT reproduced. Copying it verbatim would leave the masthead
 * permanently invisible. The same reasoning applies to `body{opacity:0}`.
 *
 * The rail is floated, not masonry-positioned. Live runs JS masonry, which
 * absolutely positions each `.grid__item` on a 419.953px column pitch while
 * each item carries 24px of left padding -- so consecutive columns overlap
 * their own padding, and three columns fit 1284px. A float cannot overlap.
 * ITEM 4 OWNS THE PITCH: it must reproduce 419.953px between column origins,
 * not 444px, or the third column will not fit. This item establishes only the
 * first cell and the container chain around it.
 *
 * BELOW 900px the nav stays in normal document flow here. Live turns
 * `.main-navigation` into a fixed off-canvas drawer at `left:-100%` opened by
 * a `.mobile-header` button -- which without its JS would be a nav no reader
 * could reach. That drawer, the `.mobile-header` bar and its triggers are
 * ITEM 8, by the checklist's own split. Until then the nav is visible and
 * usable at every width.
 * ------------------------------------------------------------------------*/

/* Icon font for the social links. This is the retired `patch` theme's OWN
 * FontAwesome 4.3.0, self-hosted from the capture and sha256-verified. It is
 * given a scoped family name on purpose: the seed already loads FontAwesome
 * 3.2.1 at /vendor/font-awesome/ under the family "FontAwesome" for its
 * `icon-*` classes, and 3.2.1 does not contain the codepoints the live theme
 * uses -- facebook-official (f230) and instagram (f16d) both arrived in 4.1.
 * Two families, no collision, and the seed's own icons keep working. */
@font-face {
	font-family: "FontAwesomePatch";
	font-style: normal;
	font-weight: 400;
	font-display: block;
	src: url("/fonts/fontawesome-patch.woff2") format("woff2");
}

/* The container chain, live's own: #page > #content.site-content >
 * #primary.content-area > main.site-main > #posts.grid > .grid__item.
 *
 * The top offset is MEASURED FROM THE RESULT, not copied from a rule: live puts
 * .site-content at y=78 desktop / y=72 mobile with its own padding and margin
 * both 0, and the rule that supplies that offset is not among the ~130
 * selectors the capture dumped. The 72px is also what clears the 50px fixed
 * .mobile-header (item 8), which is why the mobile figure is the smaller one. */
#page {
	background-color: var(--ta-c-page);
	padding-top: 72px;
}

.content-area {
	width: 100%;
}

/* base.css ships `#main { padding-top: 225px }` -- motorsportmedia reserving
 * space for its fixed navbar, which this item deleted. An ID selector beats
 * every class rule in this file, so it silently pushed the masthead and the
 * whole grid 225px down the page: measured .site-header at y=225 against the
 * capture's y=128. Killed with ID+class so it cannot come back on a tie, and
 * left here rather than edited into base.css because base.css is the seed's and
 * goes away when items 4-7 finish replacing the markup that needs it. */
#main.site-main {
	padding-top: 0;
}

/* flow-root, and not for tidiness: the grid holds floated cells (the rail is
 * one) so it needs a block formatting context to contain them, AND without one
 * the first cell's 50px top margin collapses straight up through #posts, #main,
 * #primary and #content -- all zero-padding block boxes -- to #page's padding
 * edge, dragging every container down with it. The masthead still landed at the
 * measured y=128, but .site-content sat at 128 instead of 78. Live never hits
 * this because masonry absolutely positions the cells, so no margin
 * participates in the flow at all. */
.grid {
	border-right: 0 solid transparent;
	display: flow-root;
	margin: 0 auto;
	max-width: 400px;
	position: relative;
}

/* Live's own base cell. Width and float arrive at the breakpoints in section 9;
 * this is the single-column phone case. */
.grid__item {
	border-left: 0 solid transparent;
	margin-bottom: 30px;
	width: 100%;

	/* STATED, NOT INHERITED -- woodzgit/theauto#59, and it is a fifth entry for
	 * the bootstrap ledger on #33.
	 *
	 * The ONLY `*, *:before, *:after { box-sizing: border-box }` on this site is
	 * inside vendor/bootstrap/css/bootstrap.min.css. Nothing in base.css,
	 * components.css or this file declares it for anything but `html`, and
	 * `html { box-sizing: border-box }` does not inherit. So every grid cell is
	 * border-box ONLY for as long as bootstrap is linked, and #59's sidebar
	 * insets are padding -- the day bootstrap comes out, a content-box cell
	 * would take that padding as EXTRA width and the rail would overhang the
	 * next column by exactly the 60px this issue just removed.
	 *
	 * It was also visible as measurement flap: measure.py caught the page twice
	 * before bootstrap had applied and read `content-box`, which is what a
	 * -59.50 clearance in an otherwise-clean sweep was.
	 *
	 * Same computed value as today. It simply stops being borrowed. */
	box-sizing: border-box;
}

/* Live's rule here is `margin: 12px 48px 20px`, and the 12px is NOT reproduced
 * on purpose. In live it collapses out through the container chain -- the
 * capture measures .site-header with margin-top:12px and y=72, the same y as
 * .site-content, i.e. the margin pushed the parent rather than the child.
 * #posts is a block formatting context here (it has to contain the floated
 * desktop rail), so a 12px margin would be contained instead of collapsed and
 * land the masthead at y=84 against the measured 72. The 72px on #page already
 * carries it. */
.site-header {
	display: block;
	margin: 0 var(--ta-mobile-rail-inset) 20px;
	opacity: 1;
	position: relative;
	text-transform: uppercase;
	z-index: 100;
}

/* Branding ---------------------------------------------------------------- */

.site-branding {
	margin-left: 0;
	margin-right: 0;
}

.site-logo-link {
	display: block;
}

/* The logo has NO source above 567x567 (Auto-1-copy.jpg, 84,740 B origin
 * original). Live requested a 500x500 Jetpack Photon resize, which is the
 * 24,874 B file shipped here as auto-logo-500.jpg; auto-logo-567.jpg is the
 * origin original and the srcset's only larger rung. Do not upscale past it --
 * a retina masthead needs the asset re-made. */
.site-logo {
	height: auto;
	max-width: 100%;
}

/* Live centres the logo only below the breakpoint. */
.site-branding img {
	display: block;
	margin: 0 auto 5px;
}

.site-title {
	margin: 0 0 0 -3px;
	text-align: center;
}

.site-header .site-title a {
	color: var(--ta-c-link);
	text-decoration: none;
}

.site-description {
	text-align: center;
	text-transform: none;
}

/* Primary nav ------------------------------------------------------------- */

.main-navigation {
	position: relative;
}

/* The size and 1.5 ratio sit on the LIST, not just the links: that is what
 * makes `.nav--main li` compute 24px/36px, as measured, while the links
 * themselves are 24px/34px. Setting it only on the anchor left the li at the
 * inherited 16/26 and every wrapped nav label short by 10px a line. */
.nav--main {
	font-size: var(--ta-fs-nav);
	line-height: 1.5;
	list-style: none;
	margin: 0 0 var(--ta-sp-4);
	overflow: hidden;
	padding-left: 0;
}

.nav--main li {
	display: block;
	margin-bottom: 10px;
	position: relative;
}

/* -2/+2, NOT the -7/-6/+7/+6 item 3 transcribed -- corrected in item 5.
 * The theme carries BOTH rules: `.nav--main li > a{margin-left:-7px;...}` and
 * `.nav--main a:not([class*="wp-block"]):not(.img-link){margin-left:-2px;
 * margin-right:-2px;padding-left:2px;padding-right:2px}`. The second is
 * (0,3,1) against the first's (0,1,2), so it wins, and the capture measures
 * -2/+2 on the anchor at BOTH widths and on BOTH templates. The -7 put every
 * nav link 5px left of live's, on the home page too; it went unnoticed because
 * item 4 diffed `.nav--main li`, which does not move.
 *
 * The two zeroes are load-bearing against the SEED, not against live. The list
 * carries bootstrap's `nav` class as well as `nav--main`, so
 * `.nav > li > a{display:block;padding:10px 15px}` applies at (0,1,2) and this
 * rule only overrode the horizontal half of it: measured on DEV, the anchor's
 * box came out 48px tall against the capture's 28. It changes no layout while
 * the anchor is `display:inline` (vertical padding on an inline box does not
 * grow the line box) but it is 20px of paintable area in the wrong place, and
 * below 900px the anchor is inline-block, where it would. */
.nav--main li > a {
	display: inline-block;
	line-height: var(--ta-lh-nav);
	margin-left: -2px;
	margin-right: -2px;
	padding-bottom: 0;
	padding-left: 2px;
	padding-right: 2px;
	padding-top: 0;
}

.nav--main a {
	letter-spacing: var(--ta-ls-nav);
	position: relative;
}

/* THE CURRENT ITEM GETS NO TREATMENT AT ALL, and that is measured rather than
 * assumed. Live marks it with `.current-menu-item` -- on
 * https://theauto.page/road-tested/ the class is there -- and then styles it
 * exactly like every other link: `.nav--main .current-menu-item a` computes
 * font-weight 500 and width 185.344, the same two numbers as `.nav--main a`
 * beside it. Not a lighter emphasis. None.
 *
 * This rule used to say `font-weight: var(--ta-w-bold)`, under a comment that
 * had already recorded the measurement as "identical to a plain nav link" and
 * then concluded "so the only faithful treatment is weight". Those two halves
 * contradict each other; identical means nothing is applied. It showed up as
 * `.nav--main a` measuring 106.70 against live's 104.23 on every category
 * archive at 1440 and 187.33 against 185.34 at 390 -- and only on archives,
 * because the home page has no current item, which is why the home page
 * matched live perfectly and hid it.
 *
 * The seeded code painted this #f1c40f, a motorsportmedia accent that exists
 * nowhere in this theme. That was right to remove; removing it did not go far
 * enough. woodzgit/theauto#31. */

/* Live's nav hover is two `:hover` rules that cancel: the first paints
 * #ffde00 behind the link and lays a solid-white gradient over the top 1em,
 * the second grows that white to 100% -- net effect, no visible change. That
 * is the wp.com `custom-colors` layer flattening the theme's yellow. Nothing
 * is invented here to fill the gap; the link simply underlines, which is the
 * one hover affordance the capture cannot contradict. */
.nav--main a:hover,
.nav--main a:focus {
	text-decoration: underline;
}

/* Social links ------------------------------------------------------------ */

/* Icon-only by design: the label is real text for screen readers and search,
 * hidden by a transparent colour, with the glyph drawn in :before. */
/* 18px, and the `a` is 1.75em of it = 31.5px wide. Tracking stays normal --
 * the primary nav's 1.44px does not reach here. */
.nav--social {
	font-size: 18px;
	left: -6px;
	letter-spacing: normal;
	/* 1.625 * 18 = 29.25, measured, and the THIRD place this ratio has been
	 * found written as a length -- after `.entry-content p` and
	 * `.grunion-field-label` in item 7. Item 3 put `line-height: 1` on the
	 * anchor, which made the row 45px against live's 38.5 and was 27.5px of the
	 * masthead overshoot logged since item 4. #374 item 8. */
	line-height: 1.625;
	list-style: none;
	margin: 0 0 10px;
	padding-left: 0;
	position: relative;
}

.nav--social li {
	display: inline-block;
	margin: 0;
	position: static;               /* bootstrap's `.nav > li > a` sets relative */
}

/* `.nav--social > li > a` and not `.nav--social a`, and the child combinators
 * are the whole point: the list carries bootstrap's `nav` class as well, so
 * `.nav > li > a { padding: 10px 15px }` matches at (0,2,1) and BEATS a
 * (0,1,1) rule here whatever it says. Item 3's `padding` lost that way and put
 * 20px of vertical padding on every social icon; item 5 found the same fault
 * on the primary nav's anchors. Measured: the anchor came out 49.25 tall
 * against live's 29.25 with the padding still winning. #374 item 8. */
.nav--social > li > a {
	color: transparent;
	display: inline-block;
	font-size: inherit;
	letter-spacing: normal;
	line-height: inherit;
	overflow: hidden;
	padding: 0;
	position: static;
	white-space: nowrap;
	width: 1.75em;
}

/* `line-height: inherit`, NOT `1`, and it is the 1px woodzgit/theauto#31 was
 * handed alongside the .entry-title drift. `1` against this pseudo's own 18px
 * font-size makes the glyph box 18px tall; live inherits the anchor's 29.25px
 * and gets a 29.25px box. Both sides are inline-block on the baseline, so the
 * anchor's line box is the glyph plus the strut's descender -- live measures
 * .nav--social a at 30.25 and this build measured 29.25, and .nav--social at
 * 38.5 against 37.5, on every page at both widths.
 *
 * It is the same shape as the masthead logo in section 5 and was found the same
 * way: #31's font fix moved neither, which is what left the two of them
 * standing alone and measurable. Nothing here sets 29.25 -- it inherits, so it
 * tracks .nav--social's line-height rather than pinning a number that would be
 * wrong the day the row's type changes. */
.nav--social a:before {
	background: transparent;
	border-radius: 3px;
	color: var(--ta-c-heading);
	display: inline-block;
	font-family: "FontAwesomePatch";
	font-size: 18px;
	font-style: normal;
	font-weight: 400;
	line-height: inherit;
	padding-left: 0.4em;
	padding-right: 0.4em;
	text-align: center;
	text-transform: none;
	transition: background 0.2s;
}

/* #ffde00 is the theme's one real accent, and this is the only place the
 * capture shows it actually reaching a pixel. */
.nav--social a:hover:before,
.nav--social a:focus:before {
	background: #ffde00;
}

/* Codepoints exactly as the live bundle set them, FontAwesome 4.3.0. */
.nav--social a[href*="facebook"]:before {
	content: "\f230";
}

.nav--social a[href*="instagram"]:before {
	content: "\f16d";
}

.nav--social a[href*="search"]:before {
	content: "\f002";
}

/* Desktop: the rail ------------------------------------------------------- */

/* THE 24px INSET MOVED OFF THE CELL AND ONTO THE GRID -- server-configs#374
 * item 4, correcting item 3.
 *
 * Item 3 put `padding-left: 24px` on every .grid__item and gave .site-header a
 * literal 420px width. That measured correctly with ONE cell and cannot work
 * with three: 3 x (24 + 420) = 1332px against a 1284px .site-main, so the third
 * column would not fit.
 *
 * Live's own mechanism, from the bundle, is a transparent 24px LEFT BORDER on
 * #posts.grid. Masonry positions each cell with `left:` relative to the grid's
 * PADDING box -- i.e. inside that border -- so the columns start at x=102 and
 * are 33.33% of the remaining 1260px, which is the measured 419.953px pitch.
 * Each .entry-card then pulls itself back out with margin-left:-24px, which is
 * why a card's own box starts at the column origin and the columns "overlap"
 * their own inset. A float grid reproduces all of it exactly; a per-cell
 * padding cannot. See section 9. */
@media only screen and (min-width: 480px) {
	.grid {
		border-left: var(--ta-rail-inset) solid transparent;
		max-width: 450px;
	}

	.layout-grid .site-header {
		padding-right: var(--ta-rail-inset);
	}
}

@media only screen and (min-width: 900px) {
	/* Live's own rule, and the last 50px of the masthead's y=128: .site-content
	 * starts at 78 and the first cell drops 50 below it. */
	.grid__item:nth-child(1) {
		margin-top: 50px;
	}

	/* 60, not 78. The other 18 is the body border added in section 6 -- which
	 * is where live's 18 always came from. */
	#page {
		padding-top: var(--ta-sp-6);
	}

	/* 100%, NOT 420px. The rail is one cell of the grid, so its width is the
	 * column width -- 33.33% of 1260 = 419.958px at a 1440 viewport, against
	 * the capture's measured 419.953. --ta-w-rail stays as the RECORD of that
	 * measurement; it is deliberately no longer what sets the width, because a
	 * fixed 420 would not track the 50% / 33.33% / 25% column ladder. */
	.site-header {
		float: left;
		margin: 0;
		width: 100%;
	}

	.site-header.site-header {
		padding-right: 0;
	}

	/* 420 - 96 - 24 = 300, which is the measured .site-branding width. */
	.site-branding,
	.nav--main,
	.nav--social {
		margin: 0 var(--ta-sp-7) var(--ta-sp-4) var(--ta-rail-inset);
	}

	/* The social row is the LAST thing in the rail, and its bottom margin is the
	 * ENTIRE `.site-header` height defect from #70. It was 10px here and that
	 * was measured off live's own stylesheet -- live really does say 10px on the
	 * grid templates. Copying the number was still wrong, because the number is
	 * not what the header measures.
	 *
	 * `ul.nav--social` is the last in-flow box inside `.main-navigation`, and the
	 * nav has no bottom padding and no bottom border -- so this margin COLLAPSES
	 * THROUGH the nav's bottom edge and lands against `.site-header`. What
	 * happens next depends on whether `.site-header` is a block formatting
	 * context, and that is the one place this build and live deliberately differ:
	 *
	 *   live, GRID    `.site-header` is `float:none; position:static` -- NOT a
	 *                 BFC, so the 10px collapses OUT of the header entirely and
	 *                 the measured height excludes it. Gap below the row: 0.
	 *   this build    `.site-header` is `float:left` on every template (section
	 *                 9 / `theauto.css:1099`: live runs JS masonry and a float
	 *                 cannot overlap, so the rail is floated) -- which IS a BFC,
	 *                 so the same 10px is CONTAINED. Gap below the row: 10.
	 *
	 * Measured 2026-08-16, live vs DEV at 1440 on `/`:
	 *
	 *   ul.nav--social  height 38.5   both sides, margin-bottom 10px both sides
	 *   nav.main-navigation  282.5    both sides
	 *   .site-branding       374.078  both sides
	 *   .site-header         680.578 live   690.578 this build   <- the +10
	 *
	 * Every child matches and only the container differs, which is exactly what
	 * #70 reported and could not trace. So the fix is 0, NOT live's 10: the
	 * float is a decision we are keeping, and 0 is the value that reproduces
	 * live's measured header height given that decision. Copying live's literal
	 * 10 is what produced the defect.
	 *
	 * The earlier note here read "live gives it 10 below, not 24" and cited
	 * `.site-header` 708.08 against live's 680.58. That measurement was real and
	 * this rule closed 17.5px of it; the last 10px is the collapse, and it could
	 * not be seen by looking at the row. #374 item 8, then #70.
	 *
	 * Singles set 24px of their own further down -- see `.single .nav--social`
	 * in the 900px block at section 8. There the fork is genuine: live floats
	 * its masthead on singles too, so both sides contain the margin and live's
	 * own value is what we want. */
	.nav--social {
		margin-bottom: 0;
	}

	/* INLINE, and the margin goes entirely. Same shape as the `.nav--main a`
	 * note above, and found the same way. The base rule centres the logo with
	 * `display:block; margin:0 auto 5px` -- which is live's arrangement BELOW
	 * the breakpoint and measured identical there. At desktop live leaves the
	 * image INLINE with no margin at all, so the anchor's line box adds the
	 * strut's 8px descender under it: `.site-logo-link` measures 307.95 against
	 * a 299.95 image. Carrying the block rule up here replaced that 8px with
	 * the 5px margin and left `.site-branding` 3px short -- 371.08 against
	 * live's 374.08 -- which then moved the title, the tagline, the nav and the
	 * social row on EVERY page.
	 *
	 * This is the 3px woodzgit/theauto#31 predicted its own font fix would
	 * close. It did not: the fix closed every other box on #31's table and left
	 * this one untouched, which is exactly how it was finally located. It is an
	 * item-3 defect the font defect was sitting on top of.
	 *
	 * 8px is not hardcoded anywhere here on purpose -- it is the strut of Work
	 * Sans 16px/26px and it follows the type. That only lands on live's number
	 * now that section 1 declares the fixed weights; against the old variable
	 * range the same rule would have produced a different descender.
	 *
	 * `vertical-align: baseline` IS THE LOAD-BEARING LINE, and dropping it was
	 * this fix's own first attempt: `display:inline; margin:0` alone measured
	 * .site-branding at 366.08, FIVE px worse than the 371.08 it was meant to
	 * repair. It removed the margin and produced no descender, because
	 * /vendor/bootstrap/css/bootstrap.min.css carries `img{vertical-align:
	 * middle}` and a middle-aligned image centres on the baseline instead of
	 * sitting on it, collapsing the line box onto the image. Live's theme has
	 * no bootstrap under it and its .site-logo computes `baseline`, so this
	 * restores the only value that yields live's 8px. Bootstrap is inherited
	 * with the motorsportmedia seed and is still linked ahead of this file. */
	.site-branding img {
		display: inline;
		margin: 0;
		vertical-align: baseline;
	}

	.site-title {
		font-size: var(--ta-fs-site-title);
		text-align: inherit;
	}

	.site-description {
		text-align: inherit;
	}

	/* Two columns of 150px inside the 300px rail. */
	.nav--main > li {
		float: left;
		padding-right: 10px;
		width: 50%;
	}

	/* BOTH SELECTORS, and that is the fix, not belt-and-braces. Live's rule is
	 * `.nav--main a{display:inline !important}` and the !important is doing real
	 * work: the theme's own `.nav > li > a` pattern rule makes it inline-block,
	 * and item 3 transcribed that as `.nav--main li > a`, which is MORE specific
	 * than `.nav--main a` and so kept winning here. Measured on DEV before this
	 * change: `.nav--main li` 88px tall against the capture's 72, because an
	 * inline-block anchor sits on the baseline and drags the line box down by
	 * its descender. Over four rows that is 70px of extra masthead -- which
	 * matters to ITEM 4, not just to the rail: the masthead is the first cell of
	 * the card grid, so its height decides where the first left-column card
	 * lands. Fixed with a same-specificity later rule rather than !important.
	 * server-configs#374 item 4, correcting item 3. */
	.nav--main a,
	.nav--main li > a {
		display: inline;
	}
}


/* --------------------------------------------------------------------------
 * 7. Mobile type overrides
 *
 * The only type value that changes below the 900px breakpoint is .site-title:
 * 36/45 with 1.44px tracking becomes 30/37.5 with 1.2px. Because the ratio and
 * the em tracking are shared, one size override reproduces all three numbers.
 * body and .entry-title are unchanged at 390px -- measured, not assumed.
 * ------------------------------------------------------------------------*/

@media only screen and (max-width: 899px) {
	:root {
		--ta-fs-site-title: 30px;
	}
}


/* ==========================================================================
 * 9. The archive card grid -- server-configs#374 item 4
 *
 * Used by the home page (default.asp) and by all eight category archives
 * (category.asp). Both emit the same cell; the archive adds a .page-header cell
 * in front of the cards. Every number below is transcribed from the live
 * capture's computed/home.desktop.json and computed/archive-news.desktop.json,
 * or from the theme bundle theauto.page__static_b557d47b.css where the capture
 * did not sample the selector.
 *
 * THE GEOMETRY, AS MEASURED AT A 1440 VIEWPORT
 *
 *   .site-main      1284 @ x=78          (section 6)
 *   #posts.grid     1284 border-box, 24px transparent left border -> the
 *                   columns start at x=102 and share 1260px
 *   .grid__item     33.33% of 1260 = 419.958   (live's masonry pitch: 419.953)
 *   .entry-card     margin-left -24, margin-right 48 -> 395.953 wide, and its
 *                   left edge lands ON the column origin: 102 + 419.953 - 24
 *                   = 497.95, against the capture's .hentry x=498
 *   .entry-header   margin-left 48 -> x=546, width 347.953. Capture: 546/348.
 *
 * WHY PLAIN FLOATS REPRODUCE MASONRY HERE, EXACTLY
 *
 * Live runs JS masonry. We have no JS, and live's own stylesheet without it is
 * `float:left; width:33.33%` -- which is what this is. That normally packs
 * worse than masonry, but it does not here, and the capture is why: every one
 * of the 20 home cards is the SAME height. Read the masonry `top:` values in
 * dom/home.desktop.html and the pitch down each column is 444.547px without
 * exception (414.547 card + 30 margin). The one tall cell is the masthead, at
 * 770.578; floats step down past it in exactly the same order masonry did --
 * verified box by box with ops/measure.py boxes.
 *
 * *** SO THE CARDS MUST STAY EQUAL HEIGHT, AND THAT IS WHAT THE THREE FIXED
 * SIZES BELOW ARE FOR. *** They are the measured live values, not a design:
 *
 *   image wrapper   264.172px  = 395.953 at the 640x427 masonry aspect
 *   .entry-header--medium  75.375px  = 2 lines at 26/37.7
 *   .entry-content--short  48px      = 2 lines at 16/24
 *   + 1 padding-top + 10 header margin + 8 + 8 content margins = 414.547
 *
 * DEVIATION, STATED: live let those three boxes size to their content and
 * happened to have a 2-line title and a 2-line excerpt on all 20 cards; we pin
 * them and clip the overflow, because our titles come out of a database that
 * has 1,156 of them and one 3-line title would ripple through the whole float
 * grid. `.entry-title{overflow:hidden}` is live's own; the heights are the
 * measurement made load-bearing.
 * ------------------------------------------------------------------------*/

/* THE GRID PAGE'S CONTENT INSET IS 24px UNTIL 1360, NOT 60 -- woodzgit/theauto#39
 * item 2, the 1280 half.
 *
 * Section 6 gives .site-content a flat 60px inset from 900 up. That is live's
 * rule for a SINGLE and a PAGE, and it is wrong for the grid, which live insets
 * by 24 and only widens to 60 at a breakpoint this build never carried. From
 * live's own theme source (patch-lite 1.3.4, style.css around the "7.1 - Grid"
 * heading), both blocks literally:
 *
 *     @media only screen and (min-width:  900px) {
 *       .layout-grid .site-content { padding-left: 24px; padding-right: 24px } }
 *     @media only screen and (min-width: 1360px) {
 *       .layout-grid .site-content { padding-left: 60px; padding-right: 60px } }
 *
 * MEASURED ON theauto.page AT 1280, before the domain moves:
 *
 *                        this build     live
 *   .site-content pad      60           24
 *   .site-main / #posts  1124 @ x=78  1196 @ x=42     <- 72px = 2 x (60 - 24) + ...
 *   .grid__item          366.625      390.625         <- 33.33% of 72px less
 *   .site-header         366.625      390.625
 *   .site-logo           246.625      270.625         <- the -24 the reviewer saw
 *
 * So the reported "logo looks smaller" at 1280 was never a logo rule at all: the
 * masthead is the grid's first CELL, the cell is a third of the container, and
 * the container was 72px short. The 1450 block (section 20) fixed the >=1600
 * half of the same report; this is the other end, and its cause is unrelated.
 *
 * THE BAND IS 900-1359, NOT JUST 1280. Every width in it was wrong by the same
 * mechanism; 1440 is above the step, which is why the original measurement pass
 * -- taken at 1440, the capture's desktop width -- saw nothing. Third time that
 * has happened on this issue.
 *
 * WHY .layout-grid.home / .layout-grid.archive AND NOT LIVE'S BARE .layout-grid.
 * `layout-grid` is on EVERY body here (header.asp) exactly as it is on live's,
 * so live's own 24px rule matches its singles too and is beaten there only by a
 * later `.single .site-content,.page:not(.entry-card) .site-content{padding:60px}`
 * at equal specificity -- i.e. by source order. Reproducing that literally would
 * make this block's position in the file load-bearing for a template it is not
 * about. Anchoring on the page class instead wins outright (0,3,0), cannot reach
 * a single, and produces live's numbers exactly. Verified: the article template
 * at 1280 already matches live on every x and width, and must not move.
 * --------------------------------------------------------------------------*/
@media only screen and (min-width: 900px) {
	.layout-grid.home .site-content,
	.layout-grid.archive .site-content {
		padding-left: var(--ta-p-content-grid);
		padding-right: var(--ta-p-content-grid);
	}
}

@media only screen and (min-width: 1360px) {
	.layout-grid.home .site-content,
	.layout-grid.archive .site-content {
		padding-left: var(--ta-p-content);
		padding-right: var(--ta-p-content);
	}
}

/* The cell ladder, live's own breakpoints. 900 -> two columns, 1260 -> three,
 * 1700 -> four. NOT 1200: the checkpoint note carried into this item said the
 * 33.33% rule sat at a 1200px breakpoint; the bundle says 1260, and 1260 is
 * what is reproduced here. */
@media only screen and (min-width: 900px) {
	.grid {
		margin-top: 0;
		max-width: 1000px;
	}

	.grid__item {
		float: left;
		width: 50%;
	}
}

@media only screen and (min-width: 1260px) {
	.grid {
		max-width: 1350px;
	}

	.grid__item {
		width: 33.33%;
	}

	/* The third cell drops 50px, the same way the first does. On the home page
	 * that is the second card; on an archive it is the FIRST card, because the
	 * .page-header takes cell 2 -- which is why the capture measures the
	 * archive's first .hentry at y=128 and the home page's at y=78. */
	.grid__item:nth-child(3) {
		margin-top: 50px;
	}
}

@media only screen and (min-width: 1700px) {
	.grid {
		max-width: 1850px;
	}

	.grid__item {
		width: 25%;
	}
}


/* The card ---------------------------------------------------------------- */

/* opacity is 1, not live's 0. The theme fades cards in from JS by adding
 * .is-visible; we write that class into the markup statically and skip the
 * transition, for the same reason item 3 did it for .site-header -- copying
 * opacity:0 with no JS behind it leaves the whole grid invisible. */
.entry-card {
	background: var(--ta-c-card);
	opacity: 1;
	padding-top: 1px;
	position: relative;
}

.entry-card:after {
	clear: both;
	content: "";
	display: table;
}

/* Meta ---- INVISIBLE ON PURPOSE, and this is not dead markup.
 * Measured: opacity 0, position absolute, z-index -1. The theme parks the byline
 * behind the card and only reveals it on touch devices
 * (`.touch .entry-card .entry-meta{opacity:1;position:static}`). It still
 * carries the category, the author and a machine-readable <time>, so it is
 * emitted in full rather than dropped. */
.entry-card .entry-meta {
	font-size: var(--ta-fs-meta);
	font-weight: var(--ta-w-normal);
	letter-spacing: 0;
	margin-bottom: 0;
	margin-top: 4px;
	opacity: 0;
	padding-bottom: 12px;
	position: absolute;
	z-index: -1;
}

.entry-card .entry-meta > * {
	float: left;
}

.entry-card .entry-meta .byline {
	margin-bottom: -5px;
}

.entry-card .entry-meta .byline,
.entry-card .entry-meta .posted-on {
	margin-top: 5px;
}

.entry-card .entry-time {
	display: none;
}

/* #d1d1d1, NOT #ffde00 -- item 4 wrote the yellow here from the theme bundle
 * and the capture measures the flattened grey on the card as well as on the
 * single: home.desktop.json, home.mobile.json and
 * article-passion-precision.desktop.json all read rgb(209, 209, 209) with
 * colour rgb(0, 0, 0). wp.com's custom-colors layer paints over the theme's
 * accent everywhere except the social-icon hover, which is the one place
 * section 8 reproduces it. Corrected in #374 item 5; it was invisible because
 * the card's whole .entry-meta is opacity:0 at desktop -- but it is not
 * invisible on a touch device, where the theme shows that block. */
.cat-links {
	background-color: var(--ta-c-chip);
	color: var(--ta-c-link);
	margin-right: 10px;
	padding: 6px 14px;
}

.byline {
	color: var(--ta-c-heading);
	text-transform: capitalize;
}

.byline .author {
	text-transform: uppercase;
}

.posted-on {
	color: var(--ta-c-footer-link);
	display: inline-block;
	margin-left: 4px;
}

.posted-on a {
	color: currentColor;
	font-weight: var(--ta-w-light);
}

.posted-on:before {
	content: "/";
	margin-right: 4px;
}

/* Image */

.entry-image {
	overflow: hidden;
}

.entry-card .entry-image {
	background-color: #000;
	display: block;
	position: relative;
	z-index: 32;
}

/* The aspect ratio IS the card's height. 640x427 is the theme's own
 * `patch-masonry-image` size, which is what live's Photon URLs requested and
 * what /imgrzport/.../427/640.jpg returns byte-for-byte as a 640x427 crop
 * (probed on DEV). Wrapper and img both carry it so a missing image -- 2 of the
 * 1,156 imported posts have none -- leaves a black box of exactly the right
 * size rather than a collapsed card. Black is the theme's own .entry-image
 * background, not an invention. */
.entry-image-wrapper {
	aspect-ratio: 640 / 427;
	background-color: #000;
	overflow: hidden;
	width: 100%;
}

.entry-card .entry-image > .entry-image-wrapper img {
	display: block;
	height: 100%;
	margin: 0 auto;
	object-fit: cover;
	transition: filter 0.3s ease-in-out;
	width: 100%;
}

.entry-card:hover .entry-image .entry-image-wrapper {
	filter: grayscale(1);
}

/* The "Read More" plate. Real text, centred over the image, revealed on hover.
 *
 * BODY FONT, NOT DISPLAY -- woodzgit/theauto#39 item 4. Live's own rule is
 * `.wf-active .entry-card .entry-image .hover { font-family: "Work Sans" }`,
 * and this had it in Oswald. Measured on the same span.hover at 1440,
 * 2026-08-13:
 *
 *                 this build              live
 *   font-family   Oswald, sans-serif      "Work Sans", sans-serif
 *   width         121.141px               163.547px
 *
 * The width is not a second defect -- it follows from the typeface, Oswald
 * being condensed. Every other computed property on that span already matched
 * live exactly, opacity, transform and `transition: all 0.3s` included, so the
 * reveal itself was never missing; the label was simply set in the wrong face,
 * which is what made it read as a different effect. */
.entry-card .entry-image .hover {
	color: #fff;
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-entry-title);
	left: 50%;
	letter-spacing: var(--ta-ls-entry-title);
	line-height: 1.45;
	opacity: 0;
	position: absolute;
	text-align: center;
	text-transform: uppercase;
	top: 50%;
	transform: translateY(-50%) translateX(-50%);
	transition: all 0.3s;
	z-index: 100;
}

.entry-card:hover .entry-image .hover,
.entry-card:focus-within .entry-image .hover {
	opacity: 1;
}

/* Title */

.entry-card .entry-header {
	margin-bottom: 0;
	margin-top: 10px;
	padding: 0;
	position: relative;
}

/* THREE lines, clipped. Was two. See the deviation note at the top of this
 * section for why this box is pinned at all.
 *
 * *** CLIENT REVIEW 2026-08-17, woodzgit/theauto#94. *** "Please allow for
 * three lines of copy on the homepage headline blocks across the board. Will
 * not need 4 but often they stretch to a third like on the Cruiser FJ, which
 * loses the last word there."
 *
 * MEASURED, AND THE CLIENT IS RIGHT ON BOTH HALVES. Every card title on the
 * home page was rendered with its pin removed and its natural height read:
 *
 *   viewport   titles needing 3 lines            titles needing 4
 *   1440       0                                 0
 *   1366       2  -- FJ CRUISER, PETROL RANGER   0
 *   1280       3  -- + SO CHINESE CARS           0
 *   1200-960   0                                 0
 *
 * So `FJ CRUISER: NO NONSENSE. BUT WHERE'S THE TURBODIESEL?` is the exact card
 * they named, it loses its last word at 1366 and 1280, and the maximum any of
 * the 20 needs is three -- "will not need 4" is correct as measured. The clip
 * stays at four, deliberately: it is the guard that stops one freak title from
 * stretching a cell, and nothing currently reaches it.
 *
 * 113.063px = 3 x 37.688, the same single-line height the old 75.375 was two
 * of. Not a new number, the same one counted once more.
 *
 * THIS IS A DEPARTURE FROM LIVE AND IT MOVES THE CARD. Live's cards are
 * 414.547 tall and pin to two lines; ours now run 452.234. That is fine here
 * and it is worth knowing why: `js/theauto374.js` puts `.grid--masonry` on
 * `#posts` (verified on DEV -- the class is live), and masonry measures real
 * heights, so a taller uniform card re-packs rather than breaking the grid.
 * The client said as much -- "let the random/mess sort that out". Without JS
 * the float grid still works, because every card grew by the same 37.688. */
.entry-card .entry-header--medium {
	height: 113.063px;
	overflow: hidden;
}

.entry-card .entry-title {
	margin: 0;
	overflow: hidden;
	word-break: break-word;
}

.entry-card .entry-header[class] a {
	color: currentColor;
	text-decoration: none;
}

/* Excerpt */

.entry-card .entry-content {
	margin-bottom: 8px;
	margin-top: 8px;
	position: relative;
	word-break: break-word;
}

/* Two lines, clipped, same reason as the header. */
.entry-card .entry-content--short {
	height: 48px;
	overflow: hidden;
}

.entry-card .entry-content p {
	margin: 0 0 15px;
}

.entry-card .entry-content p:last-of-type {
	margin-bottom: 0;
}

/* BELOW 480 the card is full-bleed and its three text boxes are inset 24px on
 * BOTH sides. Measured on computed/home.mobile.json: .hentry 390 wide at x=0,
 * .entry-image-wrapper 390 wide, .entry-header--medium and
 * .entry-content--short 342 wide at x=24. The first version of this section put
 * the inset only in the >=480 block and the phone layout came out with the
 * title and the excerpt running edge to edge at 390px wide -- caught by
 * ops/measure.py diff against home.mobile, not by looking. */
.entry-card .entry-meta,
.entry-card .entry-content,
.entry-card--landscape .entry-header {
	margin-left: var(--ta-rail-inset);
	margin-right: var(--ta-rail-inset);
}

/* The card's own inset. Live's `@media (min-width:480px)` block: the card pulls
 * 24px left out of the column and gives 48px back on the right, and its three
 * text boxes move to 48px on the left and nothing on the right. That is what
 * makes .entry-card 395.953 wide inside a 419.953 column and
 * .entry-header--medium 347.953 inside that. */
@media only screen and (min-width: 480px) {
	.entry-card {
		margin-left: calc(-1 * var(--ta-rail-inset));
		margin-right: var(--ta-sp-5);
	}

	/* *** HALVED, CLIENT 2026-08-17, woodzgit/theauto#103. *** "can we move the
	 * copy left margin halfway across the white gap (in other words halve the
	 * margin)".
	 *
	 * Live's value, and this build's until now, is 48px: the card pulls 24px
	 * LEFT out of its column and gives the text 48px back, so the copy sits
	 * 48px right of the image's left edge and that gap is the "white gap".
	 * Halving it puts the copy at 24px.
	 *
	 * 24 IS NOT AN ARBITRARY HALF -- it is `--ta-rail-inset`, the same 24 the
	 * card pulls out by and the same 24 the grid's transparent left border
	 * carries. So the copy now lands exactly on the COLUMN origin: card at
	 * column-24, copy at column-24+24. The old 48 was the only number in the
	 * card that was not a multiple of that inset, and halving it makes the
	 * whole card resolve to one unit instead of two.
	 *
	 * A DEPARTURE FROM LIVE, which measures 48 here. ops/adjudicate.py carries
	 * the rule. The 1450 block at the foot of this file halves its own 60 to 30
	 * for the same reason and must move with this one -- they are one decision
	 * written twice, and changing only one produces a copy inset that jumps at
	 * 1450. */
	.entry-card .entry-meta,
	.entry-card .entry-content,
	.entry-card--landscape .entry-header {
		margin-left: var(--ta-rail-inset);      /* was --ta-sp-5 (48px) */
		margin-right: 0;
	}
}


/* The archive heading cell ------------------------------------------------ */

/* Live puts this in the second grid cell, as a .page-header that ALSO carries
 * .entry-card -- so it gets the card's white background and the same -24/+48
 * insets, and lines up with the column.
 *
 * *** THE HEADING TEXT IS THE PLAIN CATEGORY NAME, NOT "Category: News", AND
 * THAT IS A DELIBERATE DEVIATION. *** Live had two pages here and we have one:
 * its /news/ was a WordPress PAGE titled "News" and its /category/news/ was the
 * archive titled "Category: News". server-configs#364 item 1 collapsed those
 * into a single canonical /news/, so the archive is what a reader reaches by
 * clicking "News" in the nav -- and "Category: News" would be the wrong label
 * for that URL. Recorded on woodzgit/theauto#23.
 *
 * The strapline underneath is catStrapline (#364 item 12), which the live PAGE
 * rendered as its `article-section-title` -- "all the latest auto news right
 * here". It keeps its place directly under the heading. Six of the eight
 * categories have one; `home` and `test-records` are NULL and emit nothing at
 * all rather than an empty bar. */
.layout-grid .page-header {
	margin-top: 50px;

	/* woodzgit/theauto#39 item 8, second pass. With .page-title corrected to
	 * live's 30/37.5 the cell was STILL 31px tall, and measuring the header
	 * itself rather than the title found spacing that is nobody's:
	 *
	 *                      this build      live's archive
	 *   .page-header       103.6 tall      72.5 tall
	 *     padding-bottom   9px             0
	 *     margin-bottom    20px            0
	 *
	 * Neither value is live's and neither was deliberate -- they are seed
	 * defaults that survived because nothing had measured this box. That 29px
	 * is what kept cells 3 and 5 sitting ~51px low in the middle column even
	 * after masonry placed them correctly. */
	margin-bottom: 0;
	padding-bottom: 0;
}

.layout-grid .page-title {
	margin-top: 0;

	/* woodzgit/theauto#39 item 8 -- the reviewer's "the page header is not
	 * right", measured on /bakkie/ 2026-08-13:
	 *
	 *                    this build          live's archive
	 *   .page-title      46px / 53px lh      30px / 37.5px lh
	 *                    padding-bottom 10   margin-bottom 24
	 *   .entry-header    92.125 tall         37.5 tall
	 *
	 * The cause is that category.asp emits `h1.page-title`, and section 3's
	 * bare `h1` rule hands it `--ta-fs-site-title` -- the MASTHEAD's size.
	 * Nothing was ever wrong with the header markup; the title was simply
	 * wearing the site title's type.
	 *
	 * SCOPED to .layout-grid ON PURPOSE. `.page-title` is also an h2 on eight
	 * seeded pages, two of which are live routes (search.asp, tagarchive.asp).
	 * Restyling the bare class to fix the archive would silently retype those
	 * as well, and neither has been measured against live yet -- they are the
	 * templates still on the Bootstrap chrome (docs/item9-bootstrap-decision.md).
	 *
	 * This 54.6px was also the whole of the remaining masonry offset on the
	 * archive: with the header in cell 2 too tall, every cell below it in that
	 * column sat ~60px low even after the placement was correct. */
	font-size: 30px;
	line-height: 37.5px;
	margin-bottom: 24px;
	padding-bottom: 0;

	/* woodzgit/theauto#56 part 2, operator ruling 2026-08-14. Family and size
	 * already matched live; the WEIGHT did not -- ours computed 300 against
	 * live's 400 on /category/news/ and /2026/08/ alike.
	 *
	 * Nothing set it. `h1, h2, h3, h4, h6` in section 3 says 400, and the seed's
	 * `base.css:478` says `.page-title { font-weight: 300 }` -- one class beats
	 * one element, so the seed won by specificity and this rule never stated a
	 * weight to beat it. Same failure class as the sidebar's dead token in #38 /
	 * PR #54: a weight that falls through rather than one that is declared.
	 *
	 * SCOPED, for the same reason the type above it is -- `.page-title` is an h2
	 * on eight seeded pages, two of them live routes (search.asp, tagarchive.asp),
	 * and neither has been measured against live yet. */
	font-weight: var(--ta-w-normal);
}

.page-title {
	margin-bottom: 0;
}

.page-strapline {
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-small);
	font-weight: var(--ta-w-light);
	line-height: var(--ta-lh-small);
	margin: 8px 0 0;
	text-transform: none;
}


/* Pagination -------------------------------------------------------------- */

/* VISIBLE HERE, HIDDEN ON LIVE, and that is forced. Live's body carries
 * `infinite-scroll` and the bundle hides .pagination outright; the posts arrive
 * from Jetpack's infinite-scroll JS instead. With no JS, hiding it would make
 * every archive exactly 20 posts deep and strand 465 of the 485 road tests. So
 * the markup and the styling are live's -- the circles, the 30px rows, the
 * prev/next rails -- and only `display` differs. */
.pagination {
	border: none;
	font-size: 0;
	margin: 0 auto;
	max-width: 400px;
	padding-left: 0;
	position: relative;
	text-align: center;
}

.pagination:after {
	content: none;
}

.pagination a,
.pagination span {
	border: 1px solid var(--ta-c-rule);
	border-radius: 50%;
	color: var(--ta-c-footer-link);
	display: inline-block;
	font-size: 14px;
	height: 30px;
	line-height: 30px;
	margin: 0 5px;
	min-width: 30px;
	opacity: 0.5;
	position: relative;
	transition: all 0.15s linear;
	z-index: 2;
}

.pagination a:hover,
.pagination a:focus {
	border-color: var(--ta-c-text);
	color: var(--ta-c-heading);
	opacity: 1;
}

.pagination span.current {
	border: 1px solid var(--ta-c-text);
	color: var(--ta-c-heading);
	opacity: 1;
}

.page-numbers.prev,
.page-numbers.next {
	border: 0;
	border-radius: 0;
	color: var(--ta-c-heading);
	height: auto;
	margin: 0;
	position: absolute;
	text-transform: uppercase;
	top: 0;
	width: auto;
}

.page-numbers.prev.disabled,
.page-numbers.next.disabled {
	opacity: 0.3;
	pointer-events: none;
}

.page-numbers.prev {
	left: 0;
}

.page-numbers.next {
	right: 0;
}

.nav-links {
	margin-left: auto;
	margin-right: auto;
	max-width: 620px;
	text-align: center;
}

@media only screen and (min-width: 480px) {
	.pagination {
		max-width: 450px;
	}
}

@media only screen and (min-width: 900px) {
	.pagination {
		margin-top: 1.875rem;
		max-width: 1000px;
		padding-left: 10rem;
		padding-right: 10rem;
	}
}

@media only screen and (min-width: 1260px) {
	.pagination {
		max-width: 1350px;
	}
}

@media only screen and (min-width: 1700px) {
	.pagination {
		max-width: 1850px;
	}
}


/* ==========================================================================
 * 10. The single / page template -- server-configs#374 item 5
 *
 * Live serves TWO layouts under one masthead, and section 8 only built the
 * first. On `home` and `archive` the masthead is the first cell of the card
 * grid, 420px wide, and the cards flow to its right. On `single` and `page`
 * there is NO GRID AT ALL: the masthead is a floated 220px rail, `#primary`
 * floats right over it with `margin-left:-220px`, and `.site-main` is pushed
 * clear with `margin-left:304px` and inset `0 180px` to a 620px measure.
 * header.asp forks the markup on bSingle374; this forks the CSS on the body
 * class that fork also sets.
 *
 * Every number here is the capture's, from computed/article-passion-precision
 * .desktop.json and computed/page-news.desktop.json. The rules themselves are
 * the retired theme's, read out of css/theauto.page__static_b557d47b.css --
 * but where the two disagree, the COMPUTED value wins: wp.com's custom-colors
 * layer flattens the theme's #ffde00 accent to #d1d1d1 on the category chip
 * and the submit button, and the Global Styles block replaces the theme's
 * Oswald on .entry-meta with Work Sans. Building from the bundle alone would
 * put a yellow chip on every article that live has never shown.
 * ------------------------------------------------------------------------*/

/* THE SEED'S BOOTSTRAP ALSO OWNS `.container`. header.asp now emits live's
 * `div.container` inside .site-content on every page, and bootstrap.min.css --
 * still linked, still ahead of this file -- makes that 1170px wide with 15px
 * gutters at desktop, which would strand the 1284px grid inside a 1170px box.
 * Neutralised for the DIRECT CHILD ONLY, so the seeded pages' own inner
 * .container elements keep working exactly as they did. */
.site-content > .container {
	margin: 0;
	max-width: none;
	padding: 0;
	width: 100%;
}

/* The outer box. #page carries 78px of top padding for the grid layouts
 * (section 8); a single measures .site-content at y=18, so the padding goes
 * and .site-content's own 60px does the work. ID specificity, because
 * `#page` in section 8 is an ID and `.single .site` would lose to it.
 *
 * 0, which is live's literal `.single .site{padding-top:0}`. Item 5 had to
 * write 18px here, because the 18 the capture measures above .site-content was
 * being supplied by a max-width on .site-content rather than by the body
 * border that actually produces it. Section 6 now carries that border and this
 * reverts to the theme's own value. */
.single #page,
.page #page {
	padding-top: 0;
}

.single .site-content,
.page .site-content {
	padding: 0 var(--ta-mobile-gutter) 30px;
}

.single .content-area,
.page .content-area {
	width: 100%;
}

/* .entry-header-wrap, .entry-content, .entry-footer, .comments-area and
 * .comment-respond all measure 620 and centre inside whatever .site-main
 * gives them. Live states it once for the whole set. */
.single .entry-header-wrap,
.single .entry-footer,
.single .comments-area,
.single .comment-respond,
.page .entry-header-wrap,
.page .entry-footer,
.page .comments-area,
.page .comment-respond {
	margin-left: auto;
	margin-right: auto;
	max-width: 620px;
}

.single .entry-header,
.page .entry-header {
	margin-bottom: 1.5em;
}

.single .entry-title,
.page .entry-title {
	margin: 0;
}

/* 2.625rem = 42px below the breakpoint, 3.5rem = 56px above it. Both measured
 * (390px: 42/52.5; 1440px: 56/70). The line-height rides the 1.25 ratio the
 * .site-title token already establishes, so one size gives both. */
.single h1.entry-title,
.page h1.entry-title {
	font-size: 42px;
	letter-spacing: var(--ta-ls-site-title);
	line-height: 1.25;
}

/* THE META IS VISIBLE HERE and it is a different size from the card's.
 * Section 4 sets .entry-meta at 11px/17.875 with normal tracking, which is
 * what the CARD measures -- the theme's own base is 13px/0.1em and
 * `.entry-card .entry-meta` is the override. Rather than invert section 4 and
 * re-verify the whole card grid, the single's values are stated here, scoped
 * to the two body classes that have no cards on them at all. */
.single .entry-meta,
.page .entry-meta,
.single .entry-meta a,
.page .entry-meta a {
	font-size: var(--ta-fs-small);
	letter-spacing: 0.1em;
	line-height: var(--ta-lh-small);
}

/* THREE SEEDED RULES HAVE TO BE BEATEN HERE, and two of them out-specify the
 * obvious `.single .entry-meta`. components.css ships `.entry-meta{opacity:.6}`
 * -- motorsportmedia greying its bylines -- plus
 * `.entry-header .entry-meta{margin-bottom:0}` and
 * `.entry-header .entry-meta:first-child{margin-bottom:5px}`, which is 0,2,1
 * and beat the 0,2,0 selector this rule started as. Measured on DEV: the meta
 * came out at 60% opacity with 5px under it against the capture's 100% and
 * 10px. Fixed by matching live's own nesting rather than by !important. */
.single .entry-header .entry-meta,
.page .entry-header .entry-meta {
	margin-bottom: 10px;
	opacity: 1;
	position: static;
}

.single .entry-meta,
.page .entry-meta {
	font-weight: var(--ta-w-light);
	opacity: 1;
	position: static;
}

.single .entry-title,
.page .entry-title,
.single .entry-meta,
.page .entry-meta {
	overflow: hidden;
}

/* 8px, against the grid rail's 24px. Live's own `.single .nav--main`. */
.single .nav--main,
.page .nav--main {
	margin-bottom: 8px;
}

.single .entry-meta > *,
.page .entry-meta > * {
	display: inline-block;
	margin-bottom: 5px;
}

/* .cat-links, .byline and .byline .author are NOT restated here. They are the
 * same three rules on a card and on a single -- measured identical in
 * home.desktop.json and article-passion-precision.desktop.json -- and section
 * 9 already carries them for the card. Only the two below differ, and only
 * because the card suppresses them.
 *
 * .posted-on gets its separator and its grey here rather than in section 9,
 * where `.entry-card .entry-meta .posted-on` has its own margins. */
.single .posted-on,
.page .posted-on {
	color: var(--ta-c-muted);
	display: inline-block;
	margin-left: 4px;
}

.single .posted-on a,
.page .posted-on a {
	color: currentColor;
	font-weight: var(--ta-w-light);
}

.single .posted-on:before,
.page .posted-on:before {
	content: "/";
	margin-right: 4px;
}

.single .entry-time:before,
.page .entry-time:before {
	content: "@";
	margin: 0 5px;
}

/* The hero. It is NOT the card's cropped 640x427: a single keeps the source
 * aspect, so only the width is pinned and the height follows. */
.single .entry-featured,
.page .entry-featured {
	margin-bottom: var(--ta-sp-4);
}

.single .entry-featured > img,
.page .entry-featured > img {
	display: block;
	height: auto;
	margin: 0 auto;
	max-width: 100%;
}

/* Body copy. `.entry-content > *` is centred at 620 so a wide block can opt
 * out with .alignwide / .alignfull, which is how the imported Gutenberg markup
 * on the static pages expects to behave (#374 item 7 leans on this). */
.single .entry-content,
.page .entry-content {
	margin-bottom: 42px;
}

.single .entry-content > *,
.page .entry-content > * {
	margin-left: auto;
	margin-right: auto;
}

.single .entry-content > :not(.alignwide):not(.alignfull),
.page .entry-content > :not(.alignwide):not(.alignfull) {
	max-width: 620px;
}

.single .entry-content > .alignfull,
.page .entry-content > .alignfull {
	max-width: none;
}

/* SCOPED, unlike the rest of this block, because the CARD's excerpt is also a
 * `.entry-content > p`: section 9 pins `.entry-content--short` at 48px, which
 * is exactly two 24px lines, and a 26px line-height here would overflow every
 * card on the site by 4px. Body copy on a single measures 16/26, the card's
 * excerpt 16/24 -- two real values, both in the capture. */
.single .entry-content p,
.page .entry-content p {
	/* A RATIO, not the 26px length --ta-lh-body carries. 1.625 * 16 IS 26, so
	 * ordinary body copy is unchanged -- but imported Gutenberg markup sets its
	 * own font-size inline, and a length does not follow it. Measured on
	 * /auto-test-records/, where item 7 found it: live's 22px opening paragraph
	 * is 35.75 (22 * 1.625) against this file's 26, and its 12px one is 19.5
	 * against 26. Three paragraphs on that page were the wrong height and
	 * everything below them sat 73.5px too high. */
	line-height: 1.625;
	margin-bottom: 36px;
}

.entry-content h2 {
	letter-spacing: var(--ta-ls-site-title);
	margin-bottom: var(--ta-sp-4);
	margin-top: 30px;
}

/* h3 is SMALLER than the body copy on this theme -- 13/15.6 Oswald 500 with
 * 1.3px tracking, uppercase. Measured, and counter-intuitive enough that it
 * would be "corrected" by anyone working from the heading ladder alone. */
.entry-content h3 {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-small);
	font-weight: var(--ta-w-medium);
	letter-spacing: 0.1em;
	line-height: 1.2;
	margin-bottom: 15px;
	text-transform: uppercase;
}

.entry-content img {
	height: auto;
	max-width: 100%;
}

/* NOT `text-decoration: underline`, which is what item 5 put here and what
 * item 7 measured as wrong on the first content link it met - the mailto on
 * /contact/. Live draws a highlight, not a rule: the accent sits BEHIND the
 * text and a white curtain covers it, and the curtain retracts on hover.
 * Section 12 carries it, because the selector needs the same
 * `:not([class*="wp-block"]):not(.img-link)` pair the nav uses in section 8
 * and it belongs beside the rest of the imported-content styling. */

/* Tags -------------------------------------------------------------------- */

/* The "#" is the theme's, drawn in CSS rather than written into the markup so
 * the tag text stays the tag text for a screen reader and for search. */
.tags-links {
	display: block;
	margin-bottom: 20px;
}

.tags-links a {
	color: var(--ta-c-muted);
	font-size: var(--ta-fs-meta);
	letter-spacing: 0.1em;
	margin-right: 10px;
	text-transform: uppercase;
}

.tags-links a:before {
	content: "#";
}

.entry-footer {
	clear: both;
}

/* Comments ---------------------------------------------------------------- */

/* The vertical hairline down the left of the thread and the dot that closes
 * it are both pseudo-elements on .comments-area -- there is no markup for
 * either, and the dot is suppressed when there is nothing to close.
 *
 * The theme's 24px top margin is cancelled on a single by its own
 * `.single .comments-area{margin-bottom:0;margin-top:0}`, which is what the
 * capture measures. The 48px of padding is what separates the thread from the
 * article, and it is inside the box so the hairline can start below it. */
.comments-area {
	margin-top: var(--ta-sp-4);
	padding-top: var(--ta-sp-5);
	position: relative;
}

.single .comments-area,
.page .comments-area,
.single .comment-respond,
.page .comment-respond {
	margin-bottom: 0;
	margin-top: 0;
}

.comments-area:before {
	border-left: 1px solid var(--ta-c-muted);
	bottom: 0;
	content: "";
	left: 20px;
	position: absolute;
	top: var(--ta-sp-5);
}

.comments-area.no-comments:before {
	display: none;
}

.comment-number {
	background-color: var(--ta-c-heading);
	border: 0;
	color: var(--ta-c-invert-text);
	display: inline-block;
	font-size: 18px;
	font-weight: var(--ta-w-light);
	height: 40px;
	line-height: 40px;
	margin-right: var(--ta-sp-4);
	position: relative;
	text-align: center;
	vertical-align: top;
	width: 40px;
	z-index: 1;
}

.comments-area-title {
	margin-bottom: 60px;
	padding-left: 40px;
}

.no-comments .comments-area-title {
	margin-bottom: 0;
	padding-bottom: 30px;
}

.comments-area-title .comment-number {
	left: -40px;
	margin-right: -20px;
}

.comments-area-title:after,
.comment-reply-title:after,
.comment-form:after {
	clear: both;
	content: "";
	display: table;
}

.comments-area-title .comments-title,
.comments-area-title a {
	display: inline-block;
	vertical-align: middle;
}

/* 40px, and it is the DISC that sets it, not the type. The heading is one line
 * box containing a 40px inline-block counter and 24px text; left to h2's 30px
 * line-height and baseline alignment the box came out 55px and pushed
 * .comments-area to 133 against the capture's 118 (48 padding + 40 heading +
 * 30 padding-bottom). Pinning the line-height to the disc's own height and
 * top-aligning the disc inside it reproduces the 40 exactly. */
.comments-title {
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-h2);
	font-weight: var(--ta-w-light);
	line-height: 40px;
	margin: 0 12px 0 0;
	text-transform: none;
}

.comments_add-comment {
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-small);
	letter-spacing: 0.1em;
	line-height: 22px;
	margin-top: 3px;
	text-transform: uppercase;
}

.comment-list {
	list-style: none;
	margin: 0;
	padding: 0;
}

.comment-list > li {
	margin-bottom: 30px;
	position: relative;
}

/* The numbered disc sits in the 40px channel the hairline runs down, so the
 * comment body is indented past it rather than around it. */
.comment-list .comment-number {
	left: 0;
	position: absolute;
	top: 0;
}

.comment-article {
	margin-bottom: 0;
	margin-left: 60px;
}

.comment-author .fn {
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-small);
	font-style: normal;
	font-weight: var(--ta-w-medium);
	letter-spacing: 0.1em;
	text-transform: uppercase;
}

.comment-metadata,
.comment-metadata a {
	color: var(--ta-c-muted);
	font-size: var(--ta-fs-meta);
	letter-spacing: 0.1em;
	text-transform: uppercase;
}

.comment-content p:last-child {
	margin-bottom: 0;
}

/* The reply form ---------------------------------------------------------- */

.comment-respond {
	margin-bottom: 1.5em;
	position: relative;
}

/* The "+" disc is FontAwesome 4.3.0, the scoped face section 8 self-hosted for
 * the social icons -- not the seed's 3.2.1, which has the codepoint but not
 * the same metrics. */
.comment-reply-title {
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-h2);
	font-weight: var(--ta-w-light);
	margin-bottom: var(--ta-sp-4);
	margin-top: 0;
	min-height: 40px;
	padding-left: 60px;
	text-transform: none;
}

.comment-reply-title:before {
	background-color: var(--ta-c-heading);
	color: var(--ta-c-invert-text);
	content: "\f067";
	display: inline-block;
	font-family: "FontAwesomePatch";
	font-size: 20px;
	height: 40px;
	left: 0;
	line-height: 42px;
	position: absolute;
	text-align: center;
	top: 0;
	width: 40px;
}

.comment-notes {
	font-size: var(--ta-fs-small);
	line-height: var(--ta-lh-small);
	margin-bottom: 0.75em;
}

.comment-form-comment label,
.comment-form-author label,
.comment-form-email label,
.comment-form-url label {
	display: none;
}

.comment-form-author,
.comment-form-email,
.comment-form-url,
.comment-form-comment {
	margin-bottom: 0;
}

.comment-form input[type="text"],
.comment-form input[type="email"],
.comment-form textarea {
	background-color: var(--ta-c-page);
	border: 1px solid var(--ta-c-muted);
	border-radius: 0;
	box-shadow: none;
	box-sizing: border-box;
	color: var(--ta-c-link);
	font-weight: var(--ta-w-light);
	padding: 12px;
	width: 100%;
}

/* `normal`, and that is the measurement: the capture reads 18.4px on these,
 * which is the UA default for 16px Work Sans, not the 26px section 5 sets on
 * every input[type=text] on the site. 18.4 + 24 padding + 2 border = the 44.39
 * the capture measures; the 26px version came out 52. */
.comment-form input[type="text"],
.comment-form input[type="email"] {
	line-height: 1.15;
	margin-bottom: 1.5em;
}

.comment-form textarea {
	font-size: 1em;
	line-height: 1.5;
	max-width: 100%;
	padding: 0.75em;
}

.form-submit {
	margin-bottom: 0;
	margin-top: 0.75em;
	position: relative;
	text-align: right;
}

/* Live's submit is #d1d1d1 on #171617, not the black-on-white section 5
 * measured off the home page's subscription widget -- two different controls,
 * two different rules, and this one is scoped so neither moves the other. */
.comment-form .submit {
	background-color: var(--ta-c-chip);
	border: 0;
	color: var(--ta-c-heading);
	float: right;
	font-family: var(--ta-font-display);
	font-size: 18px;
	font-weight: var(--ta-w-medium);
	letter-spacing: 0.1em;
	line-height: 26px;
	padding: 0 0.1em 0 0.3em;
	position: relative;
	text-transform: uppercase;
}

/* Desktop: the 220px rail --------------------------------------------------
 *
 * Measured at 1440: .site-content 1404 @ x=18 with 60px padding, .site-header
 * 220 @ x=78 floated left, #primary 1284 @ x=78 floated right with
 * margin-left:-220, .site-main 980 @ x=382. The 620px measure only arrives at
 * 1260 with the 180px inset -- between 900 and 1260 the column is the full
 * 980, which is live's own ladder. */
@media only screen and (min-width: 900px) {
	.single .site-content,
	.page .site-content {
		padding: var(--ta-p-content);
	}

	.single .site-content > .container,
	.page .site-content > .container {
		position: relative;
	}

	.single .content-area,
	.page .content-area {
		float: right;
		margin-left: -220px;
	}

	/* `width:auto`, NOT the `width:100%` section 6 gives every .site-main.
	 * 100% of a 1284px #primary is 1284, and margin-left:304 then pushes that
	 * whole 1284 out to x=382 and 82px past the right edge: measured on DEV,
	 * .site-main 1284 wide with a 924px measure inside it against the
	 * capture's 980 and 620. Auto is what makes the margin eat into the box
	 * rather than shift it. */
	.single .site-main,
	.page .site-main {
		margin-left: 304px;
		max-width: none;
		width: auto;
	}

	/* Live stacks these two at 50% -- 310px of the 620 measure - rather than
	 * running them across. The website field stays full width. */
	.single p.comment-form-author,
	.single p.comment-form-email,
	.page p.comment-form-author,
	.page p.comment-form-email {
		width: 50%;
	}

	.single .site-header,
	.page .site-header {
		float: left;
		margin: 0;
		padding-right: 0;
		position: relative;
		width: 220px;
		z-index: 10;
	}

	/* The rail is 220 wide here, not 420, so the 24px inset section 8 gives
	 * the grid masthead has nothing to inset from. Live zeroes all four. */
	.single .site-branding,
	.single .nav--main,
	.single .nav--social,
	.single .site-title,
	.page .site-branding,
	.page .nav--main,
	.page .nav--social,
	.page .site-title {
		margin-left: 0;
		margin-right: 0;
	}

	/* The other half of #70, and a genuine fork rather than a collapse artefact.
	 * On a SINGLE, live floats its own masthead (measured `/contact/`:
	 * `float:left; position:relative`, the same as ours), so both sides contain
	 * this margin and live's literal value is the one that reproduces live. Live
	 * says 24px there against the 10px it says on the grid templates.
	 *
	 * Measured 2026-08-16, live vs DEV at 1440 on `/contact/`:
	 *
	 *   ul.nav--social       38.5     both sides
	 *   nav.main-navigation  494.5    both sides
	 *   .site-branding       294.125  both sides
	 *   margin-bottom        24px live   10px this build
	 *   .site-header         836.625 live   822.625 this build   <- the -14
	 *
	 * 24 - 10 = 14, which is the whole of it. The grid rule above is now 0 for
	 * the collapse reason stated there, so without this line a single would
	 * inherit 0 and be 24px short instead of 14. */
	.single .nav--social,
	.page .nav--social {
		margin-bottom: 24px;
	}

	/* Two 150px columns do not fit 220px. Live drops the nav back to one and
	 * doubles the gap between rows -- 20px here against the grid rail's 10px,
	 * which is 80px over the eight items and most of the 60px .site-header
	 * shortfall the first measurement showed. */
	.single .nav--main > li,
	.page .nav--main > li {
		float: left;
		margin-bottom: 20px;
		width: 100%;
	}

	.single h1.entry-title,
	.page h1.entry-title {
		font-size: 56px;
	}

	/* The container has to contain both floats or the footer rides up beside
	 * the rail on any article shorter than the masthead. */
	.single .site-content > .container:after,
	.page .site-content > .container:after {
		clear: both;
		content: "";
		display: table;
	}
}

@media only screen and (min-width: 1260px) {
	.single .site-main,
	.page .site-main {
		padding: 0 180px;
	}

	/* The two breakouts: the header pulls half the inset, the hero all of it.
	 * 620 + 2*90 = 800 and 620 + 2*180 = 980, both measured. */
	.single .entry-image--landscape .entry-header,
	.page .entry-image--landscape .entry-header {
		margin-left: -90px;
		margin-right: -90px;
	}

	.single .entry-image--landscape .entry-featured,
	.page .entry-image--landscape .entry-featured {
		margin: var(--ta-sp-4) -180px;
	}
}

/* Mobile: the masthead centres and the column is the viewport ---------------
 *
 * Measured at 390: .site-content 390 @ y=72 with 0 24px padding, .site-header
 * 330 @ x=30 centred with 0 20px of its own, .site-main 342 @ x=24. The 12px
 * top margin live measures on .site-header is NOT reproduced, for the same
 * reason section 8 dropped it on the grid masthead: it collapses out through
 * the container chain on live and would be contained here, landing the rail
 * 12px low. #page's 72px already carries it. */
@media only screen and (max-width: 899px) {
	.single .site-header,
	.page .site-header {
		margin: 0 auto 20px;
		max-width: 330px;
		padding: 0 20px;
	}

	.single #page,
	.page #page {
		padding-top: 72px;
	}
}


/* ==========================================================================
 * 11. The footer -- server-configs#374 item 6
 *
 * A 66px grey bar with three cells at 33.33% each: .site-info (empty on live),
 * .back-to-top-wrapper and nav.footer-menu. Measured 1404x66.25 at x=18,
 * padding 12px 48px, background #bfbfbf, text #474747, links #b5b5b5.
 *
 * The theme's own source says `background: black; color: #b5b5b5`. It is
 * wrong for this site for the third time in this stylesheet: wp.com's
 * custom-colors layer flattens it, and the capture measures the grey. Section
 * 2 already carries the measured trio as tokens; only geometry is new here.
 *
 * MOST OF THIS EXISTS TO BEAT BOOTSTRAP, not to beat the theme. The footer
 * list carries `nav` as well as `nav--footer` - live's own class pair - and
 * the seed still links bootstrap.min.css ahead of this file, so
 * `.nav > li{display:block}` and `.nav > li > a{display:block;padding:10px
 * 15px}` apply to it. Same trap as the primary nav in section 8.
 * ------------------------------------------------------------------------*/

/* THE ONE CLASS THIS WHOLE STYLESHEET WAS MISSING. Live uses
 * `.screen-reader-text` for the footer nav's heading, the search label and
 * `h1.screen-reader-text` above the pagination -- and item 4 already emits
 * that last one from _cards374.asp, with no rule to hide it. Measured on DEV:
 * "POSTS NAVIGATION" rendered as a 36px uppercase Oswald heading above the
 * page numbers on every paginated archive, which is 45px of the .pagination
 * box that has no business being there. This is the standard WordPress clip
 * pattern, and the capture's `h5` dump is exactly it: position absolute,
 * 1x1, overflow hidden. */
.screen-reader-text {
	border: 0;
	clip: rect(1px, 1px, 1px, 1px);
	clip-path: inset(50%);
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: absolute;
	width: 1px;
	word-wrap: normal;
}

.site-footer {
	padding: var(--ta-sp-3);
}

.site-footer > * {
	display: block;
	text-align: center;
}

/* `[class]` is live's own specificity bump and it is kept: without it the
 * seed's own `a` rules and bootstrap's reach these links first. */
.site-footer[class] a {
	color: var(--ta-c-footer-link);
	font-weight: var(--ta-w-light);
	text-decoration: none;
	transition: color 0.2s;
}

.site-footer[class] a:hover,
.site-footer[class] a:focus {
	color: #ffde00;
}

.nav--footer {
	list-style-type: none;
	margin: 0;
	padding-left: 0;
}

.nav--footer li {
	color: var(--ta-c-footer-text);
	display: inline-block;
	margin: 0;
	position: static;
}

/* Bootstrap's `.nav > li > a` is (0,1,2) and would make every footer link a
 * 40px-tall block. Matched at (0,1,2) and won on source order. */
.nav--footer li > a {
	display: inline-block;
	padding: 0;
}

/* The separator is drawn, not written, so the link text stays the link text
 * for a screen reader and the last item does not trail one. */
.nav--footer li:after {
	color: var(--ta-c-footer-link);
	content: "/";
	margin: 0 5px;
}

.nav--footer li:last-child:after {
	content: none;
}

/* 0.375rem = 6px. The arrow is a 10x19 inline SVG with a #ffde00 cap -- the
 * third and last place in the whole build where the theme's accent reaches a
 * pixel, after the social-icon hover and the footer link hover. */
/* INLINE, not inline-block, and that is measured. Live sets only the padding;
 * making the anchor inline-block turns its 6px of vertical padding into real
 * box height and the middle cell grew 14.9px, taking the mobile footer to
 * 178.25 against the capture's 163.375. On an inline box the padding paints
 * and does not push. */
.back-to-top-button {
	padding: 0.375rem;
}

@media only screen and (min-width: 900px) {
	.site-footer {
		padding-left: var(--ta-sp-4);
		padding-right: var(--ta-sp-4);
	}

	/* 33.33333%, and the three cells only fit because footer.asp swallows the
	 * newlines between them in HTML comments -- two whitespace text nodes at
	 * this font size are ~8px, which is enough to wrap the third cell onto its
	 * own line and double the footer's height. */
	.site-footer > * {
		display: inline-block;
		text-align: center;
		vertical-align: middle;
		width: 33.33333%;
	}

	.site-info {
		text-align: left;
	}

	.footer-menu {
		text-align: right;
	}
}

@media only screen and (max-width: 899px) {
	.site-footer > * {
		padding: var(--ta-sp-3) 0;
	}
}

@media only screen and (min-width: 1260px) {
	.site-footer {
		padding-left: var(--ta-sp-5);
		padding-right: var(--ta-sp-5);
	}
}


/* ==========================================================================
 * 12. The static pages -- server-configs#374 item 7
 *
 * /contact/ and /auto-test-records/. Both are WordPress PAGES on live and
 * both render in the template section 10 built: a 220px left rail, a 620px
 * measure, `article.hentry.page` with `header.entry-header > h1.entry-title`
 * and `div.entry-content`. Nothing here re-does any of that.
 *
 * WHAT IS HERE is the part of those two pages the theme owns and the block
 * library does not:
 *
 *   * the entry-content link highlight, which is GLOBAL and corrects item 5;
 *   * Jetpack's contact-info blocks -- address and email -- which are markup
 *     wrappers with no geometry of their own on live and are listed so that
 *     is on the record rather than assumed;
 *   * the contact form: field wraps, labels, inputs, textarea and the submit
 *     button, all of which share their measured values with the comment form
 *     section 10 already built.
 *
 * THE BLOCK LIBRARY ITSELF IS NOT HERE. `wp-block-columns`, `wp-block-column`,
 * `wp-block-social-links`, `wp-block-image` and `wp-block-file` live in
 * /css/wp-blocks.css, which header.asp emits AFTER this file and only for
 * these two URLs -- the same arrangement #364 item 11 established and the same
 * ordering requirement. Duplicating any of it here would put a rule that wins
 * on ordering in front of one that is measured against live.
 * ======================================================================== */

/* The content link -------------------------------------------------------- */

/* Live does not underline a link inside `.entry-content`. It paints the accent
 * behind the text, covers it with a white curtain sized to one em, and shrinks
 * the curtain to nothing on hover -- so the highlight wipes in from behind the
 * words rather than appearing.
 *
 * The accent in the theme's own source is #ffde00. The capture measures
 * #d1d1d1: wp.com's custom-colors layer flattening it, for the fifth time in
 * this stylesheet after .cat-links (item 5), the comment submit (item 5), the
 * page frame (item 6) and the Download button in wp-blocks.css. --ta-c-chip is
 * that flattened value.
 *
 * MEASURED on live's /contact/, on the one content link the page has:
 * `.wp-block-jetpack-email a` is 205.28 x 19 at x=562, background #d1d1d1,
 * colour #000, weight 500, padding 0 2px, NO text-decoration.
 *
 * The `:not([class*="wp-block"]):not(.img-link)` pair is the theme's own and
 * is what keeps the highlight off the social-icon anchors and the Download
 * button three blocks away -- both of which carry wp-block classes and both of
 * which the block library paints itself. Dropping the pair puts a grey slab
 * behind every SVG tile on /contact/. */
.single .entry-content a:not([class*="wp-block"]):not(.img-link),
.page .entry-content a:not([class*="wp-block"]):not(.img-link) {
	background-color: var(--ta-c-chip);
	background-image: linear-gradient(-90deg, transparent 0%, #ffffff 0%, #ffffff 100%, transparent 100%);
	background-position: top center;
	background-repeat: no-repeat;
	background-size: 100% 1em;
	padding-left: 2px;
	padding-right: 2px;
	position: relative;
	transition: background-size 0.15s ease-out;
}

.single .entry-content a:not([class*="wp-block"]):not(.img-link):hover,
.page .entry-content a:not([class*="wp-block"]):not(.img-link):hover {
	background-size: 100% 0%;
}

/* Jetpack contact-info blocks --------------------------------------------- */

/* Both measure as plain blocks that inherit everything: the three address
 * lines are 294 x 26 each and the email line 294 x 26, stacked with no margin,
 * giving the 104px the capture measures for the wrapper. They are declared
 * rather than left out so a later reader can see that the absence of geometry
 * is a measurement and not an oversight. */
.wp-block-jetpack-contact-info,
.wp-block-jetpack-address,
.wp-block-jetpack-email {
	margin: 0;
}

/* The contact form -------------------------------------------------------- */

/* WHY THE FORM IS NARROWER THAN ITS COLUMN, which looks like a defect and is
 * live's own geometry. Jetpack wraps the form in a flex container, the form is
 * its only in-flow item with `flex-basis: auto`, and the fields inside are
 * `width: 100%` -- which contributes nothing to a max-content measurement, so
 * the form shrink-wraps to the browser's DEFAULT width for a `size`-less text
 * input. Measured: the container is 294 (the column), the form 241 at 1440 and
 * 240 at 390, and every label, input, textarea and button 241/240 with it.
 *
 * Reproduced through the same mechanism rather than by pinning 241px, because
 * 241 is a font metric, not a design value: it is what Chrome makes of twenty
 * average characters of Work Sans at 16px. Pinning it would be right today and
 * wrong on the day the font stack changes -- and the self-hosted variable Work
 * Sans this build ships is ALREADY ~4% narrow against live's static instances
 * (#374, the new item raised after item 6), so this box is expected to measure
 * a few px under 241 until that is fixed. */
.jetpack-contact-form-container {
	-webkit-box-align: center;
	-ms-flex-align: center;
	align-items: center;
	display: -webkit-box;
	display: -ms-flexbox;
	display: flex;
	-ms-flex-wrap: wrap;
	flex-wrap: wrap;
}

/* Field rows are flush -- 26px label, 4px, 44.39px control, no margin between
 * one wrap and the next. Measured: the four wraps start at y=318, 392.4, 466.8
 * and 541.2, a 74.39px pitch that is exactly the height of one wrap. */
.contact-form .grunion-field-wrap {
	margin: 0;
}

/* `display: flex` with `margin-left: auto` on the last span is how live pushes
 * "(required)" to the right-hand end of the label. align-items is baseline so
 * the 13.6px note sits on the 16px label's baseline rather than being centred
 * against it. */
.contact-form .grunion-field-label {
	-webkit-box-align: baseline;
	-ms-flex-align: baseline;
	align-items: baseline;
	color: var(--ta-c-text);
	display: -webkit-box;
	display: -ms-flexbox;
	display: flex;
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-bold);
	/* A RATIO, not the 26px length --ta-lh-body carries, and the difference is
	 * measurable: a length inherits as a length, so the 13.6px "(required)"
	 * span inside this label came out 26px tall and 2px high against live's
	 * 22.08 at y=320. 1.625 gives 26 at 16px for the label and 22.1 at 13.6 for
	 * the span -- both measured values out of one declaration. */
	line-height: 1.625;
	margin-bottom: var(--ta-sp-1);
	text-transform: none;
}

.contact-form .grunion-label-required {
	font-size: 0.85em;              /* 13.6px @16, measured */
	font-weight: var(--ta-w-normal);
	margin-left: auto;
}

/* The controls are the SAME control as the comment form's, measured to the
 * same values -- white, 1px #b5b5b5, square, 12px of padding, and the UA's own
 * 1.15 line-height rather than the 26px section 5 sets site-wide. 18.4 + 24
 * padding + 2 border = the 44.39 both forms measure. The comment form's rule
 * in section 10 is scoped to `.comment-form`, so this repeats the declarations
 * rather than reaching across two sections to widen that selector; the values
 * are one measurement and if one moves the other moves with it. */
.contact-form input[type="text"],
.contact-form input[type="email"],
.contact-form textarea {
	background-color: var(--ta-c-page);
	border: 1px solid var(--ta-c-muted);
	border-radius: 0;
	box-shadow: none;
	box-sizing: border-box;
	color: var(--ta-c-link);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-light);
	line-height: 1.15;
	padding: 12px;
	width: 100%;
}

/* rows="20" would be ~390px tall. Live measures 200 flat, so the height is
 * set and the rows attribute is only the no-CSS fallback. */
.contact-form textarea {
	display: block;
	height: 200px;
	max-width: 100%;
	resize: vertical;
}

/* Live's own p.contact-submit is EMPTY and zero-height, with the button its
 * next sibling -- the 36px below it is the theme's paragraph margin and is the
 * whole of the gap between the message box and the button. Measured: the p at
 * y=771.2 h=0, the button at y=807.2. */
.contact-form .contact-submit {
	margin-bottom: 36px;
}

/* The same control as `.comment-form .submit` in section 10 -- Oswald 18/26 at
 * weight 500, #171617 on the flattened #d1d1d1, with the theme's lopsided
 * 0.3em/0.1em padding that its uppercase tracking needs. It differs in two
 * measured ways and only two: it fills the form instead of floating right, and
 * it is an inline-flex box so the label centres in it. */
.contact-form .pushbutton-wide {
	-webkit-box-align: center;
	-ms-flex-align: center;
	align-items: center;
	background-color: var(--ta-c-chip);
	border: 0;
	color: var(--ta-c-heading);
	display: -webkit-inline-box;
	display: -ms-inline-flexbox;
	display: inline-flex;
	font-family: var(--ta-font-display);
	font-size: 18px;
	font-weight: var(--ta-w-medium);
	-webkit-box-pack: center;
	-ms-flex-pack: center;
	justify-content: center;
	letter-spacing: 0.1em;
	line-height: 26px;
	padding: 0 0.1em 0 0.3em;
	position: relative;
	text-align: center;
	text-transform: uppercase;
	width: 100%;
}

/* The two states the form can come back in. Neither is visible at cutover --
 * live's own success panel is display:none until its JavaScript reveals it,
 * and this build renders whichever one applies and nothing when neither does,
 * so the page a reader lands on carries the same empty form live's does.
 * They take the theme's own type rather than Bootstrap's alert colours, which
 * left green and red slabs in a monochrome page. */
.contact-form-submission {
	margin-bottom: var(--ta-sp-4);
}

.contact-form-submission h4 {
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-size: var(--ta-fs-h2);
	font-weight: var(--ta-w-normal);
	letter-spacing: var(--ta-ls-site-title);
	line-height: var(--ta-lh-h2);
	margin: 0;
	text-transform: uppercase;
}

.contact-form__error {
	border-left: 3px solid var(--ta-c-heading);
	margin-bottom: var(--ta-sp-4);
	padding-left: var(--ta-sp-3);
}

.contact-form__error-message {
	color: var(--ta-c-text);
	font-family: var(--ta-font-body);
	font-size: var(--ta-fs-body);
	font-weight: var(--ta-w-light);
	line-height: var(--ta-lh-body);
}

/* The honeypot. Off-screen rather than display:none, because a bot that reads
 * the computed style skips a hidden field and fills a visible one. #364 item
 * 10's inline style moved here with the rest of the form's presentation. */
.contact-form .cnt-trap {
	left: -5000px;
	position: absolute;
	top: -5000px;
}


/* ==========================================================================
 * 13. Mobile: the fixed bar and the off-canvas drawer -- #374 item 8
 *
 * THE MARKUP IS THE SAME AT EVERY WIDTH. All 22 pages in the capture serve
 * byte-identical HTML to a phone and a desktop once per-request tokens are
 * normalised (the capture's README, finding 3), so there is no mobile template
 * anywhere in this build and there must not be one. `.mobile-header` is in the
 * DOM at 1440 with `display: none` and becomes a 50px block at 390. Everything
 * below is that switch.
 *
 * WHAT WAS ACTUALLY BROKEN. Items 3 to 7 left `nav.main-navigation` in normal
 * flow at every width, so at 390 the masthead measured 794.62px tall against
 * live's 357.62 -- 437px of nav pushing every page down by the same amount, on
 * EVERY template. Item 7 measured the constant on `/contact/` (425 there, the
 * `page` rail being shorter) with every content box inside it already correct.
 * Live's nav is `position: fixed` at x=-342: off the left edge, out of flow,
 * taking no vertical space at all until the hamburger slides it in.
 *
 * Measured at 390 on the home page, and every number below comes from there:
 *
 *   .mobile-header          390 x 50   fixed at 0,0, z-index 50, overflow hidden
 *   .mobile-header-wrapper  390 x 50   absolute, white, 1px #e2e3e3 underline
 *   .navigation__trigger    46.98 x 50 absolute left 0, padding 12, 24px glyph
 *   .nav__item--search      48.69 x 50 absolute right 0, same box
 *   .site-logo-link          30 x 30   absolute, left 50%, margin-top 10
 *   nav.main-navigation     342 x 844  fixed, x=-342, white, padding 24, z 150
 *   .nav--main               294 x 368 inside it at x=-318
 *   .overlay--search        390 x 844  fixed at left 100%, z-index 151
 *
 * The widths of the two buttons are the FontAwesome glyphs' own advance plus
 * 24px of padding; nothing sets them, and pinning them would be wrong the day
 * the icon font changes.
 * ======================================================================== */

/* The bar is in the DOM at every width and hidden above the breakpoint --
 * live's own arrangement, and what makes one markup serve both. */
.mobile-header {
	display: none;
	height: var(--ta-mobile-header-h);
	left: 0;
	overflow: hidden;
	position: fixed;
	top: 0;
	width: 100%;
	z-index: 50;
}

.mobile-header-wrapper {
	background: var(--ta-c-page);
	border-bottom: 1px solid var(--ta-c-rule);
	height: 100%;
	left: 0;
	position: absolute;
	top: 0;
	width: 100%;
}

/* 50px tall inside a 49px padding box -- the wrapper's 1px underline is inside
 * its border box, so live measures `bottom: -1px` on both buttons. Reproduced
 * with an explicit height rather than `height: 100%`, which would give 49. */
/* OSWALD, AND THE 0.1em OF TRACKING SECTION 5 PUTS ON EVERY BUTTON, both of
 * which look irrelevant on a box whose only content is an icon and neither of
 * which is. Measured: live's trigger is Oswald and its glyph is 22.98 wide
 * against 20.58 here -- a flat 2.406px, which is exactly 0.1em at 24px. That is
 * the button's own letter-spacing landing AFTER the glyph, so suppressing it
 * with `letter-spacing: normal` made both buttons 2.4px narrow. The family
 * moves the glyph vertically too, because the button's strut sets the baseline
 * the inline-block icon sits on: live's icon is at y=14, ours was at 12.5. */
.navigation__trigger,
.search__trigger {
	background: none;
	border: 0;
	color: var(--ta-c-heading);
	font-family: var(--ta-font-display);
	font-size: 24px;
	height: var(--ta-mobile-header-h);
	left: 0;
	line-height: 1;
	outline: 0;
	padding: 12px;
	position: absolute;
	text-align: center;
	text-transform: none;
	top: 0;
	-webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}

/* THE GLYPHS COME FROM THE PATCHED FACE, NOT FROM THE VENDORED FontAwesome,
 * and they have to: the seed carries FontAwesome **3.2.1**, whose class prefix
 * is `icon-` and which has no `fa-bars` or `fa-search` at all. Its CSS answers
 * 200 and its font file 404s (it asks for `../font/`, and the directory it
 * points at is empty), so `<i class="fa fa-bars">` rendered as nothing --
 * measured, both buttons came out 24px wide, which is the padding and no glyph.
 *
 * `FontAwesomePatch` is the face item 3 self-hosted, and it is live's OWN file:
 * `/fonts/fontawesome-patch.woff2` is byte-identical to
 * `fonts/...fontawesome-webfont.woff2_24fa7933` in the capture, sha256
 * `aadc3580d2b64ff5...`, 56,780 bytes, 566 mapped codepoints -- `\f0c9` and
 * `\f002` among them. So these are the same two glyphs live draws, from the
 * same file, at the same size, and the button widths fall out of their own
 * advances rather than being pinned.
 *
 * The `<i class="fa fa-...">` markup stays because it is live's. It carries no
 * weight of its own here; the rules below are what make it paint. */
.mobile-header .fa {
	display: inline-block;
	font-family: "FontAwesomePatch";
	font-size: inherit;
	font-style: normal;
	font-weight: 400;
	line-height: 1;
	text-rendering: auto;
	-webkit-font-smoothing: antialiased;
}

.mobile-header .fa-bars:before {
	content: "\f0c9";
}

.mobile-header .fa-search:before {
	content: "\f002";
}

/* `left: auto` is load-bearing: the shared rule above sets `left: 0`, and an
 * absolutely positioned box with both offsets and an auto width resolves to
 * the LEFT one in this writing direction -- the search button would sit on top
 * of the hamburger. Live measures its used `left` at 341.31 with `right: 0`,
 * which is what `left: auto; right: 0` produces. */
.search__trigger {
	left: auto;
	right: 0;
}

/* The 30px logo in the bar. The transform is written by /js/theauto374.js,
 * which parks it over the masthead logo until the page scrolls -- see the note
 * there; `will-change` is live's own and is what keeps that on the compositor.
 * translateX(-50%) is repeated in the JS because it writes the whole property. */
.mobile-header .site-logo-link {
	left: 50%;
	margin-top: 10px;
	position: absolute;
	top: 0;
	transform: translateX(-50%);
	will-change: transform;
}

.mobile-header .site-logo-link,
.mobile-header .site-logo-link img {
	height: 30px;
	width: auto;
}

/* The search overlay ------------------------------------------------------
 *
 * `.is-visible` is THE THEME'S OWN class and its rule is in live's stylesheet,
 * so the open state here is measured rather than invented -- unlike the
 * drawer's, which live writes inline from a drag handler and no capture of a
 * closed page can show. `display: table` + `table-cell` is the theme's
 * vertical centring and is reproduced as-is rather than modernised to flex:
 * a flex child would size differently and the 48px field would move. */
.overlay--search {
	background: var(--ta-c-page);
	border-left: 1px solid var(--ta-c-muted);
	display: table;
	height: 100%;
	left: 100%;
	padding-left: var(--ta-sp-5);
	padding-right: var(--ta-sp-5);
	position: fixed;
	top: 0;
	transition: left 0.3s ease-in-out;
	width: 100%;
	z-index: 151;
}

.overlay--search.is-visible {
	left: 0;
}

.overlay__wrapper {
	display: table-cell;
	vertical-align: middle;
}

/* 620px and centred, which is the measure the whole site is built on -- at
 * 1440 live's field is 620 wide at x=1850.5, dead centre of the 1343px cell,
 * and this build ran it to the full 1343. It only binds above ~620: at 390 the
 * form is the 341px cell, which is what live measures there. */
.overlay--search .search-form {
	border: 0;
	display: block;
	font-family: var(--ta-font-body);
	height: auto;
	margin-left: auto;
	margin-right: auto;
	max-width: 620px;
}

.overlay--search .search-form > label {
	display: block;
	height: auto;
	position: static;
}

/* `line-height: normal` is measured, not a default left alone: something in
 * the seeded stack puts 26px on this input, and a text input whose line-height
 * is shorter than its content area does not shrink to it -- the field came out
 * 71px tall against live's 55.19, which is 48px at the UA's own 1.1497. */
.overlay--search .search-field {
	-webkit-appearance: none;
	border: 0;
	color: var(--ta-c-link);
	display: block;
	/* WORK SANS, and the bundle says Oswald. `.overlay--search .search-form,
	 * .overlay--search .search-field { font-family: Oswald, sans-serif }` is
	 * right there in the theme's stylesheet and live computes "Work Sans" --
	 * wp.com's Global Styles winning again, which is the capture README's very
	 * first correction and the reason this whole rebuild is not in Roboto.
	 * It is not cosmetic here: Oswald's `normal` line-height is ~1.486 against
	 * Work Sans's 1.15, so the field came out 107px tall against live's 82.8. */
	font-family: var(--ta-font-body);
	font-size: 72px;
	height: auto;
	line-height: normal;
	outline: 0;
	padding: 0;
	position: static;
	width: 100%;
}

.overlay--search .search-field::-webkit-input-placeholder { color: var(--ta-c-link); }
.overlay--search .search-field::-moz-placeholder { color: var(--ta-c-link); opacity: 1; }
.overlay--search .search-field:-ms-input-placeholder { color: var(--ta-c-link); }

/* Live hides it: the form submits on return, and the theme's help text says so
 * in as many words. */
.overlay--search .search-submit {
	display: none;
}

/* The close cross is drawn, not typed -- two rotated bars on the same box, so
 * there is no glyph to go missing if the icon font fails. Live's own. */
.overlay__close {
	cursor: pointer;
	height: 48px;
	position: absolute;
	right: var(--ta-sp-5);
	top: var(--ta-sp-5);
	width: 48px;
}

.overlay__close:before,
.overlay__close:after {
	background: var(--ta-c-text);
	content: "";
	display: block;
	pointer-events: none;
	position: absolute;
	transform: rotate(45deg);
}

.overlay__close:before {
	height: 0.16em;
	margin-top: -0.08em;
	top: 50%;
	width: 100%;
}

.overlay__close:after {
	height: 100%;
	left: 50%;
	margin-left: -0.08em;
	width: 0.16em;
}

/* Below the breakpoint ----------------------------------------------------
 *
 * 900px, which is live's -- its own block is `@media not screen and
 * (min-width: 900px)`, the same edge sections 8 to 11 already switch on. */
@media only screen and (max-width: 899px) {

	.mobile-header {
		display: block;
	}

	/* THE DRAWER. `left: -100%` with `margin-left: 48px` puts the box at
	 * x=-342 on a 390 viewport and makes it 342 wide -- live's numbers, and
	 * they come out of the percentages rather than out of a fixed width, so a
	 * 360 or a 430 phone gets the same proportions live gives it.
	 *
	 * `position: fixed` is the whole of the item: in flow this nav was 437px
	 * of the masthead's height on every template. */
	nav.main-navigation {
		background: var(--ta-c-page);
		height: 100%;
		left: -100%;
		margin: 0 0 0 var(--ta-sp-5);
		overflow-y: scroll;
		-webkit-overflow-scrolling: touch;
		padding: var(--ta-sp-4);
		position: fixed;
		right: 100%;
		top: 0;
		transition: transform 0.3s ease-in-out, box-shadow 0.3s ease-in-out;
		z-index: 150;
	}

	/* OPEN. Live drags this one and writes the transform inline from a touch
	 * handler, so the open state is the one thing on this page that a capture
	 * of a closed site cannot supply. Translating by the drawer's own width is
	 * what the closed geometry implies, and `.shadow` is the theme's own class
	 * with the theme's own shadow. */
	nav.main-navigation.is-open {
		transform: translateX(100%);
	}

	nav.main-navigation.shadow {
		box-shadow: rgba(0, 0, 0, 0.25) 0 0 24px, rgba(0, 0, 0, 0.5) 0 0 12px;
	}

	/* The drawer scrolls itself; the page behind it must not, or a phone
	 * scrolls the article while the menu is open on top of it. */
	.nav-is-open,
	.nav-is-open body {
		overflow: hidden;
	}

	/* Inside the drawer the two lists lose the rail's 96px right margin and
	 * its 24px inset -- the 24px of padding on the nav is what insets them
	 * here. Measured: .nav--main 294 wide at x=-318 inside a drawer at -342. */
	.nav--main,
	.nav--social,
	.single .nav--main,
	.single .nav--social,
	.page .nav--main,
	.page .nav--social {
		margin-left: 0;
		margin-right: 0;
	}

	.nav--main {
		margin-bottom: var(--ta-sp-4);
	}

	/* The overlay is narrower on a phone and its field drops from 72 to 48 --
	 * both measured, both live's. */
	.overlay--search {
		padding-left: var(--ta-sp-4);
		padding-right: var(--ta-sp-4);
	}

	.overlay--search .search-field {
		font-size: 48px;
		margin-bottom: var(--ta-sp-4);
	}

	.overlay__close {
		right: var(--ta-sp-4);
		top: var(--ta-sp-4);
	}
}

/* Above the breakpoint the drawer is an ordinary block in the rail again, and
 * the three properties the mobile block sets on it have to be unset explicitly
 * -- live carries the same reset, `transform: none !important` and all, because
 * its own JavaScript leaves an inline transform behind on resize. Ours does not
 * write one, but `.is-open` can survive a rotation from portrait to landscape
 * across the breakpoint, and without this the desktop rail would slide. */
@media only screen and (min-width: 900px) {
	nav.main-navigation,
	nav.main-navigation.is-open {
		box-shadow: none !important;
		transform: none !important;
		transition: none !important;
	}
}

/* --------------------------------------------------------------------------
 * 14. THE SIDEBAR -- woodzgit/theauto#38.
 *
 * Live renders `#secondary.sidebar` on its singles and pages; this build
 * rendered it nowhere, and that absence WAS the largest visible difference
 * from live: /contact/ measured 956px here against live's 4,001px.
 *
 * MEASURED ON LIVE, 2026-08-13, article template:
 *   #secondary       220 x 3029.703  float:left   at 1440
 *                    342 x 3656.922  float:none   at 390
 *   .widget-title    220 x 22.391    14px    <- #33's residual row 1 exactly,
 *                                               "220 x 22.39"
 *   .sidebar .widget 220 wide, 13px
 *   .jetpack-display-remote-posts img  219.984 x 146.547   (3:2)
 *
 * `clear:left` IS LOAD-BEARING. Section 12 already floats `.site-header` left
 * as the 220px rail and floats `.content-area` right with margin-left:-220px.
 * A second left float of the same width does not know the left column is only
 * 220 wide -- it knows only that the LINE has room, because #primary's box
 * starts at the same x. Without the clear, the sidebar lands BESIDE the
 * masthead, in the measure. With it, it stacks beneath the masthead in the
 * rail, which is where live puts it.
 *
 * Mobile needs no float rule at all: below 900px the rail collapses and a
 * plain block at the measure's width is already live's 342.
 * ------------------------------------------------------------------------*/

/* THE TYPE. Re-measured against live 2026-08-14, same article, same width, and
 * the numbers below are live's computed styles -- not a reading of live's
 * stylesheet, which is not ours to read after cutover.
 *
 * In one line: live's sidebar is Oswald, uppercase, 14px, 1.4px tracking; this
 * build was rendering Work Sans, sentence case, 13px, no tracking. Two separate
 * defects produced that, and neither is visible by reading this rule alone:
 *
 *   1. `var(--ta-font-head)` DID NOT EXIST. The token is `--ta-font-display`.
 *      An undefined custom property makes the whole declaration invalid at
 *      computed-value time, so font-family fell back to inherited Work Sans --
 *      silently, with no warning anywhere. The rule LOOKED right, which is why
 *      it survived a review. `ops/cssvars.py` now fails the build on this.
 *   2. base.css:539 `.widget .widget-title:not(.ribbon){margin-bottom:15px}`
 *      is (0,3,0) and beat `.sidebar .widget-title` at (0,2,0), so the 8px
 *      here never applied and the measured value was base.css's 15px. Hence
 *      `.sidebar .widget .widget-title` below -- (0,3,0), and theauto.css
 *      loads last, so it wins on order. Do not shorten that selector back.
 *
 * LINE-HEIGHT IS INHERITED ON PURPOSE. Every box live renders in this sidebar
 * computes to exactly 1.6x its own font-size -- 13px/20.8 on the widget, the
 * post-list div and the images, 14px/22.4 on both the widget title and the post
 * titles. That is one unitless 1.6 inherited from the widget, not five
 * declarations, so it is written once here. The only places it is restated are
 * the anchors, because the bare `a` rule near the top of this file sets
 * line-height directly and a matched rule always beats inheritance.
 * ------------------------------------------------------------------------*/

/* THE VIGNETTE -- client review 2026-08-17, woodzgit/theauto#96.
 *
 * "Is it possible to run a vignette behind the sidebar on all other pages
 * besides the main home, very soft, starting at 25 or 20% black at the bottom
 * and ending up plain white about 3/4 of the way up? Just to differentiate it a
 * tiny bit."
 *
 * Written exactly that way round: opaque at the BOTTOM, clear by 75% UP. In a
 * CSS gradient `to top` means the first colour stop is at the bottom edge, so
 * the 20% sits at 0% and the transparent stop at 75%; the top quarter is
 * untouched white.
 *
 * 20%, THE SOFTER END OF THE TWO NUMBERS OFFERED, because the same message
 * says "very soft" and "a tiny bit" and this rail is ~3,000px tall -- a tint
 * that reads as gentle across one screenful is a solid grey block when it runs
 * the whole column. Easy to take to 25% if they want more; it is one number.
 *
 * rgba(0,0,0,0) RATHER THAN `transparent` IS LOAD-BEARING. `transparent`
 * computes to rgba(0,0,0,0) in modern browsers, but a gradient interpolating
 * towards a keyword used to pass through visibly grey midpoints in older
 * engines; naming the colour with a zero alpha keeps the whole ramp on the
 * same black and cannot produce that band.
 *
 * NO HOME-PAGE EXCLUSION IS NEEDED, and this was checked rather than assumed:
 * neither live nor this build renders `#secondary` on the home page at all
 * (woodzgit/theauto#45 measured it across every captured page), so "all other
 * pages besides the main home" is already every page this selector can match.
 * It applies on the singles and static pages, where the sidebar is the floated
 * 220px rail, and on the category archives, where it is a grid cell.
 *
 * ON `#secondary`, NOT ON `.grid__item--sidebar`. The cell is 419.953 wide on
 * an archive and the rail inside it is 220. Painting the cell would put a grey
 * wash under the gutter as well and read as a wide grey column, which is the
 * opposite of the "tiny bit" asked for.
 *
 * THE 15px RIGHT INSET IS THE SECOND HALF OF THE SAME REQUEST -- client, later
 * the same day, having seen the vignette: "I see the vignette, maybe we can add
 * a 3-5 mm little margin to the right of the images etc?"
 *
 * 15px, because CSS defines 1mm as exactly 96/25.4 px, so 4mm -- the middle of
 * the range asked for -- is 15.12px. Written in px rather than as `4mm`
 * deliberately: CSS physical units are nominal, not measured against the actual
 * display, so `4mm` promises something the browser cannot deliver and hides a
 * plain 15.12 behind a unit that looks authoritative.
 *
 * IT IS PADDING ON THE RAIL, NOT MARGIN ON THE IMAGES. Three reasons, and the
 * third is the one that decided it:
 *   1. "the images etc" -- every widget gets it, including any added later,
 *      rather than a rule per image type (there are three: the post
 *      thumbnails, the two wp-block promos, and now the 40px trending icons).
 *   2. `#secondary` is border-box, so the rail stays exactly 220 wide and the
 *      column arithmetic in sections 14 and 17 is untouched. Only the content
 *      inside it narrows, 220 -> 205.
 *   3. A background paints across the PADDING box. So the vignette shows
 *      through the new 15px strip, which is what makes it read as a margin
 *      against a tinted rail rather than as a gap in a white one -- the effect
 *      the client is describing when they say "etc" after "the images".
 *
 * The images are `width:100%`, so they follow the content box down to 205
 * without another rule.
 *
 * *** BOTH REVISED AGAIN THE SAME DAY, and both on the client's own reading of
 * the first version: "1: same margin other side. 2: Let it fade further up so
 * it disappears more behind the trending now lot. Thnk that really worked
 * well!" ***
 *
 * SAME MARGIN OTHER SIDE -- `padding-left` now matches `padding-right`, so the
 * rail's content is a centred 190px column inside the 220px box with 15px of
 * tinted gutter each side. The rail itself is still exactly 220 and the column
 * arithmetic in sections 14 and 17 is still untouched; `#secondary` is
 * border-box, so all of this happens inside it.
 *
 * THE FADE NOW ENDS AT 90%, NOT 75%. "Disappears more behind the trending now
 * lot" is a position, not a colour: TRENDING NOW ON AUTO is the second widget
 * and sits in the top ~12% of a ~3,000px rail, so a ramp that was already clear
 * by 75% had gone completely before it got anywhere near that widget. Taking
 * the transparent stop to 90% carries the tint up past Latest: Auto. and lets
 * it die out behind Trending Now itself, which is where they are pointing.
 *
 * The 20% at the foot is UNCHANGED -- they said this version worked, so the
 * strength is not what moved; only where it runs out. */
#secondary {
	background-image: linear-gradient(to top,
	                                  rgba(0, 0, 0, 0.20) 0%,
	                                  rgba(0, 0, 0, 0) 90%);
	padding-left: 15px;             /* ~4mm, matching the right */
	padding-right: 15px;            /* ~4mm; see the note above */
}

/* Live puts 24px above the rail once it stops being a rail and stacks under the
 * content, and this build had 0. Found by #89 item 3's 390 pass -- it does not
 * show at 1440 at all, because live's own value there is 0.
 *
 * THE BREAKPOINT IS MEASURED, NOT ASSUMED. Live was read at 899 and at 900 on
 * 2026-08-18: padding-top 24px at 899 (rail 851 wide, stacked), 0px at 900
 * (rail 220, floated). So live's boundary is exactly this file's own 900, and
 * max-width:899 reproduces it rather than approximating it.
 *
 * Without this the first widget butts straight against the content above it on
 * a phone, which is the one width where the rail has no column of its own to
 * separate it. */
@media only screen and (max-width: 899px) {
	#secondary {
		padding-top: 24px;
	}
}

.sidebar .widget {
	font-size: 13px;
	line-height: 1.6;               /* -> 20.8px @13, and 22.4px @14 below */
	margin: 0 0 40px;               /* live; was 24px */
}

.sidebar .widget .widget-title {
	font-family: var(--ta-font-display);
	font-size: 14px;
	font-weight: var(--ta-w-normal);
	letter-spacing: 1.4px;
	line-height: 1.6;               /* 22.4px @14 -- see the h4 note below */
	margin: 0 0 25px;               /* live; base.css was forcing 15px */
	text-transform: uppercase;
}

/* TRENDING NOW ON AUTO -- woodzgit/theauto#89, client review 2026-08-16.
 *
 * "it has the smaller trending now icons above the Latest blocks."
 *
 * This widget was refused until now and the refusal was about the DATA, never
 * the layout -- see the header of webapp/_sidebar38.asp, which still carries
 * the argument and now carries the decision that replaced it. What follows is
 * the box.
 *
 * MEASURED ON LIVE 2026-08-16, /contact/ at 1440, with ops/measure.py -- not
 * read off live's stylesheet and not inferred from the 2026-08-11 capture,
 * which does not carry this widget at all:
 *
 *   .widget_top-posts              220 x 420.641   margin-bottom 40
 *   .widget-title                  220 x 22.391    Oswald 14/22.4, ls 1.4
 *   ul.widgets-list-layout         220 x 373.25    13px / 18.2  padding 0
 *   li                             220 x 54.563    margin-bottom 15
 *   img.widgets-list-layout-blavatar 40 x 40       display:block  float:left
 *   div.widgets-list-layout-links  176 x 54.563    float:right
 *   .widgets-list-layout-links a   13px / 500 / rgb(0,0,0)
 *
 * Only the last four need rules. The aside and its h4 are already live's,
 * because `.sidebar .widget` and `.sidebar .widget .widget-title` above are
 * written to live's numbers and this widget is one of the asides they match --
 * which is exactly why they were written as class rules and not per-widget.
 *
 * TWO THINGS THAT LOOK LIKE DECORATION AND ARE NOT:
 *
 * 1. line-height 1.4, NOT the widget's 1.6. Live computes 18.2px on the ul,
 *    the li, the div and the anchor -- every box in this widget -- against
 *    20.8px everywhere else in the same sidebar. One value on the ul, inherited
 *    down, reproduces all four. Left at the inherited 1.6 each list item runs
 *    3 x 2.6px tall and the widget ends ~47px over live.
 * 2. The ::after clearfix. Both children float, so without it the li has no
 *    in-flow content and computes height 0 -- the six items would pile up and
 *    the ul would collapse. Live's li is 54.563, which is the taller of the two
 *    floats (a 3-line title at 18.2), so a clearfix and not a fixed height:
 *    a 2-line title has to produce a shorter row, the way live's does.
 *
 * 40px + 4px + 176px = 220. The 4px gap is not declared anywhere -- it is what
 * is left between a 40px left float and a 176px right float in a 220px line,
 * which is how live gets it too.
 *
 * *** THE `.widget` IN THE FIRST TWO SELECTORS IS LOAD-BEARING, AND THE FIRST
 * CUT OF THIS SHIPPED WITHOUT IT. *** base.css carries
 *
 *     .widget > ul:not(.entries) li { margin-bottom: 5px; font-size: 13px;
 *                                     line-height: 20px }   base.css:554
 *
 * and `:not()` takes the specificity of its ARGUMENT, so that is (0,2,2) --
 * above the (0,2,1) of a plain `.sidebar .widgets-list-layout li`, and
 * specificity is settled before source order, so theauto.css loading last does
 * not save it. MEASURED on DEV after the first deploy: li 60px tall with a 5px
 * gap against live's 54.563 and 15, and the widget 392.391 against live's
 * 420.641. Adding `.widget` makes them (0,3,0) and (0,3,1).
 *
 * This is the THIRD time base.css has quietly out-specified a rule in this
 * section -- `.widget .widget-title:not(.ribbon)` was the first, and its note
 * is 60 lines up. Do not shorten either selector back. */
.sidebar .widget .widgets-list-layout {
	line-height: 1.4;               /* -> 18.2px @13; NOT the widget's 1.6 */
	list-style: none;
	margin: 0;
	padding: 0;
}

.sidebar .widget .widgets-list-layout li {
	line-height: 1.4;               /* beats base.css:554's matched 20px, which
	                                 * inheritance from the ul cannot */
	margin: 0 0 15px;
}

.sidebar .widgets-list-layout li::after {
	clear: both;
	content: "";
	display: table;
}

.sidebar .widgets-list-layout-blavatar {
	display: block;
	float: left;
	height: 40px;
	width: 40px;
}

/* *** THIS WAS A FIXED 176px AND #99's 15px RAIL INSET BROKE IT. Measured, and
 * it is why that inset was re-measured instead of eyeballed. ***
 *
 * Live's numbers are 40px image + 4px gap + 176px text = the 220px rail, and
 * 176 was written as a literal because that is what live computes. The moment
 * `#secondary` took `padding-right: 15px` the content box became 205, and
 * 40 + 176 = 216 no longer fits: the right float dropped BELOW the left one on
 * every row. MEASURED on DEV before this fix -- all six items reported the
 * image and the text on different y, the rows ran 58-95px instead of ~54, and
 * the widget came out 569.63 tall against live's 373.25.
 *
 * `calc(100% - 44px)` is the same arithmetic expressed as the relationship it
 * always was: 44 is live's own 40 + 4. It resolves to exactly 176 in a 220 box,
 * so nothing changes if the inset is ever removed, and it follows the content
 * box wherever the rail's padding puts it.
 *
 * The lesson generalises: any literal in this section that was copied from a
 * 220px live measurement is really a fraction of the rail, and will break the
 * next time the rail's padding moves. */
.sidebar .widgets-list-layout-links {
	float: right;
	width: calc(100% - 44px);       /* 176 at live's 220; 40px image + 4px gap */
}

.sidebar .widgets-list-layout-links a {
	color: var(--ta-c-link);
	font-weight: var(--ta-w-medium);
}

/* The post list. Live emits a bare h4 per post and an anchor-wrapped image
 * under it -- no list markup at all -- so the rhythm has to come from these
 * rules rather than from an li.
 *
 * The 5px top margin is not decoration: it collapses with the widget title's
 * 25px on the first post and is therefore invisible there, and between posts it
 * is what puts 11.79px under each image -- live's measured gap, the inline
 * image's descender space plus this.
 *
 * line-height is restated here and on the widget title ONLY because
 * /vendor/bootstrap/css/bootstrap.min.css carries `h4{line-height:1.1}`. That
 * is an element selector, and an element selector beats INHERITANCE outright --
 * inheritance is not a cascade competitor, it is only what happens when nothing
 * matches. Measured before this line went in: the h4 computed 15.4px (1.1 x 14)
 * against live's 22.4. The rendered box happened to look right anyway, because
 * the anchor inside sets the line boxes -- so this was invisible until the
 * computed style was read directly. Bootstrap is inherited with the
 * motorsportmedia seed and is still linked ahead of this file. */
.sidebar .jetpack-display-remote-posts h4 {
	font-family: var(--ta-font-display);
	font-size: 14px;
	font-weight: var(--ta-w-normal);
	letter-spacing: 1.4px;
	line-height: 1.6;               /* 22.4px @14; beats bootstrap's h4 1.1 */
	margin: 5px 0;
	text-transform: uppercase;
}

/* Live gets EVERYTHING in this sidebar by inheritance. The anchors cannot: the
 * bare `a` rule near the top of this file sets font-family and line-height
 * directly, and a matched rule beats inheritance. So put them back ON the
 * inherited value. font-size, letter-spacing and text-transform need no help --
 * that rule either says `inherit` or does not name them.
 *
 * THIS IS DELIBERATELY SCOPED TO EVERY SIDEBAR ANCHOR, and the first cut of it
 * was not, which cost a second round trip. It named only
 * `.jetpack-display-remote-posts h4 a`, so the WIDGET-TITLE anchors -- the two
 * Facebook headings, which live renders as links -- kept falling through to
 * Work Sans. Measured: "Auto & Sport Facebook Group" came out 164.47 wide
 * against live's 125.53 in Oswald, which pushed the title onto a SECOND LINE
 * and made that widget 92.58 tall against live's 68.19. Any widget added later
 * whose title is a link would have hit exactly the same thing. */
.sidebar .widget a {
	font-family: inherit;
	line-height: inherit;
}

/* The image anchor is INLINE on live, not a block: that is what puts the image
 * on a baseline and produces the descender the 5px margin above is measured
 * against. As a block with its own 12px margin the rhythm ran 12px loose per
 * post, 60px over five. */
.sidebar .jetpack-display-remote-posts h4 + a {
	display: inline;
	margin: 0;
}

/* width:100% and height:auto, not the measured 220x147: the box is 220 at
 * 1440 and 342 at 390, and the intrinsic ratio carries the height at both.
 * `display` differs between the two -- inline for the post images, to sit on
 * the baseline as above; block for the wp-block images, which live renders as
 * blocks inside an inline-block anchor.
 *
 * `vertical-align: baseline` IS LOAD-BEARING, and this is the SECOND time this
 * exact trap has been paid for on this site -- see .site-branding img in
 * section 12, which carries the same line for the same reason.
 * /vendor/bootstrap/css/bootstrap.min.css carries `img{vertical-align:middle}`,
 * and a middle-aligned image CENTRES on the baseline instead of sitting on it,
 * which collapses the line box onto the image and destroys the descender
 * underneath. Measured: with `middle` the gap under each post image was 5px
 * against live's 11.79, and the widget came out 30px short over five posts.
 * Live's theme has no bootstrap beneath it and computes `baseline`. */
.sidebar .jetpack-display-remote-posts img {
	display: inline;
	height: auto;
	max-width: 100%;
	vertical-align: baseline;
	width: 100%;
}

.sidebar .wp-block-image img {
	display: block;
	height: auto;
	max-width: 100%;
	width: 100%;
}

/* `display: flow-root` reproduces a measured effect, not a whim. Live's second
 * image block is a `display: table` figure with a `table-caption` figcaption, so
 * the caption's 13px bottom margin is INSIDE the figure: 329.83 image + 6.8
 * descender + 6.5 + 62.39 caption + 13 = live's 418.52 exactly. As an ordinary
 * block the caption's bottom margin escapes through the figure and collapses
 * with its own, and the box comes out 405.52. flow-root establishes a block
 * formatting context, which contains it -- the same result as live's table
 * without reproducing table layout to get there. On the FIRST image block,
 * which has no caption, it changes nothing.
 *
 * The anchor is `inline-block` on live, and that is where the 6.8px under each
 * image comes from -- the descender of the line the inline-block sits on. As a
 * plain inline wrapping a block-level image it produced no descender at all and
 * the first block measured 220 against live's 226.8. Same mechanism as the post
 * images above, arrived at from the opposite direction. */
.sidebar .wp-block-image {
	display: flow-root;
	margin: 0 0 13px;               /* live; was 12px */
}

.sidebar .wp-block-image a {
	display: inline-block;
}

.sidebar .wp-block-image figcaption {
	margin: 6.5px 0 13px;
}

/* Live's last widget carries no bottom margin. Ours did, so #secondary ran 40px
 * long whatever else was right. */
.sidebar .widget:last-child {
	margin-bottom: 0;
}

@media only screen and (min-width: 900px) {
	.single .sidebar,
	.page .sidebar {
		clear: left;
		float: left;
		position: relative;
		width: 220px;
		z-index: 5;                 /* live's own value; was a seeded 10 */
	}
}

/* --------------------------------------------------------------------------
 * 15. MASONRY -- woodzgit/theauto#39 item 1.
 *
 * These rules do NOTHING until js/theauto374.js adds .grid--masonry, and that
 * is the whole design: if the script is blocked or fails, the float grid in
 * section 9 stands exactly as it did. Absolute cells with no JS to place them
 * would pile at 0,0 -- a far worse failure than the gaps this fixes.
 *
 * The height on #posts is written by the script, because absolutely positioned
 * children do not contribute to their parent's height and the footer would ride
 * up over the grid without it.
 * ------------------------------------------------------------------------*/

.grid--masonry {
	position: relative;
}

.grid--masonry > .grid__item {
	position: absolute;
	top: 0;
	left: 0;
	/* The float and its bottom margin are what section 9 uses to lay the grid
	 * out; under masonry the script owns both, and a surviving float would
	 * fight the absolute placement. margin-bottom is still READ by the script
	 * for the 30px gutter, so it is zeroed here and applied as position. */
	float: none;
	/* BOTH margins, not just the bottom. margin-top on an absolutely
	 * positioned box is ADDED to `top` by the browser, so leaving the
	 * nth-child(1)/(3) 50px in place would apply it twice -- once as the
	 * script's measured offset and once by the browser. The script reads both
	 * values off the natural layout before this class lands. */
	margin-top: 0;
	margin-bottom: 0;
}

/* --------------------------------------------------------------------------
 * 16. THE LEAD STORY -- woodzgit/theauto#44.
 *
 * A DEPARTURE FROM LIVE, ON PURPOSE. Live's grid is uniform: every card is
 * 419.953 x ~414.5 and the only oversized cell is the masthead. Operator
 * request, 2026-08-13, revised the same day -- the first version was taller
 * only, and the ask was "wider too, more post card like".
 *
 * TWO COLUMNS WIDE. That needs real span support in the masonry loop, which
 * until now assumed one column per cell; js/theauto374.js seats a spanning cell
 * on the PAIR of adjacent columns whose deeper edge is highest. Width is set
 * here rather than in JS so the cell measures correctly before it is placed --
 * the script reads offsetHeight off the natural layout, and a cell that is
 * still one column wide at measuring time reports the wrong height for its
 * final width.
 * ------------------------------------------------------------------------*/

@media only screen and (min-width: 900px) {
	/* Two of the two columns this breakpoint has is the whole row, which is a
	 * banner rather than a lead. One column, taller only, until 1260. */
	.grid__item--lead .entry-image-wrapper {
		aspect-ratio: 640 / 560;
	}

	/* The card rules pin and clip these two boxes because a FLOAT grid needed
	 * equal heights (the DEVIATION note in section 9). Masonry measures real
	 * heights, so the lead can run to its natural length. */
	.grid__item--lead .entry-header--medium,
	.grid__item--lead .entry-content--short {
		height: auto;
		overflow: visible;
	}
}

@media only screen and (min-width: 1260px) {
	/* 66.66% = TWO of this breakpoint's three 33.33% columns. */
	.grid__item--lead {
		width: 66.66%;
	}

	/* 16:9-ish. At two columns wide the card ratio (3:2) would make the image
	 * as tall as it is at one column and twice as wide -- which is what "a bit
	 * tall" was. */
	.grid__item--lead .entry-image-wrapper {
		aspect-ratio: 640 / 360;
	}

	/* *** CLIENT REVIEW 2026-08-16, woodzgit/theauto#87 -- A DELIBERATE
	 * DEPARTURE PAST LIVE, NOT A FIDELITY FIX. ***
	 *
	 * "Make the top story headline bigger by 50%, if possible also bold. Also
	 * take the subhead up 2-3 points in size."
	 *
	 * THE 50% IS OFF THIS BUILD, NOT OFF LIVE, and that is worth writing down
	 * because the two are already different:
	 *
	 *   live's .entry-title          26px / 400   (uniform grid, no lead card)
	 *   this build, before today     34px / 400   (#44's lead card)
	 *   asked for, and shipped       51px / 700   -- 34 x 1.5
	 *
	 * So the headline is now ~2x live. Anyone re-measuring against the
	 * 2026-08-11 capture will read that as a regression and "fix" it back to
	 * 26px. It is not a regression: the client looked at THIS site and asked
	 * for more. ops/adjudicate.py carries the matching DELIBERATE rules.
	 *
	 * letter-spacing is NOT restated: .entry-title's 0.04em is a ratio, so it
	 * tracks the size on its own -- 1.36px at 34, 2.04px at 51.
	 *
	 * NO CLIPPING RISK AT THIS BREAKPOINT, and it was checked rather than
	 * assumed. Section 9 pins .entry-header--medium and .entry-content--short
	 * to fixed heights so the FLOAT grid can have equal cells; the >=900 block
	 * above already restores height:auto/overflow:visible on the lead for the
	 * masonry layout, and 1260 is inside 900. Below 900 the lead is an ordinary
	 * card at 26px and neither rule here applies.
	 *
	 * "2-3 POINTS" IS READ AS 2-3 CSS PIXELS -- 16 -> 18. The client is not
	 * writing CSS and points are not pixels; if they meant typographic points,
	 * 2-3pt is 2.7-4px and the answer would be 19-20. 18 shipped; say the word
	 * and it moves.
	 *
	 * The line-height comes with it. 24px was 1.5 of 16; 27px is 1.5 of 18, so
	 * the subhead's rhythm is unchanged rather than tightened by the growth.
	 *
	 * *** THE CHILD SELECTORS ARE THE WHOLE FIX, AND THE FIRST CUT SHIPPED
	 * WITHOUT THEM. *** Setting the type on `.entry-title` and
	 * `.entry-content--short` alone changed NOTHING a reader can see, and it
	 * measured green on the two boxes anybody would have checked. The visible
	 * text is not in either of them:
	 *
	 *   `.entry-title a`  has its own (0,2,1) rule near the top of this file --
	 *      26px / 500, the card link. MEASURED on DEV after the first deploy:
	 *      the h1 box grew to 58.703 while the anchor inside it stayed 26px /
	 *      37.7. A bigger empty box around the same small headline.
	 *   `.entry-content--short p` is matched by the bare `p` rule -- 16 / 24.
	 *      Same result: the div reported 18px and the sentence stayed 16.
	 *
	 * A MATCHED RULE ALWAYS BEATS INHERITANCE. Inheritance is not a cascade
	 * competitor; it is only what happens when nothing matches. This file has
	 * now paid for that four times -- the sidebar anchors and the bootstrap h4
	 * in section 14, and these two. Both selectors below are (0,3,1) against
	 * the (0,2,1) and (0,0,1) they have to beat.
	 *
	 * The parent rules are kept as well as the children, not instead of them:
	 * the h1's own line-height is what sizes the line BOX the anchor sits in,
	 * so leaving it at 37.7 would clip a 57.12px inline. */
	.grid__item--lead .entry-title,
	.grid__item--lead .entry-title a {
		font-size: 51px;
		font-weight: var(--ta-w-bold);
		line-height: 1.12;
	}

	.grid__item--lead .entry-content--short,
	.grid__item--lead .entry-content--short p {
		font-size: 18px;
		line-height: 27px;
	}
}

/* *** THE BREAKPOINT THIS ORIGINALLY MISSED. *** #44 was measured and signed
 * off at 1440, where the grid has three columns and 66.66% is exactly two of
 * them. The reviewer's window was wider: past 1700 the grid goes to FOUR
 * columns at 25%, and 66.66% of that is 2.67 columns -- which the masonry's
 * `Math.round(w / itemW)` then seats as THREE. Measured at 1920: the lead came
 * out 1159.9 wide against a 435 pitch, three of four columns, ~75% of the
 * grid. That is the "about 4/5ths of the page width" in the review, and the
 * extra height came with it.
 *
 * A percentage that means "two columns" is not one number -- it is one per
 * column count. 50% of four is the same two columns 66.66% of three is. */
@media only screen and (min-width: 1700px) {
	.grid__item--lead {
		width: 50%;
	}
}

/* *** THE SECTION PAGE, WHERE THE LEAD CAME OUT SECOND. *** Operator, 2026-08-14:
 * "on the section page it is the second story that is bigger, not the first? Or
 * maybe it's just been positioned wrongly?" -- positioned, and by an interaction
 * this file had no rule for.
 *
 * MEASURED, `/news/`, ops/measure.py boxes:
 *
 *   width  cols  .page-header      .grid__item--lead     reads as
 *   1280    3    col 1 @ y=128     cols 1-2 @ y=303      lead BELOW the label
 *   1440    3    col 1 @ y=128     cols 1-2 @ y=303      lead BELOW the label
 *   1920    4    col 1 @ y=128     cols 2-3 @ y=78       lead top-right -- correct
 *
 * THE MECHANISM IS A COLUMN COUNT, WHICH IS WHY IT IS A BAND AND NOT A BUG IN
 * EITHER CELL. Column 0 is spoken for on every archive: the masthead, and under
 * it the sidebar that section 17 pins there. At FOUR columns that leaves three
 * free, the `.page-header` takes one, and the lead still finds an untouched
 * adjacent PAIR -- so it seats at the top and the layout is right. At THREE it
 * leaves exactly two, the `.page-header` takes one of them, and there is no
 * untouched pair left: theauto374.js seats the lead on the pair whose deeper
 * edge is highest, which is (1,2) BELOW the label. Column 2 is then empty from
 * y=128 to y=303 -- a 175px hole of the same family item 1 is about.
 *
 * NEITHER CELL IS AT FAULT. `_cards374.asp` marks the lead from the loop's own
 * counter, correctly, on both templates; and `page-header entry-card` is LIVE'S
 * OWN markup -- archive-news.desktop.html in the capture carries
 * `<div class="page-header entry-card">` verbatim. The conflict is between live's
 * page-header cell and OUR lead, which live does not have. So the resolution is a
 * design call on our own departure, not a divergence from live: operator chose
 * the label as a banner across both free columns, with the lead beneath it.
 *
 * BOUNDED AT BOTH ENDS, DELIBERATELY.
 *   below 1260  only ONE column is free, everything is a single stack, and a
 *               two-column banner cannot be seated at all. Nothing to do.
 *   1260-1699   the band that is wrong. The label spans both free columns.
 *   1700 and up ALREADY CORRECT -- do not touch. Spanning the label here would
 *               take a second column away from a lead that currently seats at
 *               the top, and push it down: the fix would cause the defect.
 *
 * No width is set here for the span itself -- 66.66% is two of this band's three
 * 33.33% columns, the same arithmetic section 16 records for the lead, and the
 * masonry derives the span from the measured width (`Math.round(w / itemW)`),
 * so the cell spans without the script knowing anything about this class. */
@media only screen and (min-width: 1260px) and (max-width: 1699px) {
	.grid__item--pagehead {
		width: 66.66%;
	}
}


/* --------------------------------------------------------------------------
 * 17. THE SIDEBAR ON SECTIONS -- woodzgit/theauto#45.
 *
 * ALSO A DEPARTURE FROM LIVE: measured across every captured page in #38, live
 * renders its sidebar on singles, pages, search and 404, and on NEITHER the home
 * page nor any category archive.
 *
 * BELOW THE LOGO, NOT BESIDE THE GRID. The first version of this floated a
 * 220px rail and pushed the card grid across, which cost a column and moved the
 * masthead off the left edge. The operator's actual picture was the sidebar
 * sitting UNDER the masthead, with the page width unchanged -- so the sidebar
 * is now a CELL OF THE GRID, emitted by header.asp immediately after the
 * masthead's cell, and js/theauto374.js pins it to column 0 so it always lands
 * beneath the logo rather than wherever "shortest column" would have put it.
 *
 * The page keeps live's three columns at the 419.953 pitch. Nothing about the
 * grid's geometry changes -- the sidebar simply occupies the left column below
 * the masthead, the way another card would.
 * ------------------------------------------------------------------------*/

.grid__item--sidebar .sidebar {
	float: none;
	width: auto;
}

@media only screen and (min-width: 900px) {
	/* Section 14 floats the sidebar into the 220px rail on singles and pages.
	 * Inside a grid cell it is the cell that positions it, so the float and the
	 * clear are undone here rather than section 14 being made conditional.
	 *
	 * *** THE WIDTH IS NOT UNDONE ANY MORE -- CLIENT REVIEW 2026-08-16,
	 * woodzgit/theauto#89. ***
	 *
	 * "we need to get back to the original side bar on those pages because its
	 * difficult to differentiate the sidebar from the content blocks ... in
	 * other words, it's a bit smaller."
	 *
	 * The client is describing one number. `width: auto` let the sidebar fill
	 * the whole grid cell, and MEASURED on DEV /news/ at 1440 that is 347.95px
	 * -- the 419.953 column less this section's 24 left and 48 right insets.
	 * A card column on the same page is 395.95. At 348 the sidebar reads as a
	 * fourth, slightly-narrow CONTENT column; live's rail is 220 and reads as
	 * furniture. That difference IS the complaint, and it is the whole of it.
	 *
	 * 220px is live's own measured `#secondary` width -- section 14's header
	 * records it, and it is re-confirmed against live 2026-08-16:
	 *   #secondary  220 x 3058.891  float:left  at 1440, /contact/
	 *
	 * NOTHING ELSE IN THE GRID MOVES. The CELL keeps its column width and its
	 * insets, so the masonry pitch, the column count and every card's x are
	 * untouched; only the rail inside the cell narrows. The left inset still
	 * lines the rail up under the logo (#59), and the right inset is now slack
	 * rather than the gutter -- harmless, and left in place so the cell's
	 * geometry still matches the comment above it if the width is ever changed
	 * back. */
	.grid__item--sidebar .sidebar {
		clear: none;
		float: none;
		width: 220px;
	}
}

/* THE 24px INSET, WHICH THE SIDEBAR WAS NOT TAKING -- the "left column is
 * bleeding into the page content" in the review, with a screenshot.
 *
 * A card is 395.953 wide inside a 419.953 column: the grid carries a 24px
 * transparent left border and each .entry-card pulls back out of it, so every
 * card ends 24px short of the next column and that gap IS the gutter. The
 * sidebar is not an .entry-card and took none of it -- measured at 1920, the
 * cell was 435 wide at x=102 and #secondary filled all 435, ending exactly on
 * 537 where the next column begins. Not an overlap in the box sense, but with
 * zero gutter it reads as one, and the images made it obvious.
 *
 * Applied to the cell rather than the widgets so every widget inherits it,
 * including any added later.
 *
 * THE LEFT SIDE IS HERE TOO NOW -- woodzgit/theauto#59, 2026-08-14, operator
 * screenshot of /bakkie/. The right inset alone left the widgets starting on
 * the cell's own edge while the masthead directly above them starts one rail
 * inset in (.site-branding margin-left), so the sidebar images hung out to the
 * LEFT of the logo:
 *
 *                    #secondary x    .site-branding x
 *   1440             102             126
 *   1920             102             132
 *
 * Both sides now take the same token, so the rail lines up under the logo at
 * every width and clears the next column by the same amount it always did.
 *
 * ⚠️ THE TOKEN IS 24px AND ABOVE 1450 THE GEOMETRY IS 30 -- see the override in
 * the trailing 1450 block at the end of this file. It has to live there, not
 * here, for the same ordering reason the rail and the card do.
 *
 * THE RIGHT SIDE IS 2x THE LEFT, AND THAT IS THE CARD'S OWN PAIR. First pass at
 * #59 used the rail inset on both sides. That removed the overlap and lined the
 * rail up under the logo, but it left the widgets ending EXACTLY where the next
 * column's card text begins -- 0.05px of gutter at 1440, 0.00 at 1920 -- and a
 * screenshot of that still reads as touching, which is the whole complaint.
 *
 * Every other column gets its gutter from `.entry-card`'s margin pair: -24/48
 * below 1450 and -30/60 above it. The card pulls LEFT out of the cell and gives
 * back DOUBLE on the right, and the measured gap between two cards is 24.05 at
 * 1440 and 30.00 at 1920.
 *
 * The sidebar cannot use the negative half -- it has to stay under the logo,
 * which sits one inset IN -- but it can and now does use the positive half. So:
 * left = the rail inset (aligns with .site-branding), right = twice it (the same
 * gutter every card column has). */
.grid__item--sidebar {
	padding-left: var(--ta-rail-inset);
	padding-right: calc(2 * var(--ta-rail-inset));
}

/* --------------------------------------------------------------------------
 * 18. RELATED POSTS -- woodzgit/theauto#39 item 5.
 *
 * NONE OF THIS IS INVENTED. Live's related block is filled by Jetpack from
 * wp.com after load, so its markup is absent from the served HTML -- but the
 * 2026-08-11 capture froze the DOM *after* that ran, and both stylesheets that
 * paint it were captured too:
 *
 *   css/theauto.page__static_5356fce0.css   Jetpack's own related-posts CSS
 *   css/theauto.page__static_b557d47b.css   the theme's section 7.10 overrides
 *
 * What follows is those two FLATTENED. We do not ship Jetpack's stylesheet, so
 * every rule the theme was merely overriding is written here once, at its
 * final value, rather than as a base plus a correction. Two consequences worth
 * knowing before editing:
 *
 *   - `#jp-relatedposts { display: block }`. Jetpack ships `display: none` and
 *     its JavaScript writes an inline `style="display: block"` to undo it once
 *     the cards arrive. There is no JavaScript and no `display:none` here, so
 *     the block is simply visible and _related39.asp emits no inline style.
 *   - the theme's `!important`s are gone where nothing contests them, and kept
 *     where they still beat Jetpack ordering that no longer exists but might
 *     be re-introduced by a future paste of the plugin CSS.
 *
 * *** EVERY SELECTOR HERE CARRIES THE #jp-relatedposts ID, AND THAT IS LOAD-
 * BEARING, NOT STYLE. *** It is live's own shape, and dropping it -- which the
 * first cut of this section did -- loses four separate fights with rules
 * earlier in this file, all of which were measured on DEV before the id went
 * back on:
 *
 *   .entry-content h3            (0,1,1)  line-height 1.2  -> the headline
 *                                         came out 15.594 against live's
 *                                         21.125
 *   .single .entry-content p     (0,2,1)  line-height 1.625, margin 36px ->
 *                                         the context line came out 17.875
 *                                         tall with 36px of margin under it
 *   a { line-height: 26px }               -> the title's anchor set the line
 *                                         box, so a 4-line title measured 104
 *                                         instead of 80
 *   .single .entry-content a:not(...)     section 12's content-link highlight,
 *                                (0,3,1)  padding 2px each side -> every
 *                                         thumbnail measured 187.188 against
 *                                         live's 191.188, and the titles wore
 *                                         the grey highlight plate
 *
 * A plain `.jp-relatedposts-…` class is (0,1,0) or (0,2,0) and loses all four.
 * With the id it is (1,1,0) and wins on the first component. This block is
 * inside .entry-content, so it is in range of every content rule this file
 * has; that is the price of putting it where live puts it.
 *
 * MEASURED ON LIVE 2026-08-13, hours before the domain moved -- and this is
 * the last measurement of it that will ever exist:
 *
 *                                 1440 (620 measure)     390 (342 measure)
 *   #jp-relatedposts              620    x 271.375       342 x 449.25
 *   .jp-relatedposts-headline      49.688 x  21.125       49.688 x 21.125
 *   .jp-relatedposts-items        640    x   0           322 x   0
 *   .jp-relatedposts-post         211.188 x 215.25       161 x 206.563
 *   .jp-relatedposts-post-img     191.188 x 109.25       141 x  80.563
 *   .jp-relatedposts-post-title   191.188 x  60          141 x  80
 *   .jp-relatedposts-post-context  99.813 x  22           99.813 x 22
 *
 * The two zero-height rows are correct: .jp-relatedposts-items contains only
 * floats and is never cleared -- the ::after on the OUTER container is what
 * gives the block its height. Do not "fix" it into a flex or grid container.
 * Three floats of 33% inside a box widened by a -20px right margin is exactly
 * how the 211.188 arises, and section 15's masonry work is the standing
 * reminder that a layout which merely looks similar is not the same layout.
 *
 * The block is 620 wide because it is INSIDE .entry-content, which section 10
 * already measures. It inherits; it sets no width of its own. */

#jp-relatedposts {
	clear: both;
	display: block;
	margin: 20px 0;
	padding: 0;
	position: relative;
}

/* The float container's own clearfix. This is what makes the block 271.375
 * tall rather than 0 -- see the note above. */
.jp-relatedposts::after {
	clear: both;
	content: "";
	display: block;
}

/* 49.688 x 21.125. The 21.125 is 13 x 1.625 -- the body's line-height RATIO,
 * not its 26px. Live expresses the site line-height unitlessly so it rescales
 * with font-size; this build states it in px (--ta-lh-body) because every
 * other box was measured that way, so the ratio has to be restated here or the
 * heading comes out 26 tall and everything below it moves 4.875px. */
#jp-relatedposts .jp-relatedposts-headline {
	display: inline-block;
	float: left;
	font-family: var(--ta-font-display);
	font-size: 13px;
	font-weight: var(--ta-w-medium);
	letter-spacing: 0.1em;
	line-height: 1.625;
	margin: 0 0 15px;
	text-transform: uppercase;
}

#jp-relatedposts .jp-relatedposts-headline em {
	font-style: normal;
	font-weight: var(--ta-w-medium);
}

/* Jetpack draws a hairline above the word "Related" with this pseudo-element.
 * The theme kills it, and so do we -- the rule is written out rather than
 * omitted so that anyone diffing against Jetpack's stylesheet can see the
 * suppression was deliberate. */
#jp-relatedposts .jp-relatedposts-headline em:before {
	display: none;
}

#jp-relatedposts .jp-relatedposts-items {
	clear: left;
}

/* -20px, which is what widens the items box to 640 inside a 620 measure so
 * that three 33% columns each clear 20px of gutter on their right and the
 * third one's gutter falls outside the text measure. */
#jp-relatedposts .jp-relatedposts-items-visual {
	margin-right: -20px;
}

#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post {
	box-sizing: border-box;
	float: left;
	margin: 0;
	opacity: 1;
	padding-right: 20px;
	transition: none;
	width: 33%;
}

/* A fourth card would start a new row. _related39.asp emits three, because
 * three is what live renders; the rule is kept so raising RELATED_N_39 does
 * the right thing rather than a subtly wrong one. */
#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post:nth-child(3n+4) {
	clear: both;
}

#jp-relatedposts .jp-relatedposts-post-a {
	background: none;
	display: block;
	padding: 0;
}

#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post-img {
	display: block;
	height: auto;
	margin-bottom: 10px;
	max-width: 100%;
}

#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post-title {
	display: block;
	font-family: inherit;
	font-size: 15px;
	font-weight: var(--ta-w-normal);
	letter-spacing: normal;
	line-height: 20px;
	margin: 0 0 10px;
	max-width: 100%;
	text-transform: none;
}

/* `line-height: inherit` is not decoration. The site-wide `a` rule sets 26px,
 * and an inline anchor sets the height of the line box it sits in -- so a
 * four-line title measured 104 instead of 80 until this was stated. Same for
 * the background and the padding: section 12 gives every content link a grey
 * highlight plate with 2px of horizontal padding, which is right for a link in
 * a sentence and wrong for a card title, and the padding is where the 4px the
 * thumbnails were losing came from. */
#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post-title a {
	background: none;
	color: inherit;
	font-size: inherit;
	font-weight: var(--ta-w-normal);
	line-height: inherit;
	opacity: 1;
	padding: 0;
	text-decoration: none;
}

#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post:hover .jp-relatedposts-post-title a,
#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post-title a:hover {
	text-decoration: underline;
}

/* Emitted, and shown only when the card has no picture -- Jetpack's own fork,
 * and the reason _related39.asp writes `-post-nothumbs` on the two of 1,156
 * imported posts that carry no media row. */
/* `margin: 0` on every p and time in here is Jetpack's own reset and it is not
 * optional: without it the context line takes 36px of bottom margin from
 * `.single .entry-content p` -- measured, and it was exactly the 36px each
 * card was too tall by. The id beats that rule on the properties it names, but
 * a property it does NOT name is simply inherited from the loser, which is the
 * subtle half of the specificity story in this section's header. */
#jp-relatedposts .jp-relatedposts-items p,
#jp-relatedposts .jp-relatedposts-items time {
	margin: 0;
}

#jp-relatedposts .jp-relatedposts-items p.jp-relatedposts-post-excerpt {
	font-size: 14px;
	line-height: 20px;
	overflow: hidden;
}

#jp-relatedposts .jp-relatedposts-post-thumbs p.jp-relatedposts-post-excerpt {
	display: none;
}

/* The date is in the markup and never on the screen. Live emits it and the
 * theme hides it; it is kept because it is the machine-readable publication
 * date of the linked post, which is worth having in the DOM whether or not it
 * is painted. !important because Jetpack's base rule and the theme's fight
 * over it and the theme wins -- that outcome is what is reproduced. */
#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post-date {
	display: none !important;
}

/* 99.813 x 22 at both widths -- it is a fixed string ("In <category>") in a
 * fixed size, so it does not reflow. */
#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post-context {
	color: var(--ta-c-text);
	display: inline-block;
	font-size: 11px;
	font-weight: var(--ta-w-normal);
	line-height: 22px;
	opacity: 0.6;
	text-transform: uppercase;
}

/* Two columns below 640, and the sign of that margin FLIPS -- +20 where the
 * desktop rule is -20. That is Jetpack's own rule and it is not a typo in this
 * file: measured at 390 on live, .jp-relatedposts-items is 322 inside a 342
 * measure, i.e. 20 NARROWER, and each of the two 50% columns is 161. Writing
 * the "obvious" -20px here would make the cards 171 and push the second column
 * past the text measure. */
@media only screen and (max-width: 640px) {
	#jp-relatedposts .jp-relatedposts-items-visual {
		margin-right: 20px;
	}

	#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post {
		width: 50%;
	}

	#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post:nth-child(3n) {
		clear: left;
	}
}

@media only screen and (max-width: 320px) {
	#jp-relatedposts .jp-relatedposts-items .jp-relatedposts-post {
		clear: both;
		margin: 0 0 1em;
		width: 100%;
	}
}

/* --------------------------------------------------------------------------
 * 19. THE AUTHOR BIO BOX -- woodzgit/theauto#39 item 7.
 *
 * Transcribed from the theme's own sections 7.3 (.author-info) and its media
 * object, in css/theauto.page__static_b557d47b.css, and measured on live at
 * 1440 and 390 on 2026-08-13:
 *
 *                                 1440 (620 measure)     390 (342 measure)
 *   .author-info                  620   x 291.5          342 x 501.5
 *   .author-info__avatar          120   x 120            280 x 120
 *   .author-info__description     438   x 246.5          300 x 336.5
 *   .author-info__title           116.938 x 36           116.938 x 36
 *   .author-info__bio             438   x 202.5          300 x 292.5
 *
 * The 291.5 is arithmetic, not a magic number: 246.5 of description + 40 of
 * padding + 5 of border (1px on three sides, 4px on top). The 4px top border
 * is the box's whole visual identity and is the one value here most likely to
 * be "tidied" to 1px by someone who has not seen the live page.
 *
 * THE MEDIA OBJECT IS LOAD-BEARING and its class names collide. Bootstrap
 * ships its own `.media` in /vendor/bootstrap/, and the seeded comment list
 * uses `.media-list` / `.media-body` from it. These are the THEME's BEM
 * `media__img` / `media__body`, a different thing that happens to share a
 * stem. theauto.css loads after bootstrap, so these win; do not rename them to
 * "avoid the clash", because the class names are live's and the markup in
 * _authors39.asp is transcribed from live.
 *
 * `overflow: hidden` on the body is what makes the text sit BESIDE the floated
 * avatar instead of wrapping under it -- it establishes a block formatting
 * context. It is not a clipping instruction and removing it collapses the
 * layout.
 *
 * THE "ALL POSTS" CHIP IS NOW HERE -- woodzgit/theauto#49 item 3. It was left
 * out until the archive existed, because the href would have resolved to a
 * 301 back to the home page on all 1,156 article pages and a dead link is
 * worse than no link. tch-ops/server-configs#456 swapped that redirect for a
 * rewrite on 2026-08-15, so the route answers 200 and the chip is honest.
 * Its rule is below, between the title and the bio, in live's own DOM order. */

.author-info {
	border: 1px solid var(--ta-c-rule);
	border-top-width: 4px;
	font-size: 15px;
	line-height: 1.5;
	margin-bottom: 36px;
	margin-top: 54px;
	padding: 20px;
}

/* BOTH OF THESE UNDO A BOOTSTRAP RULE, and both were found by measuring DEV
 * against live on 2026-08-15 while verifying the chip above -- neither is new
 * damage from #49, they have been wrong since #39 item 7 shipped the box.
 *
 * `margin-top` is the one that shows. bootstrap.min.css carries
 * `.media:first-child{margin-top:0}`, and this aside IS the first child of
 * `.entry-footer`, so a 0,2,0 selector beat the 0,1,0 `.author-info` above and
 * live's 54px gap above the box was silently 0 on every one of 1,157 article
 * pages. The rule the section header warns about did land -- just not the way
 * it was expected to, because the collision was in SPECIFICITY, not in the
 * property. `.author-info.media` ties bootstrap at 0,2,0 and wins on order.
 *
 * `overflow` is the invisible half: bootstrap's `.media,.media-body{overflow
 * :hidden}` puts a block formatting context on the OUTER aside, where live has
 * `visible`. Nothing overflows today so it costs no pixels, but it is a
 * measured divergence and the BFC is exactly what would swallow a future
 * negative-margin or absolutely-positioned child. The `overflow: hidden` that
 * IS load-bearing is the one on `.media__body` below -- do not confuse them.
 * The box does not collapse without this BFC: the description column is 246.5
 * tall against the 120px float, so the aside's height comes from the column,
 * which is why live measures the same 291.5 with overflow visible. */
.author-info.media {
	margin-top: 54px;
	overflow: visible;
}

.media {
	display: block;
}

.media__img {
	float: left;
	margin-right: 24px;
}

.media__img > img {
	display: block;
}

.media__body {
	display: block;
	margin-bottom: 0;
	overflow: hidden;
}

.media__body > :last-child {
	margin-bottom: 0;
}

/* 20px, overriding the media object's 24 -- live states both and the narrower
 * one wins. The greyscale is the theme's, not the image's: the PNGs in
 * /img/authors/ are the colour originals as Gravatar served them, so removing
 * this filter restores the colour portrait rather than breaking anything. */
.author-info__avatar {
	-webkit-filter: saturate(0) contrast(1.5);
	filter: saturate(0) contrast(1.5);
	margin-right: 20px;
}

.author-info__avatar img {
	margin: 0;
	max-width: none;
}

/* `text-transform: none` is the whole reason this rule has to name it: the
 * global `h1, h2, h3, h4, h6` rule uppercases every heading on the site, and
 * this h3 is a person's name. Measured on DEV before it was stated - "MICHELE
 * LUPINI" is 135.734 wide against live's 116.938 for "Michele Lupini", and
 * nothing else about the box differed. Same reason font-weight is spelled out:
 * that rule also sets 400, where live's name is 300. */
.author-info__title {
	display: inline-block;
	font-family: var(--ta-font-display);
	font-size: 24px;
	font-weight: var(--ta-w-light);
	letter-spacing: normal;
	line-height: 1.5;
	margin: 0;
	margin-right: 0.5em;
	text-transform: none;
}

/* The "ALL POSTS" chip. Measured on live 2026-08-15 at 1440, on
 * /road-tested/ford-tourneo-sport/ (the article the author capture was taken
 * from): 85.313 x 22 at x=866.234, beside the name and NOT under it.
 *
 * ONLY THE DIFFERENCES FROM THE GLOBAL `a` RULE ARE DECLARED. That rule
 * already gives this element font-family --ta-font-body, colour --ta-c-link
 * (#000) and weight --ta-w-medium (500), and all three match the measurement
 * exactly. Restating them would be noise; what is here is what live changes.
 *
 * THE FAMILY IS WORK SANS, NOT OSWALD, and this is the one value most likely
 * to be "corrected" by someone reading the theme's source instead of the
 * running site. The theme's own bundle sets `font-family: Oswald` on this
 * class -- but wp.com's jetpack-custom-fonts layer loads after it and
 * reassigns .author-info__link to "Work Sans", which is what the capture
 * measures. Same class of override as --ta-c-chip's flattened yellow, and
 * #49's own issue text says "Oswald/Work Sans" because it predates the
 * measurement. Measure, do not read the theme.
 *
 * The swipe is the section-13 content-link idiom exactly: the accent painted
 * behind the text, a white curtain one em tall over it, the curtain shrunk to
 * nothing on hover. 1em is 13px against a 22px line box, so at rest the
 * accent shows as a 9px underline and on hover it fills the chip. The
 * -2px `top` is live's own optical lift against the 24px name beside it. */
.author-info__link {
	background-color: var(--ta-c-chip);
	background-image: linear-gradient(-90deg, transparent 0%, #ffffff 0%, #ffffff 100%, transparent 100%);
	background-position: top center;
	background-repeat: no-repeat;
	background-size: 100% 1em;
	display: inline-block;
	font-size: 13px;
	letter-spacing: 0.1em;
	line-height: 22px;
	padding-left: 2px;
	padding-right: 2px;
	position: relative;
	text-transform: uppercase;
	top: -2px;
	transition: background-size 0.15s ease-out;
}

.author-info__link:hover {
	background-size: 100% 0%;
}

/* font-size AND line-height both restated, because the bare `p` rule near the
 * top of this file sets both -- font-size --ta-fs-body and line-height
 * --ta-lh-copy -- and a bare element selector still beats INHERITANCE from
 * .author-info, however specific that ancestor's own rule is. Inheritance is
 * not a cascade competitor; it is only what happens when nothing matches.
 *
 * Measured on DEV twice on the way to this. Restating line-height alone fixed
 * the ratio and left the size at 16, so the paragraph was ten lines of 24 =
 * 240 against live's nine of 22.5 = 202.5, and .author-info was 37.5 tall at
 * 1440 and 43.5 at 390. 15 x 1.5 IS 22.5, and the line count follows. */
.author-info__bio {
	font-size: 15px;
	line-height: 1.5;
	margin-bottom: 12px;
	margin-top: 8px;
}

/* Live's own query, negation and all: "not (screen and min-width 740)". It
 * therefore also matches print, which is why the avatar stacks above the bio
 * on a printed article -- transcribed rather than rewritten as a plain
 * max-width, because the print behaviour is part of what was measured. */
@media not screen and (min-width: 740px) {
	.author-info__avatar,
	.author-info__description {
		display: block;
		float: none;
	}
}

/* --------------------------------------------------------------------------
 * 20. THE 1450 BREAKPOINT -- woodzgit/theauto#39 item 2.
 *
 * WHAT THIS FIXES. The reviewer said the logo looks smaller. `#39` measured it
 * at 1440, found 299.953 on both, and left the item open pending the
 * reviewer's own window width. That was the right call and the answer is here:
 * 1440 is the ONE width where this defect is invisible.
 *
 * Measured against live on 2026-08-13, `.site-logo`:
 *
 *   1280   246.625  vs live 270.625   -24   OURS SMALLER  <- what was reported
 *   1440   299.953  vs live 299.953     0
 *   1600   321.953  vs live 297.953   +24   ours bigger
 *   1700   260.000  vs live 236.000   +24
 *   1920   315.000  vs live 291.000   +24
 *
 * LIVE HAS A BREAKPOINT AT 1450 THAT THIS BUILD DID NOT CARRY. Bisected
 * against the running site -- padding-right is 0px at 1440 and 24px at 1460 --
 * and then found in the source bundle as `@media (min-width: 1450px)` in
 * css/theauto.page__static_b557d47b.css. Three declarations from that block
 * matter to the rail, and all three are transcribed below.
 *
 * It is not a coincidence that 1440 was clean: 1440 is the capture's desktop
 * width, so it is the only width the whole rebuild was measured at until the
 * previous round of this issue added 1700 by hand. This is the SAME lesson,
 * caught a second time -- measuring one viewport is not measuring.
 *
 * WHY IT HAS TO BE STATED HERE AND NOT EDITED IN PLACE. Section 6's
 * `min-width: 480px` block already gives .site-header the 24px, and the
 * `min-width: 900px` block takes it away again with a doubled-class
 * `.site-header.site-header`. Live does exactly the same and then restores it
 * at 1450. Specificity is equal at every step, so ORDER decides, and this
 * block has to come last. Moving it earlier in the file silently reverts it.
 *
 * THE CARD MARGINS ARE NOW HERE TOO -- 2026-08-14, second pass. The first pass
 * deliberately left them out and said so, because #44 and #45 had just been
 * tuned on the current values and a logo fix is the wrong thing to ride them in
 * on. They have had their own before/after sweep since, below.
 *
 * ⚠️ AND THEY WERE MEASURED OFF THE RUNNING SITE, NOT TRANSCRIBED FROM THE
 * THEME SOURCE -- which for once disagree, and it is worth knowing why before
 * anyone reaches for the zip again. `patch-lite 1.3.4` (the theme's own
 * `style.css`, in the capture's theme-source/) carries a TRAILING
 * `@media (min-width: 1450px)` block that re-states the 480px one verbatim and
 * so resets `.site-branding` to `margin: 0 96px 24px 24px`. If that were what
 * live served, the rail would be 24/96 at 1450 and the block above this one
 * would be wrong. Live MEASURES 30/90. So live's served bundle is not this
 * file -- wp.com concatenates and re-orders -- and the zip is a reading aid,
 * never the reference. theauto.page is the reference until it expires. */

@media only screen and (min-width: 1450px) {
	/* 30 and 90 against the 24 and 96 the 900px block sets. The pair still
	 * sums to 120, so the rail's total inset is unchanged and the BRANDING BOX
	 * keeps its width -- what moves is where it starts. Our logo was sitting
	 * 6px left of live's on top of being 24px wrong in size. */
	.site-branding,
	.nav--main,
	.nav--social {
		margin-left: 30px;
		margin-right: 90px;
	}

	/* The 24px that the whole defect is. .site-header is one cell of the grid,
	 * so padding on it takes width off the logo and nothing else -- the column
	 * pitch is set by .grid__item and does not move, which is why the header's
	 * own outer width already matched live at 1440, 1600, 1700 and 1920 while
	 * the logo inside it did not. */
	.layout-grid .site-header {
		padding-right: var(--ta-rail-inset);
	}

	/* THE CARD'S OWN INSET, WIDENED. Section 9's `min-width: 480px` block pulls
	 * the card 24px left out of its column and gives 48px back on the right;
	 * live does the same until 1450 and then goes to 30 and 60. Same
	 * specificity as that block ((0,1,0) and (0,2,0)), so ORDER decides here as
	 * it does for the rail above -- this is why the whole section lives at the
	 * end of the file.
	 *
	 * MEASURED ON theauto.page AT 1600, computed margins, before:
	 *
	 *                       this build   live
	 *   .entry-card         -24 / 48     -30 / 60
	 *   .entry-header         48           60
	 *   .entry-content        48           60
	 *   .entry-meta           48           60
	 *
	 * and the geometry that falls out of it -- column pitch 442 at 1600, first
	 * card in the column whose origin is 591:
	 *
	 *   .entry-card    x 567     live 560.938   +6.062   <- the reported 6px
	 *   .entry-header  x 615     live 620.938   -5.938
	 *
	 * The card starts 6px RIGHT of live's and its text starts 6px LEFT, because
	 * the two errors have opposite signs: the card is pulled out by 6 less and
	 * the text is pushed in by 12 less. 1440 measures identical on every one of
	 * these boxes, which is why this sat unseen -- the same reason the rail did.
	 *
	 * The card's WIDTH changes with it: 442 + 30 - 60 = 412 against the old
	 * 442 + 24 - 48 = 418. That is live's 411.953, and it is the number #44's
	 * lead and #45's sidebar have to be re-measured against, not assumed. */
	.entry-card {
		margin-left: -30px;
		margin-right: 60px;
	}

	/* Halved with its sibling in section 9 -- client 2026-08-17, #103. 60 -> 30,
	 * which is this breakpoint's own rail inset and the same 30 the card pulls
	 * out by. These two rules are ONE decision written twice; if only one is
	 * changed the copy's inset jumps at 1450. */
	.entry-card .entry-meta,
	.entry-card .entry-content,
	.entry-card--landscape .entry-header {
		margin-left: 30px;              /* was 60px */
		margin-right: 0;
	}

	/* THE SIDEBAR RAIL, WHICH DID NOT COME WITH THEM -- woodzgit/theauto#59.
	 *
	 * This block is exactly the re-measure its own comment above asks for and
	 * nobody did: the card's pull-out went 24 -> 30 here, section 17 insets the
	 * sidebar cell by `--ta-rail-inset` (24px, and it stays 24px), and the 6px
	 * difference is an overlap. MEASURED on DEV /bakkie/ before this rule:
	 *
	 *              #secondary right   next column's card text x   result
	 *   1440       497.95             498.00                      clean
	 *   1920       513.00             507.00                      6.00 OVER
	 *   2467       765.00             759.50                      5.50 OVER
	 *
	 * which is the operator's "the left column is bleeding into the content",
	 * and it is invisible at 1440 -- the width everything else was measured at.
	 *
	 * 30 on BOTH sides, matching .site-branding's margin-left in this same
	 * block, so the rail stays aligned under the logo up here as well.
	 *
	 * NO LIVE REFERENCE EXISTS FOR THIS BOX. Live renders no sidebar on any
	 * category archive (measured across every captured page, woodzgit/theauto#45)
	 * -- this rail is ours, so the alignment is a house call against the
	 * masthead, not a divergence from a captured number. */
	.grid__item--sidebar {
		padding-left: 30px;
		padding-right: 60px;
	}
}

/* --------------------------------------------------------------------------
 * 21. THE TEST RECORDS TABLES -- client review 2026-08-17, woodzgit/theauto#97.
 *
 * "In the Test Records, for now make the font a few points smaller to try
 * alleviate the misalignment we have there if the pane is tight."
 *
 * WHAT IS ACTUALLY WRONG, BECAUSE IT IS NOT A STYLING BUG AND IT IS WORSE THAN
 * "MISALIGNMENT". /auto-test-records/ holds five WordPress `wp-block-columns`
 * blocks. Each column is ONE `<p>` of `<br>`-separated lines -- car names in
 * the first, times in the rest -- and the columns line up only because every
 * line happens to fit on one line. Nothing associates a car with its numbers:
 * they are four independent lists that agree by counting.
 *
 * So the moment one car name wraps, every row below it in that column slides
 * down one and THE NUMBERS ATTACH TO THE WRONG CARS. Screenshotted at 1366
 * before this change: `BMW M235 Gran Coupe` was showing the 400m time of the
 * row above it. A reader cannot tell -- it looks like data, not like a defect.
 *
 * THE PANE IS NOT TIGHT WHERE YOU WOULD EXPECT, AND THIS IS THE PART THAT
 * MATTERS. `.entry-content` on this template is NOT monotonic in the viewport.
 * Measured with Playwright across 23 widths:
 *
 *   viewport   1440  1420  1400  1360  1300  1260 | 1240  1180  1100  1050
 *   .entry-content  620   600   580   540   480   440 |  780   720   640   590
 *
 * There is a band from about 1260 to 1420 where the measure is NARROWER than
 * it is at 1100 -- it drops to 440px at 1260 and then jumps back to 780 at
 * 1240. 1366, the commonest laptop width there is, sits inside that band. That
 * is "if the pane is tight", and it is why the client sees it and a 1440 review
 * does not.
 *
 * *** IT IS LIVE'S BAND, NOT OURS. *** The same sweep was run against
 * https://theauto.page/auto-test-records/ and it matches THIS BUILD TO THE
 * PIXEL at all 23 widths -- every number in the row above is identical on both
 * sides. The tight band is inherited geometry, faithfully reproduced, and the
 * misalignment is on live today. We are not fixing our own regression here; we
 * are improving on live at the client's request.
 *
 * WHY THE FONT ALONE IS NOT THE FIX, MEASURED RATHER THAN ARGUED. Every size
 * was trialled by injecting it and re-counting the rendered lines per column at
 * 16 widths. A block is "aligned" only when all its columns render the same
 * number of lines. `.` = aligned:
 *
 *   14/12 (was)   .  x  x  x  x  x  x  x  x  .  .  .  x  x  x  x
 *   13/11         .  .  x  x  x  x  x  x  x  .  .  .  .  x  x  x
 *   12/10         .  .  .  .  .  x  x  x  x  .  .  .  .  .  x  x
 *   11/9          .  .  .  .  .  .  x  x  x  .  .  .  .  .  .  x
 *   10/9          .  .  .  .  .  .  x  x  x  .  .  .  .  .  .  x
 *   12/10+nowrap  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
 *   widths     1440 1420 1400 1380 1366 1340 1300 1280 1260 1240 1100 1050 1024 1000 960 920
 *
 * NO READABLE SIZE FIXES 1260-1300. At 10px it is still broken there, and 10px
 * is already past useful. `white-space: nowrap` is what actually fixes it,
 * because it removes the failure mode instead of postponing it: a line that
 * cannot wrap cannot shift the rows under it, at ANY width, forever.
 *
 * SO BOTH SHIP. The smaller size is what was asked for and it is what keeps the
 * nowrap from overflowing: measured with 12/10 + nowrap, the worst column
 * overruns its box by 0px at 1440, 1366, 1240 and 1024, and by at most 40px in
 * the 1260-1300 pinch, which lands in the flex gutter rather than on the next
 * column's digits. At 14px the same nowrap would overrun much further.
 *
 * "A FEW POINTS" IS READ AS 2px OFF EACH BLOCK -- 14 -> 12 and 12 -> 10, the
 * same reading of "points" that #87 used for the subhead, kept consistent on
 * purpose.
 *
 * THE ATTRIBUTE SELECTORS ARE UGLY AND THEY ARE THE POINT. The sizes are INLINE
 * on the paragraphs (`style="line-height:1.3;font-size:14px"`), written into
 * `conBody` by WordPress, so nothing but `!important` can beat them and nothing
 * but the attribute distinguishes the 14px blocks from the 12px one. Matching
 * on the literal attribute text is safe here because a matched rule does not
 * rewrite the attribute -- `[style*="font-size:14px"]` keeps matching after the
 * override, and never matches the 12px paragraphs.
 *
 * ⚠️ THIS IS COUPLED TO THE CONTENT. Re-save that page in an editor that
 * renumbers the inline sizes and these selectors stop matching, silently, and
 * the tables go back to 14px and back to lying about which car did what. The
 * durable fix is to put real `<table>` markup in `conBody` so a row is a row;
 * that is a content job and it is filed. Until then this is load-bearing.
 *
 * `.wp-block-columns` appears on NO other page on this site -- checked against
 * the home page, /news/, /road-tested/, /contact/ and /about/, all zero -- so
 * the unscoped selector is page-specific in practice.
 * ------------------------------------------------------------------------*/

.wp-block-column > p[style*="font-size:14px"] {
	font-size: 12px !important;
	white-space: nowrap;
}

.wp-block-column > p[style*="font-size:12px"] {
	font-size: 10px !important;
	white-space: nowrap;
}

/* --------------------------------------------------------------------------
 * 22. THE REVERSED-OUT CARD -- woodzgit/theauto#90.
 *
 * Client, 2026-08-16: "those random reversed black/dark grey blocks we
 * discussed before". Confirmed 2026-08-17 with a screenshot and a rule: they
 * WANT them, "random", "vary between 5 and 7 stories apart", and it "can change
 * on every refresh too".
 *
 * *** THIS EXISTS ON NEITHER LIVE NOR THE 2026-08-11 CAPTURE. *** It was
 * measured before it was built: every one of the 20 cards on live's home page
 * and on this build's computes `background-color: rgb(255,255,255)` with a
 * `rgb(23,22,23)` title. Live does paint `a.entry-image` black, but that anchor
 * is exactly the size of the photo and the photo covers it, so nothing shows.
 * The treatment in the client's screenshot -- black behind the TEXT as well,
 * white type -- is not live's and never was. So this section is NEW DESIGN,
 * built from the screenshot, and every rule in it is a house call rather than a
 * reproduction. ops/adjudicate.py records it as DELIBERATE.
 *
 * WHAT THE SCREENSHOT ACTUALLY SHOWS, and it is the whole specification:
 *   - the black fills the CARD, not the image box: it runs from above the photo
 *     down past the excerpt;
 *   - the photo is INSET inside the black, with an even margin left and right;
 *   - the title and the excerpt are WHITE;
 *   - and the photo's left edge lines up with the title's left edge.
 *
 * THAT LAST POINT IS WHY THIS RESETS THE TEXT MARGINS. Everywhere else on this
 * site the photo is full-bleed to the card and the copy is inset from it -- the
 * "white gap" #103 just halved. Inside a reversed card there is no white gap to
 * sit in, and a photo running to the black edge while the type is inset reads
 * as a mistake. So the CARD takes the inset as padding and everything inside it
 * aligns to that one edge.
 *
 * IT IS APPENDED AT THE END OF THE FILE ON PURPOSE. The margins it has to
 * overrule live in section 9's >=480 block AND in the 1450 block at the foot of
 * this file, and both are (0,2,0) -- the same specificity as the selectors
 * here. Source order is what settles it, so this must stay last. Moving this
 * section earlier silently restores the 30px inset above 1450 only.
 * ------------------------------------------------------------------------*/

.entry-card--reverse {
	background-color: var(--ta-c-invert-bg);
	padding: var(--ta-rail-inset);
}

/* One edge for everything inside: the card's padding. See the note above. */
.entry-card--reverse .entry-meta,
.entry-card--reverse .entry-content,
.entry-card--reverse .entry-header,
.entry-card--reverse.entry-card--landscape .entry-header {
	margin-left: 0;
	margin-right: 0;
}

/* The type. `.entry-title a` needs naming separately -- a matched rule beats
 * inheritance, and section 4 sets a colour on it directly. This file has paid
 * for that four times already; see the note in section 16. */
.entry-card--reverse .entry-title,
.entry-card--reverse .entry-title a,
.entry-card--reverse .entry-content,
.entry-card--reverse .entry-content--short,
.entry-card--reverse .entry-content p,
.entry-card--reverse .entry-meta,
.entry-card--reverse .entry-meta a,
.entry-card--reverse .byline,
.entry-card--reverse .posted-on,
.entry-card--reverse .posted-on a {
	color: var(--ta-c-invert-text);
}

/* The category chip is #d1d1d1 on white, which is invisible on black. Live has
 * no reversed card to measure, so this is a house call: white text, no chip
 * background, which is what the screenshot shows. */
.entry-card--reverse .cat-links,
.entry-card--reverse .cat-links a {
	background-color: transparent;
	color: var(--ta-c-invert-text);
}

/* The image wrapper's own black (section 9) is now the same colour as the card
 * behind it, so a photo that cannot fill its box blends into the card instead
 * of showing as a darker rectangle inside it. Nothing to set -- noted so the
 * next reader does not "fix" it. */

/* --- the in-page search box (woodzgit/theauto#135) -------------------------
 * search.asp now emits its own .search-form inside the page-header cell. Every
 * existing .search-form rule in this file is scoped to .overlay--search, so
 * without these the box would render as a raw browser input on the one page
 * whose whole job is searching.
 *
 * Scoped to .search-form--page so nothing here can reach the overlay form and
 * disturb the measured overlay geometry (#374 item 8).
 * ------------------------------------------------------------------------- */
.search-form--page {
	display: flex;
	align-items: stretch;
	gap: 8px;
	margin: 12px 0 4px 0;
	max-width: 420px;
}

.search-form--page > label {
	display: block;
	flex: 1 1 auto;
	margin: 0;
}

.search-form--page .search-field {
	display: block;
	width: 100%;
	box-sizing: border-box;
	padding: 8px 10px;
	border: 1px solid var(--ta-c-rule, #dddddd);
	background: #ffffff;
	font-family: inherit;
	font-size: 16px;
	line-height: 20px;
	color: inherit;
}

.search-form--page .search-submit {
	flex: 0 0 auto;
	padding: 8px 14px;
	border: 1px solid var(--ta-c-link, #111111);
	background: var(--ta-c-link, #111111);
	color: #ffffff;
	cursor: pointer;
	line-height: 20px;
}

.search-form--page .search-submit:hover,
.search-form--page .search-submit:focus {
	opacity: 0.85;
}