/* PadoxMono -- Iosevka Fixed, subset and renamed, bundled with padox. WHY A BUNDLED FACE AT ALL. Every measurement in docs/decisions.md that touches the mono -- the 155.25mm measure, the 1.45 code leading, the x-height match against Fira -- was taken against Iosevka. A reader without it got whatever `monospace' means on their machine, and the sheet's careful numbers then described a font that was not on the page. WHY IT IS NOT FIRST IN THE STACK. A reader who has installed Iosevka has the whole of it: every block, their own build, their own feature choices. Ours is a subset. So the stack in --font-mono names theirs first and falls through to this one, and the rename is what makes that expressible -- a stack cannot order two families that share a name. `src: local(...)' is NOT the way to do it: Chrome narrowed local() matching to exact full-name matching for fingerprinting reasons, and the platforms disagree besides. FOUR RULES, NOT ONE. A single @font-face with four sources lets the browser synthesise bold and oblique from the regular face and stack that on top of the real ones. The font-weight and font-style descriptors here are what say which file is which. NO unicode-range. The subset drops Cyrillic, Vietnamese, CJK and the private-use area, and the point is that CSS falls back PER GLYPH: a codepoint this face has not got is drawn by the next family in the stack. A unicode-range would be a second, hand-maintained copy of the subsetter's coverage list, and the two would drift. The url() paths are relative to the sheet and are rewritten as it is emitted -- a site puts its assets under res/, a lone page keeps them beside it, and --self-contained replaces them with data: URIs. The form written here is the lone-page one, so the checked-in sheet is a valid stylesheet as it stands. See HtmlProfile.Fonts. font-display: swap -- the text is drawn in the fallback and reflows when the face arrives, which for a code block is the right trade. Irrelevant under --self-contained, where there is no fetch. */ @font-face { font-family: "PadoxMono"; font-style: normal; font-weight: 400; font-display: swap; src: url("fonts/PadoxMono-Regular.woff2?v=cfdeb02b") format("woff2"); } @font-face { font-family: "PadoxMono"; font-style: italic; font-weight: 400; font-display: swap; src: url("fonts/PadoxMono-Italic.woff2?v=36c41d7a") format("woff2"); } @font-face { font-family: "PadoxMono"; font-style: normal; font-weight: 700; font-display: swap; src: url("fonts/PadoxMono-Bold.woff2?v=25770695") format("woff2"); } @font-face { font-family: "PadoxMono"; font-style: italic; font-weight: 700; font-display: swap; src: url("fonts/PadoxMono-BoldItalic.woff2?v=f292615c") format("woff2"); } /* PadoxIcons -- padox's own drawn notation, bundled with padox. TEN GLYPHS, AND THEY ARE THE DOCUMENT'S CONTENT rather than a preference. PadoxMono is a preference: a reader with their own Iosevka is better served by it, and a page that gets neither still reads. Nothing on anybody's machine draws a five-armed asterisk or a three-arm bracket, so this face ships with EVERY shape padox emits -- linked beside the sheet, inlined under --self-contained, packed into an EPUB -- and --embed-mono does not govern it. HtmlProfile.IconFaces is the other half of that sentence. ONE RULE, NOT FOUR. The notation is never bold and never italic: it means the same thing inside a heading as in a paragraph, which the rules below restate as font-weight: 400. NAMED ONLY BY THE NOTATION'S OWN RULES, which is what makes the codepoints safe. The glyphs sit at U+2192, U+2190, U+21D2, U+21D0, U+2261, U+2016, U+005B, U+005D, U+002A and U+002B -- real characters, re-drawn -- so a reader who never received the face falls back per glyph to their own copy of each. Nothing else on the page is affected by what U+005B looks like here, because nothing else asks for this family. font-display: swap, as above: the character is drawn in the fallback and replaced when the face arrives. Irrelevant under --self-contained, where there is no fetch. */ @font-face { font-family: "PadoxIcons"; font-style: normal; font-weight: 400; font-display: swap; src: url("fonts/PadoxIcons-Regular.woff2?v=d474b2c7") format("woff2"); } :root { color-scheme: light; /* Surface */ /* Named so a rule inside a 
 can reach back to the body face. */
  --font-sans: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
  /* Likewise for div.cli, which is monospace without being code. */
  /* And for [text]{.serif}, which has to name a face rather than assume the body is not one. */
  --font-serif: Charter, "Bitstream Charter", "Source Serif Pro", Cambria, Georgia, serif;
  /* The reader's own Iosevka first, ours second, the existing fallbacks unchanged. See the
     @font-face block at the top of this sheet for why PadoxMono is not first. */
  --font-mono:
    "IosevkaTerm Nerd Font Mono", "Iosevka Fixed", Iosevka,
    "PadoxMono",
    "Cascadia Mono NF",
    ui-monospace, SFMono-Regular, Menlo, Consolas, "Liberation Mono", monospace;
  /* Iosevka's stylistic set 14, which puts * on the operators' own line rather than hanging
     it from the cap height -- so `a * b` reads level with `a = b`. A font without the
     feature ignores it, and every fallback in the stack above is such a font, so this costs
     nothing where Iosevka is absent. Set to `normal` to turn it off.

     Ligatures are a separate matter and are off everywhere the mono face is used, via
     font-variant-ligatures: none on each of those rules. Iosevka carries calt and dlig in
     its default language system, so -> => != <= would otherwise be drawn as arrows and
     relational signs. Code is quoted to be read and retyped character for character, and a
     glyph that stands for two characters works against that.

     Adding a tag here does NOT bring them back -- font-feature-settings only overrides
     font-variant for the tags it names, and "ss17" is not one of them. Verified in
     Chromium: with ligatures normal the arrows appear, with none they do not, and with
     "ss17" and none together they do not.

     ss17, NOT THE ss14 THIS READ UNTIL 2026-08-25. The ConTeXt template moved to ss17 and
     this did not follow, so the two formats applied DIFFERENT stylistic sets to the same
     face -- the one thing the shared `--mono-features` token exists to prevent.

     IT NOW REACHES A READER'S OWN IOSEVKA AND NOTHING ELSE, and it stays for that reason.
     PadoxMono is built from Iosevka source with the letterforms BAKED IN and `noCvSs'
     stripping every cv/ss tag, so the shipped face carries no ss17 to ask for and gets the
     look regardless. The stack puts a reader's own "Iosevka Fixed" or Iosevka FIRST, though,
     and that build does have ss17 -- so this is what makes their page match ours. The
     ConTeXt side dropped the tag because there a stylistic alternate's glyph NAME becomes
     the PDF's ToUnicode and Iosevka names some of them after look-alikes; a browser takes
     its text from the DOM, so no such fault exists here and there is nothing to answer. */
  --mono-features: "ss17";
  /* A code block's inner padding, named because the OUTPUT strip has to cancel it exactly.
     The strip runs the full width of the block and sits flush against its top border, which
     it reaches by pulling itself out through the padding with a negative margin -- so the
     two numbers are one number, and writing them twice is what let them drift apart. They
     had: the strip carried div.cli's 0.72rem/0.9rem while the block it sits in has these,
     and it overhung the frame by 5.4px on each side, painting over the side borders at its
     own height. */
  /* A LINKED SVG IS ITS OWN DOCUMENT, so the page's dark palette cannot reach inside it: a
     drawing made in light mode arrives with its own white ground and dark ink, and sits on a
     dark page as a bright slab. The drawing is left alone -- an author draws in light mode and
     should not have to think about themes -- and the PAGE inverts it instead.

     Measured, and this is why it is a filter rather than the obvious alternative: an SVG CAN
     carry its own `@media (prefers-color-scheme: dark)` block, that DOES work through ,
     and it survives --self-contained as a data: URI. But it follows the OS preference ONLY --
     toggled dark on a light system, the drawing stayed light -- and padox ships a toggle. A
     filter is page CSS, so it answers both.

     invert(0.92), not 1: full inversion puts white on pure black, which is harder than anything
     else this sheet paints. hue-rotate(180deg) undoes the hue flip inversion applies, so a blue
     box stays blue rather than turning orange. */
  --svg-adapt: none;
  --pre-pad-y: 0.5rem;
  --pre-pad-x: 0.6rem;
  /* THE MONO SIZE, ONCE. A mono face runs larger than the prose around it at the same nominal
     size, so every mono path takes a reduction -- inline code, a transcript, a code block,
     .cc/.co and .mono/.tt. It was written out six times at 0.92, which is six places to keep in
     step and six to find when the ratio wants moving; it is one number now. 0.95 rather than
     0.92: at 0.92 the code in a sentence read a shade small against this sheet's body face. */
  --mono-size: 0.95em;
  /* Mathematics, for MathML. Serif throughout: mathematical notation is set in a seriffed
     face by every convention this document could follow, and the body face is sans, so this
     is a deliberate departure rather than an inherited default.

     Every entry is a font with an OpenType MATH table, which is what a browser needs to size
     a radical to its contents, stretch a brace to its rows, and place limits over a sum. An
     ordinary serif has no such table, so `serif` at the end is a legibility floor and not a
     real substitute -- the layout there is the browser's own approximation.

     Cambria Math first: it ships with Windows and with Office, it is the font the OpenType
     MATH table was designed alongside, and it is therefore the one most readers on Windows
     already have. Latin Modern Math next for anyone with a TeX distribution, then the two
     open fonts a Linux box is most likely to carry. */
  --font-math:
    "Cambria Math", "Latin Modern Math", "STIX Two Math", "XITS Math",
    "TeX Gyre Termes Math", "DejaVu Math TeX Gyre", serif;
  --page: #f6f7f9;
  --paper: #ffffff;
  --text: #24292f;
  --muted: #57606a;
  --mark: #57606a;  /* line reference labels ({.lref}) */
  --border: #d8dee4;
  --border-strong: #afb8c1;
  /* Accent */
  --accent: #0969da;
  --link: #0969da;
  /* Links that stay inside the collection. Same relative luminance as --link, so it
     carries the same 5.19:1 against --paper: a different hue, not a weaker colour. */
  --link-local: #147d43;
  --accent-soft: #ddf4ff;
  /* A named term's colour, its own hook. Dark brown: it has to read as a term rather than as
     a link, so it stays clear of the blue, and against the code tint it is quieter than the
     text colour would be. */
  --co-color: #6b4423;
  /* Admonitions. THESE ARE THE PDF'S NUMBERS, hex for hex, and the tints were tuned there
     first -- ink shows a colour cast that a screen forgives, so paper is the harder case and
     what survives it survives both. Measured as the spread between a colour's highest and
     lowest channel, which at these lightnesses is the whole of the colour: admon 5, tip 8,
     note 12, important 12, warning 16, caution 16. Before that, note was 34, warning 31 and
     caution 58, and important carried a magenta cast rather than the rule's violet.

     Every colour that lands on a tint clears 4.5:1 against it -- the label, the body text,
     --link and --link-local -- and this FIXED the one that never did: warning's label was
     4.16:1 and is 4.62:1. Re-measure all four if a tint moves.

     --admon is the base: the colour a callout wears when it does not say what
     kind it is. Deliberately the muted grey rather than a sixth hue -- the five kinds mean
     something by their colour, and a neutral box is the one that means nothing in
     particular. */
  --admon: #57606a;
  --admon-soft: #f2f4f7;
  --tip: #1a7f37;
  --tip-rule: #6b9b6b;
  --tip-soft: #edf5ed;
  --note: #0969da;
  --note-soft: #f0f4fc;
  --caution: #926100;
  --caution-rule: #9a6700;
  --caution-soft: #f4f2e4;
  --important: #8250df;
  --important-soft: #f4f1fd;
  --warning: #b25100;
  --warning-rule: #c05700;
  --warning-soft: #f7f2e7;
  /* Code blocks */
  --code-overlay: rgba(0, 0, 0, 0.06);
  --code-border-overlay: rgba(0, 0, 0, 0.10);
  --pre-bg: #f0f4f8;
  /* AN OUTPUT BLOCK DARKENS ITS GROUND rather than painting a colour over it: its claim is
     "a little darker than whatever this sits on", which an opaque fill cannot make. Inside
     an admonition the flat --pre-bg was a blue-grey slab on a coloured tint. Over white this
     composites to #f0f2f5, which is what the PDF's own overlay lands on. */
  --output-bg: rgba(68, 92, 130, 0.08);
  --pre-text: #1e2430;
  --pre-border: #cdd5de;
  /* THE TRANSCRIPT'S FILL, and on a light page there is none. The green did not sit well
     beside the rest of the palette, and a box that is only its border reads as a frame
     around the commands rather than as a slab. Dark keeps a fill -- there the tint is what
     separates the box from the page at all.
     Named for the construct and not for the colour. It was called after `{.console}`, a class
     most documents never write, so a rule under `div.cli` reading that name looked like it had
     been inherited from something else -- which is exactly how it was read. The border token
     keeps its old name for now; the borders are being left alone. */
  --cli-bg: transparent;
  /* {.ascart}: the leading for box-drawing diagrams. See pre.ascart. */
  --ascart-line-height: 1.25;
  /* A code block's header bar: the OUTPUT strip and a .file/.snip label alike, because they
     are the same thing -- a band across the top of a block saying what the block is. One
     token, so the two cannot drift apart.

     Its own token rather than --thead-bg, which it matched until it needed to be darker: a
     table head is a band on --paper and this is a band on --pre-bg, so tuning one to its
     background moved the other away from its own.

     A BAND, NOT A RULE. This is the only thing separating the code from its output, so it
     has to be dark enough to read as a divider by itself -- the borders that used to run
     above and below it are gone, and a bar this close to --pre-bg would leave nothing. */
  --label-bg: #dfe6ef;
  --output-label-bg: var(--label-bg);
  /* A label over a TRANSCRIPT takes the console's own colour, not this one. A transcript is
     green — tint and border both — and a greyish-blue bar on top of it reads as two unrelated
     boxes stacked rather than as one object with a title. Derived the same way --label-bg is:
     the console tint darkened by the ratio --pre-bg takes to --label-bg, which lands it at the
     same visible separation from the block it heads (1.126:1 against the code pair's 1.138:1)
     and leaves every colour that sits on it at least as legible (accent 2.77 against 2.75,
     text 11.70 against 11.65). */
  --cli-label-bg: #dfe7e4;
  --output-label-text: #57606a;
  /* One line, fixed, so the copy button can be centred on it -- a button positioned against
     a height that depends on a font's line box is a button that moves when the font does. */
  --output-strip-h: 1.55rem;
  --cli-border: #729486;
  /* AN IN-PROSE SPAN NEEDS ITS OWN EDGE, and only in dark does it differ. The box's
     border is the band's background there, which is right for a block -- band, border
     and box read as one object -- and invisible for a span, which sits on the page
     rather than on the box: measured, that value is 1.07:1 against --paper against the
     2.02:1 this keeps. Same value as the box's in light, stated rather than inherited
     so the dark divergence is visible in one place. */
  --cli-span-border: #729486;
  /* Syntax token colours (light mode) */
  --syn-al:   #c01820;
  --syn-co:   #677080;
  --syn-at:   #2a7a5a;
  --syn-num:  #b86800;
  --syn-type: #1a5c8c;
  --syn-ctrl: #7030a0;
  --syn-cn:   #7e3030;
  --syn-fu:   #1d4f9a;
  --syn-kw:   #3545a8;
  --syn-op:   #505860;
  --syn-pp:   #a05000;
  --syn-str:  #1a6b3c;
  --syn-va:   #1e2430;
  /* Tables */
  --table-stripe: #f6f8fa;
  --thead-bg: #eef2f7;
  /* Semantic tokens for elements with hardcoded colours */
  --heading: #111827;
  --heading-xl: #111827;
  /* #90581d, the PDF's padoxAccent, and the two formats now AGREE. This was #c47828, kept
     lighter on the argument that ink shows a cast a screen forgives -- but that value is
     3.46:1 on --paper, which is a large-text ratio, and the token was colouring 0.82rem bold
     text: the title block's date and the landing page's. Its own sheet already recorded 3.46
     as "washed out" the day the hue was tried for the hero subtitle. What is left on this
     token is three 3px rules and those two dates, so darkening it costs two borders a shade
     and takes both dates to 5.83:1. Light only -- dark stays #cc8e5c, which passes on a dark
     ground and is pinned by the title-hierarchy work. */
  --h1-accent: #90581d;
  --hero-subtitle: #96263a;
  --license-badge-filter: none;
  --license-badge-opacity: 0.62;
  /*--title-text: #2e3f8f;*/
  --title-text: #097dd5;
  --del-line: rgba(190, 50, 50, 0.50);
  --kbd-bg: #eef0f3;
  --kbd-shadow: rgba(0, 0, 0, 0.20);
  --selection-bg: rgba(255, 214, 0, 0.42);
  --details-marker: #c73232;
  --author-text: #374151;
  --toc-bg: #f8fafc;
  --toc-hover: #c8deff;
  --quote-text: #1f2937;
  /* Shadows */
  --paper-shadow: rgb(31 35 40 / 9%);
  --btn-shadow: rgb(31 35 40 / 12%);
  /* Fixed-position buttons */
  --btn-border: rgb(9 105 218 / 25%);
  --btn-bg: rgb(255 255 255 / 68%);
  --btn-border-hover: rgb(9 105 218 / 38%);
  --btn-bg-hover: rgb(221 244 255 / 86%);
  --btn-bg-mobile: rgb(255 255 255 / 88%);
}

* {
  box-sizing: border-box;
}

html {
  background: var(--page);
  font-size: 18px;
}

body {
  /* Ask every font for a distinguished zero, and take it wherever it is offered. A request,
     not a guarantee: a face either has an alternate zero or it does not, and a browser will
     not draw the slash itself the way it synthesises bold or oblique.

     Measured on this machine: Iosevka's zero is slashed and DejaVu Sans Mono's is dotted
     without being asked, so the property changes nothing there; Noto Sans and Cambria have a
     plain zero and no alternate, so it changes nothing there either. It costs one declaration
     and helps whoever's body font does carry one. Inherited, so it reaches everything. */
  font-variant-numeric: slashed-zero;
  /* Ligatures in PROSE stay at the browser's default, which is on: fi, ffi and fl are what a
     text face is drawn to do, and a word is read as a word. There is deliberately no
     declaration -- `normal` would only restate the default -- and a blanket rule switching
     them off is the thing this comment exists to prevent. Verified in Chromium against the
     resolved body face: default and font-variant-ligatures: none draw the f-pairs
     differently, so the feature is genuinely applied and not merely permitted.

     Code is the opposite case and says so at each mono rule. The one prose exception is .cc,
     which names something the reader may have to type. */
  max-width: 860px;
  margin: 0 auto;
  padding: 48px 32px 72px;
  overflow-x: clip;
  background: var(--paper);
  color: var(--text);
  font-family: var(--font-sans);
  hyphens: auto;
  line-height: 1.62;
  box-shadow: 0 18px 50px var(--paper-shadow);
}

body > *:first-child {
  margin-top: 0;
}

::selection {
  background: var(--selection-bg);
  color: inherit;
}

#title-block-header {
  position: relative;
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  align-items: baseline;
  margin: -0.4rem 0 2.2rem;
  padding-bottom: 0.75rem;
  border-bottom: 3px solid var(--h1-accent);
}

#title-block-header .title {
  grid-column: 1 / -1;
  margin: 0 0 0.65rem;
  padding: 0;
  border: 0;
  font-size: 1.9rem;
  color: var(--title-text);
  text-align: left;
}

/* Title left, subtitle right: spreads the information across the block instead of
   stacking two centred/left lines, which read as one lump. */
#title-block-header .subtitle {
  grid-column: 1;
  margin: -0.35rem 0 0.8rem;
  color: var(--heading);
  font-size: 1.3rem;
  font-weight: 500;
  text-align: right;
  text-wrap: balance;
}

/* Generated, not typed: the dash marks the subtitle as a continuation of the title,
   and stays out of the document's own text and copy/paste. */
#title-block-header .subtitle::before {
  content: "\2014\2002"; /* em-dash, en-space */
}

#title-block-header p.date {
  position: absolute;
  bottom: 0;
  right: 0;
  transform: translateY(50%);
  margin: 0;
  padding: 0 0 0 0.5rem;
  background: var(--paper);
  color: var(--h1-accent);
  font-weight: 700;
  font-size: 0.82rem;
  line-height: 1.5;
}

.abstract {
  --ab-lead: 1.2rem;
  --ab-gap:  0.45rem;
  /* Inset from the measure by 2em, not 3rem: the block is a passage of the document, not
     an aside, and it was standing further off than it needed to. */
  margin: 0 2em 2rem;
  padding-bottom: 0.9rem;
  /* --border is a hairline meant for dividing table rows; against paper it is 1.35:1 and
     all but invisible at this length. --border-strong doubles that, and 2px gives the rule
     enough body to read as a deliberate edge. */
  border-bottom: 2px solid var(--border-strong);
  font-size: 1.05rem;
}

.abstract-title {
  display: flex;
  align-items: center;
  gap: var(--ab-gap);
  margin-bottom: 0.55em;
  font-size: 0.72rem;
  font-weight: 700;
  letter-spacing: 0.09em;
  text-transform: uppercase;
  color: var(--muted);
}

.abstract-title::before,
.abstract-title::after {
  content: '';
  height: 2px;
  background: var(--border-strong);
}

.abstract-title::before {
  width: var(--ab-lead);
  flex-shrink: 0;
}

.abstract-title::after {
  flex: 1;
}

/* The landing page's date, flush right on the ABSTRACT rule.
   order: 1 is what puts it there. ::after is the last flex item whatever the source order,
   so without it the date would land between the label and the rule, and the rule would then
   run past it to the margin. Ordered after ::after, the flexing rule stretches between the
   label and the date instead. --h1-accent, matching the date on an ordinary page; the
   surrounding size, weight and tracking are inherited from .abstract-title. */
.abstract-date {
  order: 1;
  flex-shrink: 0;
  color: var(--h1-accent);
}

/* The text starts where the ABSTRACT label does, past the rule that leads into it. The
   same amount on the right, so the passage sits square inside its own block rather than
   hanging off the left. */
.abstract p {
  margin: 0;
  padding-left: calc(var(--ab-lead) + var(--ab-gap));
  padding-right: calc(var(--ab-lead) + var(--ab-gap));
  font-size: 1em;
  font-style: italic;
  line-height: 1.65;
}

.abstract p + p {
  margin-top: 0.6em;
}

section.footnotes {
  margin-top: 2rem;
}

/* THE MARKER COLUMN LINES UP WITH THE LABEL, and 1.65rem is not a round number chosen by eye:
   it is .footnotes-title's rule (::before, 1.2rem) plus its flex gap (0.45rem), which is where
   the F of FOOTNOTES starts. So the ol's own box edge sits under the F.

   NO padding-left. It carried 1em, and that is a leftover from before list markers were drawn
   as an absolutely-positioned ::before in a fixed column -- back when the marker lived in the
   browser's gutter and the padding was what made room for it. `ul, ol' now set padding-left: 0
   and the li reserves --marker-col + --marker-gap itself, so the 1em was pure surplus: measured
   in Firefox at a 1200px viewport, the label's F sat at 231.7px and the marker column began at
   249.7px, 18px to its right, which put the `1.' under the T of FOOTNOTES. Removing it puts the
   COLUMN back on the F. */
section.footnotes ol {
  margin-left: 1.65rem;
  margin-right: 1.65rem;
}

/* THE NUMBER RANGES LEFT HERE, AND ONLY HERE. Every other list marker in this sheet sits flush
   RIGHT in its column, which is what keeps `9.' and `10.' on one edge; a footnote number has
   something else to line up with, and it wins. The column's own left edge is derived from the
   FOOTNOTES label above it, and ranging right left a one-digit number floating inside that
   column: measured in Chromium at 1200px, the label's F and the ol's box edge both at 231.69px,
   the marker column 28.8px wide, and `1.' starting about 14px into it -- under the second O of
   FOOTNOTES, while `10.' and `11.' started on the F. The rule the alignment exists to serve is
   the one the reader can see, so the numbers all start at the F and the two-digit ones run on
   into the gap instead.

   The note TEXT does not move: the li reserves --marker-col + --marker-gap as padding whatever
   the marker does inside it, so every note still begins on one edge. */
section.footnotes ol > li::before {
  text-align: left;
}

.footnotes-title {
  display: flex;
  align-items: center;
  gap: 0.45rem;
  margin-bottom: 0.55em;
  font-size: 0.72rem;
  font-weight: 700;
  letter-spacing: 0.09em;
  text-transform: uppercase;
  color: var(--muted);
}

/* Same construction as the abstract's rule, and the same reason for the stronger token:
   over the width of the measure --border is not there. */
.footnotes-title::before,
.footnotes-title::after {
  content: '';
  height: 2px;
  background: var(--border-strong);
}

.footnotes-title::before {
  width: 1.2rem;
  flex-shrink: 0;
}

.footnotes-title::after {
  flex: 1;
}


/* The TOC is a collapsible disclosure in the body flow, after the abstract. The 

   carries the block's own margin, the  reads like the other front-matter labels
   (the chevron comes from the generic summary rule), and the