@fusion.dev/helix-headless 0.53.0 → 0.53.2

package/types/vue.d.ts

@@ -459,13 +459,13 @@ export type HelixHeadlessAvatarGroupVueProps = {
 Unset shows all of them, which is what no limit means and is more useful
 than refusing to render.
 
-**Reflected, because the fold is a stylesheet rule and nothing else.** The
-styled tier hides past the limit with `:host([max="N"]) ::slotted(:nth-child(n + N+1))`,
-so the attribute *is* the mechanism: a `max` that reaches this property and
-never reaches the host matches no rule, and every avatar is drawn beside a
-count claiming some are hidden. Markup is the safe path and hides the fault;
-a script is the broken one, and React takes it for everyone, assigning a
-matching property rather than an attribute.
+**Reflected, because the fold is a stylesheet rule and nothing else.** A
+sheet hides past the limit one selector per value, as `FOLDS_UP_TO`
+describes, so the attribute *is* the mechanism: a `max` that reaches this
+property and never reaches the host matches no rule, and every avatar is
+drawn beside a count claiming some are hidden. Markup is the safe path and
+hides the fault; a script is the broken one, and React takes it for
+everyone, assigning a matching property rather than an attribute.
 
 **Optional rather than defaulted, per the rule that a reflected property
 takes no default**: `max = 0` would stamp `max="0"` onto every host that
@@ -647,12 +647,12 @@ export type HelixHeadlessBreadcrumbVueProps = {
   current?: (HelixHeadlessBreadcrumb["current"]) | undefined;
   /** Where the crumb goes, and nothing where it is the current page.
 
-**Optional and reflected, because a stylesheet does select on it.**
-`breadcrumb.css` writes `:host(:not([href])) [part="link"]` to take the
-block padding off a crumb that is not a link, so the attribute is what
-decides how tall a crumb is. Unreflected, an `href` set from script reached
-the property, rendered the anchor, and left the host looking unlinked: the
-crumb drew at 20px where a markup twin drew at 28.
+**Optional and reflected, because a stylesheet does select on it.** A sheet
+writes `:host(:not([href])) [part="link"]` to take the block padding off a
+crumb that is not a link, so the attribute is what decides how tall a crumb
+is. Unreflected, an `href` set from script reached the property, rendered
+the anchor, and left the host looking unlinked: the crumb drew at 20px
+where a markup twin drew at 28.
 
 Optional rather than defaulted, which is the general rule that a reflected
 property takes no default: an `href` written onto every host would be a link
@@ -714,7 +714,7 @@ the trigger silently does nothing at all. A wrapper has to hand them down,
 the same way `label` becomes `aria-label` in there.
 
 ```html
-<helix-button commandfor="confirm" command="--show">Delete…</helix-button>
+<helix-headless-button commandfor="confirm" command="--show">Delete…</helix-headless-button>
 ```
 
 `commandFor` spells its attribute out, because Lit lowercases a property
@@ -995,13 +995,13 @@ end while the slides stop moving a third of the way through.
 **The number is published to the styles rather than enumerated by them**,
 as `--carousel-per-view` on the track, which is what keeps a width and a
 count from disagreeing. A sheet can only name a value it wrote a rule for,
-so the styled tier enumerated `per-view="2"` through `5` and called five a
-judgment; above it the pane fell back to one across while this file went on
-counting positions. Measured in Chromium over eight slides, six across gave
-three dots, a pane taking the whole track and five slides reachable only by
-dragging. Written from here there is no ceiling to exceed, and a consumer's
-own sheet reads the same declaration the styled one does. `runEnd` publishes
-its correction the same way and for the same reason.
+so a sheet enumerating `per-view="2"` through `5` is a ceiling of five, and
+above it the pane falls back to one across while this file goes on counting
+positions. Measured in Chromium over eight slides against such a sheet, six
+across gave three dots, a pane taking the whole track and five slides
+reachable only by dragging. Published from here there is no ceiling to
+exceed, and every sheet reads the same declaration. `runEnd` publishes its
+correction the same way and for the same reason.
 
 **On the track and not on the host.** A custom property on the host is a
 reflected attribute by another name: it would arrive on upgrade, and a
@@ -1026,8 +1026,8 @@ inline the count would outrank the sheet that computes it, which is why an
 `auto` track is handed nothing. A count stays for the design that calls for
 exactly three.
 
-The styled sheet says how it divides, and the headless `auto` example
-carries the same three lines for a consumer writing their own.
+A sheet says how it divides, and the `auto` example here carries the same
+three lines for a consumer writing their own.
 
 **A value rather than the resting behavior**, which is what the
 responsiveness policy asks of every axis that a box decides: a splitter
@@ -1055,13 +1055,13 @@ end while the slides stop moving a third of the way through.
 **The number is published to the styles rather than enumerated by them**,
 as `--carousel-per-view` on the track, which is what keeps a width and a
 count from disagreeing. A sheet can only name a value it wrote a rule for,
-so the styled tier enumerated `per-view="2"` through `5` and called five a
-judgment; above it the pane fell back to one across while this file went on
-counting positions. Measured in Chromium over eight slides, six across gave
-three dots, a pane taking the whole track and five slides reachable only by
-dragging. Written from here there is no ceiling to exceed, and a consumer's
-own sheet reads the same declaration the styled one does. `runEnd` publishes
-its correction the same way and for the same reason.
+so a sheet enumerating `per-view="2"` through `5` is a ceiling of five, and
+above it the pane falls back to one across while this file goes on counting
+positions. Measured in Chromium over eight slides against such a sheet, six
+across gave three dots, a pane taking the whole track and five slides
+reachable only by dragging. Published from here there is no ceiling to
+exceed, and every sheet reads the same declaration. `runEnd` publishes its
+correction the same way and for the same reason.
 
 **On the track and not on the host.** A custom property on the host is a
 reflected attribute by another name: it would arrive on upgrade, and a
@@ -1086,8 +1086,8 @@ inline the count would outrank the sheet that computes it, which is why an
 `auto` track is handed nothing. A count stays for the design that calls for
 exactly three.
 
-The styled sheet says how it divides, and the headless `auto` example
-carries the same three lines for a consumer writing their own.
+A sheet says how it divides, and the `auto` example here carries the same
+three lines for a consumer writing their own.
 
 **A value rather than the resting behavior**, which is what the
 responsiveness policy asks of every axis that a box decides: a splitter
@@ -1251,13 +1251,13 @@ pinned because a conversation opens at its most recent turn.
 
 **Not reflected, and the default is why.** A reflected property that
 defaults to true writes its attribute on upgrade whether or not the
-consumer wrote one, so the server serves `<helix-chat label="x">` and the
-client turns it into `<helix-chat label="x" pinned>`: a hydration mismatch a
-React consumer reports and does not patch up. Nothing needs the attribute
-either, because the one thing that changes with the pin is the way back, and
-that is a part inside the shadow tree where a stylesheet can already reach
-it. Measured rather than assumed: `label, pinned` after upgrade against
-`label` from the server. */
+consumer wrote one, so the server serves `<helix-headless-chat label="x">`
+and the client turns it into `<helix-headless-chat label="x" pinned>`: a
+hydration mismatch a React consumer reports and does not patch up. Nothing
+needs the attribute either, because the one thing that changes with the pin
+is the way back, and that is a part inside the shadow tree where a
+stylesheet can already reach it. Measured rather than assumed: `label,
+pinned` after upgrade against `label` from the server. */
   pinned?: (HelixHeadlessChat["pinned"]) | undefined;
   /** How near the bottom still counts as being at it, in pixels.
 
@@ -1452,11 +1452,11 @@ present, which is true. Measured, and it is why this is named the other way
 round. The platform already writes booleans like this for the same reason,
 `novalidate` and `nomodule` and `noreferrer` among them.
 
-**Reflected, because the gutter is a stylesheet rule.** `code-block.css`
-reserves the copy button's width with `:host(:not([no-copy]))`, so the
-attribute is what decides whether the block pays for a control. Unreflected,
-setting it from script takes the button away (`render` reads the property)
-and leaves the 40px it stood in reserved.
+**Reflected, because the gutter is a stylesheet rule.** A sheet reserves
+the copy button's width with `:host(:not([no-copy]))`, so the attribute is
+what decides whether the block pays for a control. Unreflected, setting it
+from script takes the button away (`render` reads the property) and leaves
+the 40px it stood in reserved.
 
 A false boolean reflects as the attribute's absence, so this costs no
 `no-copy=""` on hosts that never asked for one, and the rule about a
@@ -1472,11 +1472,11 @@ present, which is true. Measured, and it is why this is named the other way
 round. The platform already writes booleans like this for the same reason,
 `novalidate` and `nomodule` and `noreferrer` among them.
 
-**Reflected, because the gutter is a stylesheet rule.** `code-block.css`
-reserves the copy button's width with `:host(:not([no-copy]))`, so the
-attribute is what decides whether the block pays for a control. Unreflected,
-setting it from script takes the button away (`render` reads the property)
-and leaves the 40px it stood in reserved.
+**Reflected, because the gutter is a stylesheet rule.** A sheet reserves
+the copy button's width with `:host(:not([no-copy]))`, so the attribute is
+what decides whether the block pays for a control. Unreflected, setting it
+from script takes the button away (`render` reads the property) and leaves
+the 40px it stood in reserved.
 
 A false boolean reflects as the attribute's absence, so this costs no
 `no-copy=""` on hosts that never asked for one, and the rule about a
@@ -1771,10 +1771,10 @@ letting it open would take a color from the reader and drop it. */
 
 **A color is exactly as requirable as a date**, which is the comparison
 that settles it: this element extends `HelixFormElement`, carries `name`
-and reports its value, so a consumer writing
-`<helix-color-picker name="brand" required>` inside a form has every reason
-to expect the form to refuse an empty one. Its two siblings in the same
-composition position, Date Picker and Time Picker, both check it.
+and reports its value, so a consumer writing `<helix-headless-color-picker
+name="brand" required>` inside a form has every reason to expect the form
+to refuse an empty one. Its two siblings in the same composition position,
+Date Picker and Time Picker, both check it.
 
 Written out rather than taken from `MixinField`, for the reason those two
 record: the mixin brings a label, a hint and a feedback region, and this is
@@ -2142,7 +2142,7 @@ the trigger silently does nothing at all. A wrapper has to hand them down,
 the same way `label` becomes `aria-label` in there.
 
 ```html
-<helix-button commandfor="confirm" command="--show">Delete…</helix-button>
+<helix-headless-button commandfor="confirm" command="--show">Delete…</helix-headless-button>
 ```
 
 `commandFor` spells its attribute out, because Lit lowercases a property
@@ -2417,17 +2417,17 @@ refusing it leaves the selection as it was. */
 
 **It announces nothing, and that is not an omission.** Nothing in this
 element ever asks for a different page size: a size selector is
-`helix-pagination-size`, which a consumer puts in the `footer` slot and
-answers themselves. Routing this through `requestChange` would announce an
-event the element never has cause to fire. */
+`PaginationSize`, which a consumer puts in the `footer` slot and answers
+themselves. Routing this through `requestChange` would announce an event
+the element never has cause to fire. */
   "page-size"?: (HelixHeadlessDataTable["pageSize"] | `${number}`) | undefined;
   /** How many rows a page holds. Zero is every row, which is what "no paging" means.
 
 **It announces nothing, and that is not an omission.** Nothing in this
 element ever asks for a different page size: a size selector is
-`helix-pagination-size`, which a consumer puts in the `footer` slot and
-answers themselves. Routing this through `requestChange` would announce an
-event the element never has cause to fire. */
+`PaginationSize`, which a consumer puts in the `footer` slot and answers
+themselves. Routing this through `requestChange` would announce an event
+the element never has cause to fire. */
   pageSize?: (HelixHeadlessDataTable["pageSize"]) | undefined;
   /** How many rows the whole result has, where this element cannot count them.
 
@@ -3170,10 +3170,10 @@ not, rather than shown or hidden by CSS. */
   modal?: (HelixHeadlessDrawer["modal"]) | undefined;
   /** Which edge the drawer comes from.
 
-Unset is `end`, which the styled tier reads as `:host(:not([placement]))`
-beside `:host([placement="end"])` rather than as a value written here: a
+Unset is `end`, and it stays unset rather than being written down: a
 default assigned to the property would reflect onto every host and put a
-`placement="end"` into markup no consumer wrote. */
+`placement="end"` into markup no consumer wrote. So what this tier
+guarantees is the absence, and a sheet selects on it. */
   placement?: (HelixHeadlessDrawer["placement"]) | undefined;
   /** Whether the element is open.
 
@@ -3701,11 +3701,12 @@ renders nothing rather than the epoch, which is what parsing an empty string
 would give.
 
 **The element's own text is read as a fallback, and only in a browser.**
-`<helix-format-date elapsed>2026-08-27T01:00:00Z</helix-format-date>` is the
-spelling that reads best in markup, and it cannot be the only one: measured
-against Lit's server shim, `textContent`, `children`, `firstChild` and
-`querySelector` are all `undefined` there, so a server has no way to see it.
-An element rendered on a server needs the attribute; one rendered in a
+`<helix-headless-format-date
+elapsed>2026-08-27T01:00:00Z</helix-headless-format-date>` is the spelling
+that reads best in markup, and it cannot be the only one: measured against
+Lit's server shim, `textContent`, `children`, `firstChild` and
+`querySelector` are all `undefined` there, so a server has no way to see
+it. An element rendered on a server needs the attribute; one rendered in a
 browser may use either. */
   date?: (HelixHeadlessFormatDate["date"]) | undefined;
   /** How the day of the month is written, where a date is shown. */
@@ -3779,12 +3780,12 @@ so a number written here that disagrees with the sheet is a promise the
 consumer has to keep by hand, and the one number a summary is told to trust
 is the one it gets wrong.
 
-The strip measures itself, so `--heatmap-cell-inline-size` and `--heatmap-gap` are
-enough on their own and these two are the estimate used until the first
-measurement lands. Writing the attribute pins the value and stops the
-measurement being consulted, which is what a container query or a transition
-on the cell size wants, where what is drawn this frame is not what the
-arithmetic should plan around.
+The strip measures itself, so sizing the cells in a sheet is enough on its
+own and these two are the estimate used until the first measurement lands.
+Writing the attribute pins the value and stops the measurement being
+consulted, which is what a container query or a transition on the cell size
+wants, where what is drawn this frame is not what the arithmetic should
+plan around.
 
 Zero turns the dropping off altogether, which is right for a strip in a
 container that cannot get narrow. */
@@ -3797,12 +3798,12 @@ so a number written here that disagrees with the sheet is a promise the
 consumer has to keep by hand, and the one number a summary is told to trust
 is the one it gets wrong.
 
-The strip measures itself, so `--heatmap-cell-inline-size` and `--heatmap-gap` are
-enough on their own and these two are the estimate used until the first
-measurement lands. Writing the attribute pins the value and stops the
-measurement being consulted, which is what a container query or a transition
-on the cell size wants, where what is drawn this frame is not what the
-arithmetic should plan around.
+The strip measures itself, so sizing the cells in a sheet is enough on its
+own and these two are the estimate used until the first measurement lands.
+Writing the attribute pins the value and stops the measurement being
+consulted, which is what a container query or a transition on the cell size
+wants, where what is drawn this frame is not what the arithmetic should
+plan around.
 
 Zero turns the dropping off altogether, which is right for a strip in a
 container that cannot get narrow. */
@@ -3864,7 +3865,7 @@ the trigger silently does nothing at all. A wrapper has to hand them down,
 the same way `label` becomes `aria-label` in there.
 
 ```html
-<helix-button commandfor="confirm" command="--show">Delete…</helix-button>
+<helix-headless-button commandfor="confirm" command="--show">Delete…</helix-headless-button>
 ```
 
 `commandFor` spells its attribute out, because Lit lowercases a property
@@ -4095,10 +4096,10 @@ Read-only to a consumer: it is a report rather than a setting.
 **Mirrored to `data-status`, and not reflected as `status`.** It is element
 state, so reflecting it puts the element's own bookkeeping into the markup
 a consumer rendered: React reads the attribute appearing at upgrade as a
-hydration mismatch, and a serialized `<helix-image status="loaded">` pasted
-back declares that a picture has arrived which this element has never
-fetched. The `data-` name is the library's answer to both, being a name a
-re-parse cannot mistake for a declaration, and it is what `data-closed` on
+hydration mismatch, and a host pasted back carrying `status="loaded"`
+declares that a picture has arrived which this element has never fetched.
+The `data-` name is the library's answer to both, being a name a re-parse
+cannot mistake for a declaration, and it is what `data-closed` on
 `Toast.Item` already does. A picture arrives after somebody fetched it,
 which puts this on the safe side of hydration: a fact that can be true on
 the *first* update mirrors to a custom state instead, which is what
@@ -4165,20 +4166,20 @@ Not a label: it goes when typing starts. */
 **The attribute is `readonly`, which is the platform's spelling.** A
 camelCase property needs an explicit `attribute`, and dash-casing a word
 HTML writes as one costs what an attribute always costs here: nothing
-warns. `<helix-input readonly>` is what anybody who has written HTML types;
-against `read-only` it parses to no property at all, and the field stays
-editable with no error anywhere. Measured on the dash-cased form, `readOnly`
-came back `false`. */
+warns. `<helix-headless-input readonly>` is what anybody who has written
+HTML types; against `read-only` it parses to no property at all, and the
+field stays editable with no error anywhere. Measured on the dash-cased
+form, `readOnly` came back `false`. */
   readonly?: (HelixHeadlessInput["readOnly"]) | undefined;
   /** Whether the field refuses input while still submitting its value.
 
 **The attribute is `readonly`, which is the platform's spelling.** A
 camelCase property needs an explicit `attribute`, and dash-casing a word
 HTML writes as one costs what an attribute always costs here: nothing
-warns. `<helix-input readonly>` is what anybody who has written HTML types;
-against `read-only` it parses to no property at all, and the field stays
-editable with no error anywhere. Measured on the dash-cased form, `readOnly`
-came back `false`. */
+warns. `<helix-headless-input readonly>` is what anybody who has written
+HTML types; against `read-only` it parses to no property at all, and the
+field stays editable with no error anywhere. Measured on the dash-cased
+form, `readOnly` came back `false`. */
   readOnly?: (HelixHeadlessInput["readOnly"]) | undefined;
   /** Whether a password field offers a toggle that shows what was typed.
 
@@ -4199,9 +4200,9 @@ The state is `aria-pressed`, not this. */
 
 **Not reflected.** Reflection exists so a selector can reach a value, and
 no stylesheet in this repository selects on `type`. Reflecting it writes
-`type="text"` onto every `<helix-input>` ever rendered, an attribute no
-consumer's markup has, which is the fault the area rules write up under
-`Button`'s `href`, `target` and `rel`.
+`type="text"` onto every `<helix-headless-input>` ever rendered, an
+attribute no consumer's markup has, which is the fault the area rules write
+up under `Button`'s `href`, `target` and `rel`.
 
 Nothing reads it from the attribute either. The real `<input>` inside takes
 it as a property binding, which is what makes the keyboard and the
@@ -4415,8 +4416,7 @@ beside it for instance. `ring` lets the ground through, for a chart drawn
 over something busy. `triangle` points along the axis and reads as "and
 onward" rather than as a second claim about the data.
 
-The shapes come from
-`helix/styled/src/shared/chart/terminus.css`, the same sheet `Sparkline` takes, so
+The shapes come from one shared sheet, the same one `Sparkline` takes, so
 the set is identical wherever one appears. **Which is why every value is
 named here.** `Sparkline` shipped `square` implemented, drawn, asserted and
 undocumented until the cohort before this one; this family reads the same
@@ -4497,10 +4497,10 @@ has to survive with the stylesheet turned off.
   label?: (HelixHeadlessList["label"]) | undefined;
   /** Which markers an ordered list draws, in `<ol type>`'s own five values.
 
-Reflected, because this is one of the things a stylesheet selects on and
-the styled tier maps each to a `list-style-type`. The platform's spellings
-rather than the CSS ones, so `<helix-list kind="ordered" type="i">` is what
-a consumer would have written on an `<ol>`.
+Reflected, because this is one of the things a stylesheet selects on, each
+value mapping to a `list-style-type`. The platform's spellings rather than
+the CSS ones, so `<helix-headless-list kind="ordered" type="i">` is what a
+consumer would have written on an `<ol>`.
 
 **`start` and `reversed` are both absent and neither can be done here.**
 This renders no `<ol>`: the rows are slotted and numbered by the CSS
@@ -5125,10 +5125,10 @@ this element then owns.
 
 **Not reflected.** Unread is a visual state, which is why the four mixins
 mirror theirs, but the mirror may not be the property's own attribute:
-`<helix-notification default-read>` comes back from a server without `read`
-and would gain it on the first update, which React reports as a hydration
-mismatch, and which a copy of the serialized element re-parses as a
-declaration. `:state(read)` is what the stylesheet reads.
+`<helix-headless-notification default-read>` comes back from a server
+without `read` and would gain it on the first update, which React reports
+as a hydration mismatch, and which a copy of the serialized element
+re-parses as a declaration. `:state(read)` is what the stylesheet reads.
 `hydration.dom.spec.ts` holds it. */
   read?: (HelixHeadlessNotification["read"]) | undefined;
   /** State to open with, where nothing declared one. */
@@ -5511,7 +5511,7 @@ attribute and the state is the property.
 **The attribute, read when it is asked for, and never a snapshot taken in
 the constructor.** A field initializer runs there, and an element the HTML
 parser created has none of its attributes yet at that moment: measured on
-this element, on `Radio` and on `Toggle`, `<helix-option value="a"
+this element, on `Radio` and on `Toggle`, `<helix-headless-option value="a"
 selected>` reported `defaultSelected` as `false` both from parsed markup
 and from `createElement` followed by `setAttribute`, which is every way a
 consumer writes one. The snapshot could only ever be true for an element
@@ -5859,10 +5859,10 @@ other end is going to reject. A consumer whose codes really do carry
 marked letters wants `text`, which judges nothing.
 
 **Not reflected**: nothing selects on it, so reflecting only writes
-`type="numeric"` onto every `<helix-pin-input>` ever rendered, an attribute
-no consumer's markup had. The area rules carry the sentence "reflect only
-what CSS selects on". The real inputs take it as a binding, which is what
-makes the keyboard follow. */
+`type="numeric"` onto every `<helix-headless-pin-input>` ever rendered, an
+attribute no consumer's markup had. The area rules carry the sentence
+"reflect only what CSS selects on". The real inputs take it as a binding,
+which is what makes the keyboard follow. */
   type?: (HelixHeadlessPinInput["type"]) | undefined;
   /** The value the markup declared, which is where a reset returns to. */
   "default-value"?: (HelixHeadlessPinInput["defaultValue"]) | undefined;
@@ -6196,7 +6196,7 @@ attribute and the state is the property.
 **The attribute, read when it is asked for, and never a snapshot taken in
 the constructor.** A field initializer runs there, and an element the HTML
 parser created has none of its attributes yet at that moment: measured on
-this element, on `Option` and on `Toggle`, `<helix-radio value="a"
+this element, on `Option` and on `Toggle`, `<helix-headless-radio value="a"
 selected>` reported `defaultSelected` as `false` both from parsed markup
 and from `createElement` followed by `setAttribute`, which is every way a
 consumer writes one. The snapshot could only ever be true for an element
@@ -6992,9 +6992,9 @@ the headline and the label is a caption under it.
 The row directions set them side by side, for a figure in a line of text or
 a narrow strip where a stacked pair would be two lines of almost nothing.
 
-A property rather than a `helix-flex` around it, because the unit has to
-stay on the value's baseline whichever way the pair goes, and only this
-element knows which of its children the unit belongs to.
+A property rather than a `Flex` around it, because the unit has to stay on
+the value's baseline whichever way the pair goes, and only this element
+knows which of its children the unit belongs to.
 
 **Optional rather than defaulted to `column`, which is not a style
 preference.** A reflecting property with a default writes its attribute onto
@@ -7194,15 +7194,15 @@ export type HelixHeadlessTableColumnHelixBeforeResizeElementEvent =
 export type HelixHeadlessTableColumnVueProps = {
   /** Which edge the values line up against.
 
-`end` is what a column of numbers wants, so digits of the same magnitude sit
-above each other. Left unset the cell inherits the table's own alignment,
-which is `start` for text in either writing direction. `helix-data-table`
-aligns the cells it draws. A `helix-table`'s cells are markup the consumer
-wrote, so the table writes nothing onto them: it publishes the edge to each
-cell under this column as `--table-cell-align`, which `@fusion.dev/helix`
-reads. The heading is this element's own, and `@fusion.dev/helix` sets it to
-the same edge in either table. `end` is the inline end, so in a
-right-to-left table it is the left.
+`end` is what a column of numbers wants, so digits of the same magnitude
+sit above each other. Left unset the cell inherits the table's own
+alignment, which is `start` for text in either writing direction.
+`DataTable` aligns the cells it draws. A `Table`'s cells are markup the
+consumer wrote, so the table writes nothing onto them: it publishes the
+edge to each cell under this column as `--table-cell-align`, which
+`@fusion.dev/helix` reads. The heading is this element's own, and
+`@fusion.dev/helix` sets it to the same edge in either table. `end` is the
+inline end, so in a right-to-left table it is the left.
 
 **Reflected, because the heading is drawn by a stylesheet and has no other
 way to learn it.** Set as a property, which is how React sets it, an
@@ -7249,8 +7249,8 @@ onto its host. */
   /** The track this column takes, as CSS.
 
 A single track value, so anything valid in `grid-template-columns` works:
-`16rem`, `auto`, `minmax(0, 2fr)`. Left unset the column takes the track
-in its place in a `helix-table`'s `columns`, where that table sets one, and
+`16rem`, `auto`, `minmax(0, 2fr)`. Left unset the column takes the track in
+its place in a `Table`'s `columns`, where that table sets one, and
 otherwise shares what is left over equally, as `minmax(max-content, 1fr)`.
 Set here, it wins over that list, which is what lets a reader resize a
 column in a table that set one.
@@ -7296,15 +7296,14 @@ export type HelixHeadlessTableColumnVueEvents = {
 export type HelixHeadlessTableVueProps = {
   /** The column widths as one track list, written once on the table.
 
-With `helix-table-column` children, each track sizes the column in its
-place, a hidden column counted, so hiding one takes its track with it and
-the rest keep theirs. The columns decide how many tracks there are and this
-list only how wide: a track past the last column is dropped, and a column
-past the last track shares what is left. With no columns declared it is
-the whole track list. Tracks count as the grid counts them, so
-`minmax(0, 1fr)` is one and `repeat(2, 8rem)` is two, and one the grid
-would refuse leaves its column at the default rather than taking the table
-down to one column.
+With `TableColumn` children, each track sizes the column in its place, a
+hidden column counted, so hiding one takes its track with it and the rest
+keep theirs. The columns decide how many tracks there are and this list
+only how wide: a track past the last column is dropped, and a column past
+the last track shares what is left. With no columns declared it is the
+whole track list. Tracks count as the grid counts them, so `minmax(0, 1fr)`
+is one and `repeat(2, 8rem)` is two, and one the grid would refuse leaves
+its column at the default rather than taking the table down to one column.
 
 **A column's own `width` wins over its track here.** The width is written
 on the column it sizes, which is the more particular statement, and it is
@@ -7318,13 +7317,11 @@ to walk, so a render there knows of no columns and this attribute is the
 whole answer: a table given one lays its grid out in the first paint, and a
 table sized only by its columns is one track wide until it upgrades.
 
-**`helix-data-table` has none of this, and should not.** Its columns are
-its schema rather than an option, so there is always a column to write a
-`width` on and a list here would be a second way to say what that says.
-This table's cells are markup, and a table written as rows of cells with no
-`helix-table-column` in it has nowhere else to be sized from. Both families
-take the same CSS hook, `--table-columns` and `--data-table-columns`, which
-wins over whichever list the element worked out. */
+**Data Table has none of this, and should not.** Its columns are its schema
+rather than an option, so there is always a column to write a `width` on
+and a list here would be a second way to say what that says. This table's
+cells are markup, and a table written as rows of cells with no column
+declared in it has nowhere else to be sized from. */
   columns?: (HelixHeadlessTable["columns"]) | undefined;
   /** Accessible name for the table. */
   label?: (HelixHeadlessTable["label"]) | undefined;
@@ -7679,8 +7676,8 @@ Absent uses the runtime's own. */
 
 Absent is one. `range` holds a start and an end, `multiple` holds any
 number, and both are carried as one comma-separated value, which is what a
-form submits. `helix-time-picker` carries the longer note on the interaction and on
-why a wheel cannot do either. */
+form submits. `TimePicker` carries the longer note on the interaction and
+on why a wheel cannot do either. */
   mode?: (HelixHeadlessTimeInput["mode"]) | undefined;
   /** What the field says before a time is in it. */
   placeholder?: (HelixHeadlessTimeInput["placeholder"]) | undefined;
@@ -7709,7 +7706,7 @@ never something this element would refuse to read back. */
 `list` offers whole times, which is what a product with slots or opening
 hours has. `wheels` splits them into an hour, a minute and a meridiem where
 the locale uses one, which is the only way to reach `23:45` without
-scrolling most of a day. `helix-time-picker` carries the longer note on the trade.
+scrolling most of a day. `TimePicker` carries the longer note on the trade.
 
 **Optional rather than defaulted, which is not a style preference.** A
 reflecting property with a default writes its attribute onto every host the
@@ -7899,7 +7896,7 @@ Absent uses the runtime's own. */
 
 Absent is one. `range` holds a start and an end with everything between
 them shown as part of the answer, `multiple` holds any number, and both are
-carried as one comma-separated value: the same shape `helix-date-picker` uses,
+carried as one comma-separated value: the same shape `DatePicker` uses,
 because it is the same question asked of a different unit.
 
 **A range is two picks, and a third starts over.** That is the calendar's
@@ -8123,7 +8120,7 @@ where they were would not be a stack.
 **Optional, and bottom-end is the absence of it.** Reflecting *and*
 defaulting is the pair that writes onto a host: every toast region anybody
 rendered would gain a `placement="bottom-end"` nobody typed, which a React
-consumer's server markup does not have. The styled sheet carries the resting
+consumer's server markup does not have. A sheet carries the resting
 arrangement in its own `:host` rule and the selectors describe only the
 departures, which is what `orientation` does. */
   placement?: (HelixHeadlessToast["placement"]) | undefined;
@@ -8265,11 +8262,11 @@ attribute and the state is the property.
 **The attribute, read when it is asked for, and never a snapshot taken in
 the constructor.** A field initializer runs there, and an element the HTML
 parser created has none of its attributes yet at that moment: measured on
-this element, on `Option` and on `Radio`, `<helix-toggle value="light"
-selected>` reported `defaultSelected` as `false` both from parsed markup
-and from `createElement` followed by `setAttribute`, which is every way a
-consumer writes one. The snapshot could only ever be true for an element
-already in the document when `customElements.define` ran.
+this element, on `Option` and on `Radio`, `<helix-headless-toggle
+value="light" selected>` reported `defaultSelected` as `false` both from
+parsed markup and from `createElement` followed by `setAttribute`, which is
+every way a consumer writes one. The snapshot could only ever be true for
+an element already in the document when `customElements.define` ran.
 
 Nothing overwrites it either, which is what makes reading it late correct
 rather than merely later: `selected` does not reflect, for the reason
@@ -9142,7 +9139,7 @@ export type HelixHeadlessVirtualListVueEvents = {};
 export type CustomCssProperties = {
   /** How wide an axis column is drawn, in `ch`, from the widest number on it. Written on the axis itself, and only where the categories run along the bottom: turned sideways an axis is a row and takes a line's height instead. */
   "--bar-chart-axis"?: (string) | undefined;
-  /** The color of the secondary axis when one series owns it. It resolves a `--helix-color-series-*` token, so on the headless tier alone it names something that is not there. #138. */
+  /** The color of the secondary axis, where one series owns it. Written by the component from that series' `--chart-series-*`, so it promises the series color and nothing more: whatever that hook resolves to is what the axis is drawn in. */
   "--bar-chart-secondary"?: (string) | undefined;
   /** The gradient a bar would take, named per bar so the styled tier can point `fill` at it. Drawn whatever the treatment and used only where `wash="gradient"` asks for it. */
   "--chart-bar-wash"?: (string) | undefined;
@@ -9166,24 +9163,14 @@ export type CustomCssProperties = {
   "--color-picker-saturation"?: (string) | undefined;
   /** A color to paint: the current one on the sample, a preset's on each preset. */
   "--color-picker-swatch"?: (string) | undefined;
-  /** The edge the column a cell sits under is set to, `start`, `center` or `end`, and unset under a column that sets none. Written by the component onto each cell it draws, read by the sheet that paints one; `helix-table` publishes `--table-cell-align` for the same attribute on the cells a consumer wrote, under its own family's name. */
+  /** The edge the column a cell sits under is set to, `start`, `center` or `end`, and unset under a column that sets none. Written by the component onto each cell it draws, read by the sheet that paints one; Table publishes `--table-cell-align` for the same attribute on the cells a consumer wrote, under its own family's name. */
   "--data-table-cell-align"?: (string) | undefined;
-  /** The column track list this element worked out from the columns declared in it. Written by the component, read by the sheet that paints: a stylesheet takes it to lay the grid out, and setting it does nothing, because the component writes it inline on the very element that reads it and an inline declaration beats any sheet. `--data-table-columns` is the one to set. */
+  /** The column track list this element worked out from the columns declared in it. Written by the component, read by the sheet that paints: a stylesheet takes it to lay the grid out, and setting it does nothing, because the component writes it inline on the very element that reads it and an inline declaration beats any sheet. A column's `width` is the one to set. */
   "--data-table-template"?: (string) | undefined;
   /** How many month columns are drawn, capped at two. `--date-picker-columns` overrides it. */
   "--date-picker-column-count"?: (string) | undefined;
   /** How thick the ring is drawn, derived from `hole`. */
   "--donut-chart-stroke"?: (string) | undefined;
-  /** How tall a cell is. A row of a tall thin cell is what a status page draws. */
-  "--heatmap-cell-height"?: (string) | undefined;
-  /** How wide a cell is. The strip fits as many as the container allows. */
-  "--heatmap-cell-inline-size"?: (string) | undefined;
-  /** How far a cell's corners are rounded. */
-  "--heatmap-cell-radius"?: (string) | undefined;
-  /** The size a cell wants on both axes, where neither is given its own. */
-  "--heatmap-cell-size"?: (string) | undefined;
-  /** Space between cells. Zero is a continuous field rather than a grid of tiles. */
-  "--heatmap-gap"?: (string) | undefined;
   /** How many rows the strip lays out. Written by the component from the data, read by the tier that draws it. */
   "--heatmap-rows"?: (string) | undefined;
   /** The tone of the cell this is set on. Written by the component, read by the sheet that paints. */
@@ -9258,7 +9245,7 @@ export type CustomCssProperties = {
   "--splitter-position"?: (string) | undefined;
   /** The edge the column this cell sits under is set to, `start`, `center` or `end`, and unset under a column that sets none. Written by the table around it, since the cell is the consumer's markup and nothing is written onto it; read by the sheet that draws the cell, where `justify-content` and `text-align` both take it as it comes and both follow the writing direction. */
   "--table-cell-align"?: (string) | undefined;
-  /** The column track list this element worked out from the columns declared in it. Written by the component, read by the sheet that paints: a stylesheet takes it to lay the grid out, and setting it does nothing, because the component writes it inline on the very element that reads it and an inline declaration beats any sheet. `--table-columns` is the one to set. */
+  /** The column track list this element worked out from the columns declared in it. Written by the component, read by the sheet that paints: a stylesheet takes it to lay the grid out, and setting it does nothing, because the component writes it inline on the very element that reads it and an inline declaration beats any sheet. `columns` is the one to set. */
   "--table-template"?: (string) | undefined;
   /** How long this message stays, in milliseconds, for a progress hint. */
   "--toast-duration"?: (string) | undefined;
@@ -9282,7 +9269,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessAccordionItemVueProps,
     HelixHeadlessAccordionItemVueEvents
   >;
-  /** Holds the mode and nothing else. The item that was clicked is what coordinates: it walks up to the nearest accordion, reads the mode off it, and closes its peers itself.  Coordination is structural, not a subscription. 'helix-before-open' does not bubble and is not composed, because overlays nest and an inner one's lifecycle must never read as the outer one's, so an accordion cannot learn that a child opened by listening for it.  Membership resolves on demand, so there is no registry to keep in step: an item added a second after render coordinates on its first click.  Items are matched with 'instanceof HelixHeadlessAccordionItem', never by tag name. Matching 'helix-accordion-item' would tie this tier to the styled one.  The keyboard listener is the controller's and is attached on connect, so none of it runs on the server, where there is no tree to walk and no events to hear. */
+  /** Holds the mode and nothing else. The item that was clicked is what coordinates: it walks up to the nearest accordion, reads the mode off it, and closes its peers itself.  Coordination is structural, not a subscription. 'helix-before-open' does not bubble and is not composed, because overlays nest and an inner one's lifecycle must never read as the outer one's, so an accordion cannot learn that a child opened by listening for it.  Membership resolves on demand, so there is no registry to keep in step: an item added a second after render coordinates on its first click.  Items are matched with 'instanceof HelixHeadlessAccordionItem', never by tag name, so this tier does not learn about the styled one.  The keyboard listener is the controller's and is attached on connect, so none of it runs on the server, where there is no tree to walk and no events to hear. */
   "helix-headless-accordion": DefineCustomElement<
     HelixHeadlessAccordion,
     HelixHeadlessAccordionVueProps,
@@ -9366,7 +9353,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessCalloutVueProps,
     HelixHeadlessCalloutVueEvents
   >;
-  /** Regions are slots rather than separate elements, because a header, body, and footer carry no state, no behavior, and no API of their own. Slotting them costs one custom element instead of five and lets the consumer bring their own markup, so a title can be a real '<h2>' rather than an emulated one.  The host is the surface. A wrapper '<div part="container">' would be a second box doing nothing the host cannot: the element itself takes the border, the radius, and the grid, and a consumer styles 'helix-card' rather than reaching through '::part'. One node instead of two, on every card on the page.  Name the card with 'aria-label' or 'aria-labelledby'. That is the only naming that survives server rendering: reading a title out of the light DOM needs a DOM, and the server has none. */
+  /** Regions are slots rather than separate elements, because a header, body, and footer carry no state, no behavior, and no API of their own. Slotting them costs one custom element instead of five and lets the consumer bring their own markup, so a title can be a real '<h2>' rather than an emulated one.  The host is the surface. A wrapper '<div part="container">' would be a second box doing nothing the host cannot: the element itself takes the border, the radius, and the grid, and a consumer styles 'Card' rather than reaching through '::part'. One node instead of two, on every card on the page.  Name the card with 'aria-label' or 'aria-labelledby'. That is the only naming that survives server rendering: reading a title out of the light DOM needs a DOM, and the server has none. */
   "helix-headless-card": DefineCustomElement<
     HelixHeadlessCard,
     HelixHeadlessCardVueProps,
@@ -9420,7 +9407,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessCodeVueProps,
     HelixHeadlessCodeVueEvents
   >;
-  /** **The picker is 'helix-color-picker', not a second one written here.** It owns the square, the ramps, the eyedropper and the syntax toggle, and it is worth having on its own: a settings pane wants a picker flat on the page with nothing to open. This element is the field, the overlay, and the form. Exactly the arrangement Date Input has with 'helix-date-picker'.  **Typed as well as picked, and the typing is the reason this is not '<input type="color">'.** The native control gives a free picker and takes nearly all styling with it, which is a fair trade until a product needs the panel to match everything around it. What is kept from the native one is the part worth keeping: a real text field, so a reader who has the hex pastes it and never opens anything.  **Every syntax is read; the one 'format' names is written.** '#f00', '#ff0000', 'rgb(255 0 0)', 'rgba(255,0,0,.5)', 'rgb(255 0 0 / 50%)' and 'hsl(0 100% 50%)' are all colors, and a field that refuses one because it prefers another is arguing with the person using it. What the field *shows* is the value itself, for the reason Date Input gives about its dates: half-typed input does not survive a round trip through a formatter.  The custom property below is written by this component and never set by a consumer: it carries a value this element resolved and CSS cannot, which is what lets a stylesheet on this tier paint the swatch without parsing anything itself. */
+  /** **The picker is 'ColorPicker', not a second one written here.** It owns the square, the ramps, the eyedropper and the syntax toggle, and it is worth having on its own: a settings pane wants a picker flat on the page with nothing to open. This element is the field, the overlay, and the form. Exactly the arrangement Date Input has with 'DatePicker'.  **Typed as well as picked, and the typing is the reason this is not '<input type="color">'.** The native control gives a free picker and takes nearly all styling with it, which is a fair trade until a product needs the panel to match everything around it. What is kept from the native one is the part worth keeping: a real text field, so a reader who has the hex pastes it and never opens anything.  **Every syntax is read; the one 'format' names is written.** '#f00', '#ff0000', 'rgb(255 0 0)', 'rgba(255,0,0,.5)', 'rgb(255 0 0 / 50%)' and 'hsl(0 100% 50%)' are all colors, and a field that refuses one because it prefers another is arguing with the person using it. What the field *shows* is the value itself, for the reason Date Input gives about its dates: half-typed input does not survive a round trip through a formatter.  The custom property below is written by this component and never set by a consumer: it carries a value this element resolved and CSS cannot, which is what lets a stylesheet on this tier paint the swatch without parsing anything itself. */
   "helix-headless-color-input": DefineCustomElement<
     HelixHeadlessColorInput,
     HelixHeadlessColorInputVueProps,
@@ -9432,13 +9419,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessColorPickerVueProps,
     HelixHeadlessColorPickerVueEvents
   >;
-  /** **The list is 'helix-listbox', and the filtering is its own.** It owns narrowing, the empty state, the highlight, 'aria-activedescendant' and scrolling an option into view. What is left for this element is the field, the panel and the traffic between them.  **The text and the value are two things.** What a reader types is a filter: it narrows the list and is thrown away. The value is whichever option they then choose, and the field is rewritten to that option's words once they have. The filter is cleared on close, so a reopened control does not start from the last visit's leftovers.  **Focus stays in the field, which is the whole of what a combobox is.** The arrows move the list without leaving the text, through the listbox's public 'navigate'. 'role="combobox"' is on the input rather than on a wrapper, because the thing the pattern describes is the text field.  **With 'multiple', the chosen options are tags in the field**, one object per answer, each with its own remove control. The panel stays open while more than one can be chosen and the filter clears on each choice, so the next pick starts from the whole list.  **'creatable' announces, and does not write.** The options are the consumer's light DOM and nothing here puts an element into it: a component that grew the consumer's markup would be one their framework re-renders over. It offers the row and fires the event; adding the option is the consumer's. */
+  /** **The list is 'Listbox', and the filtering is its own.** It owns narrowing, the empty state, the highlight, 'aria-activedescendant' and scrolling an option into view. What is left for this element is the field, the panel and the traffic between them.  **The text and the value are two things.** What a reader types is a filter: it narrows the list and is thrown away. The value is whichever option they then choose, and the field is rewritten to that option's words once they have. The filter is cleared on close, so a reopened control does not start from the last visit's leftovers.  **Focus stays in the field, which is the whole of what a combobox is.** The arrows move the list without leaving the text, through the listbox's public 'navigate'. 'role="combobox"' is on the input rather than on a wrapper, because the thing the pattern describes is the text field.  **With 'multiple', the chosen options are tags in the field**, one object per answer, each with its own remove control. The panel stays open while more than one can be chosen and the filter clears on each choice, so the next pick starts from the whole list.  **'creatable' announces, and does not write.** The options are the consumer's light DOM and nothing here puts an element into it: a component that grew the consumer's markup would be one their framework re-renders over. It offers the row and fires the event; adding the option is the consumer's. */
   "helix-headless-combobox": DefineCustomElement<
     HelixHeadlessCombobox,
     HelixHeadlessComboboxVueProps,
     HelixHeadlessComboboxVueEvents
   >;
-  /** **The list is 'helix-listbox', filtering and all.** Listbox already owns narrowing, the empty state, the highlight over what matched, 'aria-activedescendant', scrolling an option into view and the keyboard that moves between them. Its own note says a command palette is that list again with something different opening it, and this is that something: a dialog, and a key that summons it.  **The value is not kept.** A palette runs a command and forgets it: nothing here is a form control and nothing is submitted, so what it reports is that an option was chosen, once, with 'helix-select'. A consumer that wants the last command remembered is a consumer with somewhere better to keep it.  **The hotkey is global and the element does not have to be open to hear it.** The listener is on the document, because the point of a palette is that it answers from wherever the reader is, including from inside another control's text field. 'mod' is Command on a Mac and Control elsewhere, resolved here so a consumer writes one thing.  The filter is emptied as the palette closes, for the reason Combobox and Select both record: a control reopened still narrowed by the last visit's search is one whose second use starts from the first one's leftovers, and a palette is used far more often than either. */
+  /** **The list is 'Listbox', filtering and all.** Listbox already owns narrowing, the empty state, the highlight over what matched, 'aria-activedescendant', scrolling an option into view and the keyboard that moves between them. Its own note says a command palette is that list again with something different opening it, and this is that something: a dialog, and a key that summons it.  **The value is not kept.** A palette runs a command and forgets it: nothing here is a form control and nothing is submitted, so what it reports is that an option was chosen, once, with 'helix-select'. A consumer that wants the last command remembered is a consumer with somewhere better to keep it.  **The hotkey is global and the element does not have to be open to hear it.** The listener is on the document, because the point of a palette is that it answers from wherever the reader is, including from inside another control's text field. 'mod' is Command on a Mac and Control elsewhere, resolved here so a consumer writes one thing.  The filter is emptied as the palette closes, for the reason Combobox and Select both record: a control reopened still narrowed by the last visit's search is one whose second use starts from the first one's leftovers, and a palette is used far more often than either. */
   "helix-headless-command": DefineCustomElement<
     HelixHeadlessCommand,
     HelixHeadlessCommandVueProps,
@@ -9450,13 +9437,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessCopyButtonVueProps,
     HelixHeadlessCopyButtonVueEvents
   >;
-  /** **The schema is markup and the data is a property.** Columns are declared as 'helix-table-column' children, because a schema is small and something a reader should see in the HTML; rows are handed over as an array, because a table that draws ten thousand elements cannot window them.  '''html <helix-data-table .rows=${rows} sort="name:asc" page-size="20">   <helix-table-column field="name" sortable>Name</helix-table-column>   <helix-table-column field="size" align="end" sortable .cell=${bytes}>Size</helix-table-column> </helix-data-table> '''  'helix-table' takes rows as markup and is the right component for a table of twelve things a person wrote out.  **Sort and filter apply to the whole set, never the page.** Sorting the drawn window is correct on the first screen and wrong on every other one.  **The cell values do not server-render.** The headings do, and the row elements do, but reading a cell needs the columns, and the columns are markup children Lit SSR does not hand this element. So a crawler sees a table of the right shape with nothing in it. That is the cost of the first paragraph: use 'helix-table' where the served HTML has to carry the values.  **'selectable' adds a column of checkboxes, keyed on 'row-key'.** A row is selected by its identity rather than its position, so a selection survives a sort, a filter and a page. 'selected' is the chosen keys, comma separated, the shape Listbox uses for a multiple choice, and like 'sort' it is controlled when set and seeded by 'default-selected'. The box in the heading selects every row in the result, across pages, and shows a dash while only some are chosen. Choosing one of many, rather than several, is opening a row, and that is a link or a button in a cell rather than a selection.  **A reader can size and order the columns.** 'resizable' on a column puts a separator on its edge; 'reorderable' on the table puts a grip on each heading that has a 'field', moved by dragging or with the arrow keys. The order lands in 'order' as fields, and the consumer's own markup is never rewritten: the table assigns the headings to its header in that order instead.  **'csv()' hands back the result as text**: every row the filter lets through, in the order on screen, in the columns on screen. Saving it is the page's business, the same as any other file.  **There is no 'columns' attribute here, and 'helix-table' has one.** The difference is what a column is in each: here it is the schema, so a table without one has nothing to read a row with, and every column is a place to write a 'width'. A 'helix-table' holds cells a consumer wrote and can be written with no column at all, so its 'columns' is where such a table is sized from. Written on this element the attribute is inert, which is the trap worth knowing when moving between the two. What both take is the CSS hook, '--data-table-columns' here and '--table-columns' there. */
+  /** **The schema is markup and the data is a property.** Columns are declared as 'TableColumn' children, because a schema is small and something a reader should see in the HTML; rows are handed over as an array, because a table that draws ten thousand elements cannot window them.  '''html <helix-headless-data-table .rows=${rows} sort="name:asc" page-size="20">   <helix-headless-table-column field="name" sortable>Name</helix-headless-table-column>   <helix-headless-table-column field="size" align="end" sortable .cell=${bytes}>Size</helix-headless-table-column> </helix-headless-data-table> '''  'Table' takes rows as markup and is the right component for a table of twelve things a person wrote out.  **Sort and filter apply to the whole set, never the page.** Sorting the drawn window is correct on the first screen and wrong on every other one.  **The cell values do not server-render.** The headings do, and the row elements do, but reading a cell needs the columns, and the columns are markup children Lit SSR does not hand this element. So a crawler sees a table of the right shape with nothing in it. That is the cost of the first paragraph: use 'Table' where the served HTML has to carry the values.  **'selectable' adds a column of checkboxes, keyed on 'row-key'.** A row is selected by its identity rather than its position, so a selection survives a sort, a filter and a page. 'selected' is the chosen keys, comma separated, the shape Listbox uses for a multiple choice, and like 'sort' it is controlled when set and seeded by 'default-selected'. The box in the heading selects every row in the result, across pages, and shows a dash while only some are chosen. Choosing one of many, rather than several, is opening a row, and that is a link or a button in a cell rather than a selection.  **A reader can size and order the columns.** 'resizable' on a column puts a separator on its edge; 'reorderable' on the table puts a grip on each heading that has a 'field', moved by dragging or with the arrow keys. The order lands in 'order' as fields, and the consumer's own markup is never rewritten: the table assigns the headings to its header in that order instead.  **'csv()' hands back the result as text**: every row the filter lets through, in the order on screen, in the columns on screen. Saving it is the page's business, the same as any other file.  **There is no 'columns' attribute here, and Table has one.** The difference is what a column is in each: here it is the schema, so a table without one has nothing to read a row with, and every column is a place to write a 'width'. A Table holds cells a consumer wrote and can be written with no column at all, so its 'columns' is where such a table is sized from. Written on this element the attribute is inert, which is the trap worth knowing when moving between the two. */
   "helix-headless-data-table": DefineCustomElement<
     HelixHeadlessDataTable,
     HelixHeadlessDataTableVueProps,
     HelixHeadlessDataTableVueEvents
   >;
-  /** **The calendar is 'helix-date-picker', not a second one written here.** It already knows about months, ranges, disabled days, the first day of the week and every keyboard rule a grid owes a reader. This element is the field, the overlay, and the translation between them.  **Typed as well as picked, and the typing is why it is not '<input type="date">'.** The native control gives a free picker and a free locale and takes almost all styling with it. What is kept from it is the part worth keeping: a real text field. */
+  /** **The calendar is 'DatePicker', not a second one written here.** It already knows about months, ranges, disabled days, the first day of the week and every keyboard rule a grid owes a reader. This element is the field, the overlay, and the translation between them.  **Typed as well as picked, and the typing is why it is not '<input type="date">'.** The native control gives a free picker and a free locale and takes almost all styling with it. What is kept from it is the part worth keeping: a real text field. */
   "helix-headless-date-input": DefineCustomElement<
     HelixHeadlessDateInput,
     HelixHeadlessDateInputVueProps,
@@ -9498,7 +9485,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessDonutChartVueProps,
     HelixHeadlessDonutChartVueEvents
   >;
-  /** Takes 'MixinControllerOpen', so 'open', 'defaultOpen' and the 'helix-before-open' and 'helix-before-close' requests behave exactly as they do on an accordion item, and a consumer already knows the API.  Modal by default, which is three things together and not one: focus is trapped inside, Escape and an outside press close it, and the page behind is covered. A panel with the look of a modal and none of its behavior is worse than an inline one, because it invites the reader to treat it as blocking.  Content stays mounted when closed, so it is in the server's markup and can animate. A closed '<dialog>' is already out of the tab order and out of the accessibility tree, so nothing here writes 'inert'. The 'role', the 'aria-modal' and the scrim come from the element too, and 'drawer-root.ssr.spec.ts' asserts the panel carries no hand-written 'inert' and no hand-written 'role'.  Opened declaratively with the platform's invoker attributes:  '''html <helix-button commandfor="nav" command="--toggle">Menu</helix-button> <helix-drawer id="nav">…</helix-drawer> ''' */
+  /** Takes 'MixinControllerOpen', so 'open', 'defaultOpen' and the 'helix-before-open' and 'helix-before-close' requests behave exactly as they do on an accordion item, and a consumer already knows the API.  Modal by default, which is three things together and not one: focus is trapped inside, Escape and an outside press close it, and the page behind is covered. A panel with the look of a modal and none of its behavior is worse than an inline one, because it invites the reader to treat it as blocking.  Content stays mounted when closed, so it is in the server's markup and can animate. A closed '<dialog>' is already out of the tab order and out of the accessibility tree, so nothing here writes 'inert'. The 'role', the 'aria-modal' and the scrim come from the element too, and 'drawer-root.ssr.spec.ts' asserts the panel carries no hand-written 'inert' and no hand-written 'role'.  Opened declaratively with the platform's invoker attributes:  '''html <helix-headless-button commandfor="nav" command="--toggle">Menu</helix-headless-button> <helix-headless-drawer id="nav">…</helix-headless-drawer> ''' */
   "helix-headless-drawer": DefineCustomElement<
     HelixHeadlessDrawer,
     HelixHeadlessDrawerVueProps,
@@ -9552,7 +9539,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessFilterOperatorVueProps,
     HelixHeadlessFilterOperatorVueEvents
   >;
-  /** **The tokens are the consumer's own elements, slotted.** What a filter narrows by belongs to the consumer's model rather than to this element: a facet with a prefix, a saved query, a range. So they are slotted rather than rendered from a list of strings, and removing one is a request this element makes rather than a change it applies. Combobox is the other way round, and that is the difference between the two: its tokens are a view of a selection it owns, drawn from options it was handed.  **'value' is the text being typed, not the tokens**, which is what makes this a field a consumer can listen to. Every keystroke announces 'input' with the text on the element, so a table narrows as the reader types. The tokens need no reporting back, being markup the consumer already holds.  Backspace on an empty field asks the last token to go, through the same 'helix-dismiss' its own remove control fires, so a consumer who handled the pointer has already handled the keyboard.  **It reads what was declared, and nothing that was not.** Write 'FilterField's (usually inside the 'FilterMenu' slotted into 'start', so the picker and the text work off one set), and Enter reads the box against them: 'disposition:refunded,settled' and '-disposition:refunded' announce 'helix-facet', exactly as ticking those values in the picker would, and the text they were read from goes. Everything else stays where it was typed, so 'refund tuesday disposition:settled' is a filter and a search at once. 'grammar.ts' carries the whole rule and is worth reading before relying on it; the short version is that Helix owns the punctuation and the consumer owns every word in it. A field with no 'FilterField' in it parses nothing, which is the behavior this had before it could.  **A field whose values cannot be listed belongs here rather than in the picker.** 'assignee:ada' is a filter and nobody wants to enumerate every name in the company, but a menu page for it would have nothing on it to press. Written directly inside this element it is read by the grammar and never offered as a page: unslotted, so nothing draws it, which is the same trick 'FilterField' already plays on its own children.  **It can suggest what to type next, and deciding what to suggest is still the consumer's.** Slot 'helix-option' elements into 'suggestions' and the field shows them, moves through them with the arrows, and lets Enter press one; the option fires its own 'helix-select' and the consumer decides what choosing meant. Keys before a colon and values after it are the same panel with different contents, and 'readFilterText' is exported for a consumer narrowing that panel against what a reader has half typed.  **The panel opens when there is something in it and closes when there is not**, rather than on a choice. A reader who picks a key wants its values next, and closing on the choice would shut the panel between two renders. Use 'selectionStart' and 'setSelectionRange' to write a completion back and put the caret after it, or the next parse reads the wrong term.  **Three things here have three different owners, and only one of them is a controlled property.**  'value' is the text, and it is uncontrolled by default: the reader types, the element applies it, and 'input' says so. **Writing 'value' does not take that over.** It is a seed and a correction, so a consumer who sets it and then expects the field to hold still will watch the next keystroke overwrite them. Ownership is taken by refusing 'helix-before-change' and writing the value you want, which is the same shape every field in this library uses and is worth saying out loud here because the property looks like React's. 'default-value' seeds the field without claiming anything.  'open' is the suggestions panel, and it is the ordinary controlled pair: refuse 'helix-before-open' or 'helix-before-close' to take the decision, and 'default-open' to seed it.  The tokens are neither, because they are not state. They are the consumer's own elements in a slot, so there is nothing for this to own and nothing to report back: a token goes when the consumer removes it from their markup, having been asked by 'helix-dismiss'. **A 'FilterChip' naming a declared field is asked differently**, and it has to be: the picker holds what is ticked, so a chip that removed itself without telling it left the value ticked in a list nobody could see was wrong. That dismissal is answered as the field being filtered by nothing, so it arrives as 'helix-facet' like every other change and the chip goes because the filter went. */
+  /** **The tokens are the consumer's own elements, slotted.** What a filter narrows by belongs to the consumer's model rather than to this element: a facet with a prefix, a saved query, a range. So they are slotted rather than rendered from a list of strings, and removing one is a request this element makes rather than a change it applies. Combobox is the other way round, and that is the difference between the two: its tokens are a view of a selection it owns, drawn from options it was handed.  **'value' is the text being typed, not the tokens**, which is what makes this a field a consumer can listen to. Every keystroke announces 'input' with the text on the element, so a table narrows as the reader types. The tokens need no reporting back, being markup the consumer already holds.  Backspace on an empty field asks the last token to go, through the same 'helix-dismiss' its own remove control fires, so a consumer who handled the pointer has already handled the keyboard.  **It reads what was declared, and nothing that was not.** Write 'FilterField's (usually inside the 'FilterMenu' slotted into 'start', so the picker and the text work off one set), and Enter reads the box against them: 'disposition:refunded,settled' and '-disposition:refunded' announce 'helix-facet', exactly as ticking those values in the picker would, and the text they were read from goes. Everything else stays where it was typed, so 'refund tuesday disposition:settled' is a filter and a search at once. 'grammar.ts' carries the whole rule and is worth reading before relying on it; the short version is that Helix owns the punctuation and the consumer owns every word in it. A field with no 'FilterField' in it parses nothing, which is the behavior this had before it could.  **A field whose values cannot be listed belongs here rather than in the picker.** 'assignee:ada' is a filter and nobody wants to enumerate every name in the company, but a menu page for it would have nothing on it to press. Written directly inside this element it is read by the grammar and never offered as a page: unslotted, so nothing draws it, which is the same trick 'FilterField' already plays on its own children.  **It can suggest what to type next, and deciding what to suggest is still the consumer's.** Slot options into 'suggestions' and the field shows them, moves through them with the arrows, and lets Enter press one; the option fires its own 'helix-select' and the consumer decides what choosing meant. Keys before a colon and values after it are the same panel with different contents, and 'readFilterText' is exported for a consumer narrowing that panel against what a reader has half typed.  **The panel opens when there is something in it and closes when there is not**, rather than on a choice. A reader who picks a key wants its values next, and closing on the choice would shut the panel between two renders. Use 'selectionStart' and 'setSelectionRange' to write a completion back and put the caret after it, or the next parse reads the wrong term.  **Three things here have three different owners, and only one of them is a controlled property.**  'value' is the text, and it is uncontrolled by default: the reader types, the element applies it, and 'input' says so. **Writing 'value' does not take that over.** It is a seed and a correction, so a consumer who sets it and then expects the field to hold still will watch the next keystroke overwrite them. Ownership is taken by refusing 'helix-before-change' and writing the value you want, which is the same shape every field in this library uses and is worth saying out loud here because the property looks like React's. 'default-value' seeds the field without claiming anything.  'open' is the suggestions panel, and it is the ordinary controlled pair: refuse 'helix-before-open' or 'helix-before-close' to take the decision, and 'default-open' to seed it.  The tokens are neither, because they are not state. They are the consumer's own elements in a slot, so there is nothing for this to own and nothing to report back: a token goes when the consumer removes it from their markup, having been asked by 'helix-dismiss'. **A 'FilterChip' naming a declared field is asked differently**, and it has to be: the picker holds what is ticked, so a chip that removed itself without telling it left the value ticked in a list nobody could see was wrong. That dismissal is answered as the field being filtered by nothing, so it arrives as 'helix-facet' like every other change and the chip goes because the filter went. */
   "helix-headless-filter-input": DefineCustomElement<
     HelixHeadlessFilterInput,
     HelixHeadlessFilterInputVueProps,
@@ -9672,7 +9659,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessNotificationGroupVueProps,
     HelixHeadlessNotificationGroupVueEvents
   >;
-  /** A notification is a toast that did not go away. 'helix-toast' is deliberately the opposite of this: a live region whose items carry a 'duration' and whose root never creates or destroys anything. What makes this its own family is the state each item carries rather than the arrangement it sits in: read and unread, a timestamp that has to stay correct, and an action a reader can take later.  **The row is a label, a caption under it, and one trailing column that holds either the time or the controls.** A feed is scanned rather than read, so the thing that happened gets the first line on its own and everything qualifying it goes under. The time and the controls occupy the same place because a reader wants exactly one of them at a time: the time while they are scanning, and what they can do about it once they have stopped on a row.  **The timestamp is 'helix-format-date'**, which is where the reading, the '<time datetime>' and the shared timer now live. It was implemented here, and a component that formats a date is not a fact about notifications: Chat wanted the same thing and had its own copy of half of it.  **Read state is reported, not invented.** Marking something read is usually a round trip, and a component that flips its own state and then hears the request failed has told the reader something untrue. 'helix-read' is cancelable, and a 'read' set by the consumer makes this element defer entirely. */
+  /** A notification is a toast that did not go away. 'Toast' is deliberately the opposite of this: a live region whose items carry a 'duration' and whose root never creates or destroys anything. What makes this its own family is the state each item carries rather than the arrangement it sits in: read and unread, a timestamp that has to stay correct, and an action a reader can take later.  **The row is a label, a caption under it, and one trailing column that holds either the time or the controls.** A feed is scanned rather than read, so the thing that happened gets the first line on its own and everything qualifying it goes under. The time and the controls occupy the same place because a reader wants exactly one of them at a time: the time while they are scanning, and what they can do about it once they have stopped on a row.  **The timestamp is 'FormatDate'**, which is where the reading, the '<time datetime>' and the shared timer now live. It was implemented here, and a component that formats a date is not a fact about notifications: Chat wanted the same thing and had its own copy of half of it.  **Read state is reported, not invented.** Marking something read is usually a round trip, and a component that flips its own state and then hears the request failed has told the reader something untrue. 'helix-read' is cancelable, and a 'read' set by the consumer makes this element defer entirely. */
   "helix-headless-notification": DefineCustomElement<
     HelixHeadlessNotification,
     HelixHeadlessNotificationVueProps,
@@ -9714,7 +9701,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessOutlineVueProps,
     HelixHeadlessOutlineVueEvents
   >;
-  /** **The component is the truncation.** Given a page and a total it works out which numbers to show and where the runs break, so this is data-driven rather than composed: '<helix-pagination page="4" pages="12">' rather than twelve slotted children a consumer keeps in step with their own query.  **The width does not change as you page.** The run around the current page is 'siblings' either side, and grows to absorb a gap slot at a boundary, so the control holds the same number of slots from the first page to the last. Anything that lets the count vary moves the buttons under the pointer between one click and the next.  **A gap is only drawn where it hides more than one page, and a gap is a control.** It goes to the middle of the run it stands over, which is the binary-search step: any page in a set of any size is a handful of presses.  **'href' is what makes these links.** Set it and every page renders an '<a>' with '{page}' filled in, so the output is crawlable, a middle click opens a tab, and the address bar is the state. Left unset they are buttons, which is right for a table paging in place. Either way the click announces 'helix-navigate' first, and 'preventDefault()' stops the navigation as well as the change, which is how a router takes over.  **'helix-navigate' and not 'helix-change'.** Moving to page four chooses nothing; it moves the view over a result that has not changed.  **The count and the page-size control are their own elements.** 'Pagination.Summary' and 'Pagination.Size' sit beside this one, because a slot can only offer one place: at one end of one row, in one order. */
+  /** **The component is the truncation.** Given a page and a total it works out which numbers to show and where the runs break, so this is data-driven rather than composed: '<helix-headless-pagination page="4" pages="12">' rather than twelve slotted children a consumer keeps in step with their own query.  **The width does not change as you page.** The run around the current page is 'siblings' either side, and grows to absorb a gap slot at a boundary, so the control holds the same number of slots from the first page to the last. Anything that lets the count vary moves the buttons under the pointer between one click and the next.  **A gap is only drawn where it hides more than one page, and a gap is a control.** It goes to the middle of the run it stands over, which is the binary-search step: any page in a set of any size is a handful of presses.  **'href' is what makes these links.** Set it and every page renders an '<a>' with '{page}' filled in, so the output is crawlable, a middle click opens a tab, and the address bar is the state. Left unset they are buttons, which is right for a table paging in place. Either way the click announces 'helix-navigate' first, and 'preventDefault()' stops the navigation as well as the change, which is how a router takes over.  **'helix-navigate' and not 'helix-change'.** Moving to page four chooses nothing; it moves the view over a result that has not changed.  **The count and the page-size control are their own elements.** 'Pagination.Summary' and 'Pagination.Size' sit beside this one, because a slot can only offer one place: at one end of one row, in one order. */
   "helix-headless-pagination": DefineCustomElement<
     HelixHeadlessPagination,
     HelixHeadlessPaginationVueProps,
@@ -9828,7 +9815,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessSpeedDialItemVueProps,
     HelixHeadlessSpeedDialItemVueEvents
   >;
-  /** **A menu, and deliberately not a new one.** Its rows are commands, which is what 'role="menu"' and 'menuitem' exist for, so this takes them and takes the behavior with them: the arrow keys are 'KeyboardNavigationController', the panel is 'PopoverController', and open and closed is 'MixinControllerOpen'. 'Menu' is built from the same pieces. What is not shared is what actually differs: a dial has no submenus, no headers, no checkable rows and no long list to type ahead through, and shipping it as an appearance of 'Menu' would mean defining what a dial with a submenu in it does.  **The trigger is a control the consumer slots**, and the floating action button is the usual one: 'helix-icon-button' with 'shape="circle"' and 'raised'. There is no 'helix-fab', because it would re-declare 'emphasis', 'tone', 'label' and a size around a control that already has all four. A round raised button is a shape, and where it sits is 'data-dock' in the base layer.  **Nothing is reserved from the keyboard.** A menu that drills has to keep the horizontal pair for going in and coming back; a dial goes nowhere, so all four arrows move through the actions and a reader who guesses either axis is answered. That is the controller's own house position, and this is a component with no reason to argue with it. */
+  /** **A menu, and deliberately not a new one.** Its rows are commands, which is what 'role="menu"' and 'menuitem' exist for, so this takes them and takes the behavior with them: the arrow keys are 'KeyboardNavigationController', the panel is 'PopoverController', and open and closed is 'MixinControllerOpen'. 'Menu' is built from the same pieces. What is not shared is what actually differs: a dial has no submenus, no headers, no checkable rows and no long list to type ahead through, and shipping it as an appearance of 'Menu' would mean defining what a dial with a submenu in it does.  **The trigger is a control the consumer slots**, and the floating action button is the usual one: 'IconButton' with 'shape="circle"' and 'raised'. There is no 'helix-fab', because it would re-declare 'emphasis', 'tone', 'label' and a size around a control that already has all four. A round raised button is a shape, and where it sits is 'data-dock' in the base layer.  **Nothing is reserved from the keyboard.** A menu that drills has to keep the horizontal pair for going in and coming back; a dial goes nowhere, so all four arrows move through the actions and a reader who guesses either axis is answered. That is the controller's own house position, and this is a component with no reason to argue with it. */
   "helix-headless-speed-dial": DefineCustomElement<
     HelixHeadlessSpeedDial,
     HelixHeadlessSpeedDialVueProps,
@@ -9858,7 +9845,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessStepsVueProps,
     HelixHeadlessStepsVueEvents
   >;
-  /** **The name is a button, and only the name.** The marker is 'aria-hidden' decoration, so wrapping it would add hit area and no meaning. It is 'helix-button' rather than a '<button>' this element resets: the hover wash, the focus ring and the disabled treatment are decisions the button carries.  **It says nothing about where a reader may go.** Every step is pressable and announces itself with 'helix-select'; refusing the ones ahead is 'disabled', which the consumer sets, because only they know whether a form can be skipped.  **The marker is a slot whose fallback is the state.** A finished stage shows a check, the current one a target, one not yet reached an empty ring. Exactly one is rendered, chosen from the step's own two booleans, rather than three with two hidden in CSS: the accessibility tree would otherwise carry marks that are not there. */
+  /** **The name is a button, and only the name.** The marker is 'aria-hidden' decoration, so wrapping it would add hit area and no meaning. It is 'Button' rather than a '<button>' this element resets: the hover wash, the focus ring and the disabled treatment are decisions the button carries.  **It says nothing about where a reader may go.** Every step is pressable and announces itself with 'helix-select'; refusing the ones ahead is 'disabled', which the consumer sets, because only they know whether a form can be skipped.  **The marker is a slot whose fallback is the state.** A finished stage shows a check, the current one a target, one not yet reached an empty ring. Exactly one is rendered, chosen from the step's own two booleans, rather than three with two hidden in CSS: the accessibility tree would otherwise carry marks that are not there. */
   "helix-headless-step": DefineCustomElement<
     HelixHeadlessStep,
     HelixHeadlessStepVueProps,
@@ -9876,7 +9863,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTableCellVueProps,
     HelixHeadlessTableCellVueEvents
   >;
-  /** **The column is the source of both its heading and its track.** Add one and the table has another track; remove one and it does not. That is what ties the two together, and a table-level track list on its own does not: a list that is accidentally the headings is invalid CSS a grid ignores in silence, drawing the whole table as one column. 'helix-table''s 'columns' is dealt out a track at a time against the columns declared under it, so a heading among the widths costs its own column a width and no more, and a list longer or shorter than the columns is trimmed or shared rather than being a second count of them. A column's own 'width' wins over the track in its place.  **It is also where every per-column fact goes**, which is the reason 'helix-data-table' needs no column config object. 'field' names the key the cell reads, 'sortable' says a reader may reorder by it, 'align' says which edge the values line up against, and 'cell' takes a function for anything the field alone cannot express. The schema is markup and the data is a property: a schema is small, declarative, and something a reader should be able to see in the HTML, and data is large and windowed.  **The same element serves both tables**, the markup one and the data one. It is identified by a flag rather than by 'instanceof', so a 'helix-table-column' works inside either without the two roots sharing anything else.  **It generates no box of its own**, the same as a row: the heading is a grid item of the table, so it lines up with the cells under it rather than sitting in a wrapper that has to be kept the same width.  **'hidden' takes the column out of the grid**, its heading and its track both, so the columns after it keep their own widths and every row keeps its cells under their headings. 'hidden="until-found"' keeps its track, the heading being left drawn, as every Helix element leaves one with that value. 'helix-data-table' draws the cells, so it leaves out the ones under a hidden column. A 'helix-table''s cells are markup the consumer wrote, so hide them with the column, as removing a column means removing its cells: a row with a cell more than the table has tracks wraps into the next.  **A heading that does something holds a control that does it.** The host is the column header, and a header is not focusable, so a sortable heading is a '<button>' inside it: the pattern for a sortable table, and the only way a reader on a keyboard reaches the sort at all. A column a reader may resize carries a 'separator' on its end edge, moved by dragging it or with the arrow keys, and a column in a table that lets a reader reorder its columns carries a grip the table moves. */
+  /** **The column is the source of both its heading and its track.** Add one and the table has another track; remove one and it does not. That is what ties the two together, and a table-level track list on its own does not: a list that is accidentally the headings is invalid CSS a grid ignores in silence, drawing the whole table as one column. 'Table''s 'columns' is dealt out a track at a time against the columns declared under it, so a heading among the widths costs its own column a width and no more, and a list longer or shorter than the columns is trimmed or shared rather than being a second count of them. A column's own 'width' wins over the track in its place.  **It is also where every per-column fact goes**, which is the reason 'DataTable' needs no column config object. 'field' names the key the cell reads, 'sortable' says a reader may reorder by it, 'align' says which edge the values line up against, and 'cell' takes a function for anything the field alone cannot express. The schema is markup and the data is a property: a schema is small, declarative, and something a reader should be able to see in the HTML, and data is large and windowed.  **The same element serves both tables**, the markup one and the data one. It is identified by a flag rather than by 'instanceof', so a 'TableColumn' works inside either without the two roots sharing anything else.  **It generates no box of its own**, the same as a row: the heading is a grid item of the table, so it lines up with the cells under it rather than sitting in a wrapper that has to be kept the same width.  **'hidden' takes the column out of the grid**, its heading and its track both, so the columns after it keep their own widths and every row keeps its cells under their headings. 'hidden="until-found"' keeps its track, the heading being left drawn, as every Helix element leaves one with that value. 'DataTable' draws the cells, so it leaves out the ones under a hidden column. A 'Table''s cells are markup the consumer wrote, so hide them with the column, as removing a column means removing its cells: a row with a cell more than the table has tracks wraps into the next.  **A heading that does something holds a control that does it.** The host is the column header, and a header is not focusable, so a sortable heading is a '<button>' inside it: the pattern for a sortable table, and the only way a reader on a keyboard reaches the sort at all. A column a reader may resize carries a 'separator' on its end edge, moved by dragging it or with the arrow keys, and a column in a table that lets a reader reorder its columns carries a grip the table moves. */
   "helix-headless-table-column": DefineCustomElement<
     HelixHeadlessTableColumn,
     HelixHeadlessTableColumnVueProps,
@@ -9888,7 +9875,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTableVueProps,
     HelixHeadlessTableVueEvents
   >;
-  /** 'display: contents' in the styled tier, so the row's cells become items of the table's own grid and every column lines up across every row. The row still exists as an element, which is what a '<table>' gives away when its cells are laid out by the table algorithm. */
+  /** The row renders its cells straight through and lays out none of them, so a sheet can take them into the table's own grid and every column lines up across every row. The row still exists as an element, which is what a '<table>' gives away when its cells are laid out by the table algorithm. */
   "helix-headless-table-row": DefineCustomElement<
     HelixHeadlessTableRow,
     HelixHeadlessTableRowVueProps,
@@ -9924,13 +9911,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTextareaVueProps,
     HelixHeadlessTextareaVueEvents
   >;
-  /** **The list is 'helix-time-picker', not a second one written here.** It is worth having on its own, flat in a settings pane with nothing to open, and this element is the field, the overlay and the form. Exactly the arrangement Input Date has with 'helix-date-picker' and Color Input with 'helix-color-picker'.  **Typed as well as picked, and that is the division the list depends on.** A list at a step offers the times a product actually has, and the field is how a reader says '09:07'. Neither is a worse version of the other: without the field a step is a cage, and without the list every common time is typed out.  **The value is 'HH:mm' on a twenty-four hour clock, always**, because that is what a form submits, what 'min' and 'max' compare against, and what sorts as a string. What the field *shows* is the reader's own convention while it is idle, and the value itself once the caret is in it: the same separation Input Date draws, and for the same reason, which is that '2:30 PM' cannot be typed back and 'Intl' has no parser to make it so. */
+  /** **The list is 'TimePicker', not a second one written here.** It is worth having on its own, flat in a settings pane with nothing to open, and this element is the field, the overlay and the form. Exactly the arrangement Input Date has with 'DatePicker' and Color Input with 'ColorPicker'.  **Typed as well as picked, and that is the division the list depends on.** A list at a step offers the times a product actually has, and the field is how a reader says '09:07'. Neither is a worse version of the other: without the field a step is a cage, and without the list every common time is typed out.  **The value is 'HH:mm' on a twenty-four hour clock, always**, because that is what a form submits, what 'min' and 'max' compare against, and what sorts as a string. What the field *shows* is the reader's own convention while it is idle, and the value itself once the caret is in it: the same separation Input Date draws, and for the same reason, which is that '2:30 PM' cannot be typed back and 'Intl' has no parser to make it so. */
   "helix-headless-time-input": DefineCustomElement<
     HelixHeadlessTimeInput,
     HelixHeadlessTimeInputVueProps,
     HelixHeadlessTimeInputVueEvents
   >;
-  /** **A list rather than three wheels**, and the reason is what a list already is. 'helix-listbox' brings the keyboard, the typeahead, the scroll into view and the announcement of a set of options, and a time at a step is a set of options. Three little wheels for hours, minutes and a meridiem are three controls to build, three to test, and a tab stop each for something a reader answers once.  **A step is what makes it a list at all.** Fifteen minutes is ninety-six rows, which a reader scrolls or types into; one minute is one thousand four hundred and forty, which is a listbox in name only. So the list is for the times a product actually offers, and arbitrary times are the field's job in Input Time, the same division Date Input draws between typing a date and using the calendar.  **The value is 'HH:mm' on a twenty-four hour clock, always.** That is what a form submits and what 'min' and 'max' compare against, and it sorts as a string, which is the whole reason the shape is that one. What each row *says* is the reader's own convention, from 'Intl'.  **The chosen row is marked in the markup, not worked out on upgrade.** The listbox is handed the answer as '.value', and lit-ssr serializes no property binding, so a served 'value="09:30"' shipped ninety-six rows with nothing on any of them saying which one it was: the mark arrived when the listbox upgraded and ran 'place'. So each option is given 'selected' as well, which is an attribute binding and does serve, and which the listbox then agrees with rather than fights, 'place' writing the same answer from the same value. 'selected' is the declaration a consumer writes on 'Option' anywhere else in the library, and Date Picker expresses its own choice as markup for the same reason: a picker whose answer is invisible until a script runs is a picker whose answer is not served at all. Both readings do it, the list and the wheels, a wheel being a listbox like the list is. */
+  /** **A list rather than three wheels**, and the reason is what a list already is. 'Listbox' brings the keyboard, the typeahead, the scroll into view and the announcement of a set of options, and a time at a step is a set of options. Three little wheels for hours, minutes and a meridiem are three controls to build, three to test, and a tab stop each for something a reader answers once.  **A step is what makes it a list at all.** Fifteen minutes is ninety-six rows, which a reader scrolls or types into; one minute is one thousand four hundred and forty, which is a listbox in name only. So the list is for the times a product actually offers, and arbitrary times are the field's job in Input Time, the same division Date Input draws between typing a date and using the calendar.  **The value is 'HH:mm' on a twenty-four hour clock, always.** That is what a form submits and what 'min' and 'max' compare against, and it sorts as a string, which is the whole reason the shape is that one. What each row *says* is the reader's own convention, from 'Intl'.  **The chosen row is marked in the markup, not worked out on upgrade.** The listbox is handed the answer as '.value', and lit-ssr serializes no property binding, so a served 'value="09:30"' shipped ninety-six rows with nothing on any of them saying which one it was: the mark arrived when the listbox upgraded and ran 'place'. So each option is given 'selected' as well, which is an attribute binding and does serve, and which the listbox then agrees with rather than fights, 'place' writing the same answer from the same value. 'selected' is the declaration a consumer writes on 'Option' anywhere else in the library, and Date Picker expresses its own choice as markup for the same reason: a picker whose answer is invisible until a script runs is a picker whose answer is not served at all. Both readings do it, the list and the wheels, a wheel being a listbox like the list is. */
   "helix-headless-time-picker": DefineCustomElement<
     HelixHeadlessTimePicker,
     HelixHeadlessTimePickerVueProps,
@@ -9978,7 +9965,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessToolbarVueProps,
     HelixHeadlessToolbarVueEvents
   >;
-  /** The trigger is slotted and stays the consumer's own element. The bubble is rendered here, in the top layer through the popover API, so it clears any ancestor with 'overflow: hidden' without a 'z-index' anywhere. Position comes from 'FloatingController', which flips to another side when the preferred one does not fit.  **Two forms, and they are not equivalent for a screen reader.** Wrapping is the convenience form and is right where the bubble decorates a control that already says what it is: nothing here can describe a slotted trigger, an IDREF being unable to cross a shadow boundary.  'for' is the form that works. The tooltip sits *beside* the trigger in the consumer's own tree and names it by id, so an IDREF between them is legal in the ordinary way:  '''html <helix-button id="save" aria-describedby="save-tip">Save</helix-button> <helix-tooltip id="save-tip" for="save" content="Save your work"></helix-tooltip> '''  The reference points at *this host*, not at the bubble in its shadow root: the description is computed from the flat tree, which descends into shadow content on its own.  **The consumer writes that 'aria-describedby', and nothing here writes it for them.** Setting it at runtime is a hydration mismatch React will not patch up. 'for' audits itself on first open and warns once where it is missing.  It shows on hover and on focus, and hides on leave, on blur, on Escape, and once the trigger has been activated: the hint is spent when the control has been used. */
+  /** The trigger is slotted and stays the consumer's own element. The bubble is rendered here, in the top layer through the popover API, so it clears any ancestor with 'overflow: hidden' without a 'z-index' anywhere. Position comes from 'FloatingController', which flips to another side when the preferred one does not fit.  **Two forms, and they are not equivalent for a screen reader.** Wrapping is the convenience form and is right where the bubble decorates a control that already says what it is: nothing here can describe a slotted trigger, an IDREF being unable to cross a shadow boundary.  'for' is the form that works. The tooltip sits *beside* the trigger in the consumer's own tree and names it by id, so an IDREF between them is legal in the ordinary way:  '''html <helix-headless-button id="save" aria-describedby="save-tip">Save</helix-headless-button> <helix-headless-tooltip id="save-tip" for="save" content="Save your work"></helix-headless-tooltip> '''  The reference points at *this host*, not at the bubble in its shadow root: the description is computed from the flat tree, which descends into shadow content on its own.  **The consumer writes that 'aria-describedby', and nothing here writes it for them.** Setting it at runtime is a hydration mismatch React will not patch up. 'for' audits itself on first open and warns once where it is missing.  It shows on hover and on focus, and hides on leave, on blur, on Escape, and once the trigger has been activated: the hint is spent when the control has been used. */
   "helix-headless-tooltip": DefineCustomElement<
     HelixHeadlessTooltip,
     HelixHeadlessTooltipVueProps,
@@ -9990,7 +9977,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTourVueProps,
     HelixHeadlessTourVueEvents
   >;
-  /** A stop names a target with 'for' and holds whatever the consumer puts in it. It owns no content of its own, which is the whole shape of this family: the tour abstracts the three things that are genuinely hard, and the words are the consumer's.  What it does own:  - **Where the panel goes.** Anchored to the target through the same floating   pass every other overlay here uses. - **That it is on top.** A popover, so it is in the top layer. A tour points   at things inside dialogs, inside scrollers, inside anything with a stacking   context, and a panel in the ordinary flow loses to all three. - **When it shows.** Which is 'current', and which the root decides.  What it does not own is the heading, the paragraph, the picture and the layout. Slot a 'helix-card', or a heading and a line of prose, or anything else. Fixed 'title' and 'body' parts would be a component deciding what a tour is allowed to say.  **The buttons are slot fallback, so the common case costs nothing and the uncommon one is possible.** Write nothing and get Back, Next and Skip already wired. Slot 'actions' and they are yours, driven by 'next()', 'back()' and 'skip()' on the root, which are public for exactly that.  **'for' is an id, the same as 'Tooltip''s.** The target is elsewhere on the page, and an id is the one reference a consumer can write in markup without holding an element. Resolved against the root node, so a stop inside a shadow tree points at a target in that tree. */
+  /** A stop names a target with 'for' and holds whatever the consumer puts in it. It owns no content of its own, which is the whole shape of this family: the tour abstracts the three things that are genuinely hard, and the words are the consumer's.  What it does own:  - **Where the panel goes.** Anchored to the target through the same floating   pass every other overlay here uses. - **That it is on top.** A popover, so it is in the top layer. A tour points   at things inside dialogs, inside scrollers, inside anything with a stacking   context, and a panel in the ordinary flow loses to all three. - **When it shows.** Which is 'current', and which the root decides.  What it does not own is the heading, the paragraph, the picture and the layout. Slot a 'Card', or a heading and a line of prose, or anything else. Fixed 'title' and 'body' parts would be a component deciding what a tour is allowed to say.  **The buttons are slot fallback, so the common case costs nothing and the uncommon one is possible.** Write nothing and get Back, Next and Skip already wired. Slot 'actions' and they are yours, driven by 'next()', 'back()' and 'skip()' on the root, which are public for exactly that.  **'for' is an id, the same as 'Tooltip''s.** The target is elsewhere on the page, and an id is the one reference a consumer can write in markup without holding an element. Resolved against the root node, so a stop inside a shadow tree points at a target in that tree. */
   "helix-headless-tour-stop": DefineCustomElement<
     HelixHeadlessTourStop,
     HelixHeadlessTourStopVueProps,