/* JOB HEADER + BODY — .db-job  (job-detail = 2)
   No hero image: breadcrumb, date, title and a definition list of meta,
   then the posting body. Text-only by design (_content.php). */
.db-job-head { background: var(--cream); color: var(--ink); }
.db-job-head .db-job-head__inner { display: flex; flex-direction: column; gap: 32px; padding-top: 88px; padding-bottom: 20px; }
.db-job-head__date { font-weight: 300; font-size: 14px; line-height: 20px; color: var(--muted); }
/* Explicit px, and scoped through the section so nothing core prints for
   `wp-block-post-title` can out-order it: 36/40 on mobile (368:5211) and 80/80 on
   desktop (368:3781). The inherited clamp was resolving to 24/32 at 390. */
.db-job-head .db-job-head__title { font-size: 36px; line-height: 40px; color: var(--ink); }

/* The frame shows the trail on mobile at 12/16, wrapping (368:5204); the base
   hero hides it below 861px. The date is NOT on the mobile frame at all — it
   goes breadcrumb, title, meta — so it only appears from 861px. */
/* ⚠️ `body.db-page-plain` is the third arm, and it is not optional (§9.72).
   The BASE breadcrumb is `rgba(255,255,255,.4)` and `display: none` below
   861px, because it was drawn over a dark hero photograph. Every light-ground
   context has to opt back in, and until now only two did — `.db-hero--light`
   in hero.css and `.db-job-head` here. A page the client typed has neither
   wrapper, so adding the Brotkrumen block gave them white text on cream and
   nothing at all on mobile. */
/* ⚠️ Four arms, and the fourth is the editor. `db-page-plain` is a front-end
   `body_class`, so the canvas never sees it and the block previewed white on
   cream there even after the front end was right (§9.72). The canvas equivalent
   is the same guard the rest of the plain-page rules use. On a page built from
   `dabaffo/page-text` the crumb sits inside `.db-job-head` in the content, so
   the first arm already covers it in the editor too. */
.db-job-head .db-hero__breadcrumb,
body.db-page-plain .db-hero__breadcrumb,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) .db-hero__breadcrumb {
	display: flex;
	margin-bottom: 0;
	font-size: 12px;
	line-height: 16px;
	color: var(--muted);
}
.db-job-head .db-hero__breadcrumb a:hover,
.db-job-head .db-hero__breadcrumb .is-active,
body.db-page-plain .db-hero__breadcrumb a:hover,
body.db-page-plain .db-hero__breadcrumb .is-active,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) .db-hero__breadcrumb a:hover,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) .db-hero__breadcrumb .is-active { color: var(--ink); }
.db-job-head .db-job-head__date { display: none; }
.db-job-head__body { display: flex; flex-direction: column; gap: 20px; }

/* Each pair is one core/post-terms block whose `prefix` carries the label
   (§9.56). Core wraps that prefix in its own span, so making the span a block
   puts the label above the value exactly as 368:3783 draws it — no extra markup
   and nothing for the client to keep in sync. A field left blank renders an
   empty block, which `:empty` removes from the row. */
.db-job-head .db-job-meta { display: flex; flex-direction: column; gap: 4px; margin: 0; }
/* Mobile is label-LEFT of value in a 100px column (368:5213); desktop stacks the
   label above it (368:3784). Same markup either way — core's prefix span just
   switches between inline and block. */
.db-job-meta__pair { display: flex; gap: 8px; margin: 0; font-size: 14px; line-height: 24px; color: rgba(0, 0, 0, 0.6); }
.db-job-meta__pair:empty { display: none; }
.db-job-meta__pair a { color: inherit; text-decoration: none; }
.db-job-meta__pair .wp-block-post-terms__prefix {
	flex: 0 0 100px;
	margin: 0;
	font-weight: 300;
	color: rgba(0, 0, 0, 0.32);
}

/* ⚠️ The 920 column is LEFT-aligned on the page gutter (368:3793 is a flex row
   whose single 920 child starts at the column edge), not centred. As a direct
   child of the constrained group it was caught by core's
   `margin-inline: auto !important` (Trap 25) and sat in the middle of the page
   while the title above it started at 40 — which is the misalignment that got
   reported. `.db-job-body__inner` is a flow group between the two, so the rule
   no longer reaches the content. */
/* ⚠️ EVERY rule in this block carries a second selector for the block editor,
   and they must stay paired. The post editor renders the content with **no
   template around it**, so `.db-job-body__content` — which `single-job.html`
   puts on the post-content block — does not exist in the canvas and none of
   these would match: headings fell back to theme.json's `h2: huge` and rendered
   at 80px against the 24px the visitor sees (§9.64).
   The canvas is a same-origin iframe whose body core stamps with
   `post-type-job`, and whose root block list is `.is-root-container`. That pair
   is the editor's equivalent of `__content` — narrow enough that no other post
   type's editor is touched, and it needs no separate editor stylesheet, which
   is the point: a mirrored file is a file that silently drifts.
   Verified against the real canvas, not assumed — see §9.64. */
.db-job-body .db-job-body__content,
body.post-type-job .is-root-container { display: flex; flex-direction: column; gap: 40px; max-width: 920px; padding-block: 0 40px; }
.db-job-body__section { display: flex; flex-direction: column; gap: 20px; }

/* ⚠️ These hang off `__content`, not `__section`. A posting written straight
   into the editor has no group wrapper — the client has no reason to invent
   one — so scoping the body's typography to `__section` left every plain
   heading, paragraph and list unstyled, which is how the missing bullets were
   reported (§9.63). `__content` is on the post-content block in
   `single-job.html`, so it is always there; grouped content still matches,
   since these are descendant selectors and the specificity is unchanged. */
.db-job-body__content h2,
body.post-type-job .is-root-container h2,
body.db-page-plain .db-page__content h2,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) h2 { font-size: clamp(1.125rem, 4.5vw, 1.5rem); line-height: 1.3; }
/* The list sits 8px under its h3 on mobile and 12 on desktop, where the section
   gap is 20 and 24 — one -12 correction covers both. */
.db-job-body__content h3,
body.post-type-job .is-root-container h3,
body.db-page-plain .db-page__content h3,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) h3 { margin-bottom: -12px; font-family: var(--font-display); font-size: 14px; line-height: 20px; text-transform: uppercase; }
.db-job-body__content p,
body.post-type-job .is-root-container p,
body.db-page-plain .db-page__content p,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) p { font-size: 16px; line-height: 28px; color: var(--muted); }
.db-job-body__content ul,
body.post-type-job .is-root-container ul,
body.db-page-plain .db-page__content ul,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) ul { display: flex; flex-direction: column; gap: 2px; padding-left: 0; list-style: none; }
.db-job-body__content ul li,
body.post-type-job .is-root-container ul li,
body.db-page-plain .db-page__content ul li,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) ul li { position: relative; padding-left: 14px; font-size: 16px; line-height: 28px; color: var(--muted); }
.db-job-body__content ul li::before,
body.post-type-job .is-root-container ul li::before,
body.db-page-plain .db-page__content ul li::before,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) ul li::before {
	content: ""; position: absolute; left: 0; top: 12px;
	width: 6px; height: 6px; border-radius: 50%; background: var(--gold);
}

/* …and the rhythm has to follow, or ungrouped content reads at section spacing
   throughout. The column's own 40/60 gap is the distance *between* sections; a
   heading and the list it introduces need the section's internal 20/8. Each
   heading pulls its own neighbours back, so a run of h2 → list → h2 → list
   spaces exactly like the grouped version. Direct children only: content that
   IS grouped keeps the values above untouched. */
.db-job-body__content > h2,
body.post-type-job .is-root-container > h2 { margin-bottom: -20px; }
.db-job-body__content > h3,
body.post-type-job .is-root-container > h3 { margin-top: -20px; margin-bottom: -32px; }
/* ⚠️ The two corrections stack where an h3 follows an h2 directly, and 40 - 20
   - 20 is 0 — the subheading sat on the heading's baseline (60 - 36 - 36 was
   worse: -12, i.e. overlapping). Zeroing one side leaves the h2's own -20/-36,
   which is the section spacing both breakpoints want. */
.db-job-body__content > h2 + h3,
body.post-type-job .is-root-container > h2 + h3 { margin-top: 0; }
.db-job-body__content > :first-child,
body.post-type-job .is-root-container > :first-child { margin-top: 0; }

/* ⚠️ Editor only, and it is load-bearing — without it the canvas centres every
   block. Core lays the root container out with

     .block-editor-block-list__layout.is-root-container > :where(…)
       { max-width: 1360px; margin-left: auto !important; margin-right: auto !important; }

   In core's own flow layout those autos are inert: the block is width:auto, so
   they resolve to 0 and it fills. The moment the container is a flex column
   they out-rank `align-items: stretch`, every block shrink-wraps to its own
   text and centres, and each one lands on a different left edge.
   `width: 100%` fixes it without an `!important` of our own: with a definite
   width there is no free space left for an auto margin to take, so core's rule
   resolves to 0 on its own terms and the blocks fill the column and share one
   left edge — which is what the visitor sees. Safe here because the job body is
   a single text column with no wide or full-width blocks.
   Not needed on the frontend: `single-job.html` gives post-content the
   `default` (flow) layout, which never emits that rule. */
body.post-type-job .is-root-container > * { width: 100%; }

/* The canvas root carries `has-global-padding`, so the 40px gutter is *inside*
   the 920 and the text measure came out 840 — close, but it wraps in different
   places than the visitor's 920, which is the one thing a preview has to get
   right. Widen by exactly the padding, and keep the gutter rather than zeroing
   it: it is what puts the body on the post title's left edge.
   ⚠️ …but only up to a point, which is the second half of this. The title is a
   `wp-block-post-title` with core's `max-width: 1360px` and auto margins, so it
   is CENTRED in the canvas: past a canvas of about 1440 its left edge walks
   right (40 → 80 → 280 at canvas 1120 / 1520 / 1920) while a left-pinned column
   stays at 40. Below that width the two coincide exactly, which is how the
   first version of this shipped looking correct — measure a canvas *wider* than
   contentSize or this defect is invisible.
   The margin tracks the title's own centring, so the two share a left edge at
   every width: zero until the canvas exceeds contentSize plus its gutters, then
   half the overflow. */
body.post-type-job .is-root-container {
	max-width: calc(920px + var(--wp--style--root--padding-left) + var(--wp--style--root--padding-right));
	margin-left: max(0px, calc((100% - var(--wp--style--root--padding-left) - var(--wp--style--root--padding-right) - var(--wp--style--global--content-size, 1360px)) / 2));
}

/* The legal pages (§9.59) reuse this shell but have no date and no meta list,
   so the head's 20px bottom padding was the entire gap between an 80px title and
   the first heading. Only mobile needs it — desktop already opens the body at 60. */
.db-job-body--text .db-job-body__content { padding-top: 32px; }

/* ---------- a page the client just types (§9.67) ----------
   `page.html` and `page-full.html` hand post-content `db-page__content`. Until
   now they handed it nothing, so a new page typed in the editor rendered the
   same way a new post did before §9.66: `h2` at theme.json's 80px and prose
   running the full 1440.
   ⚠️ The guard is what makes this safe, and it was measured before it was
   written: across all four sites, **310 of 310 top-level blocks on 76 published
   pages carry a `db-` class**. So `:not(:has(> [class*="db-"]))` cannot match a
   page that exists — it fires only on a page whose top level is plain blocks,
   which is exactly the case that had no styling. The moment the client inserts
   a pattern, the guard goes false and the page is a section page again.
   Values are the simple text page (368:3755), the shell the legal pages use;
   the top padding is `db-job-head__inner`'s, because a plain page has no hero
   to clear the fixed header for it. */
body.db-page-plain .db-page__content {
	display: flex; flex-direction: column; gap: 20px;
	max-width: calc(920px + var(--wp--style--root--padding-left) + var(--wp--style--root--padding-right));
	padding-inline: var(--wp--style--root--padding-left) var(--wp--style--root--padding-right);
	padding-block: 88px 40px;
	/* ⚠️ Trap 29 on the FRONT end (§9.69). Every other page centres its 1360
	   content grid, so past a 1440 viewport its text column walks right — 40 →
	   160 → 280 → 600 at 1440/1680/1920/2560. A column pinned to the gutter
	   stays at 40 and reads as a different, wider container. At exactly 1440 the
	   two coincide, which is why measuring only there passed it.
	   Same formula as the editor arm below: nothing until the viewport exceeds
	   contentSize plus its gutters, then half the overflow. */
	margin-left: max(0px, calc((100% - var(--wp--style--root--padding-left) - var(--wp--style--root--padding-right) - var(--wp--style--global--content-size, 1360px)) / 2));
}
/* ⚠️ Trap 28 on the FRONT end this time, not just in the canvas. `page.html`
   gives post-content a constrained layout, so core puts `margin-left/right:
   auto` on every child; making the container a flex column lets those autos
   beat `align-items: stretch`. It shows up only on *short* children — the
   paragraph's max-content exceeds the column so its free space is 0 and it
   looks fine, while the h2 shrank to its text and sat in the middle. A definite
   width leaves the autos nothing to take. */
body.db-page-plain .db-page__content > * { width: 100%; }

/* ⚠️ The h1 needs saying explicitly. On a section page the page title is a
   `db-hero__title` / `db-job-head__title`; on a plain page it is whatever `h1`
   the client typed, and theme.json's `h1: display` renders that at **120px**
   (§9.68). These are `db-job-head__title`'s values — the same size the legal
   pages give their title, which is the closest thing to a spec for this. */
body.db-page-plain .db-page__content h1,
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) h1 {
	font-size: 36px; line-height: 40px; color: var(--ink);
}

/* The editor canvas again — no template around the content, plus Trap 28's
   `width: 100%` and Trap 29's title-tracking margin. */
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) {
	display: flex; flex-direction: column; gap: 20px;
	max-width: calc(920px + var(--wp--style--root--padding-left) + var(--wp--style--root--padding-right));
	margin-left: max(0px, calc((100% - var(--wp--style--root--padding-left) - var(--wp--style--root--padding-right) - var(--wp--style--global--content-size, 1360px)) / 2));
}
body.post-type-page .is-root-container:not(:has(> [class*="db-"])) > * { width: 100%; }

@media (min-width: 861px) {
	.db-job-head .db-job-head__inner { gap: 60px; padding-top: 120px; padding-bottom: 0; }
	/* 24 between date, title and meta (368:3778) — 32 was the prototype's. */
	.db-job-head__body { gap: 24px; }
	.db-job-head__date { font-size: 14px; }
	.db-job-head .db-job-head__title { font-size: 5rem; line-height: 80px; }
	.db-job-head .db-hero__breadcrumb,
	body.db-page-plain .db-hero__breadcrumb,
	body.post-type-page .is-root-container:not(:has(> [class*="db-"])) .db-hero__breadcrumb { font-size: 14px; line-height: 20px; }
	.db-job-head .db-job-head__date { display: block; }
	.db-job-head .db-job-meta { flex-direction: row; flex-wrap: wrap; gap: 40px; }
	.db-job-meta__pair { display: block; font-size: 16px; line-height: 28px; }
	.db-job-meta__pair .wp-block-post-terms__prefix { display: block; }
	.db-job-body .db-job-body__content,
	body.post-type-job .is-root-container { gap: 60px; padding-block: 60px 120px; }
	.db-job-body__section { gap: 24px; }
	/* Editor arm on every one of these too — see the block above. */
	.db-job-body__content h2,
	body.post-type-job .is-root-container h2,
	body.db-page-plain .db-page__content h2,
	body.post-type-page .is-root-container:not(:has(> [class*="db-"])) h2 { font-size: 1.5rem; line-height: 32px; }
	.db-job-body__content h3,
	body.post-type-job .is-root-container h3,
	body.db-page-plain .db-page__content h3,
	body.post-type-page .is-root-container:not(:has(> [class*="db-"])) h3 { font-size: 1rem; line-height: 1.5; }
	.db-job-body__content ul,
	body.post-type-job .is-root-container ul,
	body.db-page-plain .db-page__content ul,
	body.post-type-page .is-root-container:not(:has(> [class*="db-"])) ul { gap: 6px; }
	/* 60 → 24 after an h2 and before an h3, 60 → 12 after one. */
	.db-job-body__content > h2,
	body.post-type-job .is-root-container > h2 { margin-bottom: -36px; }
	.db-job-body__content > h3,
	body.post-type-job .is-root-container > h3 { margin-top: -36px; margin-bottom: -48px; }
	body.db-page-plain .db-page__content,
	body.post-type-page .is-root-container:not(:has(> [class*="db-"])) { gap: 24px; padding-block: 120px; }
	body.db-page-plain .db-page__content h1,
	body.post-type-page .is-root-container:not(:has(> [class*="db-"])) h1 { font-size: 5rem; line-height: 80px; }
}