@fusion.dev/helix-headless 0.42.0 → 0.43.0

package/custom-elements.json

@@ -30667,7 +30667,7 @@
           "helix": {
             "category": "forms",
             "since": "0.1.0",
-            "status": "experimental",
+            "status": "stable",
             "documentation": "https://fusion.dev/helix/components/date-picker",
             "aliases": [
               "Calendar",
@@ -42521,7 +42521,7 @@
           "helix": {
             "category": "typography",
             "since": "0.1.0",
-            "status": "experimental",
+            "status": "stable",
             "documentation": "https://fusion.dev/helix/components/format-date",
             "aliases": [
               "RelativeTime",
@@ -42533,7 +42533,7 @@
             "part": "Root",
             "examples": [
               {
-                "description": "The same readings on the headless tier, where the value is the element's own text.",
+                "description": "The same readings on the headless tier, with every rule written by hand.",
                 "slug": "preview"
               }
             ],
@@ -63024,13 +63024,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the markup declared this one chosen, which is what a reset returns to.\n\n`<option selected>` reflects to `defaultSelected` and `option.selected` is\nlive state that does not reflect, and those are two different facts. This\nelement has one `selected` doing both jobs, so what is captured here is what\nthe markup said at upgrade, before anything could overwrite it: read the\nattribute later and the listbox's own writes answer instead.\n\n**The deeper half is 302 and is not this.** State reflecting under the\ndeclaration's name is the fault `TreeItem` already avoids by mirroring to\n`data-selected`, and four families here still write `selected` back into a\nconsumer's markup. Splitting them means moving what every stylesheet selects\non, which is a change of its own rather than a property being added."
-            },
-            {
-              "kind": "field",
-              "name": "seeded",
-              "privacy": "private",
-              "description": "What the markup said, read once at construction for the reason above."
+              "description": "Whether the markup declared this one chosen, which is what a reset returns to.\n\n`<option selected>` reflects to `defaultSelected` and `option.selected` is\nlive state that does not reflect, and those are two different facts. This\nelement has one `selected` doing both jobs, so the declaration is the\nattribute and the state is the property.\n\n**The attribute, read when it is asked for, and never a snapshot taken in\nthe constructor.** A field initializer runs there, and an element the HTML\nparser created has none of its attributes yet at that moment: measured on\nthis element, on `Radio` and on `Toggle`, `<helix-option value=\"a\"\nselected>` reported `defaultSelected` as `false` both from parsed markup\nand from `createElement` followed by `setAttribute`, which is every way a\nconsumer writes one. The snapshot could only ever be true for an element\nalready in the document when `customElements.define` ran.\n\nNothing overwrites it either, which is what makes reading it late correct\nrather than merely later: `selected` does not reflect, for the reason\n`willUpdate` records, so the listbox's writes never reach the attribute and\nwhat it says is what the markup said.\n\n**The deeper half is not this.** State reflecting under the declaration's\nname is the fault `TreeItem` avoids by mirroring to `data-selected`.\nSplitting them means moving what every stylesheet selects on, which is a\nchange of its own rather than a property being added."
             },
             {
               "kind": "field",
@@ -71504,13 +71498,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the markup declared this one chosen, which is what a reset returns to.\n\n`<option selected>` reflects to `defaultSelected` and `option.selected` is\nlive state that does not reflect, and those are two different facts. This\nelement has one `selected` doing both jobs, so what is captured here is what\nthe markup said at upgrade, before anything could overwrite it: read the\nattribute later and the listbox's own writes answer instead.\n\n**The deeper half is not this.** State reflecting under the declaration's\nname is the fault `TreeItem` avoids by mirroring to `data-selected`.\nSplitting them means moving what every stylesheet selects on, which is a\nchange of its own rather than a property being added."
-            },
-            {
-              "kind": "field",
-              "name": "seeded",
-              "privacy": "private",
-              "description": "What the markup said, read once at construction for the reason above."
+              "description": "Whether the markup declared this one chosen, which is what a reset returns to.\n\n`<option selected>` reflects to `defaultSelected` and `option.selected` is\nlive state that does not reflect, and those are two different facts. This\nelement has one `selected` doing both jobs, so the declaration is the\nattribute and the state is the property.\n\n**The attribute, read when it is asked for, and never a snapshot taken in\nthe constructor.** A field initializer runs there, and an element the HTML\nparser created has none of its attributes yet at that moment: measured on\nthis element, on `Option` and on `Toggle`, `<helix-radio value=\"a\"\nselected>` reported `defaultSelected` as `false` both from parsed markup\nand from `createElement` followed by `setAttribute`, which is every way a\nconsumer writes one. The snapshot could only ever be true for an element\nalready in the document when `customElements.define` ran.\n\nNothing overwrites it either, which is what makes reading it late correct\nrather than merely later: `selected` does not reflect, for the reason\n`willUpdate` records, so the group's writes never reach the attribute and\nwhat it says is what the markup said.\n\n**The deeper half is not this.** State reflecting under the declaration's\nname is the fault `TreeItem` avoids by mirroring to `data-selected`.\nSplitting them means moving what every stylesheet selects on, which is a\nchange of its own rather than a property being added."
             },
             {
               "kind": "field",
@@ -77355,7 +77343,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "A real `<input type=\"range\">`, so the drag, the arrow keys, Home and End, the\npage keys and the touch target are the platform's. The last is the one nobody\nnotices: a native range has a hit area larger than its thumb, sized by the\nplatform for a finger.\n\n**The value is a string, like every other form control's.** A range submits\ntext and `MixinControllerValue` holds text, so the number is a reading of the\nvalue. `valueAsNumber` is there for arithmetic.\n\n**Marks are drawn rather than left to `<datalist>`**, whose ticks cannot be\nstyled and which Firefox does not render for a range at all. A mark is\ndecoration; what a reader can land on is `step`, which the input enforces\nwhether or not anything is drawn. `markers` is a count rather than a flag, so\na slider from zero to a hundred cannot silently ask for a hundred and one.\n\n**A range is two of them.** There is no native two-thumb range, so two are\nstacked on one track and each thumb keeps its own.",
+          "description": "A real `<input type=\"range\">`, so the drag, the arrow keys, Home and End, the\npage keys and the touch target are the platform's. The last is the one nobody\nnotices: a native range has a hit area larger than its thumb, sized by the\nplatform for a finger.\n\n**The value is a string, like every other form control's.** A range submits\ntext and `MixinControllerValue` holds text, so the number is a reading of the\nvalue. `valueAsNumber` is there for arithmetic.\n\n**Marks are drawn rather than left to `<datalist>`**, whose ticks cannot be\nstyled and which Firefox does not render for a range at all. A mark is\ndecoration; what a reader can land on is `step`, which the input enforces\nwhether or not anything is drawn. `markers` is a count rather than a flag, so\na slider from zero to a hundred cannot silently ask for a hundred and one.\n\n**A range is two of them.** There is no native two-thumb range, so two are\nstacked on one track and each thumb keeps its own.\n\n**`required` arrives with the field mixin and cannot fail here**, which is\nworth saying rather than leaving a reader to find. A range is never empty:\nthe platform shows its own midpoint whatever is set, and `willUpdate` seeds\nthat midpoint into `defaultValue` so the value agrees with the handle from the\nfirst render. HTML does not apply `required` to a range either, so it stays\noff the control and the marker beside the label is all it does.",
           "name": "HelixHeadlessSlider",
           "cssProperties": [
             {
@@ -77363,7 +77351,7 @@
               "name": "--slider-fraction"
             },
             {
-              "description": "Where the filled span starts, as a percentage of the track.",
+              "description": "Where a range's filled span starts, as a fraction of the track, 0 to 1.",
               "name": "--slider-from"
             },
             {
@@ -77371,7 +77359,7 @@
               "name": "--slider-marker-at"
             },
             {
-              "description": "Where the filled span ends, as a percentage of the track.",
+              "description": "Where a range's filled span ends, as a fraction of the track, 0 to 1.",
               "name": "--slider-to"
             }
           ],
@@ -78720,7 +78708,7 @@
           "helix": {
             "category": "forms",
             "since": "0.1.0",
-            "status": "experimental",
+            "status": "stable",
             "documentation": "https://fusion.dev/helix/components/slider",
             "aliases": [
               "Range",
@@ -97186,9 +97174,28 @@
             {
               "description": "The group's items.",
               "name": ""
+            },
+            {
+              "description": "Whatever sits after the track on its own line, such as a count or a reset.",
+              "name": "end"
+            },
+            {
+              "description": "Whatever sits before the track on its own line, such as an icon or a caption.",
+              "name": "start"
             }
           ],
           "members": [
+            {
+              "kind": "method",
+              "name": "adopt",
+              "privacy": "private",
+              "return": {
+                "type": {
+                  "text": "void"
+                }
+              },
+              "description": "Takes the markup's own answer where nothing has set a value.\n\n**The case a server renders**, and `Tabs` records the same fault from the\nother side. This element cannot choose on the server, having no children to\ncount, so a consumer whose first paint is right wrote `selected` on the\nitem: that serves `aria-checked=\"true\"`, and `sync` then cleared it one\nframe later, because `value` is `''` and nothing matches it. The shipped\n`disabled` example is exactly that markup, and drew both of its groups with\nnothing chosen.\n\n**Onto `defaultValue`, never onto `value`**, which is the same call\n`Slider` makes about the midpoint it seeds: what the markup declared is a\nfact about the markup, so it is where a reset returns to rather than\nsomething the reader chose. It also makes the group report the answer it is\nshowing, which marking the item alone would not: a `required` group would\notherwise tell a reader a value is missing while they are looking at one.\n\nA written `value` still wins, a declared property being a seed and a\ncorrection, and a group with neither still marks nothing at all.\n\n**The property and never `defaultSelected`, which is the attribute.** React\nassigns a JSX prop as a property where the custom element has one, and\nwrites no attribute at all, so keying on the attribute answers for markup\nand not for JSX. Measured by the parity check on the shipped `disabled`\nexample, whose two syntaxes are the same tree: 192 pixels apart, the HTML\nmarking `List` and the TSX marking nothing. The attribute seeds the\nproperty at upgrade, so reading the property covers both.\n\nRead before `sync` writes to it, which is the only moment it still holds\nwhat the consumer declared: after that it holds this group's answer, and\n`value` is no longer empty, so this returns above.\n\n**Called from `willUpdate` and from the slot, never from `sync`**, which\nruns in `updated`: a reactive property set there schedules a second update,\nand Lit's development build warns about exactly that once per group. From\n`willUpdate` the first render already carries the value, which is the pass\nthat has to be right. `children` is undefined on the server, whose element\nshim carries attributes and no tree, and that is the same guard\n`MixinCollection` records for the same reason."
+            },
             {
               "kind": "method",
               "name": "sync",
@@ -98278,7 +98285,7 @@
           "summary": "A row of options with the selection marked by a moving indicator.",
           "helix": {
             "since": "0.1.0",
-            "status": "experimental",
+            "status": "stable",
             "documentation": "https://fusion.dev/helix/components/toggle",
             "aliases": [
               "SegmentedControl",
@@ -98376,13 +98383,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the markup declared this one chosen, which is what a reset returns to.\n\n`<option selected>` reflects to `defaultSelected` and `option.selected` is\nlive state that does not reflect, and those are two different facts. This\nelement has one `selected` doing both jobs, so what is captured here is what\nthe markup said at upgrade, before anything could overwrite it: read the\nattribute later and the listbox's own writes answer instead.\n\n**The deeper half is not this.** State reflecting under the declaration's\nname is the fault `TreeItem` avoids by mirroring to `data-selected`.\nSplitting them means moving what every stylesheet selects on, which is a\nchange of its own rather than a property being added."
-            },
-            {
-              "kind": "field",
-              "name": "seeded",
-              "privacy": "private",
-              "description": "What the markup said, read once at construction for the reason above."
+              "description": "Whether the markup declared this one chosen, which is what a reset returns to.\n\n`<option selected>` reflects to `defaultSelected` and `option.selected` is\nlive state that does not reflect, and those are two different facts. This\nelement has one `selected` doing both jobs, so the declaration is the\nattribute and the state is the property.\n\n**The attribute, read when it is asked for, and never a snapshot taken in\nthe constructor.** A field initializer runs there, and an element the HTML\nparser created has none of its attributes yet at that moment: measured on\nthis element, on `Option` and on `Radio`, `<helix-toggle value=\"light\"\nselected>` reported `defaultSelected` as `false` both from parsed markup\nand from `createElement` followed by `setAttribute`, which is every way a\nconsumer writes one. The snapshot could only ever be true for an element\nalready in the document when `customElements.define` ran.\n\nNothing overwrites it either, which is what makes reading it late correct\nrather than merely later: `selected` does not reflect, for the reason\n`willUpdate` records, so the group's writes never reach the attribute and\nwhat it says is what the markup said.\n\n**The deeper half is not this.** State reflecting under the declaration's\nname is the fault `TreeItem` avoids by mirroring to `data-selected`.\nSplitting them means moving what every stylesheet selects on, which is a\nchange of its own rather than a property being added."
             },
             {
               "kind": "field",
@@ -98825,7 +98826,7 @@
           "helix": {
             "category": "actions",
             "since": "0.1.0",
-            "status": "experimental",
+            "status": "stable",
             "documentation": "https://fusion.dev/helix/components/toggle",
             "aliases": [
               "Segment",

package/dist/color-picker/root/color-picker-root.js

@@ -264,8 +264,7 @@ let HelixHeadlessColorPicker = class HelixHeadlessColorPicker extends MixinContr
                     @click=${() => this.handleSwatch(preset)}
                   ></button>`;
             })}
-              </div>`}
-      </div>`;
+              </div>`}`;
     }
 };
 __decorate([

package/dist/date-picker/root/date-picker-root.d.ts

@@ -21,7 +21,7 @@ declare const HelixHeadlessDatePicker_base: (new (...args: any[]) => import("@fu
  * write the same comma-separated `value`.
  *
  * @since 0.1.0
- * @status experimental
+ * @status stable
  * @category forms
  * @aliases Calendar, Date grid, Month view
  * @documentation https://fusion.dev/helix/components/date-picker

package/dist/format-date/root/format-date-root.d.ts

@@ -30,7 +30,7 @@ import { nothing, type PropertyValues, type TemplateResult } from 'lit';
  * "yesterday".
  *
  * @since 0.1.0
- * @status experimental
+ * @status stable
  * @category typography
  * @aliases RelativeTime, Timestamp, TimeAgo
  * @documentation https://fusion.dev/helix/components/format-date

package/dist/option/root/option-root.d.ts

@@ -101,20 +101,30 @@ export declare class HelixHeadlessOption extends HelixElement {
      *
      * `<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.
      */
     get defaultSelected(): boolean;
     set defaultSelected(next: boolean);
-    /** What the markup said, read once at construction for the reason above. */
-    private seeded;
     /**
      * A second line under the words, for what the choice actually is.
      *

package/dist/option/root/option-root.js

@@ -17,17 +17,16 @@ let HelixHeadlessOption = class HelixHeadlessOption extends HelixElement {
         this.active = false;
         this.alternate = '';
         this.alternateLabel = '';
-        this.seeded = this.hasAttribute('selected');
         this.disabled = false;
         this.label = '';
         this.selected = false;
         this.value = '';
     }
     get defaultSelected() {
-        return this.seeded;
+        return this.hasAttribute('selected');
     }
     set defaultSelected(next) {
-        this.seeded = next;
+        this.toggleAttribute('selected', next);
     }
     get text() {
         return [...this.childNodes]

package/dist/radio/root/radio-root.d.ts

@@ -51,9 +51,22 @@ export declare class HelixHeadlessRadio extends HelixElement {
      *
      * `<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`.
@@ -62,8 +75,6 @@ export declare class HelixHeadlessRadio extends HelixElement {
      */
     get defaultSelected(): boolean;
     set defaultSelected(next: boolean);
-    /** What the markup said, read once at construction for the reason above. */
-    private seeded;
     /**
      * Whether this is the current choice.
      *

package/dist/radio/root/radio-root.js

@@ -11,15 +11,14 @@ let HelixHeadlessRadio = class HelixHeadlessRadio extends HelixElement {
     constructor() {
         super(...arguments);
         this.disabled = false;
-        this.seeded = this.hasAttribute('selected');
         this.selected = false;
         this.value = '';
     }
     get defaultSelected() {
-        return this.seeded;
+        return this.hasAttribute('selected');
     }
     set defaultSelected(next) {
-        this.seeded = next;
+        this.toggleAttribute('selected', next);
     }
     focusItem() {
         this.partNamed('item')?.focus();

package/dist/slider/root/slider-root.d.ts

@@ -23,8 +23,15 @@ declare const HelixHeadlessSlider_base: (new (...args: any[]) => import("@fusion
  * **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.
+ *
  * @since 0.1.0
- * @status experimental
+ * @status stable
  * @category forms
  * @aliases Range, Range input
  * @documentation https://fusion.dev/helix/components/slider
@@ -44,9 +51,9 @@ declare const HelixHeadlessSlider_base: (new (...args: any[]) => import("@fusion
  * @csspart output - The current value, shown beside it.
  *
  * @cssproperty --slider-fraction - The value as a fraction of the range, 0 to 1.
- * @cssproperty --slider-from - Where the filled span starts, as a percentage of the track.
+ * @cssproperty --slider-from - Where a range's filled span starts, as a fraction of the track, 0 to 1.
  * @cssproperty --slider-marker-at - Where one marker sits, as a percentage of the track.
- * @cssproperty --slider-to - Where the filled span ends, as a percentage of the track.
+ * @cssproperty --slider-to - Where a range's filled span ends, as a fraction of the track, 0 to 1.
  *
  * @cssstate invalid - While there is feedback to show: the platform's verdict, or the consumer's `feedback`.
  */

package/dist/toggle/group/toggle-group.d.ts

@@ -16,11 +16,13 @@ declare const HelixHeadlessToggleGroup_base: (new (...args: any[]) => import("@f
  * it has somewhere to be, which is the harmless direction.
  *
  * @since 0.1.0
- * @status experimental
+ * @status stable
  * @aliases SegmentedControl, Segmented, Navigation, Switcher
  * @documentation https://fusion.dev/helix/components/toggle
  *
  * @slot - The group's items.
+ * @slot end - Whatever sits after the track on its own line, such as a count or a reset.
+ * @slot start - Whatever sits before the track on its own line, such as an icon or a caption.
  *
  * @event {Event} change - Announced once the value has moved.
  * @event {HelixBeforeChangeEvent} helix-before-change - Fired before the answer moves, and cancelable. The only way to refuse one.
@@ -38,6 +40,48 @@ declare const HelixHeadlessToggleGroup_base: (new (...args: any[]) => import("@f
  * @cssstate invalid - While there is feedback to show: the platform's verdict, or the consumer's `feedback`.
  */
 export declare class HelixHeadlessToggleGroup extends HelixHeadlessToggleGroup_base {
+    /**
+     * Takes the markup's own answer where nothing has set a value.
+     *
+     * **The case a server renders**, and `Tabs` records the same fault from the
+     * other side. This element cannot choose on the server, having no children to
+     * count, so a consumer whose first paint is right wrote `selected` on the
+     * item: that serves `aria-checked="true"`, and `sync` then cleared it one
+     * frame later, because `value` is `''` and nothing matches it. The shipped
+     * `disabled` example is exactly that markup, and drew both of its groups with
+     * nothing chosen.
+     *
+     * **Onto `defaultValue`, never onto `value`**, which is the same call
+     * `Slider` makes about the midpoint it seeds: what the markup declared is a
+     * fact about the markup, so it is where a reset returns to rather than
+     * something the reader chose. It also makes the group report the answer it is
+     * showing, which marking the item alone would not: a `required` group would
+     * otherwise tell a reader a value is missing while they are looking at one.
+     *
+     * A written `value` still wins, a declared property being a seed and a
+     * correction, and a group with neither still marks nothing at all.
+     *
+     * **The property and never `defaultSelected`, which is the attribute.** React
+     * assigns a JSX prop as a property where the custom element has one, and
+     * writes no attribute at all, so keying on the attribute answers for markup
+     * and not for JSX. Measured by the parity check on the shipped `disabled`
+     * example, whose two syntaxes are the same tree: 192 pixels apart, the HTML
+     * marking `List` and the TSX marking nothing. The attribute seeds the
+     * property at upgrade, so reading the property covers both.
+     *
+     * Read before `sync` writes to it, which is the only moment it still holds
+     * what the consumer declared: after that it holds this group's answer, and
+     * `value` is no longer empty, so this returns above.
+     *
+     * **Called from `willUpdate` and from the slot, never from `sync`**, which
+     * runs in `updated`: a reactive property set there schedules a second update,
+     * and Lit's development build warns about exactly that once per group. From
+     * `willUpdate` the first render already carries the value, which is the pass
+     * that has to be right. `children` is undefined on the server, whose element
+     * shim carries attributes and no tree, and that is the same guard
+     * `MixinCollection` records for the same reason.
+     */
+    private adopt;
     /** Marks the chosen item, separately from placing the indicator. */
     private sync;
     private readonly indicator;

package/dist/toggle/group/toggle-group.js

@@ -25,6 +25,15 @@ let HelixHeadlessToggleGroup = class HelixHeadlessToggleGroup extends MixinContr
             this.requestValue(event.detail.value);
         };
     }
+    adopt() {
+        if (this.value !== '' || this.children === undefined) {
+            return;
+        }
+        const declared = this.items.find((item) => item.selected);
+        if (declared) {
+            this.defaultValue = declared.value;
+        }
+    }
     sync() {
         const active = this.items.find((item) => item.value === this.value);
         const entry = active ? undefined : this.items.find((item) => !item.disabled);
@@ -57,6 +66,7 @@ let HelixHeadlessToggleGroup = class HelixHeadlessToggleGroup extends MixinContr
     }
     willUpdate(changed) {
         super.willUpdate(changed);
+        this.adopt();
         hostAria(this.internals, { label: this.label, role: 'radiogroup' });
         this.internals.setFormValue(this.value === '' ? null : this.value);
     }
@@ -74,6 +84,7 @@ let HelixHeadlessToggleGroup = class HelixHeadlessToggleGroup extends MixinContr
         <div part="indicator" aria-hidden="true"></div>
         <slot
           @slotchange=${() => {
+            this.adopt();
             this.sync();
             this.indicator.place();
         }}

package/dist/toggle/root/toggle-root.d.ts

@@ -11,7 +11,7 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  * without radio semantics announcing destinations as choices.
  *
  * @since 0.1.0
- * @status experimental
+ * @status stable
  * @category actions
  * @aliases Segment, NavItem, Option
  * @documentation https://fusion.dev/helix/components/toggle
@@ -34,9 +34,22 @@ export declare class HelixHeadlessToggle extends HelixElement {
      *
      * `<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`.
@@ -45,8 +58,6 @@ export declare class HelixHeadlessToggle extends HelixElement {
      */
     get defaultSelected(): boolean;
     set defaultSelected(next: boolean);
-    /** What the markup said, read once at construction for the reason above. */
-    private seeded;
     /**
      * Whether this item holds the group's tab stop while nothing is chosen.
      *

package/dist/toggle/root/toggle-root.js

@@ -11,16 +11,15 @@ let HelixHeadlessToggle = class HelixHeadlessToggle extends HelixElement {
     constructor() {
         super(...arguments);
         this.disabled = false;
-        this.seeded = this.hasAttribute('selected');
         this.focusable = false;
         this.selected = false;
         this.value = '';
     }
     get defaultSelected() {
-        return this.seeded;
+        return this.hasAttribute('selected');
     }
     set defaultSelected(next) {
-        this.seeded = next;
+        this.toggleAttribute('selected', next);
     }
     focusItem() {
         this.partNamed('item')?.focus();

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.42.0",
+  "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.42.0",
-    "@fusion.dev/helix-icons": "0.42.0",
+    "@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.42.0",
-    "@fusion.dev/helix-testing": "0.42.0",
+    "@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

@@ -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`.
@@ -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`.
@@ -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

@@ -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,