@fusion.dev/helix-headless 0.0.0-dev → 0.0.3

package/dist/checkbox/root/checkbox-root.js

@@ -60,30 +60,27 @@ let HelixHeadlessCheckbox = class HelixHeadlessCheckbox extends MixinControllerC
         this.aria = new AriaForwardController(this, {
             target: () => this.renderRoot?.querySelector('[part="control"]') ?? null,
         });
-        /**
-         * Value submitted when the box is checked.
-         */
-        this.value = 'on';
         /**
          * Whether the box shows as neither checked nor unchecked.
          *
          * Presentation only. It never submits, and the first change resolves it.
          */
         this.indeterminate = false;
+        /**
+         * Value submitted when the box is checked.
+         */
+        this.value = 'on';
         this.handleChange = (event) => {
             const input = event.target;
-            // The input has already flipped itself. Where the change is refused, or the
-            // element is controlled, it is put back to whatever the element resolves
-            // to, so the box never shows a state the element does not hold.
+            // The input has already flipped itself. Where the change is refused it is
+            // put back to whatever the element resolves to, so the box never shows a
+            // state the element does not hold.
             const next = input.checked;
-            /* The dash goes only where the change is taken.
-             *
-             * It was cleared first and unconditionally, so a consumer calling
-             * `preventDefault()` on the change kept the checked state and lost the
-             * third one: the box came back neither ticked nor dashed, which is a state
-             * nobody asked for and the element did not hold. Refusing a change should
-             * leave everything as it was, which is the argument the line below already
-             * makes for `checked`. */
+            /* The dash goes only where the change is taken. Clearing it
+             * unconditionally leaves a refused change holding the checked state and
+             * losing the third one: a box neither ticked nor dashed, which is a state
+             * nobody asked for. Refusing leaves everything as it was, which is the
+             * argument the line below already makes for `checked`. */
             if (this.requestChecked(next)) {
                 this.indeterminate = false;
             }
@@ -124,8 +121,8 @@ let HelixHeadlessCheckbox = class HelixHeadlessCheckbox extends MixinControllerC
     /** Returns the box to the state its markup declared. */
     formResetCallback() {
         this.indeterminate = false;
-        // `resetChecked` drops both halves now, the consumer's and the element's,
-        // so there is nothing to clear before it.
+        // `resetChecked` drops both halves, the consumer's and the element's, so
+        // there is nothing to clear before it.
         this.resetChecked();
     }
     willUpdate(changed) {
@@ -142,37 +139,34 @@ let HelixHeadlessCheckbox = class HelixHeadlessCheckbox extends MixinControllerC
      *
      * Called on `slotchange` and after every update, and the second is not
      * belt-and-braces: **`slotchange` does not fire when nothing is assigned.**
-     * So a checkbox labeled only by its property, which is most of them, never
-     * heard about its own label and rendered without one. Caught by the spec that
-     * asks a labeled row to be wider than a bare one.
+     * Without it a checkbox labeled only by its property, which is most of them,
+     * never hears about its own label and renders without one.
      *
-     * **`:state(has-label)` and not `data-has-label`, since 27 Aug 2026.** This
-     * one could never have been in server output whatever it was called, the
-     * answer coming from `assignedNodes` and a server having no tree to ask, so
-     * it was an attribute that appeared on every labeled checkbox the instant it
-     * upgraded and on none that any server sent. See `HelixElement.toggleState`.
+     * **`:state(has-label)` and not `data-has-label`.** The answer comes from
+     * `assignedNodes` and a server has no tree to ask, so an attribute would
+     * appear on every labeled checkbox the instant it upgraded and on none that
+     * any server sent. See `HelixElement.toggleState`.
      */
     syncLabelPresence() {
         const slot = this.renderRoot.querySelector('[part="label"] slot');
         const filled = (slot?.assignedNodes({ flatten: true }) ?? []).some((node) => node.textContent?.trim() !== '' || node.nodeType === Node.ELEMENT_NODE);
         this.toggleState('has-label', filled);
         /* And `hidden` on the region itself, because the state is on the host and
-           this tier has no sheet to turn one into the other: a checkbox with no
-           label kept an empty label box beside it. The styled rule stays, since it
-           hides through a descendant selector this cannot replace. */
+           this tier has no sheet to turn one into the other, so a checkbox with no
+           label would keep an empty label box beside it. The styled rule stays,
+           since it hides through a descendant selector this cannot replace. */
         this.renderRoot.querySelector('[part="label"]')?.toggleAttribute('hidden', !filled);
     }
     render() {
         /* A real `<label>` around both, which is the whole of what makes the text a
-           target. It was a `<span>` beside the input, so pressing the words did
-           nothing: the styled tier's own description claimed the pair behaved like
-           a native label wrapping a checkbox, and nothing was doing that work.
+           target. A `<span>` beside the input leaves pressing the words doing
+           nothing.
     
            Labeling is behavior, which is what earns an element here rather than a
            bare slot: the wrapper is not decoration and there is no other way to get
            it. The browser handles the forwarding, so there is no click handler to
            write and none to get wrong.
-     
+    
            The one line of description goes under that row, which is where a field
            puts it too. */
         return html `<label part="field">
@@ -195,12 +189,12 @@ let HelixHeadlessCheckbox = class HelixHeadlessCheckbox extends MixinControllerC
     ${this.renderHint()}${this.renderFeedback()}`;
     }
 };
-__decorate([
-    property()
-], HelixHeadlessCheckbox.prototype, "value", void 0);
 __decorate([
     property({ reflect: true, type: Boolean })
 ], HelixHeadlessCheckbox.prototype, "indeterminate", void 0);
+__decorate([
+    property()
+], HelixHeadlessCheckbox.prototype, "value", void 0);
 HelixHeadlessCheckbox = __decorate([
     customElement('helix-headless-checkbox')
 ], HelixHeadlessCheckbox);

package/dist/checkbox-group/root/checkbox-group-root.d.ts

@@ -19,11 +19,9 @@ declare const HelixHeadlessCheckboxGroup_base: (new (...args: any[]) => import("
  * `value` is the checked values, comma separated, in the order the boxes are
  * written. Setting it ticks exactly those and unticks the rest.
  *
- * **Its message is always given, never derived.** Every form-related member of
- * `ElementInternals` throws on an element that is not form-associated, and this
- * one is not, on purpose: the boxes submit themselves. So `feedback` is what
- * shows here, and the browser has nothing to say about a set it does not know
- * is a set.
+ * **Its message is always given, never derived.** The group is form-associated
+ * for validity alone and never calls `setFormValue`, so `feedback` is what shows
+ * here: the browser has nothing to say about a set it does not submit.
  *
  * @since 0.1.0
  * @status stable
@@ -63,18 +61,17 @@ export declare class HelixHeadlessCheckboxGroup extends HelixHeadlessCheckboxGro
     /**
      * Reads the boxes' own state into `value`, once, before anything is pushed.
      *
-     * `sync` used to refuse to write anything while `value` was empty, and the
-     * guard was there for this: a group written with no `value` and boxes that
-     * declare their own `checked` would have had them all cleared on the first
-     * update. What it also did was make `group.value = ''` do nothing at all, so
-     * the obvious way to clear a group silently did not, and the last box could
-     * not be unticked through the group either.
+     * Seeding, and never a guard in `sync` refusing to write while `value` is
+     * empty. The guard would answer the same case, a group written with no `value`
+     * whose boxes declare their own `checked` being cleared on the first update,
+     * and it also makes `group.value = ''` do nothing at all: the obvious way to
+     * clear a group would silently not, and the last box could not be unticked
+     * through the group either.
      *
-     * Seeding is the honest version of the same intent. The markup decides the
-     * starting set, exactly as before, and from then on `value` is what the boxes
-     * follow, including when it is empty. The group's `value` is a derived read
-     * of the boxes rather than state it owns, so reading it out of them at the
-     * start is what it already means.
+     * The markup decides the starting set, and from then on `value` is what the
+     * boxes follow, including when it is empty. The group's `value` is a derived
+     * read of the boxes rather than state it owns, so reading it out of them at
+     * the start is what it already means.
      */
     private seed;
     /**
@@ -95,18 +92,16 @@ export declare class HelixHeadlessCheckboxGroup extends HelixHeadlessCheckboxGro
     /**
      * Stops a box's own announcement, for the reason the request above is stopped.
      *
-     * **The split gave the requests two names and left the notifications sharing
-     * one.** A box announces `input` and `change` from its own host now, which is
-     * what makes `onChange` work on a checkbox, and both bubble up through this
-     * group: measured, one click produced `change` from the group and `input` and
+     * A box announces `input` and `change` from its own host, which is what makes
+     * `onChange` work on a checkbox, and both bubble up through this group:
+     * measured, one click produced `change` from the group and `input` and
      * `change` from the box, all three at a consumer listening here, two of them
-     * describing one box rather than the set. That is exactly the collision the
-     * comment on `handleToggle` describes, arriving by the other route.
+     * describing one box rather than the set.
      *
-     * `stopImmediatePropagation` and not `stopPropagation`, and for the same
-     * reason it gives: the box's event and this group's own carry one name from
-     * what a consumer sees as one element, so stopping propagation alone still
-     * leaves every other listener on this host receiving both.
+     * `stopImmediatePropagation` and not `stopPropagation`: the box's event and
+     * this group's own carry one name from what a consumer sees as one element,
+     * so stopping propagation alone still leaves every other listener on this
+     * host receiving both.
      *
      * A listener on the box itself is unaffected, which is where per-box handling
      * belongs. Each box is form-associated and submits itself; what this stops is
@@ -118,27 +113,19 @@ export declare class HelixHeadlessCheckboxGroup extends HelixHeadlessCheckboxGro
     protected willUpdate(changed: PropertyValues): void;
     protected firstUpdated(changed: PropertyValues): void;
     /**
-     * Refuses an empty set where one was required, which nothing did.
+     * Refuses an empty set where one was required.
      *
-     * `required` arrives with `MixinField`, reflects, and paints the asterisk
-     * through the composed field sheet, and enforced nothing at all: no validity,
-     * no message, and nothing cascading to the boxes. A group marked required
-     * submitted empty.
+     * **The group is form-associated, and submits nothing.** Nothing here calls
+     * `setFormValue`, so the set that reaches the server is exactly the boxes,
+     * each of which submits itself. What form association buys is the other half
+     * of participation, validity, and there is no other mechanism for it:
+     * `setValidity` throws `NotSupportedError` on an element the platform does not
+     * know is a control. happy-dom's shim does not throw, so a spec passes against
+     * code that fails on every update in Chromium.
      *
-     * **The group is form-associated, and submits nothing.** It was not, on the
-     * reasoning that its boxes are the controls and each submits itself, which is
-     * still true: nothing here calls `setFormValue`, so the set that reaches the
-     * server is exactly the boxes it always was. What form association buys is the
-     * other half of participation, validity, and there is no other mechanism for
-     * it: `setValidity` throws `NotSupportedError` on an element the platform does
-     * not know is a control.
-     *
-     * So the fix that was written for "a group marked required submitted empty"
-     * threw on every update in a real browser, and happy-dom's shim does not
-     * throw, so the specs passed and the behavior never worked. Eleven of them
-     * failed the moment they were run in Chromium. It is also what makes the rest
-     * work: the form now refuses to submit, which fires `invalid`, which is what
-     * marks the field touched and puts the message on screen.
+     * It is also what makes the rest work: the form refuses to submit, which fires
+     * `invalid`, which is what marks the field touched and puts the message on
+     * screen.
      *
      * Anchored on the list, because the browser needs somewhere to point the
      * bubble.

package/dist/checkbox-group/root/checkbox-group-root.js

@@ -25,11 +25,9 @@ import { HelixHeadlessCheckbox } from '../../checkbox/root/checkbox-root.js';
  * `value` is the checked values, comma separated, in the order the boxes are
  * written. Setting it ticks exactly those and unticks the rest.
  *
- * **Its message is always given, never derived.** Every form-related member of
- * `ElementInternals` throws on an element that is not form-associated, and this
- * one is not, on purpose: the boxes submit themselves. So `feedback` is what
- * shows here, and the browser has nothing to say about a set it does not know
- * is a set.
+ * **Its message is always given, never derived.** The group is form-associated
+ * for validity alone and never calls `setFormValue`, so `feedback` is what shows
+ * here: the browser has nothing to say about a set it does not submit.
  *
  * @since 0.1.0
  * @status stable
@@ -52,20 +50,18 @@ import { HelixHeadlessCheckbox } from '../../checkbox/root/checkbox-root.js';
  */
 let HelixHeadlessCheckboxGroup = class HelixHeadlessCheckboxGroup extends MixinField(HelixFormElement) {
     constructor() {
-        /* `name` is inherited. It arrives with `HelixFormElement` reflected and with
-           the converter that makes an empty one absent rather than `name=""`, which
-           the copy declared here had neither of. What it means differs slightly and
-           the property does not: the group submits nothing under it, and hands it to
-           every box that has none. */
+        /* `name` is inherited from `HelixFormElement`, reflected and with the
+           converter that makes an empty one absent rather than `name=""`. What it
+           means differs slightly and the property does not: the group submits nothing
+           under it, and hands it to every box that has none. */
         super(...arguments);
         /**
          * The checked values, comma separated.
          */
         this.value = '';
-        /* Stated once, and the group never thinks about it again. See the
-           controller: the cascade was four hand calls from four different
-           methods, so which paths reached it differed by component and a fifth
-           group would have got none at all. */
+        /* Stated once, and the group never thinks about it again. The controller is
+           what stops the cascade being hand-called from whichever methods a component
+           happens to have. */
         this.cascade = new DisabledCascadeController(this, {
             items: () => this.boxes,
         });
@@ -89,30 +85,22 @@ let HelixHeadlessCheckboxGroup = class HelixHeadlessCheckboxGroup extends MixinF
             if (!changed) {
                 return;
             }
-            /* Still stopped, though the names no longer collide. A box's `helix-toggle`
-               bubbles, and the group is the single voice for the set: a consumer
-               listening here wants the whole answer, not one box's half of it. Before
-               the split this had to be `stopImmediatePropagation` rather than
-               `stopPropagation`, because the box's event and the group's own carried
-               the same name from the same host and the other listeners on it would have
-               received both. */
+            /* A box's `helix-before-toggle` bubbles, and the group is the single voice
+               for the set: a consumer listening here wants the whole answer, not one
+               box's half of it. */
             event.stopImmediatePropagation();
             const wanted = event.detail.checked;
-            /* Announced before it is written, which is the way round it was not: the
-               group set its value and then dispatched, so `preventDefault()` refused a
-               set that had already changed.
+            /* Announced before it is written, never after: dispatching once the group's
+               value has moved leaves `preventDefault()` refusing a set that has already
+               changed.
         
-               Hand-rolled rather than through `MixinControllerValue`, and that is the
-               decision rather than an omission. The group is deliberately not
-               form-associated: its boxes are the form controls and each submits itself,
-               so the mixin, which is constrained to `HelixFormElement`, does not apply
-               to it. Its `value` is a derived read of the boxes rather than state it
-               owns, which is also why it is not controllable and why that is written
-               down rather than fixed.
+               Hand-rolled rather than through `MixinControllerValue`, and that is a
+               decision rather than an omission. The group's `value` is a derived read of
+               the boxes rather than state it owns, so there is nothing for the mixin to
+               control.
         
                The boxes have already moved either way. Each answered the reader before
-               this ran, so refusing here stops the group's value from following, and
-               the honest limit of that is recorded with the decision. */
+               this ran, so refusing here stops only the group's value from following. */
             const next = this.boxes
                 .filter((box) => (box === changed ? wanted : box.checked))
                 .map((box) => box.value)
@@ -126,27 +114,23 @@ let HelixHeadlessCheckboxGroup = class HelixHeadlessCheckboxGroup extends MixinF
         
                `input` beside it, because this is a discrete control and that is the
                pair a native `<select>` sends and the pair every other discrete control
-               here sends through `MixinControllerValue`. The group had only `change`,
-               so a consumer binding `onInput` on the set heard the boxes and never the
-               group. */
+               here sends through `MixinControllerValue`. */
             this.dispatchEvent(new Event('input', { bubbles: true, composed: true }));
             this.dispatchEvent(new Event('change', { bubbles: true, composed: false }));
         };
         /**
          * Stops a box's own announcement, for the reason the request above is stopped.
          *
-         * **The split gave the requests two names and left the notifications sharing
-         * one.** A box announces `input` and `change` from its own host now, which is
-         * what makes `onChange` work on a checkbox, and both bubble up through this
-         * group: measured, one click produced `change` from the group and `input` and
+         * A box announces `input` and `change` from its own host, which is what makes
+         * `onChange` work on a checkbox, and both bubble up through this group:
+         * measured, one click produced `change` from the group and `input` and
          * `change` from the box, all three at a consumer listening here, two of them
-         * describing one box rather than the set. That is exactly the collision the
-         * comment on `handleToggle` describes, arriving by the other route.
+         * describing one box rather than the set.
          *
-         * `stopImmediatePropagation` and not `stopPropagation`, and for the same
-         * reason it gives: the box's event and this group's own carry one name from
-         * what a consumer sees as one element, so stopping propagation alone still
-         * leaves every other listener on this host receiving both.
+         * `stopImmediatePropagation` and not `stopPropagation`: the box's event and
+         * this group's own carry one name from what a consumer sees as one element,
+         * so stopping propagation alone still leaves every other listener on this
+         * host receiving both.
          *
          * A listener on the box itself is unaffected, which is where per-box handling
          * belongs. Each box is form-associated and submits itself; what this stops is
@@ -184,18 +168,17 @@ let HelixHeadlessCheckboxGroup = class HelixHeadlessCheckboxGroup extends MixinF
     /**
      * Reads the boxes' own state into `value`, once, before anything is pushed.
      *
-     * `sync` used to refuse to write anything while `value` was empty, and the
-     * guard was there for this: a group written with no `value` and boxes that
-     * declare their own `checked` would have had them all cleared on the first
-     * update. What it also did was make `group.value = ''` do nothing at all, so
-     * the obvious way to clear a group silently did not, and the last box could
-     * not be unticked through the group either.
+     * Seeding, and never a guard in `sync` refusing to write while `value` is
+     * empty. The guard would answer the same case, a group written with no `value`
+     * whose boxes declare their own `checked` being cleared on the first update,
+     * and it also makes `group.value = ''` do nothing at all: the obvious way to
+     * clear a group would silently not, and the last box could not be unticked
+     * through the group either.
      *
-     * Seeding is the honest version of the same intent. The markup decides the
-     * starting set, exactly as before, and from then on `value` is what the boxes
-     * follow, including when it is empty. The group's `value` is a derived read
-     * of the boxes rather than state it owns, so reading it out of them at the
-     * start is what it already means.
+     * The markup decides the starting set, and from then on `value` is what the
+     * boxes follow, including when it is empty. The group's `value` is a derived
+     * read of the boxes rather than state it owns, so reading it out of them at
+     * the start is what it already means.
      */
     seed() {
         const checked = this.boxes.filter((box) => box.checked).map((box) => box.value);
@@ -233,27 +216,19 @@ let HelixHeadlessCheckboxGroup = class HelixHeadlessCheckboxGroup extends MixinF
         }
     }
     /**
-     * Refuses an empty set where one was required, which nothing did.
+     * Refuses an empty set where one was required.
      *
-     * `required` arrives with `MixinField`, reflects, and paints the asterisk
-     * through the composed field sheet, and enforced nothing at all: no validity,
-     * no message, and nothing cascading to the boxes. A group marked required
-     * submitted empty.
+     * **The group is form-associated, and submits nothing.** Nothing here calls
+     * `setFormValue`, so the set that reaches the server is exactly the boxes,
+     * each of which submits itself. What form association buys is the other half
+     * of participation, validity, and there is no other mechanism for it:
+     * `setValidity` throws `NotSupportedError` on an element the platform does not
+     * know is a control. happy-dom's shim does not throw, so a spec passes against
+     * code that fails on every update in Chromium.
      *
-     * **The group is form-associated, and submits nothing.** It was not, on the
-     * reasoning that its boxes are the controls and each submits itself, which is
-     * still true: nothing here calls `setFormValue`, so the set that reaches the
-     * server is exactly the boxes it always was. What form association buys is the
-     * other half of participation, validity, and there is no other mechanism for
-     * it: `setValidity` throws `NotSupportedError` on an element the platform does
-     * not know is a control.
-     *
-     * So the fix that was written for "a group marked required submitted empty"
-     * threw on every update in a real browser, and happy-dom's shim does not
-     * throw, so the specs passed and the behavior never worked. Eleven of them
-     * failed the moment they were run in Chromium. It is also what makes the rest
-     * work: the form now refuses to submit, which fires `invalid`, which is what
-     * marks the field touched and puts the message on screen.
+     * It is also what makes the rest work: the form refuses to submit, which fires
+     * `invalid`, which is what marks the field touched and puts the message on
+     * screen.
      *
      * Anchored on the list, because the browser needs somewhere to point the
      * bubble.
@@ -275,9 +250,8 @@ let HelixHeadlessCheckboxGroup = class HelixHeadlessCheckboxGroup extends MixinF
         return html `${this.renderGroupLabel()}
       <div part="items">
         ${
-        /* A box arriving after first render got neither the shared name nor
-           the value's checked state, because nothing was listening: both
-           sibling groups wire this and this one did not. */
+        /* A box arriving after first render has neither the shared name nor
+           the value's checked state until something pushes them onto it. */
         ''}
         <slot @slotchange=${() => this.requestUpdate()}></slot>
       </div>

package/dist/code-block/root/code-block-root.d.ts

@@ -59,10 +59,9 @@ export declare class HelixHeadlessCodeBlock extends HelixElement {
      *
      * **Reflected, because the gutter is a stylesheet rule.** `code-block.css`
      * reserves the copy button's width with `:host(:not([no-copy]))`, so the
-     * attribute is what decides whether the block pays for a control. Set from
-     * script the button went away, `render` reading the property, and the 40px it
-     * stood in stayed reserved: the exact waste that rule was written to stop,
-     * arrived at from the other side.
+     * attribute is what decides whether the block pays for a control. Unreflected,
+     * setting it from script takes the button away (`render` reads the property)
+     * and leaves the 40px it stood in reserved.
      *
      * A false boolean reflects as the attribute's absence, so this costs no
      * `no-copy=""` on hosts that never asked for one, and the rule about a

package/dist/code-block/root/code-block-root.js

@@ -69,10 +69,9 @@ let HelixHeadlessCodeBlock = class HelixHeadlessCodeBlock extends HelixElement {
          *
          * **Reflected, because the gutter is a stylesheet rule.** `code-block.css`
          * reserves the copy button's width with `:host(:not([no-copy]))`, so the
-         * attribute is what decides whether the block pays for a control. Set from
-         * script the button went away, `render` reading the property, and the 40px it
-         * stood in stayed reserved: the exact waste that rule was written to stop,
-         * arrived at from the other side.
+         * attribute is what decides whether the block pays for a control. Unreflected,
+         * setting it from script takes the button away (`render` reads the property)
+         * and leaves the 40px it stood in reserved.
          *
          * A false boolean reflects as the attribute's absence, so this costs no
          * `no-copy=""` on hosts that never asked for one, and the rule about a
@@ -109,14 +108,11 @@ let HelixHeadlessCodeBlock = class HelixHeadlessCodeBlock extends HelixElement {
         this.requestUpdate();
     }
     render() {
-        /* The copy button sits beside the code, not in a bar above it.
-         *
-         * It was in the header, which meant a block with nothing to call itself
-         * still drew a full-width bar to hold one button: an empty strip above
-         * every snippet, which is what a `Usage` section of one-line imports looked
-         * like. Beside the code it needs no bar at all, so a block with no `label`
-         * is just the code and a way to take it, and the header exists only when
-         * there is a name to put in it. One less appearance to choose between. */
+        /* The copy button sits beside the code, not in a bar above it. In the
+           header, a block with nothing to call itself still draws a full-width bar
+           to hold one button, so a `Usage` section of one-line imports is a run of
+           empty strips. Beside the code, the header exists only when there is a
+           name to put in it. */
         return html `${this.label ? html `<div part="header"><span part="label">${this.label}</span></div>` : nothing}
       <div part="frame">
         <pre part="block"><code part="code"><slot @slotchange=${() => this.requestUpdate()}></slot></code></pre>

package/dist/color-input/root/color-input-root.d.ts

@@ -27,10 +27,10 @@ declare const HelixHeadlessColorInput_base: (new (...args: any[]) => import("@fu
  * the value itself, for the reason Date Input gives about its dates: half-typed
  * input does not survive a round trip through a formatter.
  *
- * The properties below are written by this component and read by whoever draws
- * it. A consumer sets none of them: they carry a number this element computed
- * and CSS cannot, which is what lets a stylesheet on this tier draw the thing
- * without measuring anything itself.
+ * The custom property below is written by this component and never set by a
+ * consumer: it carries a value this element resolved and CSS cannot, which is
+ * what lets a stylesheet on this tier paint the swatch without parsing anything
+ * itself.
  *
  * @since 0.1.0
  * @status experimental
@@ -92,48 +92,29 @@ declare const HelixHeadlessColorInput_base: (new (...args: any[]) => import("@fu
  */
 export declare class HelixHeadlessColorInput extends HelixHeadlessColorInput_base {
     protected readonly aria: AriaForwardController;
+    /**
+     * Whether the color carries an alpha channel.
+     */
+    alpha: boolean;
     /**
      * What the browser may autofill in the text field, as a platform token.
      *
      * **Defaults to `off`, which is not the platform's default and is the
-     * point.** The field filters a list rather than collecting a value, so a
-     * browser offering to fill it with a saved address is competing for the same
-     * keystrokes as the listbox. A consumer who wants autofill can still ask.
+     * point.** The field holds a color, so a browser offering to fill it with a
+     * saved address is competing for the same keystrokes as the picker. A
+     * consumer who wants autofill can still ask.
      */
     autocomplete: string;
-    /**
-     * Whether the field is a text box with a swatch on it, or only the swatch.
-     *
-     * `swatch` is the native control's shape: a block of color that opens a
-     * picker, with no text beside it. It is what a toolbar wants, and a form that
-     * asks for a color among twenty other questions, where a hex in a box is
-     * eleven characters of noise next to the thing itself.
-     *
-     * It also settles where the value is stated. The default field *is* the input,
-     * so the panel is told `no-value` and would otherwise show a second one. A
-     * swatch states nothing, so the panel keeps its own row and the value is
-     * readable and typeable exactly once, in whichever of the two is present.
-     *
-     * The trade is real and is the reason this is not the default: a swatch cannot
-     * be read or pasted into without opening the panel, which is worse for a form
-     * where the color is the answer rather than a setting.
-     */
-    variant?: 'swatch';
-    /**
-     * Whether the color carries an alpha channel.
-     */
-    alpha: boolean;
     /**
      * The syntax the value is written in: `hex`, `rgb` or `hsl`.
      *
-     * **Undefaulted, because it reflects.** The two together are what stamp an
-     * attribute onto every host anybody renders, including the ones nobody
-     * configured: the server wrote `format="hex"` on every color input on the
-     * page, and React, holding no such prop, reported a hydration mismatch for
-     * each one. That is the fault `Tree.chevronPlacement` had and the reason the
-     * area rules say a reflected property takes no default. Hex is still what an
-     * unset one writes; the difference is that the resting arrangement is the
-     * attribute's absence rather than a value spelled out.
+     * **Undefaulted, because it reflects.** The two together stamp an attribute
+     * onto every host anybody renders, including the ones nobody configured: the
+     * server writes `format="hex"` on every color input on the page, and React,
+     * holding no such prop, reports a hydration mismatch for each one.
+     * `helix component`'s `reflected-defaults` holds it. Hex is still what an unset one
+     * writes; the resting arrangement is the attribute's absence rather than a
+     * value spelled out.
      */
     format?: ColorFormat;
     /**
@@ -152,6 +133,24 @@ export declare class HelixHeadlessColorInput extends HelixHeadlessColorInput_bas
      * Accessible name for the control that opens the panel.
      */
     triggerLabel: string;
+    /**
+     * Whether the field is a text box with a swatch on it, or only the swatch.
+     *
+     * `swatch` is the native control's shape: a block of color that opens a
+     * picker, with no text beside it. It is what a toolbar wants, and a form that
+     * asks for a color among twenty other questions, where a hex in a box is
+     * eleven characters of noise next to the thing itself.
+     *
+     * It also settles where the value is stated. The default field *is* the input,
+     * so the panel is told `no-value` and would otherwise show a second one. A
+     * swatch states nothing, so the panel keeps its own row and the value is
+     * readable and typeable exactly once, in whichever of the two is present.
+     *
+     * The trade is real and is the reason this is not the default: a swatch cannot
+     * be read or pasted into without opening the panel, which is worse for a form
+     * where the color is the answer rather than a setting.
+     */
+    variant?: 'swatch';
     /** The overlay, placed against the field for the reason Date Input gives. */
     protected readonly panel: PopoverController;
     /**