@fusion.dev/helix-headless 0.42.0 → 0.44.0

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`.
@@ -6697,9 +6722,9 @@ has an honest answer. */
 };
 
 export type HelixHeadlessSplitterVueEvents = {
-  /** Fired before a pane shuts or reopens, and cancelable. */
+  /** Fired before a pane shuts or reopens, and only where the position it is derived from stood. Cancelable: refusing it leaves the pane as it was and the divider where the gesture put it. */
   "helix-before-collapse": HelixHeadlessSplitterHelixBeforeCollapseElementEvent;
-  /** Fired before the divider settles, and cancelable. */
+  /** Fired before the divider settles. Cancelable: refusing it takes the whole of where the gesture ended, so no collapse follows from it either. A drag has already drawn itself by then and holds where it was dropped until the consumer assigns their own. */
   "helix-before-resize": HelixHeadlessSplitterHelixBeforeResizeElementEvent;
 };
 
@@ -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`.
@@ -8187,8 +8225,6 @@ export type HelixHeadlessTourVueEvents = {
   "helix-complete": HelixHeadlessTourHelixCompleteElementEvent;
   /** A stop's own controls asking the tour to move, dispatched by the stop and heard here because the tour is what moves. */
   "helix-tour-ask": HelixHeadlessTourHelixTourAskElementEvent;
-  /** Says the state moved, carrying `newState` and `oldState`. */
-  toggle: HelixHeadlessTourElementEvent;
 };
 
 /** `HelixHeadlessTourStop` component event */
@@ -8928,11 +8964,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 +9530,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,