/* SECTION - General Styles */ body { /* THE DOCUMENT'S BASE SIZE, and until 2026-10-25 nothing set one. No `font-size` existed on or anywhere in the theme, so the base was the browser's default 16px -- a value from outside our type scale that every unconverted run of text was quietly sitting on. Converted pages pin --step-0 (14.00-14.22px) themselves, so the two coexisted 11% apart and Joy reported it off the request list and the single-request page: "I noticed the font shrank a little." Nothing had shrunk; those pages had joined the scale and the rest of the document never had. --step-1, not --step-0. This is deliberately almost a no-op on screen -- --step-1 is 15.751px at a 320px viewport and 15.997px at 1440, so against the old flat 16px the shift is -0.249px at its largest (the NARROW end, not the wide one) and -0.003px on a desktop. The point is structural: the base now comes from our scale instead of from the UA, which is what lets `article_page` inherit a defined prose size rather than pinning one. --step-0 was the other candidate and is wrong here: it would have shrunk every unpinned run by 11%, which is the direction Joy had already called too small. THE CONVENTION THIS SETS: is the PROSE base, and UI chrome opts *down* to --step-0 explicitly. That is already how the theme behaves -- the converted chrome all pins --step-0 -- so this names the existing split rather than changing it. Article prose and anything else that pins nothing lands on --step-1 for free. --step--1 stays the floor (css-root.css:128); don't size text below it. Does not touch the layout widths restored in 3e798e4. Every --step-* is a `clamp()` of rem + vi, and `rem` resolves against , not , so a size here cannot feed back into them -- which is the whole reason those widths went to rem rather than em. Does reach form controls, though it changes nothing for them today: css-reset.css:380 already gives input, button, textarea and select `font-size: inherit`, so they were following rather than the UA's ~13.3px before this and simply keep doing so. The part that matters for `new_request_page` is that whatever is set here is what its fields render at -- they have no size of their own to fall back on. Accessibility, since this is the question that prompted it: WCAG specifies NO minimum font size -- there is no such success criterion. What applies is 1.4.4 Resize Text and 1.4.12 Text Spacing, and both still pass, because this is a rem-based clamp rather than a px pin and so continues to scale with the reader's own base-size setting. (`text-size-adjust: none` at css-reset.css:115 only suppresses mobile auto-inflation; it does not block user zoom or user font settings.) */ font-size: var(--step-1); line-height: 1.5; /* THE DOCUMENT'S FAMILY, and it was still Open Sans until 2026-10-25. Joy found it on the single-request page: "The request_page is still using Open Sans as the font instead of Inter. I think it's still referring to our :root file." It was, exactly -- this read `var(--ff-primary)`, which css-root.css defines as `'Open Sans', system-ui, sans-serif`. THIS IS THE SIBLING OF THE BUG ALREADY FIXED ON THE NEXT LINE, and that is the useful part. On 2026-10-20 the `color` here was migrated off --clr-neutral-160 for precisely this reason -- anything that does not name its own value inherits from this rule, so one stale declaration here mis-paints most of the page. The family was left behind in that same pass. Both declarations had the same defect and only one got fixed, which is why the symptom came back five days later wearing a different hat. Why it hid for so long: twenty-three refreshed components pin --brand-font-family-sans themselves, so every part of the theme that had been through a round was already Inter and looked right. The pages that still read Open Sans are the ones whose CSS pins no family at all -- css-page-request.css has ZERO `font-family` declarations in it, which is why the single-request page is where Joy saw it. --brand-font-family-sans, not --font-family-secondary. Both are Inter; Codex's own token carries no fallbacks, where this one is `'Inter', Verdana, sans-serif`. It is also the token the other 23 sites already use, so this makes the inherited family the same object as the pinned one rather than a second spelling of it. Codex backs Inter for body copy: in the Semantic Scales file every `body/*` type style binds `font/family/secondary` (Inter) and only `heading/*` binds `font/family/primary` (Sora). NOTHING SURVIVES THIS -- --ff-primary now has no live reference in the theme. Two sites pinned it explicitly and so would not have inherited the new family: the search field and the paginator digits, both on the search results page. Both pins were deleted in the same commit. Neither was a real exception; they only looked deliberate because the document's family was --ff-primary too, so the pin and the inherited value were the same face and the pin changed nothing. Left standing they would have become the only Open Sans on the site -- an Inter page with one Open Sans input in it. The note at css-page-search-results.css:1784 has the full history, including the reasoning that wrongly called the digits deliberate. AND THE LAST TWO TRACES ARE GONE TOO, 2026-10-28. This note used to end by saying css-root.css:82 still defined --ff-primary and document_head.hbs still downloaded Open Sans from Google Fonts, that the definition would go with the css-root.css consolidation, and that the download was held back on purpose because Zendesk article authors can specify a family inline in content this theme cannot see. Joy overruled both: "let's get rid of Open Sans everywhere--including Google Fonts request." So --ff-primary no longer exists (css-root.css:81 has its epitaph) and the face is not requested. The author risk the old paragraph described is still real but it is now a content problem, not a stylesheet one: an article body whose inline style says `font-family: 'Open Sans'` falls through to the next name it lists. If that ever turns up, the fix is an @font-face block aliasing the name onto Inter, not restoring a 100KB download for every visitor on every page -- document_head.hbs has that note next to the request. */ font-family: var(--brand-font-family-sans); /* The document's ink, and the only place it is set -- migrated off --clr-neutral-160 (#333333) on 2026-10-20 so it follows [data-theme]. This one declaration was why the dark theme looked half-finished. Anything that doesn't name its own colour inherits from here, which is most of the page: the hero

, every article body (.article-content sets no colour of its own), card copy, list text. All of it stayed #333333 in dark mode -- dark grey on a dark background. The hero heading is simply the biggest and so the one that got reported. Note for anyone who looks for this on instead: it cannot live there. A declaration on wins over an inherited value, so whatever says is overridden the moment this rule exists (css-reset.css:81 has a note to the same effect). Light mode is not unaffected -- this is #10171e rather than #333333 now, the brand's ink, slightly darker and slightly higher contrast sitewide. That is the intended value, not a side effect, but it is a visible change outside dark mode and worth knowing when diffing screenshots. Surfaces that stay light in dark mode have to opt out of this, since they would otherwise get white ink on a white fill. The ones that still exist are listed and pinned at the end of css-utilities.css. */ color: var(--neutral-text); min-height: 100svh; /* No `place-items: center` here. It was removed 2026-10-21; do not restore it. It was written for a that was expected to be a grid container and never became one, so it read as inert -- but Chrome implements Box Alignment for block-level boxes, and the `justify-items: center` half of it therefore made every in-flow child of that does not declare a width shrink to fit its own max-content and centre in what was left.
and the header were already immune by declaring `width: 100%` for unrelated reasons; the footer band was not, so above ~2279px viewport it detached from the window edges and its background and border-top stopped short with an even gutter either side (reported 2026-10-21 at 2545px; the band measured 2278.75px at left 133). The declaration had no upside left: `align-items` does not apply to a block container at all, and the only boxes it was still centring were three empty zero-width divs. Every Forethought box at this level is `absolute` or `fixed`, so none of them were ever subject to it. The one place it was NOT inert is the custom product pages, where css-page-custom.css:23 makes a flex column -- there it was doing real cross-axis centring, so that file now declares `align-items: center` itself rather than inheriting it from here. Those pages would have been unaffected either way, because both of their in-flow children declare `width: 100%` and so resolve identically under `align-items: stretch`. Check them explicitly after any future change here; plan.md:167 explains why they are the template most likely to diverge. `overflow-x: hidden` stays, and is now the only thing containing the Forethought widget's own ~32px of horizontal overflow. */ overflow-x: hidden; /* ---- Sticky footer, sitewide ---- Joy, 2026-10-23: "the footer needs to be situated to the bottom of the page even when the content doesn't fill it out." Reported against a section page holding two articles, where the footer ended two-thirds of the way down the window with page background below it. THIS IS THE THIRD COPY OF THIS PATTERN AND THE FIRST GLOBAL ONE. css-page-custom.css:23 and css-page-error.css:76 already scope exactly these declarations to `html.product-page` and `html.error-page`, for the same reason in a more extreme form -- on those pages
collapses to 0 height, so the footer rode up under the header. Every other template has the milder version of the same bug whenever its content is shorter than the window: the category and section pages, search results with two hits, an empty requests list. So this belongs on , not on a fourth scope. The two page-scoped copies are left alone rather than deleted -- they are now redundant, but the custom pages also set `align-items: center` and `min-height: 100vh` in the same rule, and untangling that is its own change. Deleting them is a cleanup, not part of this fix. `align-items` IS LEFT AT ITS DEFAULT `stretch`, deliberately, and this is the one line to be careful about in this rule.
,
and .footer-wrapper all declare `width: 100%`, so stretch and center resolve identically today -- but the `place-items: center` bug described above is precisely what happens when a child that does *not* declare a width meets a centring alignment on this element. Stretch stays correct for a future child; center silently shrink-wraps it. Do not "tidy" this by adding an alignment here. Nothing un-collapses that was collapsing. Making a flex container stops its children's margins collapsing out of it, but `overflow-x: hidden` above already made overflow-y compute to `auto`, which establishes a block formatting context, which already prevented that -- so the ~32px above the header from `block-flow--sm` is there today and is unchanged. And of the three in-flow children, main and .footer-wrapper declare no block margins at all, so there is no adjacent pair to collapse either. The Forethought boxes at this level are all `absolute` or `fixed` (see the place-items note above), so none of them become flex items taking a share of the column. */ display: flex; flex-direction: column; /* css-reset.css:99 puts `padding-bottom: 3rem` on every page. With `min-height: 100svh` and border-box, that is 48px of body background *below* the footer -- which is the gap in Joy's screenshot, and it would survive the flex column above: the footer gets pushed to the bottom of the content box, and the padding sits under it. So it has to go for the footer to reach the window edge. Zeroed here rather than deleted at source because that declaration is in the reset, which also covers the two templates that already zero it themselves; one override beside the rule that needs it is easier to follow than an edit to css-reset.css plus two now-pointless overrides. It was never protecting against the Forethought launcher, which is position:fixed and floats over the footer regardless. */ padding-bottom: 0; } main { position: relative; /* `1 0 auto`, matching css-page-custom.css:38 and css-page-error.css:87: grow to absorb whatever window height the header and footer leave over, so the footer lands on the window's bottom edge on a short page -- but never shrink, so a page taller than the window keeps main's natural height and scrolls rather than being squashed into it. THIS ALSO FIXES WHERE THE BACK-TO-TOP BUTTON SITS, and the two changes are load-bearing for each other. That button is absolutely positioned inside
and clamped to it (css-components.css's Back-to-Top section). Before this, a short page gave it a track only as tall as the content, so it had nowhere to go; with main filling the window, the track does too, and the button rests just above the footer on a page that cannot scroll and at `calc(100vh - 5rem)` on one that can. */ flex: 1 0 auto; /* 100%, not 100vw: vw counts the classic scrollbar gutter, so 100vw made every page ~15px wider than its container, and `place-items: center` on then centred the excess, putting half of it off the left edge where `overflow-x: hidden` makes it unrecoverable. That centring is gone as of 2026-10-21 (see the rule above), so the overflow would now all land on one side rather than being split -- still wrong, just differently, so this declaration stays. 100% resolves against , which also keeps it correct if ever narrows for the docked Forethought panel again (see css-page-forethought.css). */ width: 100%; } #page-container { width: 100%; margin-block-end: 5rem; } /* THE 5rem ABOVE IS THE PAGE'S WHOLE BOTTOM GAP, at every width, and it is deliberately NOT changed at the mobile breakpoint -- read this before adding a media query here, because one was added on 2026-10-24 and reverted the same day. Joy: "why is there more margin/padding on the bottom of the pages in mobile vs in desktop? I prefer the spacing on desktop and would like to keep it uniform." She was measuring a real 2x, and the cause is that the back-to-top button changes positioning scheme at 45em (css-components.css, Back to Top). On desktop it is `position: absolute`, out of flow, contributing no height, so this 5rem is the entire gap. Below 45em it is in flow as the last block in
, and its own top margin COLLAPSES with this one rather than replacing it -- so the gap became this 5rem plus the 48px circle plus its bottom margin: 161px at 390px wide against 80px on desktop. The first attempt zeroed this margin at the breakpoint and had the wrapper carry the full 5rem itself. It made six templates uniform and BROKE THE TWO THAT PAINTED A BACKGROUND, which is why it is gone: - The wash on the home page and the search results page was painted on a box that ENCLOSED this margin (`.home-page` was an outer
wrapping #page-container, home_page.hbs:13; `.search-page-wrapper` is #page-container itself and restates this margin as padding, css-page-search-results.css). Either way the 5rem was inside the painted box and the gradient covered it. - The back-to-top wrapper is a sibling OUTSIDE that box on both. So whatever bottom gap the wrapper supplied out of its own margins was unpainted, and the flat --page-bg-middle showed through as a pale band above the footer -- the bug Joy reported on 2026-10-22, reported again on 2026-10-24 against the search results page. - Zeroing this margin therefore moved 80px of gap from inside the painted box to outside it, which was the wrong direction on exactly those two pages. PAST TENSE ON PURPOSE, because the wash moved on 2026-10-25: it is sitewide now, on
, in css-reset.css. That changes this trap in two ways worth knowing before anyone reads the paragraph above as still-current fact. It no longer applies to two pages; it applies to all of them but the error page. And the specific failure it describes can no longer happen, because
encloses BOTH this margin and the back-to-top wrapper -- the wrapper is inside the painted box now, so a gap it supplies is painted like any other. What remains true is the measurement that drove the revert: zeroing this at the breakpoint moves the gap rather than fixing it, and the arrangement below already lands all seven templates on the same 80px. So the conclusion stands and the margin stays; the reason is now uniformity alone, not an unpainted band. WHAT REPLACED IT: this 5rem stays, and the wrapper pulls the button UP into it with a negative top margin instead of adding to it. One rule in css-components.css, no page-specific cases, and it comes out at 16px / 48px circle / 16px on all seven templates -- 80px total, matching desktop, with the circle inside the painted area everywhere. The arithmetic and the two different ways it resolves are written up there; the short version is that sibling margins collapse to `max(positives) + min(negatives)`, so 5rem against -4rem is 1rem. The practical consequence for this rule: THIS VALUE IS NOW LOAD-BEARING FOR THE BUTTON'S POSITION, not just the footer gap. css-components.css restates the 5rem to derive its negative margin from it, so the two have to change together. Its comment says the same thing back. */ /*!SECTION - General Styles */ /* SECTION - Hero */ /*!SECTION - Hero */ /* SECTION - Call to Action */ .cta { display: flex; flex-direction: column; align-items: center; padding: var(--space-l); gap: var(--gap-sm); position: relative; & a { padding: 0.75rem 2rem; } } /*!SECTION - Call to Action */ /*SECTION - Breadcrumbs Rebuilt 2026-10-22 against Codex's live `.kb-breadcrumb-link` rule read out of DevTools. The Figma frame (node 6819:7684 in Knowledge-Base-Prototype-v2.0) was the first reference and got two things wrong that only the live CSS showed: the crumb links are underlined at rest, and the hover is a colour change to brand rather than a change of decoration. Codex's own declarations, and what each maps to here: Codex .kb-breadcrumb-link -> this block ------------------------------------ --------------------------------- color: --neutral-text-soft same token, both tiers exist font-family: --font-family-secondary --brand-font-family-sans (Inter) font-size: --font-size-xs (12px) --step--1 (12.44px), see below font-weight: --font-weight-regular same token line-height: 1.3 --leading-body--1 text-decoration: underline same text-decoration-skip-ink: none same text-underline-offset: 2px left to css-reset.css, see below border-radius: --radius-sm same token transition: color .2s --motion-duration-control (0.2s) :hover { color: --brand-text } same token, both tiers exist :focus-visible { } nothing -- see the focus note Every colour is a semantic role with a dark-tier counterpart, so this block has no dark-mode rule and still lands the right way round in both themes. That is the point of the rebuild: what it replaced was built on --clr-secondary-140, --clr-secondary-5 and --clr-neutral-160, and the legacy --clr-* ramp has no dark tier at all, so breadcrumbs rendered light-mode ink on a dark background on all seven templates that show them (article, category, section, search_results, request, requests, new_request). STRUCTURE. {{breadcrumbs}} is Zendesk's and cannot be changed. It emits the *whole* landmark, not just the list: so the wrapper this block hangs off is a plain
, with no role and no label of its own:
{{breadcrumbs}}
It was a second