@codenhub/styles 0.5.0 → 0.6.0

package/dist/tw/utilities/content.css

@@ -1,29 +1,53 @@
 @reference "../box.css";
 
+/* A scroll box clips whatever paints outside it, and `overflow-x` takes the
+   vertical overflow with it, so an aesthetic's halo around the table -- cyber's
+   glow -- would be cut flush on every side. The wrapper makes room for the halo
+   inside itself and gives the same room back outside, so the table sits where
+   it does and only the scroll box grows. Zero wherever no halo is drawn. The
+   cost, under a halo: the wrapper reaches that far past its parent, which shows
+   only where the parent is flush with the viewport. Vertical margins still add
+   up to the same gap when they collapse with a sibling's, since the negative
+   one is paid back by the padding.
+
+   It reads the halo from its own scope, so an aesthetic class on the table
+   alone gives it nothing to make room for: the class belongs on the wrapper or
+   an ancestor, as `content-and-layout.md` says. A parent cannot read a child's
+   tokens, and reaching down with `:has()` would name an aesthetic here. */
 @utility table-wrap {
-  @apply w-full overflow-x-auto;
+  @apply overflow-x-auto;
+
+  --_table-wrap-bleed: calc(var(--ui-halo-blur, 0px) + var(--ui-halo-spread, 0px));
+
+  box-sizing: border-box;
+  width: calc(100% + var(--_table-wrap-bleed) * 2);
+  margin: calc(var(--_table-wrap-bleed) * -1);
+  padding: var(--_table-wrap-bleed);
 }
 
 /* The one component that takes the frame of `box` and not the whole of it. The
-   border, the radius and the clip come from the box; the head tone, the cell
-   rules and the row hover are private tokens, because none of the three axes has
-   a vocabulary for the inside of a table.
-
-   Its `overflow: hidden` is what keeps `border-separate` corners inside the
-   radius, and it does not compose with an aesthetic's `clip-path`: where both
-   apply, the clip wins and the corners square off. Recorded in `registry.json`
-   beside the decision. */
+   border and the plate come from the box, and the corner is a surface's,
+   because a table is a pane of content rather than a control; the head tone,
+   the cell rules and the row hover are private tokens, because none of the
+   three axes has a vocabulary for the inside of a table.
+
+   Nothing here clips the table. Chromium and WebKit lay a `<caption>` out
+   inside the table's own box while painting the plate and the frame around the
+   rows alone, so anything that acts on the whole box -- an `overflow` clip, a
+   `clip-path`, a backdrop filter, a positioned layer -- spans the caption: an
+   `overflow: hidden` would round the caption's corners instead of the head's
+   and cut the caption's first letter. The corner cells take the table's corners
+   instead (below), which every engine draws on the rows. Recorded in
+   `registry.json` beside the decision. */
 @utility data-table {
-  @apply box text-body w-full border-separate text-left;
+  @apply box text-body w-full border-separate text-start;
 
   --_d-fill: 12%;
   --_d-fg-on-fill: 0%;
   /* Edgeless, so the frame is asked for rather than inherited from a default
-     nobody can see in their own markup. Published `edged`, `.edged` on a table
-     computed exactly what no class computed -- a switch that could not move
-     anything -- and the frame arrived because of a line in `registry.json`.
-     `.edged` draws it now, and the two boundaries a table keeps whatever else it
-     draws mean a frameless one still reads as a table. */
+     nobody can see in their own markup. `.edged` draws it, and the two
+     boundaries a table keeps whatever else it draws mean a frameless one still
+     reads as a table. */
   --_d-border: 0%;
   --_d-elevation: 0;
 
@@ -31,30 +55,25 @@
      other and a neutral table head is otherwise a slab of the page's ink with
      ink printed on it. */
   --table-fill: calc(min(var(--ui-fill, var(--_d-fill)), var(--intent-fill-max, 100%)) * var(--ui-bg-alpha, 1));
-  /* The head's plate is the tint, so a table carrying no fill has no head plate.
-     `.ghost` means no tint here the way it means no fill everywhere else, and a
-     ghost table is boundaries and type and nothing else -- which is what `.ghost`
-     is for on this component, since the published resting fill is `soft`.
-
-     Zero stays zero, and nothing past it saturates the same way any more. A
-     `* 100` multiplier used to put every non-zero fill over the `min(100%, ...)`
-     ceiling in one step -- `.soft`'s 12% and `.solid`'s 100% both landed on a
-     fully opaque plate, so the only thing left to tell them apart was how much
-     `--intent-color` got mixed onto it after (`--table-fill`, 12% vs 20% capped),
-     a difference too small to read as the volume-level step presentation
-     promises everywhere else in the model. `* 5` keeps zero at zero and a
-     `.solid`'s 100% raw fill still clears the ceiling -- the same fully opaque
-     head it always drew -- but stops `.soft`'s 12% short, at 60%: a visibly
-     lighter, partly-page-showing-through plate instead of a second opaque one,
-     which is what makes the two presentations separate again.
-
-     It reads `--ui-fill` rather than `--table-fill` because that is the question
-     being asked: what the presentation wanted, not what the intent cap and an
-     aesthetic's alpha left of it. A glass `.soft` table still wants its head
-     plate, and neutral's 20% cap has no bearing on whether there is one. Reading
-     the raw class value also keeps the expression a `calc()` over one `var()`
-     rather than over `--table-fill`'s own `calc()`/`min()` chain, which matters
-     for the reason `--table-rule-plated` below records. */
+  /* The head's plate is the tint, so a table carrying no fill has no head
+     plate. `.ghost` means no tint here the way it means no fill everywhere
+     else, and a ghost table is boundaries and type and nothing else -- which is
+     what `.ghost` is for on this component, since the published resting fill is
+     `soft`.
+
+     Zero stays zero, and nothing past it saturates: `* 5` keeps zero at zero,
+     lets `.solid`'s 100% clear the `min(100%, ...)` ceiling to a fully opaque
+     head, and stops `.soft`'s 12% short at 60%, a visibly lighter plate, so the
+     two presentations separate. A larger multiplier lands both on a fully
+     opaque plate, leaving only the small intent mix to tell them apart.
+
+     It reads `--ui-fill` rather than `--table-fill` because the question is
+     what the presentation wanted, not what the intent cap and an aesthetic's
+     alpha left of it: a glass `.soft` table still wants its head plate, and
+     neutral's 20% cap has no bearing on whether there is one. Reading the raw
+     class value also keeps the expression a `calc()` over one `var()` rather
+     than over `--table-fill`'s own `calc()`/`min()` chain, which matters for
+     the reason `--table-rule-plated` below records. */
   --table-ground: min(100%, calc(var(--ui-fill, var(--_d-fill)) * 5));
   --table-head-plate: color-mix(in oklab, var(--intent-subtle) var(--table-ground), transparent);
   --table-head-bg: color-mix(in oklab, var(--intent-color) var(--table-fill), var(--table-head-plate));
@@ -62,147 +81,201 @@
 
   /* Untinted rather than mixed, the same call `.card.soft` makes: 12% ink onto
      `--intent-subtle` still reads as `.solid` on neutral, since neutral's ink
-     and ground are both on the same greyscale axis and no ramp over that ground
-     changes it much. A head has no hover or interaction state to reveal a tint
-     into the way a card does on `.interactive`/`.hoverable`, so there is no
-     second state to move a mechanism to -- `.soft` is `--color-foreground`,
-     flat, always, for every intent. That mutes a colored `.success`/`.destructive`
-     head at rest the way it mutes a non-interactive `.card.soft`; accepted for
-     the same reason, not solved a different way.
-
-     The table's own base plate rests the same way, for a reason the head fix
-     alone did not cover: a `.soft` head landing at `--color-foreground` (five
-     units off the page) sitting directly above a body still carrying the
-     ordinary 12% tint (twenty-four units past the head) read backwards -- the
-     seam that should read as one table read as the head belonging to the page
-     and the body being the odd one out. `--_fill-cap` is `box.css`'s override
-     slot (the same one `.card.soft` uses, for the reasons the comment there
-     gives), and `--_d-ground` is box's own private ground
-     slot, unclaimed here until now -- both land on the table's own element,
-     same as `--table-fill`/`--table-head-plate` do, so nothing here fights
-     `.soft` for `--ui-fill` either. `.ghost` is left at box's default
-     (`--_d-ground: transparent`), so it stays the fully bare boundaries-only
-     table it already was -- `.soft` now differs from it by keeping an opaque,
-     untinted plate and a head label strip, not by how much ink is in either.
+     and ground are both on the same greyscale axis. A head has no hover or
+     interaction state to reveal a tint into the way a card does, so `.soft` is
+     `--color-foreground`, flat, always, for every intent. That mutes a coloured
+     `.success`/`.destructive` head at rest the way it mutes a non-interactive
+     `.card.soft`; accepted for the same reason.
+
+     The table's own base plate rests the same way: a `.soft` head at
+     `--color-foreground` (five units off the page) above a body carrying the
+     ordinary 12% tint (twenty-four units past the head) reads backwards, as
+     though the head belonged to the page and the body were the odd one out.
+     `--_fill-cap` is `box.css`'s override slot (the one `.card.soft` uses) and
+     `--_d-ground` is box's private ground slot; both land on the table's own
+     element, so nothing here fights `.soft` for `--ui-fill`. `.ghost` is left
+     at box's default (`--_d-ground: transparent`), so it stays the fully bare
+     boundaries-only table; `.soft` differs from it by keeping an opaque,
+     untinted plate and a head label strip.
 
      `:not(.solid, .ghost)` rather than `.soft`: the published resting fill is
-     `soft`, so a bare `<table class="data-table">` -- the members table in
-     `playground/app-shell/`, with no fill class at all -- is the common case
-     this has to reach, not the edge case. `.soft` alone would miss every table
-     that gets soft by doing nothing. */
+     `soft`, so a bare `<table class="data-table">` with no fill class at all is
+     the common case this has to reach. */
   &:not(.solid, .ghost) {
     --table-fill: 0%;
-    --table-head-plate: var(--color-foreground);
+    --table-head-plate: var(--table-ground-plate);
     --_fill-cap: 0%;
-    --_d-ground: var(--color-foreground);
+    --_d-ground: var(--table-ground-plate);
+
+    /* A table is a pane of content, so under an aesthetic whose surfaces are
+       glass it is glass too: the plate is the aesthetic's surface ground when
+       one is named, and the blur behind it is the one surfaces take. Head and
+       body share the plate, as they do on the page. Only this arm reads them:
+       a `.solid` table is opaque, like every `.solid`, and a `.ghost` one is
+       boundaries and type with nothing behind them to blur. */
+    --table-ground-plate: var(--ui-surface-ground, var(--color-foreground));
+
+    -webkit-backdrop-filter: var(--ui-backdrop, none);
+    backdrop-filter: var(--ui-backdrop, none);
   }
 
   /* How much rule there is between body rows, and none unless asked for. Ruling
-     every row is a style choice rather than part of what a table is, and tying it
-     to the edge axis made it arrive by implication instead: a table drew rules
-     because its published edge default happened to be `edged`, which is a fact
-     about the registry rather than anything the markup says. A consumer reading
-     their own HTML could not tell whether they had asked for rules.
-
-     `.ruled` is that ask and `.ruleless` is its opposite, with `--ui-rule` behind
-     both -- so a consumer who wants a whole region ruled, or a whole region bare,
-     sets the token on a container instead of classing every table.
+     every row is a style choice rather than part of what a table is, so it is
+     not tied to the edge axis: `.ruled` asks for it, `.ruleless` is its
+     opposite, and `--ui-rule` is behind both, so a consumer who wants a whole
+     region ruled, or a whole region bare, sets the token on a container instead
+     of classing every table.
 
      One token covers three positions because the two places that read it take
      different fallbacks. Unset, each site answers for itself: no rules between
      rows, but the boundaries below still drawn. Set, the answer is the same at
-     both. So `.ruled` writes 100% and gets rules everywhere, `.ruleless` writes 0%
-     and gets a table with no lines in it at all, and a table nobody classed sits
-     between them. A second token would have said the same thing with more parts,
-     and would have let the two drift. */
+     both. So `.ruled` writes 100% and gets rules everywhere, `.ruleless` writes
+     0% and gets a table with no lines in it at all, and a table nobody classed
+     sits between them. */
   --table-rule-amount: var(--ui-rule, 0%);
   --table-boundary-amount: var(--ui-rule, 100%);
   /* What the rule is drawn in, which is not the same tone at every fill.
-     `.ghost` and `.soft` keep `--intent-border` -- the slot an aesthetic restates
-     through `--ui-ink` -- because at those fills the plate has not swallowed it.
-     `.solid` is where it has: at a full fill `--intent-border` *is* the plate for
-     every intent, and at neutral's capped fill it is a near shade of the same
-     grey, so the rule the rows are separated by disappears exactly where the
-     plate is busiest.
-
-     The filled case draws in `currentColor` instead, at a fifth. That is the ink
-     the cell is already printing -- `--table-head-fg` on a head, `box`'s own
-     `--_fg` in the body -- so it reads on a light plate and a dark one without a
-     per-intent branch, and it lands *over* the plate because a translucent border
-     composites onto the background the element already painted.
-
-     Naming the ink rather than composing it is also what keeps this expression
-     cheap, and cheap is a requirement here rather than a preference. Written as
-     `color-mix(--table-head-fg 20%, --_bg)` the rule expanded, through four levels
-     of substitution, into a `color-mix()` over two more `color-mix()`es over a
-     `min()`/`max()`/`calc()` chain -- and every `th` and `td` on a page resolves it.
-     WebKit's renderer crashed outright on the two routes that draw tables, taking
-     22 specs across four files with it, while Chromium and Firefox rendered them
-     correctly. Neither the depth nor the table alone did it: bisected, the new
-     tokens were fine until the cells consumed them.
-
-     `currentColor` and `transparent` are leaves the engine has resolved already,
-     which is what takes the expression back down to something every engine can
-     carry. `--table-row-hover` below is written the same way, for the same
-     reason. */
+     `.ghost` and `.soft` keep `--intent-border` -- the slot an aesthetic
+     restates through `--ui-ink` -- because at those fills the plate has not
+     swallowed it. `.solid` is where it has: at a full fill `--intent-border`
+     *is* the plate for every intent, and at neutral's capped fill it is a near
+     shade of the same grey, so the row rule disappears exactly where the plate
+     is busiest.
+
+     The filled case draws in `currentColor` at a fifth instead: the ink the
+     cell is already printing (`--table-head-fg` on a head, `box`'s own `--_fg`
+     in the body), so it reads on a light plate and a dark one without a
+     per-intent branch, and it lands *over* the plate because a translucent
+     border composites onto the background the element already painted.
+
+     Naming the ink rather than composing it also keeps this expression cheap,
+     which is a requirement: every `th` and `td` on a page resolves it, and
+     written as `color-mix(--table-head-fg 20%, --_bg)` it expands, through four
+     levels of substitution, into a `color-mix()` over two more `color-mix()`es
+     over a `min()`/`max()`/`calc()` chain, which crashes WebKit's renderer on
+     the routes that draw tables. `currentColor` and `transparent` are leaves
+     the engine has already resolved, which takes the expression back down to
+     something every engine can carry. `--table-row-hover` below is written the
+     same way, for the same reason. */
   --table-rule-plated: color-mix(in oklab, currentColor 20%, transparent);
   --table-rule-tone: color-mix(in oklab, var(--table-rule-plated) var(--ui-fill, var(--_d-fill)), var(--intent-border));
   --table-rule: color-mix(in oklab, var(--table-rule-tone) var(--table-rule-amount), transparent);
   --table-boundary: color-mix(in oklab, var(--table-rule-tone) var(--table-boundary-amount), transparent);
   /* A hovered row is a step from the table it is in, not from a tone the page
-     happens to own. Mixed into `--color-foreground` it was neither: a solid
-     table paints its body with the intent, so a primary table in dark theme is
-     white and its hovered row came out near-black -- a dark band across a light
-     table. Painting a translucent step instead makes it relative at every fill,
-     the way `box-hover` is: the row composites onto whatever plate the table
-     drew, so a filled table shifts within its own colour, a soft one deepens its
-     tint, and a ghost one picks up a faint wash of the page.
-
-     Which tone it steps toward has to move with the fill as well. On a bare or
-     tinted plate that is `--intent-hover`, the deepening every other component
-     gets. On a filled one it cannot be: `--intent-hover` is
-     `mix(--intent-color 82%, --intent-strong)`, which is very nearly the colour
-     the plate is already painted, so a step toward it is no step. Measured, a
-     solid success table moved 1.00:1 in light and a solid destructive one
-     1.008:1 -- the feedback was declared and invisible. A filled plate steps
-     toward `currentColor` instead, which is the ink that plate already carries
-     and therefore always contrasts with it.
+     happens to own. A translucent step is relative at every fill, the way
+     `box-hover` is: the row composites onto whatever plate the table drew, so a
+     filled table shifts within its own colour, a soft one deepens its tint, and
+     a ghost one picks up a faint wash of the page. (Mixed into
+     `--color-foreground`, a solid primary table in dark theme would hover to
+     near-black, a dark band across a light table.)
+
+     Which tone it steps toward moves with the fill. On a bare or tinted plate
+     that is `--intent-hover`, the deepening every other component gets. On a
+     filled one it cannot be: `--intent-hover` is `mix(--intent-color 82%,
+     --intent-strong)`, very nearly the colour the plate is already painted, so
+     a step toward it is no step (a solid success table moves 1.00:1 in light).
+     A filled plate steps toward `currentColor` instead, the ink that plate
+     already carries and therefore always contrasts with it.
 
      Both ends are leaves, and the step lands on `transparent` rather than on
-     `--_bg`, for the reason `--table-rule-plated` above gives: compositing is
-     what the browser does with a translucent background anyway, so naming `--_bg`
-     buys the same colour for two more levels of substitution. */
+     `--_bg`, for the reason `--table-rule-plated` above gives. */
   --table-hover-tone: color-mix(in oklab, currentColor var(--ui-fill, var(--_d-fill)), var(--intent-hover));
   --table-row-hover: color-mix(in oklab, var(--table-hover-tone) 12%, transparent);
 
   border-spacing: 0;
-  overflow: hidden;
+
+  /* A surface's corner, as `surface` computes it: a table sits beside cards and
+     panels as a pane, and under `.cyber` it took the controls' diagonal while
+     every pane around it cut the other one. */
+  --_corner-surface: calc(var(--ui-corner-surface, var(--radius-surface)) * var(--_scale));
+  border-radius: var(
+    --ui-radius-surface,
+    calc(var(--_corner-surface) * var(--ui-corner-tl, 1)) calc(var(--_corner-surface) * var(--ui-corner-tr, 1))
+      calc(var(--_corner-surface) * var(--ui-corner-br, 1)) calc(var(--_corner-surface) * var(--ui-corner-bl, 1))
+  );
+  /* No silhouette clip either, for the caption's sake: `.pixel`'s stepped clip
+     cut the caption's corners and left the head's square. A pixel table is
+     square, which is the chip answer that aesthetic already gives. */
+  clip-path: none;
+
+  /* The corners pass down to the cells that sit in them. Each section and row
+     inherits the table's four corners -- a radius does not apply to either, but
+     it still computes and inherits -- and each corner cell takes only its own
+     corner, as a longhand, so an elliptical or bevelled corner arrives whole.
+     The first row is the head's when there is one and the first body's when
+     not, and the last row likewise the foot's or the last body's; a caption
+     and a `colgroup` are skipped. A cell spanning rows into a corner is not
+     reached, and a percentage corner resolves against the cell. */
+  & > :is(thead, tbody, tfoot),
+  & > :is(thead, tbody, tfoot) > tr {
+    border-radius: inherit;
+    corner-shape: inherit;
+  }
+
+  & > :is(thead, tbody, tfoot) > tr > * {
+    corner-shape: inherit;
+  }
+
+  & > thead > tr:first-child,
+  &:not(:has(> thead)) > tbody:first-of-type > tr:first-child {
+    & > :first-child {
+      border-start-start-radius: inherit;
+    }
+
+    & > :last-child {
+      border-start-end-radius: inherit;
+    }
+  }
+
+  & > tfoot > tr:last-child,
+  &:not(:has(> tfoot)) > tbody:last-of-type > tr:last-child {
+    & > :first-child {
+      border-end-start-radius: inherit;
+    }
+
+    & > :last-child {
+      border-end-end-radius: inherit;
+    }
+  }
 
   & caption {
-    @apply text-label text-text-secondary pb-2 text-left;
+    @apply text-label text-text-secondary pb-2 text-start;
   }
 
+  /* The head's plate is painted on its cells rather than on the section, so the
+     corner cells round it: a section's background ignores the cells' corners. */
   & thead,
   & tfoot {
-    background-color: var(--table-head-bg);
     color: var(--table-head-fg);
   }
 
+  & :is(thead, tfoot) > tr > * {
+    background-color: var(--table-head-bg);
+  }
+
   /* Every cell carries the hairline; what varies is whether it is painted. The
-     width tracks the aesthetic's own line weight (`--_width`, the same token
-     `box` uses for the table's outer frame) rather than a fixed `1px`, so a
-     row rule reads as the same material as the boundary around it instead of
-     as a leftover default under an aesthetic whose whole point is thickness --
-     `.chunky-tile`'s 2px frame used to sit over a 1px row rule, which read as
-     unstyled rather than as a deliberate, quieter line. It still survives a
-     fill that would otherwise paint over it, because color and width are
-     independent here: `.ruleless` zeroes the color, not this. */
+     width tracks the aesthetic's own line weight rather than a fixed `1px`, so
+     a row rule reads as the same material as the boundary around it. It
+     survives a fill that would otherwise paint over it, because color and width
+     are independent here: `.ruleless` zeroes the color, not this.
+
+     The width is the aesthetic's, not `box`'s `--_width`: that one is capped by
+     `--ui-border-max`, which `.pixel` sets to zero because its frame is an
+     inset ring a clip cannot cut. A rule is not a frame and nothing clips a
+     table, so under pixel the capped width would draw no rule at all -- no line
+     under the head or above the foot, and `.ruled` would change nothing. A
+     divider reads the same uncapped width for the same reason.
+
+     Alignment is logical and stated on the cells, not only on the table: a
+     `th` centers unless its parent names an alignment, and `start` is the
+     initial value, which counts as naming none. */
+  --_table-rule-width: var(--ui-border-width, var(--border-width));
   & th,
   & td {
-    @apply px-4 py-3 align-top;
+    @apply px-4 py-3 text-start align-top;
 
     border-bottom-style: var(--ui-rule-style, var(--ui-line-style, solid));
-    border-bottom-width: var(--_width);
+    border-bottom-width: var(--_table-rule-width);
     border-color: var(--table-rule);
   }
 
@@ -221,7 +294,7 @@
 
   & tfoot tr:first-child > * {
     border-top-style: var(--ui-rule-style, var(--ui-line-style, solid));
-    border-top-width: var(--_width);
+    border-top-width: var(--_table-rule-width);
     border-top-color: var(--table-boundary);
   }
 
@@ -243,57 +316,49 @@
   /* Rows deliberately inherit the table's intent instead of resetting it, so a
      `.data-table.success` tints its own rows. A `<tr class="warning">` still wins,
      because an intent class on the element beats an inherited value. */
-  & tbody tr {
+  & tbody tr > * {
     transition: background-color var(--motion-duration-fast) var(--motion-ease);
   }
 
-  & tbody tr:hover {
+  /* On the cells, for the reason the head's plate is: a hovered last row keeps
+     the table's bottom corners. */
+  & tbody tr:hover > * {
     background-color: var(--table-row-hover);
   }
 
   /* The rule comes off the row that is visually last, which is not always the
-     last row of the body. Written as `tbody tr:last-child` it came off the body's
-     last row unconditionally, so a table with a footer lost the one rule that
-     separates the two -- the summary ran straight on from the rows it summarises --
-     while the footer kept a bottom rule of its own, drawing a hairline immediately
-     inside the frame. A missing line where one belongs and a doubled one where it
-     does not, from the same declaration.
+     last row of the body. `tbody tr:last-child` would remove the body's last
+     row rule unconditionally, so a table with a footer would lose the one rule
+     that separates the two while the footer kept a bottom rule of its own,
+     drawing a hairline immediately inside the frame.
 
      Both selectors are `:last-child` on the section, so whichever section the
-     markup puts last is the one that loses its rule. That covers a footer written
-     before the body, which HTML still allows, and multiple bodies, where only the
-     last one ends the table.
-
-     It went unseen because it was invisible until this release: `thead` and
-     `tfoot` shared an unconditional `--intent-subtle` plate, so the footer was a
-     band and the band did the separating. `.ghost` dropping that plate is what
-     left the rule doing the job alone. */
+     markup puts last is the one that loses its rule. That covers a footer
+     written before the body, which HTML allows, and multiple bodies, where only
+     the last one ends the table. `.ghost` drops the head and foot plate, which
+     leaves this rule doing the separating alone. */
   & tbody:last-child tr:last-child > *,
   & tfoot:last-child tr:last-child > * {
     @apply border-b-0;
   }
 }
 
-/* Three components rest on a ground rather than on nothing: a key cap, an inline
-   code chip and a code block are each a quiet tinted plate at rest, and that tone
-   is `--intent-subtle` rather than a fill of the component's own intent.
-
-   All three rest at `soft`, and `.ghost` is published as unsupported on them.
-   The ground is what makes a chip a chip, and `.ghost` asks for no fill while
-   the ground stays -- so on these three it drew the plate anyway and meant
-   nothing, which is the opposite of what it means everywhere else. Worse, at
-   zero fill the plate is `--intent-subtle` alone, and that slot is a near-page
-   tint: measured on the light page, a ghost `code` chip was `#e5e5e5` for both
-   neutral and primary, and `#f5f5f5` for secondary at 1.04:1 against a `#fafafa`
-   page. A class that renders four intents as the same invisible chip is not a
-   variation. Resting at `soft` puts a real 12% of the intent over the ground, so
-   the plate is a step past the page and the intents separate.
-
-   Each used to restate its foreground too, because `box` mixed toward
-   `--intent-color` -- the tone meant to sit *on* a page rather than on a tint of
-   itself, and amber-600 on amber-100 is a smudge. `box` now mixes toward
-   `--intent-strong`, which is what these three were reaching for, so the three
-   copies are gone and the ground is the only thing left to declare. */
+/* Three components rest on a ground rather than on nothing: a key cap, an
+   inline code chip and a code block are each a quiet tinted plate at rest, and
+   that tone is `--intent-subtle` rather than a fill of the component's own
+   intent.
+
+   All three rest at `soft`, and `.ghost` is published as unsupported on them:
+   the ground draws the plate whatever the fill says, so `.ghost` would draw it
+   anyway and mean nothing, and at zero fill the plate is `--intent-subtle`
+   alone, a near-page tint that renders four intents as the same invisible chip
+   (`#e5e5e5` for neutral and primary on the light page). Resting at `soft` puts
+   a real 12% of the intent over the ground, so the plate is a step past the
+   page and the intents separate.
+
+   The foreground is `box`'s, which mixes toward `--intent-strong`, the tone
+   meant to sit on a page rather than on a tint of itself, so the ground is the
+   only thing left to declare. */
 /* Neutral, for the same reason `.panel`'s own carve-out is: 12% of
    `--color-text` mixed onto `--intent-subtle` (`--color-surface` for
    neutral) reads as an assertive slab rather than a quiet chip -- measured,
@@ -376,7 +441,7 @@
 
    The bar is twice the line width the aesthetic asks for, plus a pixel, which is
    this component's own choice about what a quotation looks like rather than a
-   scale applied to an edge -- there is no such scale any more. The constant is
+   scale applied to an edge. The constant is
    what makes the bar read as a bar at the default hairline: doubling 1px gives
    2px, and a quotation mark needs more presence than a table rule. */
 @utility quote {
@@ -389,22 +454,27 @@
      `--ui-bg-alpha` thins it. */
   --quote-capped: min(var(--ui-fill, var(--_d-fill)), var(--intent-fill-max, 100%));
   --quote-fill: calc(var(--quote-capped) * var(--ui-bg-alpha, 1));
-  --quote-bg: color-mix(in oklab, var(--intent-color) var(--quote-fill), transparent);
+  /* `box`'s `--_plate`: a fill the intent's cap stopped short rests on the page
+     background, so a neutral `.solid` quotation is a plate rather than a tint
+     of whatever is behind it. */
+  --quote-plate: clamp(0%, calc((var(--ui-fill, var(--_d-fill)) - var(--quote-capped)) * 1000), 100%);
+  --quote-bg: color-mix(
+    in oklab,
+    var(--intent-color) var(--quote-fill),
+    color-mix(in oklab, var(--color-background) var(--quote-plate), transparent)
+  );
   /* The same edge blend `box` draws, in the same order and for the same reason:
      the blend is the line's colour, and how much line there is comes after it.
-     Written the other way round -- how much line, then blend the fill into it --
-     `.edgeless` lands on the fill colour rather than on nothing, and the border
-     box paints that over the fill it already drew, so a quotation that asked for
-     no bar got a bar of two coats of its own tint.
-
-     It also fades toward `transparent` rather than toward the plate, as `box`'s
-     does: the plate runs under the bar, so a bar blended toward it painted a
-     translucent plate twice and drew a darker stripe on a neutral `.solid`
-     quotation.
-
-     That this had to be fixed three times is the cost of a quotation drawing
-     its own edge instead of taking `box`'s. Recorded in `registry.json` beside
-     the decision to compose none of `box`. */
+     Written the other way round, `.edgeless` lands on the fill colour rather
+     than on nothing, and the border box paints that over the fill it already
+     drew. It also fades toward `transparent` rather than toward the plate, as
+     `box`'s does: the plate runs under the bar, so a bar blended toward it
+     would paint a translucent plate twice and draw a darker stripe on a neutral
+     `.solid` quotation.
+
+     A quotation draws its own edge instead of taking `box`'s, so an edge change
+     is made in `box`, `.quote`, and `.progress`. Recorded in `registry.json`
+     beside the decision to compose none of `box`. */
   --quote-line: color-mix(in oklab, transparent var(--ui-fill, var(--_d-fill)), var(--intent-border));
   --quote-edge: color-mix(in oklab, var(--quote-line) var(--ui-border, var(--_d-border)), transparent);
   --quote-width: calc(var(--ui-border-width, var(--border-width)) * 2 + 1px);
@@ -414,13 +484,12 @@
   background-color: var(--quote-bg);
   border-inline-start-color: var(--quote-edge);
   border-inline-start-width: var(--quote-width);
-  /* The ink is gated by the plate, not tied to the fill: `--ui-fg-on-fill` is the
-     ceiling, and the contrast tone only ramps in past a half fill, reaching full
-     at a full fill. Below that the ink stays `--intent-strong`, the tone chosen
-     to read on the page. This is `box`'s `--_on-fill` exactly -- `min(asked,
-     --intent-fill-max)` read plausibly and was wrong at the bottom of the range,
-     printing a capped-neutral `.solid` quote at ~6.6:1 where the ramp gives
-     ~11:1, and this renderer has to agree with `box`. */
+  /* The ink is gated by the plate, not tied to the fill: `--ui-fg-on-fill` is
+     the ceiling, and the contrast tone only ramps in past a half fill, reaching
+     full at a full fill. Below that the ink stays `--intent-strong`, the tone
+     chosen to read on the page. This is `box`'s `--_on-fill` exactly, and this
+     renderer has to agree with it: a fill-proportional ink prints a
+     capped-neutral `.solid` quote at ~6.6:1 where the ramp gives ~11:1. */
   color: color-mix(
     in oklab,
     var(--intent-contrast)