@fusion.dev/helix 0.41.1 → 0.43.0

package/types/jsx.d.ts

@@ -1087,13 +1087,17 @@ are interpolations, so a larger number extrapolates rather than
 exaggerating, and a streak whose length has passed through zero is drawn
 as a bar across the whole frame.
 
-Read by the shapes made of many similar things, whether those are counted
-or continuous: `streaks`, whose lanes draw a speed, a length, a width, a
-spacing and a weight apiece; `particles`, whose motes draw a size, a
-brightness and a wander; and `rays` and `aurora`, whose fan, bundles and
-folds widen or even out. `braid`, `waves` and `flow` have a
-single subject and nothing to vary, and `threads` is even on purpose, so on
-those four this is inert. */
+Read by four of the eleven shapes, the ones made of many similar things,
+whether those are counted or continuous: `streaks`, whose lanes draw a
+speed, a length, a width, a spacing and a weight apiece; `particles`, whose
+motes draw a size, a brightness and a wander; and `rays` and `aurora`, whose
+fan, bundles and folds widen or even out.
+
+Inert on the other seven, for three different reasons. `braid`, `waves` and
+`flow` have a single subject and nothing to vary. `threads` and `lattice`
+are even on purpose, a scatter of strands and a regular structure each being
+what it is because its members do not differ. `caustics` and `fracture` are
+populations this does not reach, which is a gap rather than a refusal. */
   variance?: (HelixAura["variance"]) | undefined;
   /** Which form the light takes. Absent is `braid`.
 
@@ -1185,13 +1189,17 @@ are interpolations, so a larger number extrapolates rather than
 exaggerating, and a streak whose length has passed through zero is drawn
 as a bar across the whole frame.
 
-Read by the shapes made of many similar things, whether those are counted
-or continuous: `streaks`, whose lanes draw a speed, a length, a width, a
-spacing and a weight apiece; `particles`, whose motes draw a size, a
-brightness and a wander; and `rays` and `aurora`, whose fan, bundles and
-folds widen or even out. `braid`, `waves` and `flow` have a
-single subject and nothing to vary, and `threads` is even on purpose, so on
-those four this is inert. */
+Read by four of the eleven shapes, the ones made of many similar things,
+whether those are counted or continuous: `streaks`, whose lanes draw a
+speed, a length, a width, a spacing and a weight apiece; `particles`, whose
+motes draw a size, a brightness and a wander; and `rays` and `aurora`, whose
+fan, bundles and folds widen or even out.
+
+Inert on the other seven, for three different reasons. `braid`, `waves` and
+`flow` have a single subject and nothing to vary. `threads` and `lattice`
+are even on purpose, a scatter of strands and a regular structure each being
+what it is because its members do not differ. `caustics` and `fracture` are
+populations this does not reach, which is a gap rather than a refusal. */
   "prop:variance"?: (HelixAura["variance"]) | undefined;
   /** Which form the light takes. Absent is `braid`.
 
@@ -1906,7 +1914,15 @@ export type HelixBreadcrumbsSolidJsProps = {
 };
 
 export type HelixButtonGroupProps = {
-  /** Whether the buttons are one bar or a spaced row. */
+  /** Whether the buttons are one bar or a spaced row.
+
+Joined by default: one control made of parts, sharing borders, reading as a
+segmented bar.
+
+`spaced` is the same set with air between them, for a row of related but
+separate actions. The semantics and the joining are separate questions:
+`role="group"` and a shared name are what make a set of buttons a set, and
+`helix-flex` gives the spacing without the group. */
   variant?: (HelixButtonGroup["variant"]) | undefined;
   /** Accessible name for the group.
 
@@ -1934,7 +1950,15 @@ column. */
 };
 
 export type HelixButtonGroupSolidJsProps = {
-  /** Whether the buttons are one bar or a spaced row. */
+  /** Whether the buttons are one bar or a spaced row.
+
+Joined by default: one control made of parts, sharing borders, reading as a
+segmented bar.
+
+`spaced` is the same set with air between them, for a row of related but
+separate actions. The semantics and the joining are separate questions:
+`role="group"` and a shared name are what make a set of buttons a set, and
+`helix-flex` gives the spacing without the group. */
   "prop:variant"?: (HelixButtonGroup["variant"]) | undefined;
   /** Accessible name for the group.
 
@@ -2802,7 +2826,7 @@ server markup never had, which React reports as a mismatch. The one-across
 case is the absent attribute, and the styles read it that way. */
   perView?: (HelixCarousel["perView"]) | undefined;
 
-  /** Fired when the slide in view changes, with its index. Cancelable: refusing it takes the decision and nothing moves. */
+  /** Fired when the slide in view changes, with its index. Cancelable where the carousel is about to move: refusing a control or an indicator takes the decision and nothing moves. A drag has already moved the track, so that one announces after the fact and refusing it does nothing. See `handleScroll`. */
   "onhelix-select"?: ((e: HelixCarouselHelixSelectElementEvent) => void) | undefined;
 };
 
@@ -3032,7 +3056,7 @@ its attribute on upgrade, and the host then carries something a consumer's
 server markup never had, which React reports as a mismatch. The one-across
 case is the absent attribute, and the styles read it that way. */
   "prop:perView"?: (HelixCarousel["perView"]) | undefined;
-  /** Fired when the slide in view changes, with its index. Cancelable: refusing it takes the decision and nothing moves. */
+  /** Fired when the slide in view changes, with its index. Cancelable where the carousel is about to move: refusing a control or an indicator takes the decision and nothing moves. A drag has already moved the track, so that one announces after the fact and refusing it does nothing. See `handleScroll`. */
   "on:helix-select"?: ((e: HelixCarouselHelixSelectElementEvent) => void) | undefined;
 
   /** Set the innerHTML of the element */
@@ -6604,9 +6628,36 @@ export type HelixDialogHelixBeforeOpenElementEvent =
   HelixDialogElementEvent<HelixBeforeOpenEvent>;
 
 export type HelixDialogProps = {
-  /** Whether the panel's contents run from the start or center on it. */
+  /** Which way the panel's contents read.
+
+One property for the whole panel rather than one per region. The regions are
+never mixed in practice: a dialog that asks a short question centers its
+mark, its title, its sentence and its buttons together, and a dialog holding
+a form runs all four from the start. Three properties would be three ways to
+write the same two arrangements, and a fourth way to get one of them wrong.
+
+Unset is `start` and stays unset, so a reflected default cannot appear on a
+host whose server output never had it. */
   align?: (HelixDialog["align"]) | undefined;
-  /** How wide the panel is allowed to be. */
+  /** How wide the panel is allowed to be.
+
+Steps rather than a number, because a dialog's width is a fact about what is
+in it: a confirmation is narrow, a form is not, and picking pixels per
+dialog is how a product ends up with nine of them. `full` takes the viewport
+less the same inset every step already stops short by, so a takeover is one
+more rung and not a second property.
+
+Unset is `md`, read as `:host(:not([size]))` beside `:host([size="md"])`
+rather than assigned here, for the reason `Drawer.placement` gives: this
+reflects, and a default would put `size="md"` into markup no consumer wrote.
+
+`size` is right despite the rule that controls have no size, because that
+rule's own test is whether two of them sitting together could legitimately
+differ, and it is answering "a ragged row is unwritable". Two dialogs never
+sit together. One is on screen at a time, in the top layer, and it is the
+region rather than a control in one, which is the same reason `Avatar` and
+`Spinner` keep theirs. Not `appearance`, which says how a thing reads
+rather than how wide it is. */
   size?: (HelixDialog["size"]) | undefined;
   /** Whether the element is open.
 
@@ -6682,9 +6733,36 @@ survives to it and a consumer reading one back gets what they wrote. */
 };
 
 export type HelixDialogSolidJsProps = {
-  /** Whether the panel's contents run from the start or center on it. */
+  /** Which way the panel's contents read.
+
+One property for the whole panel rather than one per region. The regions are
+never mixed in practice: a dialog that asks a short question centers its
+mark, its title, its sentence and its buttons together, and a dialog holding
+a form runs all four from the start. Three properties would be three ways to
+write the same two arrangements, and a fourth way to get one of them wrong.
+
+Unset is `start` and stays unset, so a reflected default cannot appear on a
+host whose server output never had it. */
   "prop:align"?: (HelixDialog["align"]) | undefined;
-  /** How wide the panel is allowed to be. */
+  /** How wide the panel is allowed to be.
+
+Steps rather than a number, because a dialog's width is a fact about what is
+in it: a confirmation is narrow, a form is not, and picking pixels per
+dialog is how a product ends up with nine of them. `full` takes the viewport
+less the same inset every step already stops short by, so a takeover is one
+more rung and not a second property.
+
+Unset is `md`, read as `:host(:not([size]))` beside `:host([size="md"])`
+rather than assigned here, for the reason `Drawer.placement` gives: this
+reflects, and a default would put `size="md"` into markup no consumer wrote.
+
+`size` is right despite the rule that controls have no size, because that
+rule's own test is whether two of them sitting together could legitimately
+differ, and it is answering "a ragged row is unwritable". Two dialogs never
+sit together. One is on screen at a time, in the top layer, and it is the
+region rather than a control in one, which is the same reason `Avatar` and
+`Spinner` keep theirs. Not `appearance`, which says how a thing reads
+rather than how wide it is. */
   "prop:size"?: (HelixDialog["size"]) | undefined;
   /** Whether the element is open.
 
@@ -12010,15 +12088,27 @@ Written by the listbox. */
 
 `<option selected>` reflects to `defaultSelected` and `option.selected` is
 live state that does not reflect, and those are two different facts. This
-element has one `selected` doing both jobs, so what is captured here is what
-the markup said at upgrade, before anything could overwrite it: read the
-attribute later and the listbox's own writes answer instead.
-
-**The deeper half is 302 and is not this.** State reflecting under the
-declaration's name is the fault `TreeItem` already avoids by mirroring to
-`data-selected`, and four families here still write `selected` back into a
-consumer's markup. Splitting them means moving what every stylesheet selects
-on, which is a change of its own rather than a property being added. */
+element has one `selected` doing both jobs, so the declaration is the
+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"
+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
+`willUpdate` records, so the listbox's writes never reach the attribute and
+what it says is what the markup said.
+
+**The deeper half is not this.** State reflecting under the declaration's
+name is the fault `TreeItem` avoids by mirroring to `data-selected`.
+Splitting them means moving what every stylesheet selects on, which is a
+change of its own rather than a property being added. */
   defaultSelected?: (HelixOption["defaultSelected"]) | undefined;
 
   /** Fired when this choice is made. Cancelable: refusing it takes the decision and nothing moves. */
@@ -12105,15 +12195,27 @@ Written by the listbox. */
 
 `<option selected>` reflects to `defaultSelected` and `option.selected` is
 live state that does not reflect, and those are two different facts. This
-element has one `selected` doing both jobs, so what is captured here is what
-the markup said at upgrade, before anything could overwrite it: read the
-attribute later and the listbox's own writes answer instead.
-
-**The deeper half is 302 and is not this.** State reflecting under the
-declaration's name is the fault `TreeItem` already avoids by mirroring to
-`data-selected`, and four families here still write `selected` back into a
-consumer's markup. Splitting them means moving what every stylesheet selects
-on, which is a change of its own rather than a property being added. */
+element has one `selected` doing both jobs, so the declaration is the
+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"
+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
+`willUpdate` records, so the listbox's writes never reach the attribute and
+what it says is what the markup said.
+
+**The deeper half is not this.** State reflecting under the declaration's
+name is the fault `TreeItem` avoids by mirroring to `data-selected`.
+Splitting them means moving what every stylesheet selects on, which is a
+change of its own rather than a property being added. */
   "prop:defaultSelected"?: (HelixOption["defaultSelected"]) | undefined;
   /** Fired when this choice is made. Cancelable: refusing it takes the decision and nothing moves. */
   "on:helix-select"?: ((e: HelixOptionHelixSelectElementEvent) => void) | undefined;
@@ -13512,9 +13614,22 @@ Written by the group. */
 
 `<option selected>` reflects to `defaultSelected` and `option.selected` is
 live state that does not reflect, and those are two different facts. This
-element has one `selected` doing both jobs, so what is captured here is what
-the markup said at upgrade, before anything could overwrite it: read the
-attribute later and the listbox's own writes answer instead.
+element has one `selected` doing both jobs, so the declaration is the
+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"
+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
+`willUpdate` records, so the group's writes never reach the attribute and
+what it says is what the markup said.
 
 **The deeper half is not this.** State reflecting under the declaration's
 name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -13589,9 +13704,22 @@ Written by the group. */
 
 `<option selected>` reflects to `defaultSelected` and `option.selected` is
 live state that does not reflect, and those are two different facts. This
-element has one `selected` doing both jobs, so what is captured here is what
-the markup said at upgrade, before anything could overwrite it: read the
-attribute later and the listbox's own writes answer instead.
+element has one `selected` doing both jobs, so the declaration is the
+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"
+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
+`willUpdate` records, so the group's writes never reach the attribute and
+what it says is what the markup said.
 
 **The deeper half is not this.** State reflecting under the declaration's
 name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -18231,9 +18359,22 @@ export type HelixToggleProps = {
 
 `<option selected>` reflects to `defaultSelected` and `option.selected` is
 live state that does not reflect, and those are two different facts. This
-element has one `selected` doing both jobs, so what is captured here is what
-the markup said at upgrade, before anything could overwrite it: read the
-attribute later and the listbox's own writes answer instead.
+element has one `selected` doing both jobs, so the declaration is the
+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.
+
+Nothing overwrites it either, which is what makes reading it late correct
+rather than merely later: `selected` does not reflect, for the reason
+`willUpdate` records, so the group's writes never reach the attribute and
+what it says is what the markup said.
 
 **The deeper half is not this.** State reflecting under the declaration's
 name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -18264,9 +18405,22 @@ export type HelixToggleSolidJsProps = {
 
 `<option selected>` reflects to `defaultSelected` and `option.selected` is
 live state that does not reflect, and those are two different facts. This
-element has one `selected` doing both jobs, so what is captured here is what
-the markup said at upgrade, before anything could overwrite it: read the
-attribute later and the listbox's own writes answer instead.
+element has one `selected` doing both jobs, so the declaration is the
+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.
+
+Nothing overwrites it either, which is what makes reading it late correct
+rather than merely later: `selected` does not reflect, for the reason
+`willUpdate` records, so the group's writes never reach the attribute and
+what it says is what the markup said.
 
 **The deeper half is not this.** State reflecting under the declaration's
 name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -19462,7 +19616,35 @@ export type HelixVideoHelixPreviousElementEvent =
   HelixVideoElementEvent<HelixPreviousEvent>;
 
 export type HelixVideoProps = {
-  /** Whether the bar floats on the picture or sits on its own ground. */
+  /** How the control bar sits on the picture.
+
+`separation` and not `emphasis`: all three states say what the bar sits on,
+which is where it separates from the picture, rather than how loud it is.
+
+Absent is the default and is what a player looks like, and what the
+platform's own controls do: they float on a gradient that fades up into the
+picture, dark enough to read them against a bright frame and gone entirely
+a little higher up. The picture runs edge to edge behind them. It has no
+name because it is the resting treatment.
+
+`filled` gives the controls a bar of their own, which is what a video
+embedded in a document usually wants, where the player is a component on a
+page rather than the page itself. It stays put rather than fading, because
+a bar that is part of the frame would leave a strip of the well behind it.
+
+`plain` is neither: the controls sit straight on the picture with nothing
+behind them. For a consumer who knows their footage, or who is putting
+their own ground there.
+
+A presentation property, so it lives on this tier. The headless element renders
+the same bar for all three.
+
+**Optional rather than defaulted, which is not a style preference.** A
+reflecting property with a default writes its attribute onto every host the
+moment the element upgrades, including the ones a consumer rendered and did
+not touch, and React reads that as a hydration mismatch. The absent
+attribute *is* the shadow, which the stylesheet reads as the base rule, so
+only the departure has to be named. */
   separation?: (HelixVideo["separation"]) | undefined;
   /** Whether it starts on its own, which a browser only allows while silent.
 
@@ -19711,7 +19893,35 @@ past the end is the one write the platform answers with an exception. */
 };
 
 export type HelixVideoSolidJsProps = {
-  /** Whether the bar floats on the picture or sits on its own ground. */
+  /** How the control bar sits on the picture.
+
+`separation` and not `emphasis`: all three states say what the bar sits on,
+which is where it separates from the picture, rather than how loud it is.
+
+Absent is the default and is what a player looks like, and what the
+platform's own controls do: they float on a gradient that fades up into the
+picture, dark enough to read them against a bright frame and gone entirely
+a little higher up. The picture runs edge to edge behind them. It has no
+name because it is the resting treatment.
+
+`filled` gives the controls a bar of their own, which is what a video
+embedded in a document usually wants, where the player is a component on a
+page rather than the page itself. It stays put rather than fading, because
+a bar that is part of the frame would leave a strip of the well behind it.
+
+`plain` is neither: the controls sit straight on the picture with nothing
+behind them. For a consumer who knows their footage, or who is putting
+their own ground there.
+
+A presentation property, so it lives on this tier. The headless element renders
+the same bar for all three.
+
+**Optional rather than defaulted, which is not a style preference.** A
+reflecting property with a default writes its attribute onto every host the
+moment the element upgrades, including the ones a consumer rendered and did
+not touch, and React reads that as a hydration mismatch. The absent
+attribute *is* the shadow, which the stylesheet reads as the base rule, so
+only the departure has to be named. */
   "prop:separation"?: (HelixVideo["separation"]) | undefined;
   /** Whether it starts on its own, which a browser only allows while silent.
 
@@ -20779,13 +20989,17 @@ export type CustomElements = {
    * exaggerating, and a streak whose length has passed through zero is drawn
    * as a bar across the whole frame.
    *
-   * Read by the shapes made of many similar things, whether those are counted
-   * or continuous: `streaks`, whose lanes draw a speed, a length, a width, a
-   * spacing and a weight apiece; `particles`, whose motes draw a size, a
-   * brightness and a wander; and `rays` and `aurora`, whose fan, bundles and
-   * folds widen or even out. `braid`, `waves` and `flow` have a
-   * single subject and nothing to vary, and `threads` is even on purpose, so on
-   * those four this is inert.
+   * Read by four of the eleven shapes, the ones made of many similar things,
+   * whether those are counted or continuous: `streaks`, whose lanes draw a
+   * speed, a length, a width, a spacing and a weight apiece; `particles`, whose
+   * motes draw a size, a brightness and a wander; and `rays` and `aurora`, whose
+   * fan, bundles and folds widen or even out.
+   *
+   * Inert on the other seven, for three different reasons. `braid`, `waves` and
+   * `flow` have a single subject and nothing to vary. `threads` and `lattice`
+   * are even on purpose, a scatter of strands and a regular structure each being
+   * what it is because its members do not differ. `caustics` and `fracture` are
+   * populations this does not reach, which is a gap rather than a refusal.
    * - `variant`: Which form the light takes. Absent is `braid`.
    *
    * Reflected because the fallback gradient selects on it, and given no default
@@ -21656,6 +21870,14 @@ export type CustomElements = {
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
    * - `variant`: Whether the buttons are one bar or a spaced row.
+   *
+   * Joined by default: one control made of parts, sharing borders, reading as a
+   * segmented bar.
+   *
+   * `spaced` is the same set with air between them, for a row of related but
+   * separate actions. The semantics and the joining are separate questions:
+   * `role="group"` and a shared name are what make a set of buttons a set, and
+   * `helix-flex` gives the spacing without the group.
    * - `label`: Accessible name for the group.
    *
    * On the host through internals, so an author's `aria-label` still overrides
@@ -22372,7 +22594,7 @@ export type CustomElements = {
    *
    * Events that will be emitted by the component.
    *
-   * - `helix-select`: Fired when the slide in view changes, with its index. Cancelable: refusing it takes the decision and nothing moves.
+   * - `helix-select`: Fired when the slide in view changes, with its index. Cancelable where the carousel is about to move: refusing a control or an indicator takes the decision and nothing moves. A drag has already moved the track, so that one announces after the fact and refusing it does nothing. See `handleScroll`.
    *
    * ## Slots
    *
@@ -25132,9 +25354,12 @@ export type CustomElements = {
    * difference is the space between days, which belongs to the track rather than
    * to a `gap`, so a range can paint across the whole track and stay continuous.
    *
-   * Days from the neighboring months stay in place and stay selectable, marked
-   * quieter rather than hidden, so the first and last weeks are whole and the
-   * grid reads as a continuous run of dates.
+   * Days from the neighboring months stay in place, marked quieter rather than
+   * hidden, so the first and last weeks are whole rows rather than ragged ones.
+   * They are filler and take no click, which the pointer says: no hover, and the
+   * cursor a box that does nothing has. At `months="2"` the same date is a
+   * trailing cell in one grid and a real one in the next, so a filler day that
+   * could be chosen would put one answer on the page twice.
    *
    * ## Attributes & Properties
    *
@@ -25542,8 +25767,35 @@ export type CustomElements = {
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
-   * - `align`: Whether the panel's contents run from the start or center on it.
+   * - `align`: Which way the panel's contents read.
+   *
+   * One property for the whole panel rather than one per region. The regions are
+   * never mixed in practice: a dialog that asks a short question centers its
+   * mark, its title, its sentence and its buttons together, and a dialog holding
+   * a form runs all four from the start. Three properties would be three ways to
+   * write the same two arrangements, and a fourth way to get one of them wrong.
+   *
+   * Unset is `start` and stays unset, so a reflected default cannot appear on a
+   * host whose server output never had it.
    * - `size`: How wide the panel is allowed to be.
+   *
+   * Steps rather than a number, because a dialog's width is a fact about what is
+   * in it: a confirmation is narrow, a form is not, and picking pixels per
+   * dialog is how a product ends up with nine of them. `full` takes the viewport
+   * less the same inset every step already stops short by, so a takeover is one
+   * more rung and not a second property.
+   *
+   * Unset is `md`, read as `:host(:not([size]))` beside `:host([size="md"])`
+   * rather than assigned here, for the reason `Drawer.placement` gives: this
+   * reflects, and a default would put `size="md"` into markup no consumer wrote.
+   *
+   * `size` is right despite the rule that controls have no size, because that
+   * rule's own test is whether two of them sitting together could legitimately
+   * differ, and it is answering "a ragged row is unwritable". Two dialogs never
+   * sit together. One is on screen at a time, in the top layer, and it is the
+   * region rather than a control in one, which is the same reason `Avatar` and
+   * `Spinner` keep theirs. Not `appearance`, which says how a thing reads
+   * rather than how wide it is.
    * - `open`: Whether the element is open.
    *
    * One property, not two, so `dialog.open` answers the question anyone
@@ -31036,15 +31288,27 @@ export type CustomElements = {
    *
    * `<option selected>` reflects to `defaultSelected` and `option.selected` is
    * live state that does not reflect, and those are two different facts. This
-   * element has one `selected` doing both jobs, so what is captured here is what
-   * the markup said at upgrade, before anything could overwrite it: read the
-   * attribute later and the listbox's own writes answer instead.
-   *
-   * **The deeper half is 302 and is not this.** State reflecting under the
-   * declaration's name is the fault `TreeItem` already avoids by mirroring to
-   * `data-selected`, and four families here still write `selected` back into a
-   * consumer's markup. Splitting them means moving what every stylesheet selects
-   * on, which is a change of its own rather than a property being added. (property only)
+   * element has one `selected` doing both jobs, so the declaration is the
+   * 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"
+   * 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
+   * `willUpdate` records, so the listbox's writes never reach the attribute and
+   * what it says is what the markup said.
+   *
+   * **The deeper half is not this.** State reflecting under the declaration's
+   * name is the fault `TreeItem` avoids by mirroring to `data-selected`.
+   * Splitting them means moving what every stylesheet selects on, which is a
+   * change of its own rather than a property being added. (property only)
    * - `text`: The words, for a listbox that has to match text against them.
    *
    * Read from the rendered content rather than required as a property, because
@@ -32542,9 +32806,22 @@ export type CustomElements = {
    *
    * `<option selected>` reflects to `defaultSelected` and `option.selected` is
    * live state that does not reflect, and those are two different facts. This
-   * element has one `selected` doing both jobs, so what is captured here is what
-   * the markup said at upgrade, before anything could overwrite it: read the
-   * attribute later and the listbox's own writes answer instead.
+   * element has one `selected` doing both jobs, so the declaration is the
+   * 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"
+   * 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
+   * `willUpdate` records, so the group's writes never reach the attribute and
+   * what it says is what the markup said.
    *
    * **The deeper half is not this.** State reflecting under the declaration's
    * name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -34226,9 +34503,9 @@ export type CustomElements = {
    * - `--slider-track-image`: The whole track, for a slider whose color is the value. (default: `undefined`)
    * - `--slider-track-size`: How thick the track is. The progress bar's own size by default, the two being the same object. (default: `undefined`)
    * - `--slider-fraction`: The value as a fraction of the range, 0 to 1. (default: `undefined`)
-   * - `--slider-from`: Where the filled span starts, as a percentage of the track. (default: `undefined`)
+   * - `--slider-from`: Where a range's filled span starts, as a fraction of the track, 0 to 1. (default: `undefined`)
    * - `--slider-marker-at`: Where one marker sits, as a percentage of the track. (default: `undefined`)
-   * - `--slider-to`: Where the filled span ends, as a percentage of the track. (default: `undefined`)
+   * - `--slider-to`: Where a range's filled span ends, as a fraction of the track, 0 to 1. (default: `undefined`)
    *
    * ## CSS Parts
    *
@@ -37416,6 +37693,8 @@ export type CustomElements = {
    * Areas where markup can be added to the component.
    *
    * - `(default)`: The group's items.
+   * - `end`: Whatever sits after the track on its own line, such as a count or a reset.
+   * - `start`: Whatever sits before the track on its own line, such as an icon or a caption.
    *
    * ## Methods
    *
@@ -37517,9 +37796,22 @@ export type CustomElements = {
    *
    * `<option selected>` reflects to `defaultSelected` and `option.selected` is
    * live state that does not reflect, and those are two different facts. This
-   * element has one `selected` doing both jobs, so what is captured here is what
-   * the markup said at upgrade, before anything could overwrite it: read the
-   * attribute later and the listbox's own writes answer instead.
+   * element has one `selected` doing both jobs, so the declaration is the
+   * 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.
+   *
+   * Nothing overwrites it either, which is what makes reading it late correct
+   * rather than merely later: `selected` does not reflect, for the reason
+   * `willUpdate` records, so the group's writes never reach the attribute and
+   * what it says is what the markup said.
    *
    * **The deeper half is not this.** State reflecting under the declaration's
    * name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -37580,7 +37872,7 @@ export type CustomElements = {
    *
    * Custom selectors for styling elements within the component.
    *
-   * - `item`: The button or anchor.
+   * - `item`: The radio button.
    *
    * ## CSS States
    *
@@ -38774,7 +39066,35 @@ export type CustomElements = {
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
-   * - `separation`: Whether the bar floats on the picture or sits on its own ground.
+   * - `separation`: How the control bar sits on the picture.
+   *
+   * `separation` and not `emphasis`: all three states say what the bar sits on,
+   * which is where it separates from the picture, rather than how loud it is.
+   *
+   * Absent is the default and is what a player looks like, and what the
+   * platform's own controls do: they float on a gradient that fades up into the
+   * picture, dark enough to read them against a bright frame and gone entirely
+   * a little higher up. The picture runs edge to edge behind them. It has no
+   * name because it is the resting treatment.
+   *
+   * `filled` gives the controls a bar of their own, which is what a video
+   * embedded in a document usually wants, where the player is a component on a
+   * page rather than the page itself. It stays put rather than fading, because
+   * a bar that is part of the frame would leave a strip of the well behind it.
+   *
+   * `plain` is neither: the controls sit straight on the picture with nothing
+   * behind them. For a consumer who knows their footage, or who is putting
+   * their own ground there.
+   *
+   * A presentation property, so it lives on this tier. The headless element renders
+   * the same bar for all three.
+   *
+   * **Optional rather than defaulted, which is not a style preference.** A
+   * reflecting property with a default writes its attribute onto every host the
+   * moment the element upgrades, including the ones a consumer rendered and did
+   * not touch, and React reads that as a hydration mismatch. The absent
+   * attribute *is* the shadow, which the stylesheet reads as the base rule, so
+   * only the departure has to be named.
    * - `autoplay`: Whether it starts on its own, which a browser only allows while silent.
    *
    * Forwarded rather than acted on. Whether an unprompted play is permitted is
@@ -39899,13 +40219,17 @@ export type CustomElementsSolidJs = {
    * exaggerating, and a streak whose length has passed through zero is drawn
    * as a bar across the whole frame.
    *
-   * Read by the shapes made of many similar things, whether those are counted
-   * or continuous: `streaks`, whose lanes draw a speed, a length, a width, a
-   * spacing and a weight apiece; `particles`, whose motes draw a size, a
-   * brightness and a wander; and `rays` and `aurora`, whose fan, bundles and
-   * folds widen or even out. `braid`, `waves` and `flow` have a
-   * single subject and nothing to vary, and `threads` is even on purpose, so on
-   * those four this is inert.
+   * Read by four of the eleven shapes, the ones made of many similar things,
+   * whether those are counted or continuous: `streaks`, whose lanes draw a
+   * speed, a length, a width, a spacing and a weight apiece; `particles`, whose
+   * motes draw a size, a brightness and a wander; and `rays` and `aurora`, whose
+   * fan, bundles and folds widen or even out.
+   *
+   * Inert on the other seven, for three different reasons. `braid`, `waves` and
+   * `flow` have a single subject and nothing to vary. `threads` and `lattice`
+   * are even on purpose, a scatter of strands and a regular structure each being
+   * what it is because its members do not differ. `caustics` and `fracture` are
+   * populations this does not reach, which is a gap rather than a refusal.
    * - `variant`: Which form the light takes. Absent is `braid`.
    *
    * Reflected because the fallback gradient selects on it, and given no default
@@ -40801,6 +41125,14 @@ export type CustomElementsSolidJs = {
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
    * - `variant`: Whether the buttons are one bar or a spaced row.
+   *
+   * Joined by default: one control made of parts, sharing borders, reading as a
+   * segmented bar.
+   *
+   * `spaced` is the same set with air between them, for a row of related but
+   * separate actions. The semantics and the joining are separate questions:
+   * `role="group"` and a shared name are what make a set of buttons a set, and
+   * `helix-flex` gives the spacing without the group.
    * - `label`: Accessible name for the group.
    *
    * On the host through internals, so an author's `aria-label` still overrides
@@ -41528,7 +41860,7 @@ export type CustomElementsSolidJs = {
    *
    * Events that will be emitted by the component.
    *
-   * - `helix-select`: Fired when the slide in view changes, with its index. Cancelable: refusing it takes the decision and nothing moves.
+   * - `helix-select`: Fired when the slide in view changes, with its index. Cancelable where the carousel is about to move: refusing a control or an indicator takes the decision and nothing moves. A drag has already moved the track, so that one announces after the fact and refusing it does nothing. See `handleScroll`.
    *
    * ## Slots
    *
@@ -44331,9 +44663,12 @@ export type CustomElementsSolidJs = {
    * difference is the space between days, which belongs to the track rather than
    * to a `gap`, so a range can paint across the whole track and stay continuous.
    *
-   * Days from the neighboring months stay in place and stay selectable, marked
-   * quieter rather than hidden, so the first and last weeks are whole and the
-   * grid reads as a continuous run of dates.
+   * Days from the neighboring months stay in place, marked quieter rather than
+   * hidden, so the first and last weeks are whole rows rather than ragged ones.
+   * They are filler and take no click, which the pointer says: no hover, and the
+   * cursor a box that does nothing has. At `months="2"` the same date is a
+   * trailing cell in one grid and a real one in the next, so a filler day that
+   * could be chosen would put one answer on the page twice.
    *
    * ## Attributes & Properties
    *
@@ -44748,8 +45083,35 @@ export type CustomElementsSolidJs = {
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
-   * - `align`: Whether the panel's contents run from the start or center on it.
+   * - `align`: Which way the panel's contents read.
+   *
+   * One property for the whole panel rather than one per region. The regions are
+   * never mixed in practice: a dialog that asks a short question centers its
+   * mark, its title, its sentence and its buttons together, and a dialog holding
+   * a form runs all four from the start. Three properties would be three ways to
+   * write the same two arrangements, and a fourth way to get one of them wrong.
+   *
+   * Unset is `start` and stays unset, so a reflected default cannot appear on a
+   * host whose server output never had it.
    * - `size`: How wide the panel is allowed to be.
+   *
+   * Steps rather than a number, because a dialog's width is a fact about what is
+   * in it: a confirmation is narrow, a form is not, and picking pixels per
+   * dialog is how a product ends up with nine of them. `full` takes the viewport
+   * less the same inset every step already stops short by, so a takeover is one
+   * more rung and not a second property.
+   *
+   * Unset is `md`, read as `:host(:not([size]))` beside `:host([size="md"])`
+   * rather than assigned here, for the reason `Drawer.placement` gives: this
+   * reflects, and a default would put `size="md"` into markup no consumer wrote.
+   *
+   * `size` is right despite the rule that controls have no size, because that
+   * rule's own test is whether two of them sitting together could legitimately
+   * differ, and it is answering "a ragged row is unwritable". Two dialogs never
+   * sit together. One is on screen at a time, in the top layer, and it is the
+   * region rather than a control in one, which is the same reason `Avatar` and
+   * `Spinner` keep theirs. Not `appearance`, which says how a thing reads
+   * rather than how wide it is.
    * - `open`: Whether the element is open.
    *
    * One property, not two, so `dialog.open` answers the question anyone
@@ -50361,15 +50723,27 @@ export type CustomElementsSolidJs = {
    *
    * `<option selected>` reflects to `defaultSelected` and `option.selected` is
    * live state that does not reflect, and those are two different facts. This
-   * element has one `selected` doing both jobs, so what is captured here is what
-   * the markup said at upgrade, before anything could overwrite it: read the
-   * attribute later and the listbox's own writes answer instead.
-   *
-   * **The deeper half is 302 and is not this.** State reflecting under the
-   * declaration's name is the fault `TreeItem` already avoids by mirroring to
-   * `data-selected`, and four families here still write `selected` back into a
-   * consumer's markup. Splitting them means moving what every stylesheet selects
-   * on, which is a change of its own rather than a property being added. (property only)
+   * element has one `selected` doing both jobs, so the declaration is the
+   * 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"
+   * 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
+   * `willUpdate` records, so the listbox's writes never reach the attribute and
+   * what it says is what the markup said.
+   *
+   * **The deeper half is not this.** State reflecting under the declaration's
+   * name is the fault `TreeItem` avoids by mirroring to `data-selected`.
+   * Splitting them means moving what every stylesheet selects on, which is a
+   * change of its own rather than a property being added. (property only)
    * - `text`: The words, for a listbox that has to match text against them.
    *
    * Read from the rendered content rather than required as a property, because
@@ -51904,9 +52278,22 @@ export type CustomElementsSolidJs = {
    *
    * `<option selected>` reflects to `defaultSelected` and `option.selected` is
    * live state that does not reflect, and those are two different facts. This
-   * element has one `selected` doing both jobs, so what is captured here is what
-   * the markup said at upgrade, before anything could overwrite it: read the
-   * attribute later and the listbox's own writes answer instead.
+   * element has one `selected` doing both jobs, so the declaration is the
+   * 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"
+   * 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
+   * `willUpdate` records, so the group's writes never reach the attribute and
+   * what it says is what the markup said.
    *
    * **The deeper half is not this.** State reflecting under the declaration's
    * name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -53629,9 +54016,9 @@ export type CustomElementsSolidJs = {
    * - `--slider-track-image`: The whole track, for a slider whose color is the value. (default: `undefined`)
    * - `--slider-track-size`: How thick the track is. The progress bar's own size by default, the two being the same object. (default: `undefined`)
    * - `--slider-fraction`: The value as a fraction of the range, 0 to 1. (default: `undefined`)
-   * - `--slider-from`: Where the filled span starts, as a percentage of the track. (default: `undefined`)
+   * - `--slider-from`: Where a range's filled span starts, as a fraction of the track, 0 to 1. (default: `undefined`)
    * - `--slider-marker-at`: Where one marker sits, as a percentage of the track. (default: `undefined`)
-   * - `--slider-to`: Where the filled span ends, as a percentage of the track. (default: `undefined`)
+   * - `--slider-to`: Where a range's filled span ends, as a fraction of the track, 0 to 1. (default: `undefined`)
    *
    * ## CSS Parts
    *
@@ -56897,6 +57284,8 @@ export type CustomElementsSolidJs = {
    * Areas where markup can be added to the component.
    *
    * - `(default)`: The group's items.
+   * - `end`: Whatever sits after the track on its own line, such as a count or a reset.
+   * - `start`: Whatever sits before the track on its own line, such as an icon or a caption.
    *
    * ## Methods
    *
@@ -57001,9 +57390,22 @@ export type CustomElementsSolidJs = {
    *
    * `<option selected>` reflects to `defaultSelected` and `option.selected` is
    * live state that does not reflect, and those are two different facts. This
-   * element has one `selected` doing both jobs, so what is captured here is what
-   * the markup said at upgrade, before anything could overwrite it: read the
-   * attribute later and the listbox's own writes answer instead.
+   * element has one `selected` doing both jobs, so the declaration is the
+   * 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.
+   *
+   * Nothing overwrites it either, which is what makes reading it late correct
+   * rather than merely later: `selected` does not reflect, for the reason
+   * `willUpdate` records, so the group's writes never reach the attribute and
+   * what it says is what the markup said.
    *
    * **The deeper half is not this.** State reflecting under the declaration's
    * name is the fault `TreeItem` avoids by mirroring to `data-selected`.
@@ -57064,7 +57466,7 @@ export type CustomElementsSolidJs = {
    *
    * Custom selectors for styling elements within the component.
    *
-   * - `item`: The button or anchor.
+   * - `item`: The radio button.
    *
    * ## CSS States
    *
@@ -58291,7 +58693,35 @@ export type CustomElementsSolidJs = {
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
-   * - `separation`: Whether the bar floats on the picture or sits on its own ground.
+   * - `separation`: How the control bar sits on the picture.
+   *
+   * `separation` and not `emphasis`: all three states say what the bar sits on,
+   * which is where it separates from the picture, rather than how loud it is.
+   *
+   * Absent is the default and is what a player looks like, and what the
+   * platform's own controls do: they float on a gradient that fades up into the
+   * picture, dark enough to read them against a bright frame and gone entirely
+   * a little higher up. The picture runs edge to edge behind them. It has no
+   * name because it is the resting treatment.
+   *
+   * `filled` gives the controls a bar of their own, which is what a video
+   * embedded in a document usually wants, where the player is a component on a
+   * page rather than the page itself. It stays put rather than fading, because
+   * a bar that is part of the frame would leave a strip of the well behind it.
+   *
+   * `plain` is neither: the controls sit straight on the picture with nothing
+   * behind them. For a consumer who knows their footage, or who is putting
+   * their own ground there.
+   *
+   * A presentation property, so it lives on this tier. The headless element renders
+   * the same bar for all three.
+   *
+   * **Optional rather than defaulted, which is not a style preference.** A
+   * reflecting property with a default writes its attribute onto every host the
+   * moment the element upgrades, including the ones a consumer rendered and did
+   * not touch, and React reads that as a hydration mismatch. The absent
+   * attribute *is* the shadow, which the stylesheet reads as the base rule, so
+   * only the departure has to be named.
    * - `autoplay`: Whether it starts on its own, which a browser only allows while silent.
    *
    * Forwarded rather than acted on. Whether an unprompted play is permitted is
@@ -59463,11 +59893,11 @@ export type CustomCssProperties = {
   "--slider-track-size"?: (string) | undefined;
   /** The value as a fraction of the range, 0 to 1. */
   "--slider-fraction"?: (string) | undefined;
-  /** Where the filled span starts, as a percentage of the track. */
+  /** Where a range's filled span starts, as a fraction of the track, 0 to 1. */
   "--slider-from"?: (string) | undefined;
   /** Where one marker sits, as a percentage of the track. */
   "--slider-marker-at"?: (string) | undefined;
-  /** Where the filled span ends, as a percentage of the track. */
+  /** Where a range's filled span ends, as a fraction of the track, 0 to 1. */
   "--slider-to"?: (string) | undefined;
   /** How much of the line's color the wash takes where it meets the line. */
   "--sparkline-area-opacity"?: (string) | undefined;