/* LAYER: page — the docs' own shell and prose, the most specific sheet a docs page loads. Beats `component` (sidenav.css, topbar.css) and `site` (footer.css), which is what lets the footer rules below simply say what they mean. */ @layer page { /* Drift Documentation — docs-only styles. * * Shared concerns (the --brand-1/2/3, --ink, --bg, --max-width, and * --padding custom properties, the html/body reset, the .btn family) * come from styles/global.css, loaded * right alongside this file in every docs page's — the same file * the homepage loads, not a second copy of the same values. Nothing * below touches .navbar, .brand, .btn, or :root — if the navbar ever * needs to look different in docs, that's a shared/components/navbar.html * slot (see scripts/sync-navbar.py), not a rule here. * * Page structure (all present in the static HTML — nothing is created * and appended by JS anymore): * * .docs-layout (single column; offset past the sidebar) * div.docs-center (inner grid: main | toc) * div.docs-main (everything in the middle column) * main.docs-content (the page's own reading content) * nav.docs-footer-nav (prev/next) * nav.docs-toc (auto-built from this page's headings) */ html { /* The renderer fills the footer nav; docs.js still builds the * TOC after first paint. If that * growth crosses the "needs a scrollbar" threshold, the scrollbar * appearing shrinks the viewport width out from under any * 100vw-sized fixed element, producing a brief horizontal shift. * Reserving the scrollbar's space up front means its presence never * toggles, so there's nothing to shift. */ overflow-y: scroll; } /* ── The chrome is carried across a navigation ─────────────────────────────── * * Every docs page is its own document, so a click tears the whole page down and * paints a new one — measured at 76–84ms from click to first contentful paint. * The ARTICLE should change in that window. The column should not: it is * identical either side of the click, down to the pixel (same groups, same open * branch, same scroll position — only the highlighted row differs). Blinking it * out and back is what reads as the navigation flickering, and it is worst where * an expanded branch has put twenty-five rows of ink on screen. * * Naming an element makes the browser treat the old and new instances as ONE * object and carry it across rather than draw a new one. The names must be * unique within a document, which is why the two bands are named separately * instead of sharing one. * * Both documents have to opt in for this to engage, which every docs page does * by loading this file. A browser without cross-document view transitions * ignores the at-rule and navigates exactly as before — there is no fallback to * write, and nothing degrades. */ } /* @layer page — reopened below. @view-transition is valid only at the TOP LEVEL of a stylesheet, never inside a grouping rule, so the layer has to be interrupted around it rather than wrapping the file whole. Two @layer blocks of the same name merge, so this costs nothing but the braces. */ @view-transition { navigation: auto; } @layer page { .docs-sidenav { view-transition-name: docs-sidebar; } .topbar { view-transition-name: docs-topbar; } /* A blink, not a production. The chrome does not move, so the only thing animating is the article replacing itself; a longer cross-fade would turn every page change into an event and add its own duration to a navigation that already completes in under 100ms. */ ::view-transition-old(root), ::view-transition-new(root) { animation-duration: 90ms; } /* Motion IS the mechanism here, so this turns it off rather than shortening it: with `navigation: none` the browser does a plain navigation, which is the behaviour someone asking for reduced motion is asking for. */ } /* @layer page — interrupted again for the same reason */ @media (prefers-reduced-motion: reduce) { @view-transition { navigation: none; } } @layer page { /* ── Page grid ───────────────────────────────────────────────────── */ /* Two nested grids remain, though the outer one now has a single column: * .docs-layout clears the pinned header bands and spans full width, while * .docs-center caps and centres the content + TOC. The rationale that used to * be here was entirely about keeping a left sidebar flush to the true screen * edge, and that sidebar is gone. */ /* ---- Where the chrome sits ------------------------------------------------- * The two components are the page's whole chrome: `sidenav` down the left, * `topbar` across the rest of the top. NEITHER OWNS ITS OWN PLACE ON THE PAGE — * a component that dictated where it sat could not be used twice, and HQ wears * the same column against a different layout. So the pinning is here, in the * page's own sheet, which is the only file that knows there are two of them. */ .docs-sidenav { position: fixed; inset: 0 auto 0 0; /* Above the bar's 997. They do not overlap, but the column is the more important surface if a future width ever makes them. */ z-index: 998; /* The column's own padding stops at the last row; this is the air under it, so the final entry is not flush against the bottom of the viewport. */ padding-bottom: 40px; } /* How far from the left edge the bar starts: the width of what sits beside it. The bar reads this and knows nothing else about the column. */ .topbar { --topbar-left: var(--sidenav-w); } /* No announcement strip and no navbar on the docs. The marketing site's strip * carries a broadcast to a stranger arriving on a landing page, and a reader * three levels into the CLI reference has already arrived; the column holds the * wordmark, the way back to the site and every page, so a second bar across the * top would repeat what it already says. * * ZEROED rather than deleted, all three. Every offset on this page — the * layout's top padding, the TOC's resting and sticky position, every heading's * scroll-margin — is written as calc(--header-h + --subnav-h), so retiring the * bands here retires them in all four places at once and nothing derived has to * be found and rewritten. * * --header-h is the TOP BAR's height on these pages, because the top bar is the * only thing pinned above the content. One mapping line, so the derived offsets * below keep reading the name they always did. */ :root { --announce-h: 0px; --nav-h: 0px; --subnav-h: 0px; --header-h: var(--topbar-h); } /* Everything in flow clears the top bar. One rule on the layout rather than on the content, so the TOC column clears it too. */ .docs-layout { padding-top: calc(var(--header-h) + var(--subnav-h)); } /* Nothing is pinned above the content here, so this is the whole of the page's top air rather than a gap under a band. It is --docs-top-gap, not a number of its own: the TOC beside it derives its offset from the same token, and the two columns have to start on the same line. */ .docs-main { padding-top: calc(var(--docs-top-gap) * 1.5); } /* ONE column. This was "220px 1fr" — a sidebar track beside the content — until * the sub-navbar became the docs' navigation and the sidebar was deleted for * answering the same question twice. .docs-center still does the capping and * centring; .docs-layout is now just what clears the pinned bands. * * The max-width cap went with the sidebar: it existed so margin:auto would not * pull the sidebar off the true left edge. With one centred column there is * nothing to hold flush, and .docs-center caps itself. */ .docs-layout { display: grid; grid-template-columns: 1fr; grid-template-areas: "center"; min-height: 100vh; /* THIS element owns the content column, and it is the only one that does. * Deriving the same edge in two places is two chances to disagree, and this * page has paid for that repeatedly — a missing box-sizing, then a centred * grid, then a parent that became a flex container. * * Capped at --docs-region rather than the site-wide --max-width: the docs hold * a wider measure and a wider outline than 1500px has room for once the left * gutter is paid. The gutters themselves are the site's, unchanged, so this * column starts on the same left edge every other page does. */ box-sizing: border-box; max-width: var(--docs-region); margin: 0 auto; padding-left: calc(var(--padding) * 1.5); padding-right: var(--padding); /* Room for the fixed sidebar. It is out of flow, so nothing reserves this space on its own and the prose would start underneath it. margin-left rather than padding because the cap above measures the content column, and padding would eat --padding out of it at every width. Stated after the shorthand: `margin: 0 auto` sets all four, and only the left one is ours to override. --sidenav-w is the column's own width, stated once in shared/components/sidenav/sidenav.css. */ margin-left: var(--sidenav-w); } /* The footer needs the same offset for the same reason: the sidebar is fixed, so it reserves no space, and a full-bleed footer runs underneath it and comes out from behind on the left. width has to move with the margin: 100vw plus a 284px margin is 284px of horizontal scroll on every docs page. */ .site-footer { margin-left: var(--sidenav-w); width: auto; } /* The footer's inner column, on the prose's left edge instead of its own. footer.css sizes .wrap from --max-width and --padding, which on a docs page starts it some hundred pixels right of the text above it — two columns on one page, neither wrong on its own. */ .site-footer .wrap { max-width: var(--docs-region); margin: 0; padding-left: calc(var(--padding) * 1.5); padding-right: var(--padding); } /* ── The docs footer ───────────────────────────────────────────── * Two rows: the brand and the status badge share the first, the rule that opens * .footer-bottom separates them from the copyright line. * * The badge is injected between the two by status-badge.js, so this cannot be a * two-column grid with named areas — the middle child does not exist until the * script runs, and on a failed fetch it never does. A wrapping flex row places * whatever is present and lets .footer-bottom claim a line of its own. */ .docs-site-footer .wrap { display: flex; flex-wrap: wrap; align-items: flex-start; justify-content: space-between; gap: 1.5rem; } /* Full width, so it always lands on its own row under the two above it. */ .docs-site-footer .footer-bottom { flex: 0 0 100%; margin-top: 0; } .docs-site-footer .footer-brand p { margin: 0.35rem 0 0; } /* Level with the wordmark rather than the slogan beneath it: the badge is a peer of the mark, and aligning it to the block's top edge reads as a stray line of text hanging off the right. */ .docs-site-footer .footer-status { margin-top: 0.5rem; } @media (max-width: 700px) { /* Side by side, the badge and the mark end up a few characters each. Stacked they keep their own line and the row order still reads top to bottom. */ .docs-site-footer .wrap { flex-direction: column; gap: 1rem; } } @media (max-width: 900px) { /* A 284px column is most of a phone, so the sidebar goes back into normal flow at the top of the document. The PINNING is dropped here because the pinning was this file's to begin with; the column's own sheet handles what it looks like once it is a wrapping row. It is the first thing in the document, so it clears the top bar itself — and the layout drops its own clearance, or the gap is counted twice. */ .docs-sidenav { position: static; margin-top: var(--header-h); padding-bottom: 0; } .docs-layout { padding-top: 0; } /* The sidebar reserves its own space now, so an offset here would double it. */ .docs-layout { margin-left: 0; } .site-footer { margin-left: 0; width: 100vw; } } /* ── Center column (main content + TOC, capped and centered) ────── */ .docs-center { grid-area: center; display: grid; /* TOC on the right. It was tried on the left, where the deleted sidebar used to sit, on the theory that the eye starts at the left edge — it read worse: the outline competed with the prose for the starting position instead of staying out of its way. The content keeps the left edge; the TOC is reference material and sits beside it. */ grid-template-columns: minmax(0, var(--docs-measure)) var(--docs-toc-w); grid-template-areas: "main toc"; /* START, not center. The content column has ONE left edge on this page — the one the sub-navbar's first card sits on, and the wordmark above it — and the prose has to begin there too. Centring the grid tracks inside the column floated the text some hundred pixels right of everything it is supposed to line up with. */ justify-content: start; align-items: start; /* The TOC is reference material sitting beside the prose, and a narrow gap crowds the measure's right edge — close enough to read as a second column of the text rather than as an aside. */ column-gap: var(--docs-col-gap); /* border-box, STATED. Without it max-width applies to the CONTENT box and the padding is added OUTSIDE it, making this column 1800px wide where a sibling sharing --max-width and --padding resolves to 1500px total — two elements nominally on the same measure, landing on different left edges. One of several places a width or height met a padding or border under a box model nobody declared. */ /* No width, no centring, no side padding: .docs-layout already placed this inside the column. Anything here would be a second opinion about where the column starts. */ padding-bottom: 80px; } /* No room for the TOC's column. * * 1500, not the 1240 a 190px outline could live with, and the number is measured * rather than chosen. Below this width a 280px outline costs the prose more than * the wider measure wins it: at 1440 the text would come out around 600px, which * is NARROWER than it was when the outline was 190. So this is the point where * the outline stops earning its column — and giving it up hands the prose the * whole 940-odd pixels instead. * The reader loses the outline on a 1440 laptop. That is the trade, stated * plainly: the prose is the page, and a cramped measure costs every reader while * a missing outline costs the ones who were going to jump. */ @media (max-width: 1500px) { .docs-center { grid-template-columns: minmax(0, var(--docs-measure)); grid-template-areas: "main"; } .docs-toc { display: none; } } @media (max-width: 768px) { /* One gutter for both, or the footer keeps the desktop 40px while the prose drops to 16 and the page shows two left edges on a phone. */ .docs-layout, .site-footer .wrap { padding-left: 16px; padding-right: 16px; } .docs-content { padding: 24px 0; } .docs-card-grid { grid-template-columns: 1fr; } } /* More space BETWEEN sections than WITHIN one (below) — proximity does * the grouping work: tight spacing reads as "these belong together", * generous spacing reads as "new group starts here". */ /* ── Middle column (content + footer nav) ───────────────────────── */ .docs-main { grid-area: main; min-width: 0; /* let wide 
 blocks scroll instead of stretching the column */
}

:root {
  /* The gap above the first thing on the page. BOTH columns need it: .docs-main
   * takes it as padding, .docs-toc as part of its own offset — so the outline
   * starts level with the h2 it belongs to. One token, consumed twice; when the
   * two were separate numbers they disagreed by a whole rem and the TOC sat
   * high. */
  /* ---- The reading column, ported from Scaleway's docs ---------------------
   * Read out of their shipped stylesheet rather than eyeballed:
   *   --container-width: 1280px      the region holding prose AND outline
   *   --container-padding: 2.5rem    40px each side of it, at desktop
   *   the outline: min-width 280px; max-width 280px — a hard track
   * so their prose is the 1000px the outline leaves of the 1280.
   *
   * The region grows to the RIGHT, and only to the right. The left gutter is
   * --padding * 1.5, unchanged, so the prose begins exactly where it always has;
   * widening the measure and pushing the outline outward is done by raising the
   * cap, never by moving the edge the reader's eye already knows.
   *
   * Which means the cap cannot be the site-wide --max-width. At 1500px there is
   * no room for a 225px gutter plus 1000 of prose plus 280 of outline, so the
   * prose track would silently shrink back to about what it already was —
   * minmax(0, …) is a ceiling, not a promise. It is summed from its parts
   * below instead. */
  --docs-measure: 1000px;
  --docs-toc-w: 280px;
  /* Ours, not theirs: their outline sits flush against the prose and separates
     itself with a left rail, while this one is reference material that must not
     read as a second column of the text. */
  --docs-col-gap: clamp(40px, 4vw, 88px);
  /* Left gutter + the three tracks + right gutter. Written as the sum so the cap
     cannot fall out of step with what it has to hold. */
  --docs-region: calc(var(--padding) * 1.5 + var(--docs-measure)
                      + var(--docs-col-gap) + var(--docs-toc-w) + var(--padding));

  --docs-top-gap: 3.5rem;
  /* One prev/next card's height. The footer nav is filled by a script after
   * first paint and needs the space reserved — see .docs-footer-nav. */
  --footer-link-h: 76px;
}

.docs-footer-nav {
  display: flex;
  gap: 16px;
  margin-top: 3rem;
  padding-top: 1.5rem;
  /* Shipped in the HTML by scripts/build-docs.py. The reservation stays:
   * 25px tall empty, 101px filled, so the document grew ~95px the
   * moment the script ran. Nothing visible sits below it, so this is not what
   * anyone SAW move — but a document that changes height after paint is what
   * makes a restored scroll position land somewhere other than where it was
   * left. Free to hold, so it is held. */
  min-height: var(--footer-link-h);
  box-sizing: content-box;
}

.docs-footer-link {
  display: flex;
  flex-direction: column;
  gap: 4px;
  text-decoration: none;
  padding: 12px 16px;
  border: 2px solid var(--ink);
  color: var(--ink);
  width: 250px;
  /* Stated, so the space the mount reserves above and the card that lands in it
     are the same number rather than two numbers that happen to agree today. */
  min-height: var(--footer-link-h);
  box-sizing: border-box;
  transition: transform 0.15s ease, box-shadow 0.15s ease;
}

.docs-footer-link:hover {
  color: white;
  background-color: var(--ink);
}

.docs-footer-next { margin-left: auto; text-align: right; }

.docs-footer-label {
  font-size: 11px;
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: 0.06em;
  color: var(--muted);
}

.docs-footer-title { font-size: 0.95rem; font-weight: 600; }

/* ── TOC (right column, populated from this page's own headings) ─── */

.docs-toc {
  grid-area: toc;
  /* Clears the one thing standing between the top of the row and the page's own
     h2: the gap above the content. Derived from the same token that gap uses, so
     the two columns cannot drift apart the next time it changes. Only the
     resting position — once the column sticks it uses `top` below. */
  margin-top: var(--docs-top-gap);
  position: sticky;
  /* Sticks exactly where it STARTED — level with the page's h2 — rather than
     riding up the moment you scroll. Same sum as its resting position, written
     from the same tokens so it cannot drift away from the margin-top above.
     --header-h and --subnav-h are both zero on the docs and stay in the sum
     because they are what a host with chrome above the content would set. */
  top: calc(var(--header-h) + var(--subnav-h) + var(--docs-top-gap)
            - var(--header-shift, 0px));
  align-self: start;
  max-height: calc(100vh - var(--header-h) - var(--subnav-h) - var(--docs-top-gap)
                   - 24px + var(--header-shift, 0px));
  overflow-y: auto;
  /* No divider. The column gap already separates the two, and a hairline rule
     alongside a page whose every other border is 2px ink read as a stray. */
  padding-left: 20px;
}

/* Fewer than two headings: docs.js leaves this empty rather than
 * building a table of contents with one entry in it. The column's own
 * width is a fixed 190px (not content-sized), so this doesn't collapse
 * the grid track — it just stops the empty border from floating next
 * to nothing. */
.docs-toc:empty { display: none; }

.docs-toc-title {
  font-size: 11px;
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: 0.08em;
  color: var(--muted);
  padding: 2px 0 8px;
}

/* A single-cell grid, not a block, so the label and its bold twin below can be
 * stacked in the same cell. See .docs-toc-label. */
.docs-toc-link {
  display: grid;
  padding: 4px 0 4px 12px;
  font-size: 13px;
  font-weight: 300;
  line-height: 1.4;
  color: var(--muted);
  text-decoration: none;
  border-left: 2px solid transparent;
  transition: color 0.1s ease, border-color 0.1s ease;
}

/* ---- The outline holds still while you read --------------------------------
 * Every link reserves the height its OWN BOLD FORM would need, at all times.
 *
 * The active entry goes from weight 300 to 600, and bold is wider. In a 190px
 * column that is enough to push a link that fitted on two lines onto three — it
 * gains a line, and every entry below it drops one. Scrolling /docs/sdk/ moved
 * ten of its twenty-six links by 18px each, and the movement tracks the reading
 * position, so the outline squirms exactly while you are looking at it.
 *
 * The twin is the fix: the same string, permanently at 600, permanently hidden,
 * in the same grid cell as the visible label. The cell is as tall as the taller
 * of the two, which is always the bold one — so becoming active changes weight
 * and nothing else. The height was already reserved.
 *
 * Hidden with `visibility`, not `opacity` or a clip: visibility:hidden still
 * takes part in layout (which is the entire point) and is removed from the
 * accessibility tree, so the outline is not read out twice.
 *
 * The cost is a few pixels of slack under the rare link whose bold form needs
 * the extra line — one of twenty-six on a dense page, none at all on most.
 * A little steady whitespace beats ten moving links.
 *
 * The other two active signals — ink colour and the brand-1 left edge — were
 * already free of this: the border is 2px transparent at rest and only changes
 * colour, so it reserves its own space by construction. Bold was the one
 * property that changed the box. Anything added to .active later has to clear
 * the same bar. */
.docs-toc-label { grid-area: 1 / 1; }

.docs-toc-link::before {
  content: attr(data-label);
  grid-area: 1 / 1;
  font-weight: 600;
  visibility: hidden;
}

.docs-toc-link:hover { color: var(--ink); }

.docs-toc-link.active {
  color: var(--ink);
  font-weight: 600;
  border-left-color: var(--brand-1);
}

.docs-toc-link.toc-h4 {
  padding-left: 24px;
  font-size: 12px;
}

/* ── Content typography ─────────────────────────────────────────── */

/* The headline face, same as the marketing page's. --display is defined in
   styles/global.css, and each docs page requests it across `wght@200..700` in
   its own  — the face is variable over that range, so every weight named
   below is a weight that actually renders. Ask for a single weight there and
   CSS font matching silently substitutes the nearest one it has, which reads as
   a rule that had no effect rather than as a missing file.
   700 is the default here; the rules below override it where the level wants a
   different weight, and each keeps its own size. */
.docs-content h1,
.docs-content h2,
.docs-content h3,
.docs-content h4 {
  font-family: var(--display);
  font-weight: 700;
}

/* The vertical rhythm is proportional to the hierarchy, and every heading sits
   FAR from what precedes it and CLOSE to what it introduces. That asymmetry is
   the whole of it: a heading equidistant between two paragraphs belongs to
   neither, and the page reads as one undifferentiated column.
   h2 carried no top margin at all, so a new section began against the last line
   of the previous one with only that paragraph's own gap between them. */
.docs-content h1 {
  font-size: 2rem;
  margin-bottom: 0.6rem;
  line-height: 1.2;
}

/* h2 and h3 share a weight, so the step between them is carried by size and by
   h2's rule alone. That is deliberate: at 2.2rem against 24px the size already
   separates them, and a weight change on top would make a section title shout
   twice. */
.docs-content h2 {
  font-size: 2.2rem;
  margin-top: 3.75rem;
  border-bottom: 2px solid var(--bg);
  font-weight: 500;
  /* Negative, because tracking drawn for reading sizes is loose at display
     sizes — the gaps scale with the type while the eye's tolerance does not, and
     the line drifts apart. Well past the marketing hero's -0.01em, because this
     sits at 500 where the hero sits at 700: thinner strokes leave more apparent
     air between letters at the same measured gap, so a heading set lighter needs
     pulling tighter, not looser. About 1.2px out of every gap at 2.2rem. */
  letter-spacing: -0.05em;
}

.docs-content h3 {
  font-size: 24px;
  margin-top: 4rem;
  margin-bottom: 0.75rem;
  font-weight: 500;
  letter-spacing: -0.075rem;;
}

.docs-content h4 {
  font-size: 1.02rem;
  margin-top: 1.9rem;
  margin-bottom: 0.45rem;
  color: var(--ink);
}

/* A page opening on a heading gets its air from .docs-main's padding, not from
   the heading as well — otherwise the first screen is mostly empty and every
   page starts lower than the sidebar beside it. */
.docs-content > :first-child { margin-top: 0; }

/* Anchor-jump offset so a TOC click lands the heading below the fixed navbar */
.docs-content h2,
.docs-content h3,
.docs-content h4 {
  /* An in-page anchor must land below the pinned bands, or the heading you
     jumped to is the one thing hidden behind them. */
  scroll-margin-top: calc(var(--header-h) + var(--subnav-h) + 20px);
}

.docs-content p {
  margin-bottom: 1.15rem;
}

/* Lists were left to the browser, so pages inlined their own margins to get a
   gap at all — the indent and the spacing ended up written per page, differently
   each time. Stated once here, they stop being every author's problem.
   Items get their own gap: a run of one-line bullets with none reads as a
   paragraph that happens to have dots. */
.docs-content ul,
.docs-content ol {
  margin: 0 0 1.25rem 1.25rem;
  padding-left: 0.75rem;
}
.docs-content li { margin-bottom: 0.45rem; }
.docs-content li:last-child { margin-bottom: 0; }
/* A nested list belongs to the item above it, not to the gap after it. */
.docs-content li > ul,
.docs-content li > ol { margin: 0.45rem 0 0 1rem; }

/* ── Code ────────────────────────────────────────────────────────── */

/* brand.css owns how inline code LOOKS — white fill, ink border, 14px, the
   system mono stack, `padding: 0 4px`. This rule adds the one thing the docs
   need on top of it and restates nothing.
   What used to be here was a second opinion, and every difference pushed the
   same way: weight 700, `padding: 2px 7px`, and Courier New. Bold monospace in
   a sentence stops being a token and becomes a shout, the fatter padding made
   every `--flag` a button, and Courier New is a different typeface from the one
   the rest of the page is set in. A token should be quiet enough to read a
   paragraph through. */
.docs-content code {
  /* INLINE code must be allowed to break. Docs prose is full of unbreakable
     tokens — `drift-slice--`, a fully-qualified path, an env var —
     and a run of characters with no space in it will not wrap on its own. One
     such token measured 465px inside a 390px viewport and pushed the DOCUMENT
     to 486px, so every page on the docs site scrolled sideways on a phone. The
     page moving is far worse than a token breaking mid-word.

     `pre code` is untouched and must stay that way: it sets white-space:pre and
     its parent already scrolls (overflow-x:auto above), which is the right
     behaviour for a block you are meant to copy verbatim — a wrapped shell
     command is a command that no longer works when pasted.

     Not in a media query on purpose: overflow-wrap only acts when the token
     would otherwise overflow, so this is inert at desktop widths and also fixes
     a narrow browser window. */
  overflow-wrap: anywhere;
}

/* No font-family: every block here is 
, so the inner element takes
   brand.css's mono stack and the blocks are set in the same face as the inline
   tokens. Naming a second one here is how they drifted apart. */
.docs-content pre {
  background: #1e1e1e;
  color: #dadada;
  border: 2px solid var(--ink);
  padding: 16px 20px;
  font-size: 13px;
  line-height: 1.4;
  overflow-x: auto;
  /* More than a paragraph's gap. A code block is a set piece the eye stops at,
     and at a paragraph's spacing it reads as another line of the prose rather
     than as the thing the prose was leading to. */
  margin: 1.75rem 0;
}

.docs-content pre code {
  background: none;
  border: none;
  padding: 0;
  font-size: inherit;
  font-weight: normal;
  white-space: pre;
  color: inherit;
}

/* ── A single command is a key you press ─────────────────────────────────────
 * A one-line shell command is the one code block a reader does not read — they
 * take it. So it stops being a window onto a terminal and becomes a control: a
 * white card on the grey desk, ink border, ink shadow, and a click that copies
 * it. The dark fill belongs to blocks you read; this is a thing you press, and
 * it wears the same palette as every other pressable object on the platform.
 *
 * Raised at rest, straight from HQ's epic latch: it starts UP, and pressing is
 * what puts it down. That is why there is NO hover raise — raised-at-rest has
 * exactly two positions, up and pressed, and lifting it further on hover
 * borrows the gesture belonging to flat-at-rest controls. Hover brightens the
 * hint instead, which says "this responds" without spending the position.
 *
 * docs.js decides which blocks qualify and builds the element; see the
 * predicate there for what counts as a command. */
.docs-content .docs-cmd {
  position: relative;
  display: block;
  box-sizing: border-box;
  text-align: left;
  /* The block's own margin, so swapping a 
 for one of these does not move
     the paragraphs around it. */
  margin: 1.75rem 0;
  padding: 12px 76px 12px 16px;
  background: var(--panel);
  color: var(--ink);
  border: 2px solid var(--ink);
  border-radius: 0;
  font-size: 13px;
  line-height: 1.4;
  cursor: pointer;
  /* Already up, waiting to be pushed. */
  transform: translateY(-3px);
  box-shadow: 0 4px 0 var(--ink);
  /* Springy on release, at the latch's 160ms rather than the marketing site's
     320ms: this sits inside prose, and the full overshoot reads as sluggish
     next to text. */
  transition: transform .16s cubic-bezier(.34, 1.56, .64, 1),
              box-shadow .16s cubic-bezier(.34, 1.56, .64, 1);
}
.docs-content .docs-cmd:active {
  transform: translateY(0);
  box-shadow: 0 0 0 var(--ink);
}
.docs-content .docs-cmd:focus-visible {
  outline: 2px solid var(--brand-2);
  outline-offset: 2px;
}
/* brand.css paints every  as a chip. Inside the key that would be a grey
   box around the command, so the chip is cleared here exactly as it is inside a
   
. */
.docs-content .docs-cmd code {
  background: none;
  border: none;
  padding: 0;
  font-size: inherit;
  font-weight: inherit;
  color: inherit;
  white-space: pre;
}
/* The affordance in words. The raise says "pressable"; this says what pressing
   does, because copy is not the only thing a button could mean. */
.docs-content .docs-cmd::after {
  content: "copy";
  position: absolute;
  top: 50%;
  right: 14px;
  transform: translateY(-50%);
  font-size: 10px;
  font-weight: 600;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  color: var(--muted);
  transition: color .1s ease;
}
.docs-content .docs-cmd:hover::after { color: var(--ink); }
.docs-content .docs-cmd[data-copied="yes"]::after { content: "copied"; color: var(--brand-3); }
.docs-content .docs-cmd[data-copied="no"]::after  { content: "failed"; color: var(--brand-1); }

/* Syntax highlighting (VS Code Dark+) */
.kw { color: #569CD6; }   /* keywords */
.str { color: #CE9178; }  /* strings */
.cmt { color: #6A9955; }  /* comments */
.fn { color: #DCDCAA; }   /* functions */
.num { color: #B5CEA8; }  /* numbers */
.ctrl { color: #C586C0; } /* control flow */

/* ── Cards ───────────────────────────────────────────────────────── */


.docs-card-grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 12px;
  margin: 1rem 0;
}

/* One card per row on a phone. `repeat(3, 1fr)` is a fixed count, not a
   responsive one — 1fr floors at min-content, so three cards plus .btn-docs's
   own `margin-right: 1rem` pushed the DOCUMENT to 470px in a 390px viewport and
   /docs/ was the last page still scrolling sideways. The margin goes too: it is
   spacing between cards in a row, and there is no row any more. */
@media (max-width: 640px) {
  .docs-card-grid { grid-template-columns: 1fr; }
}

/* ── The list: contents of a box ─────────────────────────────────────────────
 *
 * The file tree's shape, applied to prose. A filled ink bar NAMES the set and
 * the items are its contents, indented beneath it as quiet cards — the same
 * argument a folder makes: containment carries the meaning, so nothing has to
 * be framed and no marker has to point.
 *
 * The bar is the page's own 
, styled, not a second element carrying the
 * same words. That matters twice over: the heading stays in the document
 * outline, and docs.js keeps building a table-of-contents entry from it. A bar
 * that replaced the heading would have silently cost this page its outline —
 * and with only one h3 left, docs.js drops the TOC entirely.
 *
 *   
What you get out of the box

 *