@fusion.dev/helix-headless 0.41.1 → 0.43.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fusion.dev/helix-headless",
   "description": "Headless component tier. Structure, accessibility, state, and form participation. No styling.",
-  "version": "0.41.1",
+  "version": "0.43.0",
   "license": "MIT",
   "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
   "repository": {
@@ -46,14 +46,14 @@
   },
   "bugs": "https://github.com/project-fusion/fusion/issues",
   "dependencies": {
-    "@fusion.dev/helix-core": "0.41.1",
-    "@fusion.dev/helix-icons": "0.41.1",
+    "@fusion.dev/helix-core": "0.43.0",
+    "@fusion.dev/helix-icons": "0.43.0",
     "uqr": "^0.1.3"
   },
   "devDependencies": {
     "@custom-elements-manifest/analyzer": "^0.11.0",
-    "@fusion.dev/helix-cem": "0.41.1",
-    "@fusion.dev/helix-testing": "0.41.1",
+    "@fusion.dev/helix-cem": "0.43.0",
+    "@fusion.dev/helix-testing": "0.43.0",
     "@fusion.dev/scripts": "0.0.0-dev",
     "@happy-dom/global-registrator": "^20.0.0",
     "@lit-labs/ssr": "^4.1.0",

package/types/jsx.d.ts

@@ -1861,7 +1861,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?: (HelixHeadlessCarousel["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: HelixHeadlessCarouselHelixSelectElementEvent) => void) | undefined;
 };
 
@@ -1961,7 +1961,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"?: (HelixHeadlessCarousel["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: HelixHeadlessCarouselHelixSelectElementEvent) => void) | undefined;
 
   /** Set the innerHTML of the element */
@@ -10296,15 +10296,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?: (HelixHeadlessOption["defaultSelected"]) | undefined;
 
   /** Fired when this choice is made. Cancelable: refusing it takes the decision and nothing moves. */
@@ -10391,15 +10403,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"?: (HelixHeadlessOption["defaultSelected"]) | undefined;
   /** Fired when this choice is made. Cancelable: refusing it takes the decision and nothing moves. */
   "on:helix-select"?: ((e: HelixHeadlessOptionHelixSelectElementEvent) => void) | undefined;
@@ -11669,9 +11693,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`.
@@ -11696,9 +11733,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`.
@@ -15520,9 +15570,22 @@ export type HelixHeadlessToggleProps = {
 
 `<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`.
@@ -15553,9 +15616,22 @@ export type HelixHeadlessToggleSolidJsProps = {
 
 `<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`.
@@ -19076,7 +19152,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
    *
@@ -27561,15 +27637,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
@@ -28948,9 +29036,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`.
@@ -29885,6 +29986,13 @@ export type CustomElements = {
    * **A range is two of them.** There is no native two-thumb range, so two are
    * stacked on one track and each thumb keeps its own.
    *
+   * **`required` arrives with the field mixin and cannot fail here**, which is
+   * worth saying rather than leaving a reader to find. A range is never empty:
+   * the platform shows its own midpoint whatever is set, and `willUpdate` seeds
+   * that midpoint into `defaultValue` so the value agrees with the handle from the
+   * first render. HTML does not apply `required` to a range either, so it stays
+   * off the control and the marker beside the label is all it does.
+   *
    * ## Attributes & Properties
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
@@ -30049,9 +30157,9 @@ export type CustomElements = {
    * CSS variables available for styling the component.
    *
    * - `--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
    *
@@ -33118,6 +33226,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
    *
@@ -33217,9 +33327,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`.
@@ -36749,7 +36872,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
    *
@@ -45349,15 +45472,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
@@ -46761,9 +46896,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`.
@@ -47715,6 +47863,13 @@ export type CustomElementsSolidJs = {
    * **A range is two of them.** There is no native two-thumb range, so two are
    * stacked on one track and each thumb keeps its own.
    *
+   * **`required` arrives with the field mixin and cannot fail here**, which is
+   * worth saying rather than leaving a reader to find. A range is never empty:
+   * the platform shows its own midpoint whatever is set, and `willUpdate` seeds
+   * that midpoint into `defaultValue` so the value agrees with the handle from the
+   * first render. HTML does not apply `required` to a range either, so it stays
+   * off the control and the marker beside the label is all it does.
+   *
    * ## Attributes & Properties
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
@@ -47879,9 +48034,9 @@ export type CustomElementsSolidJs = {
    * CSS variables available for styling the component.
    *
    * - `--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
    *
@@ -51015,6 +51170,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
    *
@@ -51115,9 +51272,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`.
@@ -52860,11 +53030,11 @@ export type CustomCssProperties = {
   "--chart-tick"?: (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;
   /** Where a nested splitter crosses this one, as a percentage. */
   "--splitter-corner-at"?: (string) | undefined;

package/types/vue.d.ts

@@ -1009,7 +1009,7 @@ case is the absent attribute, and the styles read it that way. */
 };
 
 export type HelixHeadlessCarouselVueEvents = {
-  /** 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`. */
   "helix-select": HelixHeadlessCarouselHelixSelectElementEvent;
 };
 
@@ -5318,15 +5318,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?: (HelixHeadlessOption["defaultSelected"]) | undefined;
 };
 
@@ -5987,9 +5999,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`.
@@ -7967,9 +7992,22 @@ export type HelixHeadlessToggleVueProps = {
 
 `<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`.
@@ -8928,11 +8966,11 @@ export type CustomCssProperties = {
   "--chart-tick"?: (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;
   /** Where a nested splitter crosses this one, as a percentage. */
   "--splitter-corner-at"?: (string) | undefined;
@@ -9494,7 +9532,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessSkipLinkVueProps,
     HelixHeadlessSkipLinkVueEvents
   >;
-  /** A real '<input type="range">', so the drag, the arrow keys, Home and End, the page keys and the touch target are the platform's. The last is the one nobody notices: a native range has a hit area larger than its thumb, sized by the platform for a finger.  **The value is a string, like every other form control's.** A range submits text and 'MixinControllerValue' holds text, so the number is a reading of the value. 'valueAsNumber' is there for arithmetic.  **Marks are drawn rather than left to '<datalist>'**, whose ticks cannot be styled and which Firefox does not render for a range at all. A mark is decoration; what a reader can land on is 'step', which the input enforces whether or not anything is drawn. 'markers' is a count rather than a flag, so a slider from zero to a hundred cannot silently ask for a hundred and one.  **A range is two of them.** There is no native two-thumb range, so two are stacked on one track and each thumb keeps its own. */
+  /** A real '<input type="range">', so the drag, the arrow keys, Home and End, the page keys and the touch target are the platform's. The last is the one nobody notices: a native range has a hit area larger than its thumb, sized by the platform for a finger.  **The value is a string, like every other form control's.** A range submits text and 'MixinControllerValue' holds text, so the number is a reading of the value. 'valueAsNumber' is there for arithmetic.  **Marks are drawn rather than left to '<datalist>'**, whose ticks cannot be styled and which Firefox does not render for a range at all. A mark is decoration; what a reader can land on is 'step', which the input enforces whether or not anything is drawn. 'markers' is a count rather than a flag, so a slider from zero to a hundred cannot silently ask for a hundred and one.  **A range is two of them.** There is no native two-thumb range, so two are stacked on one track and each thumb keeps its own.  **'required' arrives with the field mixin and cannot fail here**, which is worth saying rather than leaving a reader to find. A range is never empty: the platform shows its own midpoint whatever is set, and 'willUpdate' seeds that midpoint into 'defaultValue' so the value agrees with the handle from the first render. HTML does not apply 'required' to a range either, so it stays off the control and the marker beside the label is all it does. */
   "helix-headless-slider": DefineCustomElement<
     HelixHeadlessSlider,
     HelixHeadlessSliderVueProps,