/*
 * Starter/source compatibility shim for page BODIES.
 *
 * Same job as shell-compat.css, one layer further in. The theme loads two
 * stylesheets written independently — the starter's base.css plus theme.json's
 * global styles, and the design source's rules copied verbatim — and where both
 * touch the same element with DIFFERENT properties, "later wins" settles
 * nothing, because they are not competing over one property. base.css gives an
 * element a margin the source never mentions; the source's value is then the
 * browser default, and the browser default is exactly what never arrives.
 *
 * Slice 1 solved this for the header and the footer and scoped the fix to them,
 * deliberately: page bodies were still block content and keeping theme.json's
 * prose rhythm there was the right default. Slice 2 is the first page body that
 * is a TRANSCRIBED DESIGN rather than prose, so it needs the same treatment.
 *
 * EVERY RULE HERE IS A MEASURED CONFLICT, with the measurement recorded.
 * Deleting one should reproduce the difference it describes; if it does not,
 * the rule is stale and should be removed. This is not a place to redesign
 * anything — these exist only so the source's own values render.
 *
 * SCOPE, AND WHY IT IS THE DESIGN'S OWN PRIMITIVES
 *
 * `.page-hero` and `.section` are the design source's two body-section
 * primitives; every page body in this design is made of them. Scoping to them
 * rather than to a service-specific wrapper means the fix is about "content
 * laid out by the design" rather than "content on a service page", which is
 * what it actually is. This file is loaded only on service pages today because
 * that is the only body built. When the second body slice lands it will be
 * promoted rather than copied.
 */

/*
 * .container width and gutter
 *
 * base.css caps it at `max-width: calc(wide-size + 2 * spacing-30)` = 1232px
 * and adds `padding-inline: 1rem`. The source sizes it with
 * `width: min(1240px, calc(100% - 56px))` and gives it no padding at all.
 *
 * Both applied, so the starter clamped the source and then inset its contents:
 *
 *     at 1440   source  x=100  w=1240      wp  x=104  w=1232, children at 120
 *     at 1024   source  x=28   w=968       wp  x=28   w=968,  children at 44
 *
 * — a 20px horizontal shift on every element in the body and an 8px narrow
 * container at the widest viewport. Identical in kind to the header/footer
 * conflict shell-compat.css records, and fixed the same way: inside the
 * design's own sections, the container is the design's.
 */
/*
 * `:where()` is not decoration here.
 *
 * Written as `.section > .container` this weighs (0,2,0) and outranks anything
 * the design says about a particular container. The blog article's shell is
 * exactly that case: `.article-shell { max-width: 980px }` at (0,1,0) lost to
 * this shim, and the article rendered 1240px wide instead of 980 — with the
 * cover, the copy column and every heading below it in the wrong place.
 *
 * `:where()` contributes nothing to specificity, so the whole selector weighs
 * (0,1,0): still enough to beat base.css's bare `.container`, which is all
 * this shim is for, and low enough that any later class rule the design wrote
 * wins. A shim should be the floor, never the ceiling.
 */
/*
 * The list is the design's SECTION WRAPPERS, and Slice 8 added two.
 *
 * The homepage opens with `<section class="hero">` and `<section
 * class="proofbar">`, neither of which carries `.section`. The proofbar showed
 * the defect this shim exists for, exactly as recorded above -- measured at
 * 1440, source x=100 w=1240 against wp x=104 w=1232, with every figure inset
 * 20px. The hero did not, because `.hero-content` declares its own max-width
 * and padding and lands later in the cascade; it is listed anyway, because
 * "this container is the design's" is true of it too and leaving it out would
 * mean the shim is right by accident rather than by rule.
 */
:where(.page-hero, .section, .hero, .proofbar) > .container {
	max-width: none;
	padding-inline: 0;
}

/*
 * line-height
 *
 * theme.json declares a global `typography.lineHeight` of 1.6, which WordPress
 * emits as `body { line-height: 1.6 }`. The design source sets no global
 * line-height, so every element that does not name one computes `normal` there
 * and 1.6 here. Measured on the intro feature rows:
 *
 *     .feature   70px source  ->  81.2px
 *
 * Restoring `normal` at the section level lets it inherit exactly as the source
 * does, while every element the source DOES give a line-height — `p` at 1.75,
 * `.lead` at 1.8, `h1` at .98, `h2` at 1.02 — keeps its own value, because a
 * rule always beats inheritance.
 */
/*
 * Slice 8 added the homepage's two section wrappers here for the same reason
 * they were added to the container shim: `.hero` and `.proofbar` do not carry
 * `.section`, so the inherited 1.6 reached them. Measured on a proofbar figure:
 *
 *     .proof   58.3px source  ->  63.6px    (16px * 1.6 strut)
 *
 * -- and because that block sits above nine more sections, the 5.3px it gained
 * moved every element on the page below it.
 */
.page-hero,
.section,
.hero,
.proofbar {
	line-height: normal;
}

/*
 * Heading line-height, for the headings the source does not size
 *
 * base.css sets `h1..h6 { line-height: 1.2 }` as a RULE, not as inheritance, so
 * the section-level `normal` above cannot reach h3 and below. h1 and h2 are
 * already correct -- the source gives them .98 and 1.02 and its stylesheet
 * loads later -- but h3 has no source line-height at all. Measured on a
 * process card:
 *
 *     .card h3   26px source  ->  25.2px   (21px * 1.2)
 *
 * h3..h6 only. Naming h1 and h2 here would outweigh the source's own values
 * and break the two headings that are currently right.
 *
 * ON THE `main` SCOPE, WHICH IS LOAD-BEARING -- see the note below.
 */
main h3,
main h4,
main h5,
main h6 {
	line-height: normal;
}

/*
 * Heading and paragraph bottom margin
 *
 * base.css sets `margin-block-end: var(--wp--preset--spacing--30)` = 16px on
 * every heading and on `p`. The source sets neither, so both fall to the
 * browser's own values, which scale with font size instead of being flat.
 * Measured on the intro heading:
 *
 *     h2 margin-bottom   48.14px source  ->  16px      (58px * 0.83)
 *
 * `revert` is the precise instrument: it rolls the declaration back to the
 * user-agent origin, which is exactly where the source's value comes from. A
 * hardcoded `0.83em` would be right for h2 and wrong for everything else.
 *
 * `margin-top` is deliberately not touched -- the source's own
 * `h1, h2, h3, h4 { margin-top: 0 }` already sets it, and reverting it would
 * undo a rule the design actually wrote.
 *
 * WHY THE SELECTOR IS `main p` AND NOT `.section p`
 *
 * THIS IS THE WHOLE POINT OF THE RULE AND IT WAS GOT WRONG FIRST.
 *
 * `.section p` weighs (0,1,1), which outweighs the source's own class rules --
 * `.eyebrow { margin-bottom: 20px }` at (0,1,0), and `.answer-block p`,
 * `.cta-band p` and `.page-hero h1 { margin: 0 }` at (0,1,1) with this file
 * loading later. The shim then reverted margins the design had deliberately
 * set, and measurably broke five elements it was not aimed at:
 *
 *     .eyebrow           20px  ->  11px
 *     .answer-block h3    8px  ->  23px
 *     .answer-block p     0px  ->  16px
 *     .cta-band p        28px  ->  16px
 *     .page-hero h1       0px  ->  45.6px
 *
 * `main p` weighs (0,0,2): heavy enough to beat base.css's bare `p` at (0,0,1),
 * light enough to lose to every class rule the design wrote. That is precisely
 * the window this shim has to sit in -- it must undo the starter's default and
 * be invisible to the design.
 *
 * `main` is a safe scope because this stylesheet is loaded on service pages
 * only. When it is promoted to cover other page bodies, this scope is the thing
 * to re-check, not the specificity arithmetic.
 */
main h1,
main h2,
main h3,
main h4,
main h5,
main h6,
main p {
	margin-block-end: revert;
}

/*
 * ...and the TOP margin, for paragraphs.
 *
 * The rule above restored only the bottom, because that was the only side the
 * service pages needed: every paragraph in a service body carries a class rule
 * that sets its margins outright, so the browser default never showed. The
 * blog is the first family with a paragraph the design leaves entirely alone —
 * the listing card's meta line — and there the difference is visible:
 *
 *     .article-meta margin-top   14px source  ->  0px
 *
 * which made every card 14px short. Same instrument, same window: `main p` at
 * (0,0,2) beats the starter's bare `p` and loses to every class rule the
 * design wrote, so paragraphs the design does style are untouched. Headings are
 * deliberately NOT included — the source sets `h1..h4 { margin-top: 0 }`
 * itself, and reverting that would undo a rule the design actually wrote.
 */
main p {
	margin-block-start: revert;
}

/*
 * Base font size
 *
 * theme.json's global `typography.fontSize` resolves to a FLUID preset, so the
 * inherited size changes with the viewport. The design source declares no body
 * font-size at all, so everything that does not name one is the browser's
 * default at every width. Measured on three separate elements at 1024:
 *
 *     .feature / .faq-question / .answer-block p   16px source  ->  15.598px
 *
 * `medium` rather than `16px`, because `medium` IS the initial value — it
 * restores the source's behaviour rather than asserting the number that
 * behaviour happens to produce on this machine.
 */
.page-hero,
.section {
	font-size: medium;
}