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

package/dist/mixins/mixin-collection/mixin-collection.js

@@ -12,9 +12,7 @@ import { property, state } from 'lit/decorators.js';
  * **Empty and loading are different answers and a reader can tell them apart.**
  * "No results" under a spinner is a lie for as long as the request is in
  * flight, and a blank box is not an answer at all: a reader cannot know whether
- * a list is empty, still arriving, or broken. Six components each rendered rows
- * and none of them said either thing, so every consumer wrote their own and
- * wrote it differently.
+ * a list is empty, still arriving, or broken.
  *
  * **`aria-busy` on the collection, not on the message.** A reader with a screen
  * reader is told the region is changing and then told once, politely, what it
@@ -26,10 +24,6 @@ import { property, state } from 'lit/decorators.js';
  * which question it is answering, and this is the point in a component's life
  * when a consumer is most likely to be looking at stale content.
  *
- * Listbox had `empty-text` and nothing else, and Combobox forwarded it. Both
- * keep the name, so nothing a consumer wrote has moved.
- *
- *
  * **`empty` and `loading` are documented on each of the five families that
  * apply this, rather than here.** See `MixinField` for why a class-level tag on
  * a mixin reaches no manifest.
@@ -38,6 +32,10 @@ export const MixinCollection = (Base) => {
     class Collection extends Base {
         constructor() {
             super(...arguments);
+            /**
+             * What is said where there are none, and none are coming.
+             */
+            this.emptyText = 'Nothing to show';
             /**
              * Whether the rows are still on their way.
              *
@@ -50,10 +48,6 @@ export const MixinCollection = (Base) => {
              * What is said while they are on their way.
              */
             this.loadingText = 'Loading';
-            /**
-             * What is said where there are none, and none are coming.
-             */
-            this.emptyText = 'Nothing to show';
             /**
              * Whether the rows have been looked at yet.
              */
@@ -61,14 +55,13 @@ export const MixinCollection = (Base) => {
             /**
              * How many there were, the last time anyone looked.
              *
-             * **Not `rows`, and the rename is the whole point of this comment.**
-             * TypeScript's `private` is a compile-time claim and the runtime field is
-             * whatever it is named, so a subclass declaring `@property() rows` for the
-             * data a consumer hands it would share one field with this counter: the
-             * slot count would overwrite the consumer's array on every `updated`, and
-             * `hasRows` would read the array's length as a slot count. Nothing would
-             * throw. `helix-data-table` takes exactly that property, which is what
-             * found this before it happened.
+             * **Never name this `rows`.** TypeScript's `private` is a compile-time
+             * claim and the runtime field is whatever it is named, so a subclass
+             * declaring `@property() rows` for the data a consumer hands it would share
+             * one field with this counter: the slot count would overwrite the
+             * consumer's array on every `updated`, and `hasRows` would read the array's
+             * length as a slot count. Nothing would throw. `helix-data-table` takes
+             * exactly that property.
              */
             this.slotRows = 0;
         }
@@ -79,7 +72,7 @@ export const MixinCollection = (Base) => {
          * count. `slotchange` never fires there, so `counted` is false exactly when
          * the answer is unknown, and an unknown answer is not "empty": a list that
          * shipped "Nothing to show" over markup about to have rows in it is the one
-         * thing an empty state must never do. Listbox's spec caught precisely that.
+         * thing an empty state must never do.
          */
         countRows(event) {
             this.slotCounted = true;
@@ -135,15 +128,15 @@ export const MixinCollection = (Base) => {
             return html `<p part="empty">${this.emptyText}</p>`;
         }
     }
+    __decorate([
+        property({ attribute: 'empty-text' })
+    ], Collection.prototype, "emptyText", void 0);
     __decorate([
         property({ reflect: true, type: Boolean })
     ], Collection.prototype, "loading", void 0);
     __decorate([
         property({ attribute: 'loading-text' })
     ], Collection.prototype, "loadingText", void 0);
-    __decorate([
-        property({ attribute: 'empty-text' })
-    ], Collection.prototype, "emptyText", void 0);
     __decorate([
         state()
     ], Collection.prototype, "slotCounted", void 0);

package/dist/mixins/mixin-controller-active/mixin-controller-active.d.ts

@@ -11,8 +11,9 @@ export declare class MixinControllerActiveInterface {
     /**
      * Which item is current, by its `value`.
      *
-     * Reading gives the real one, in either mode. Writing hands ownership to the
-     * consumer: from then on the set announces changes and applies none of them.
+     * Reading gives the real one. Writing always applies, and is a seed and a
+     * correction rather than a claim of ownership: a consumer who wants the
+     * decision refuses the `helix-before-activate`.
      */
     active: string;
     /** Initial item for uncontrolled use. Ignored once `active` is written. */
@@ -22,8 +23,8 @@ export declare class MixinControllerActiveInterface {
     /**
      * Which item is current, given what there is to choose from.
      *
-     * The first enabled one when `value` names nothing, which is a set before its
-     * consumer has chosen and a set whose current item has just been removed.
+     * The first enabled one when `active` names nothing, which is a set before
+     * its consumer has chosen and a set whose current item has just been removed.
      */
     protected resolveActive<Item extends ActivatableItem>(items: Item[]): Item | undefined;
 }
@@ -35,19 +36,17 @@ export declare class MixinControllerActiveInterface {
  * is submitted and belongs to `MixinControllerValue`, which is why these are
  * two mixins and not one with a flag.
  *
- * **Announcing before applying is the part worth sharing.** `Tabs` and `Tree`
- * both wrote the current value straight from the item's event, so a consumer
- * had no way to refuse a change, while `Radio.Group` announced first. Neither
- * was wrong on its own and the two together are: whether a selection can be
- * refused should not depend on which component a reader is looking at.
+ * **Announcing before applying is the part worth sharing.** Writing the current
+ * value straight from the item's event leaves a consumer no way to refuse a
+ * change, and whether a selection can be refused must not depend on which
+ * component a reader is looking at.
  *
- * **The fallback is the other half.** Four components had written
- * `items.find(match) ?? items[0]`, and it is not the obvious line it looks
- * like: it is what makes a set with a `value` naming nothing still show
- * something, which is every set before its consumer has set one and every set
- * whose current item has just been removed. `resolveActive` also skips disabled
- * items, which the hand-written copies did not, so a set opening on a disabled
- * first item showed it as current.
+ * **The fallback is the other half.** `items.find(match) ?? items[0]` is not
+ * the obvious line it looks like: it is what makes a set whose `active` names
+ * nothing still show something, which is every set before its consumer has set
+ * one and every set whose current item has just been removed. `resolveActive`
+ * also skips disabled items in that fallback, or a set opening on a disabled
+ * first item shows it as current.
  */
 export declare const MixinControllerActive: <T extends Constructor<HelixElement>>(Base: T) => Constructor<MixinControllerActiveInterface> & T;
 export {};

package/dist/mixins/mixin-controller-active/mixin-controller-active.js

@@ -16,19 +16,17 @@ import { resolveActiveItem, } from '../../utils/resolve-active-item/resolve-acti
  * is submitted and belongs to `MixinControllerValue`, which is why these are
  * two mixins and not one with a flag.
  *
- * **Announcing before applying is the part worth sharing.** `Tabs` and `Tree`
- * both wrote the current value straight from the item's event, so a consumer
- * had no way to refuse a change, while `Radio.Group` announced first. Neither
- * was wrong on its own and the two together are: whether a selection can be
- * refused should not depend on which component a reader is looking at.
+ * **Announcing before applying is the part worth sharing.** Writing the current
+ * value straight from the item's event leaves a consumer no way to refuse a
+ * change, and whether a selection can be refused must not depend on which
+ * component a reader is looking at.
  *
- * **The fallback is the other half.** Four components had written
- * `items.find(match) ?? items[0]`, and it is not the obvious line it looks
- * like: it is what makes a set with a `value` naming nothing still show
- * something, which is every set before its consumer has set one and every set
- * whose current item has just been removed. `resolveActive` also skips disabled
- * items, which the hand-written copies did not, so a set opening on a disabled
- * first item showed it as current.
+ * **The fallback is the other half.** `items.find(match) ?? items[0]` is not
+ * the obvious line it looks like: it is what makes a set whose `active` names
+ * nothing still show something, which is every set before its consumer has set
+ * one and every set whose current item has just been removed. `resolveActive`
+ * also skips disabled items in that fallback, or a set opening on a disabled
+ * first item shows it as current.
  */
 export const MixinControllerActive = (Base) => {
     // JSDoc is duplicated from the interface deliberately. The interface is what
@@ -47,27 +45,19 @@ export const MixinControllerActive = (Base) => {
              * The state, whoever set it, and `undefined` until somebody has.
              *
              * One field and not two. Writing always applies, the way a native control
-             * does when a script assigns to it. What the write does not do is change
-             * which mode the element is in.
+             * does when a script assigns to it.
              */
             this.activeState = undefined;
         }
         /**
          * Which item is current, by its `value`.
          *
-         * Called `active`, which is what this mixin is named for and what it was
-         * not: it declared `value`, so the one mixin whose whole subject is which
-         * item is active had no such property, and `active` meant something else
-         * entirely elsewhere in the library. It still does, and only there now:
-         * `option.active` is the option the keyboard is on, which is a different
-         * question from which one is chosen.
-         *
-         * An accessor pair, the same shape as the other three. Reading gives the
-         * real item; writing hands ownership to the consumer, so `<helix-tabs
-         * active="one">` is a set that stays on that tab and `default-active` is
-         * how markup says where to start.
-         *
+         * Not `option.active`, which is the option the keyboard is on: that is a
+         * different question from which one is chosen.
          *
+         * Writing always applies, so `<helix-tabs active="one">` starts on that
+         * tab, and `default-active` is how markup says where to start without
+         * naming the current one.
          */
         get active() {
             return this.activeState ?? this.defaultActive;
@@ -85,7 +75,7 @@ export const MixinControllerActive = (Base) => {
          * by the time this runs, so refusing is simply not writing: there is
          * nothing to put back. Nobody refusing means the set updates itself,
          * whether or not a consumer declared `active`, a declared property being a
-         * seed and a correction. See 294.
+         * seed and a correction.
          */
         requestActive(next) {
             if (next === this.active) {
@@ -109,25 +99,21 @@ export const MixinControllerActive = (Base) => {
         /**
          * Says the current child moved, once it has.
          *
-         * **This was the only one of the four mixins with no notification**, and the
-         * event class said so deliberately: no native word means "a set chose a
-         * different member", so borrowing `change` would be a lie about what moved.
-         * That half still holds, and is why the pair is `helix-activate`. What did
-         * not follow is that a set should therefore announce nothing.
+         * `helix-activate` rather than a native word: nothing on the platform means
+         * "a set chose a different member", and borrowing `change` would be a lie
+         * about what moved.
          *
-         * The cost is the one 294 fixed for values and left here. A consumer who
-         * only wants to know which child is current had one channel and it fires
-         * *before* `apply`, so `currentTarget.active` is the previous value inside
-         * the handler and `detail.value` is a proposal another listener may refuse.
-         * Measured across the four families taking this: `Tabs` and `Tree` looked
-         * covered because `helix-select` bubbles up from a child, which fires when an
-         * item is *chosen* and not when `active` is assigned, and `Steps` and
-         * `Video Playlist` announced nothing at all.
+         * A consumer who only wants to know which child is current cannot use
+         * `helix-before-activate` for it, that one firing *before* `apply`, so
+         * `currentTarget.active` is the previous value inside the handler and
+         * `detail.value` is a proposal another listener may refuse. `helix-select`
+         * is no substitute either: it fires when an item is *chosen* and not when
+         * `active` is assigned.
          *
          * **After `apply`, which is the whole reason it is a second event**, so the
          * state is on the element by the time a handler reads it. Not cancelable:
          * the decision was taken by the event before this one, and two refusable
-         * events for one transition are two answers to one question. See #325.
+         * events for one transition are two answers to one question.
          */
         announceActivated(value) {
             this.dispatchEvent(new HelixActivateEvent({ value }));
@@ -135,7 +121,7 @@ export const MixinControllerActive = (Base) => {
         /**
          * Which item is current, given what there is to choose from.
          *
-         * The first enabled one when `value` names nothing, which is a set before
+         * The first enabled one when `active` names nothing, which is a set before
          * its consumer has chosen and a set whose current item has just been
          * removed. Disabled items are skipped in the fallback but not in the match:
          * a consumer who names a disabled item meant it, and quietly moving to

package/dist/mixins/mixin-controller-checked/mixin-controller-checked.d.ts

@@ -11,9 +11,9 @@ export declare class MixinControllerCheckedInterface {
     /**
      * Whether the control is checked.
      *
-     * Reading gives the real state, in either mode. Writing hands ownership to
-     * the consumer: from then on the control announces changes and applies none
-     * of them.
+     * Reading gives the real state. Writing always applies, and is a seed and a
+     * correction rather than a claim of ownership: a consumer who wants the
+     * decision refuses the `helix-before-toggle`.
      */
     checked: boolean;
     /** Initial checked state for uncontrolled use. Ignored once `checked` is set. */
@@ -28,27 +28,25 @@ export declare class MixinControllerCheckedInterface {
     /** Requests the opposite of the current state. */
     toggleChecked(): boolean;
     /**
-     * Drops the uncontrolled state, so the control reads `defaultChecked` again.
+     * Drops the recorded state, so the control reads `defaultChecked` again.
      *
-     * A form reset has to return a control to what its markup declared. Clearing
-     * `checked` alone cannot do it: that only leaves controlled mode, and the
-     * uncontrolled value the element has been keeping is private to the mixin
-     * and would still be what `checked` reports.
+     * A form reset has to return a control to what its markup declared, and
+     * assigning `checked` cannot do it: any assignment records a state, and the
+     * recorded state is private to the mixin. This is the only way to clear it.
      */
     resetChecked(): void;
 }
 /**
- * Grafts controlled and uncontrolled checked state onto a base class.
+ * Grafts checked state onto a base class.
  *
- * Which mode it is in is read once, at the first update, from whether anything
- * had set `checked` by then: markup, a hydrating server's attributes and a
- * framework's initial properties have all arrived, and nothing else has
- * happened yet. Set, and the consumer owns it and the element only announces.
- * Unset, and the element owns it and `defaultChecked` says where it starts.
+ * `checked` is a seed and a correction rather than a claim: the element applies
+ * its own changes from wherever markup started it, `defaultChecked` is what a
+ * reset returns to, and a consumer takes the decision by refusing the
+ * `helix-before-toggle`.
  *
- * Records `:state(checked)` whenever the element is checked, in either mode.
- * Styled tiers select on that rather than on `[checked]`, which is absent for
- * uncontrolled consumers.
+ * Records `:state(checked)` whenever the element is checked. Styled tiers
+ * select on that rather than on `[checked]`, which is absent until somebody
+ * writes it.
  */
 export declare const MixinControllerChecked: <T extends Constructor<HelixElement>>(Base: T) => Constructor<MixinControllerCheckedInterface> & T;
 export {};

package/dist/mixins/mixin-controller-checked/mixin-controller-checked.js

@@ -8,17 +8,16 @@ import { property } from 'lit/decorators.js';
 import { HelixBeforeToggleEvent } from '../../events/events.js';
 import { requestChange } from '../../utils/request-change/request-change.js';
 /**
- * Grafts controlled and uncontrolled checked state onto a base class.
+ * Grafts checked state onto a base class.
  *
- * Which mode it is in is read once, at the first update, from whether anything
- * had set `checked` by then: markup, a hydrating server's attributes and a
- * framework's initial properties have all arrived, and nothing else has
- * happened yet. Set, and the consumer owns it and the element only announces.
- * Unset, and the element owns it and `defaultChecked` says where it starts.
+ * `checked` is a seed and a correction rather than a claim: the element applies
+ * its own changes from wherever markup started it, `defaultChecked` is what a
+ * reset returns to, and a consumer takes the decision by refusing the
+ * `helix-before-toggle`.
  *
- * Records `:state(checked)` whenever the element is checked, in either mode.
- * Styled tiers select on that rather than on `[checked]`, which is absent for
- * uncontrolled consumers.
+ * Records `:state(checked)` whenever the element is checked. Styled tiers
+ * select on that rather than on `[checked]`, which is absent until somebody
+ * writes it.
  */
 export const MixinControllerChecked = (Base) => {
     // JSDoc is duplicated from MixinControllerCheckedInterface deliberately. The
@@ -35,25 +34,19 @@ export const MixinControllerChecked = (Base) => {
              * The state, whoever set it, and `undefined` until somebody has.
              *
              * One field and not two. Writing always applies, the way a native control
-             * does when a script assigns to it. What the write does not do is change
-             * which mode the element is in.
+             * does when a script assigns to it.
              */
             this.checkedState = undefined;
         }
         /**
          * Whether the control is checked.
          *
-         * One property rather than two. Reading gives the real state whichever
-         * mode the control is in; writing hands ownership to the consumer, which
-         * is what the attribute in `<helix-checkbox checked>` does as well. The
-         * same shape all four of these mixins have, for the reason given on
-         * `MixinControllerOpen.open`.
+         * One property rather than two. Writing always applies;
+         * `<helix-checkbox checked>` is the same statement in markup.
          *
          * Not reflected: the attribute is the consumer's input and stays as they
          * wrote it, and `:state(checked)` carries the resolved state for
          * stylesheets.
-         *
-         *
          */
         get checked() {
             return this.checkedState ?? this.defaultChecked;
@@ -66,19 +59,15 @@ export const MixinControllerChecked = (Base) => {
         /**
          * Records the resolved state as the custom state `checked`.
          *
-         * **A state and not `data-checked`, which is what this wrote until 27 Aug
-         * 2026.** The attribute went on in `willUpdate`, so `<helix-checkbox
-         * default-checked>` came back from a consumer's server without it and
-         * gained it the moment the definition landed, which React lists as a
-         * hydration mismatch and does not patch up. `HelixElement.toggleState` says
-         * why the host is the wrong place to keep a component's own bookkeeping.
+         * **A custom state and never `data-checked`.** An attribute written here
+         * means `<helix-checkbox default-checked>` comes back from a consumer's
+         * server without it and gains it the moment the definition lands, which
+         * React lists as a hydration mismatch and does not patch up.
+         * `HelixElement.toggleState` says why the host is the wrong place to keep a
+         * component's own bookkeeping.
          *
-         * Still in `willUpdate`, which is where the resolved state is first known
-         * and is what a subclass rendering from it expects. The old note here said
-         * SSR calls `willUpdate` and not `connectedCallback`, so the attribute
-         * reached server output: true, and no longer a reason for anything, a
-         * custom state being a fact about a running element that a server has
-         * nothing to say about.
+         * In `willUpdate`, which is where the resolved state is first known and is
+         * what a subclass rendering from it expects.
          */
         willUpdate(changed) {
             super.willUpdate(changed);
@@ -88,10 +77,11 @@ export const MixinControllerChecked = (Base) => {
          * Requests a checked change, and reports whether it was applied.
          *
          * Announces before it acts, so `preventDefault()` on the
-         * `helix-before-toggle` is a refusal and nothing moves. Nobody refusing means the element updates itself, whether or not a consumer
-         * declared the property: a declared property is a seed and a correction,
-         * the way `<input value>` is, and a consumer who wants the change for
-         * themselves refuses it and assigns their own. See 294.
+         * `helix-before-toggle` is a refusal and nothing moves. Nobody refusing
+         * means the element updates itself, whether or not a consumer declared the
+         * property: a declared property is a seed and a correction, the way
+         * `<input value>` is, and a consumer who wants the change for themselves
+         * refuses it and assigns their own.
          */
         requestChecked(next) {
             if (this.checked === next) {
@@ -122,24 +112,22 @@ export const MixinControllerChecked = (Base) => {
         /**
          * Restores the control when the browser brings a form back.
          *
-         * Hand-written on the checkbox and nowhere else, so `Switch`, the mixin's
-         * only other consumer, had no restore at all: a reader who navigated away
-         * and came back to a restored form found their switch flipped off. The
-         * mixin owns `checked`, so the mixin owns putting it back.
+         * The mixin owns `checked`, so the mixin owns putting it back: written on
+         * one consumer and not the other, a reader who navigates away and comes
+         * back to a restored form finds that control flipped off.
          *
-         * Through `checked` rather than the private state, so a controlled consumer
-         * is asked the same way every other change asks.
+         * Through the public accessor rather than the private field, so a restore
+         * takes the same path a script assignment does.
          */
         formStateRestoreCallback(state) {
             this.checked = state !== null;
         }
         /**
-         * Drops the uncontrolled state, so the control reads `defaultChecked`
-         * again.
+         * Drops the recorded state, so the control reads `defaultChecked` again.
          *
-         * A form reset has to return a control to what its markup declared, and
-         * clearing `checked` alone only leaves controlled mode. The value the
-         * element has been keeping lives here, so this is where it is dropped.
+         * A form reset has to return a control to what its markup declared, and no
+         * assignment to `checked` can do that: any assignment records a state. The
+         * recorded state lives here, so this is where it is dropped.
          */
         resetChecked() {
             const previous = this.checked;

package/dist/mixins/mixin-controller-open/mixin-controller-open.d.ts

@@ -13,9 +13,9 @@ export declare class MixinControllerOpenInterface {
     /**
      * Whether the element is open.
      *
-     * Reading gives the real state, in either mode. Writing hands ownership to
-     * the consumer: from then on the element announces changes and applies none
-     * of them, and waits to be told.
+     * Reading gives the real state. Writing always applies, and is a seed and a
+     * correction rather than a claim of ownership: a consumer who wants the
+     * decision refuses the `helix-before-open` or `helix-before-close`.
      */
     open: boolean;
     /**
@@ -36,7 +36,7 @@ export declare class MixinControllerOpenInterface {
  * `toggle` announces it afterwards, once the state has actually gone, carrying
  * `newState` and `oldState` the way the platform does on `<details>` and on a
  * popover. The first is how a consumer takes the decision; the second is what
- * they bind when they only want to know. See 294 and 296.
+ * they bind when they only want to know.
  *
  * `open` is a seed and a correction rather than a claim: the element applies
  * its own changes from wherever markup started it, and `defaultOpen` is what a

package/dist/mixins/mixin-controller-open/mixin-controller-open.js

@@ -15,7 +15,7 @@ import { requestChange } from '../../utils/request-change/request-change.js';
  * `toggle` announces it afterwards, once the state has actually gone, carrying
  * `newState` and `oldState` the way the platform does on `<details>` and on a
  * popover. The first is how a consumer takes the decision; the second is what
- * they bind when they only want to know. See 294 and 296.
+ * they bind when they only want to know.
  *
  * `open` is a seed and a correction rather than a claim: the element applies
  * its own changes from wherever markup started it, and `defaultOpen` is what a
@@ -45,37 +45,24 @@ export const MixinControllerOpen = (Base) => {
              * silently overwrites the first. Measured, as a select whose `value` came
              * back holding its `open` boolean.
              *
-             * One field and not two. Writing always applies, which is what a native
-             * control does when a script assigns to it, and is the behavior an
-             * imperative `element.open = true` should have whatever mode the element is
-             * in. What the write does *not* do is change which mode that is.
+             * One field and not two. Writing always applies, the way a native control
+             * does when a script assigns to it.
              */
             this.openState = undefined;
         }
         /**
          * Whether the element is open.
          *
-         * One property, not two. Reading gives the real state whichever mode the
-         * element is in, so `dialog.open` answers the question anyone asking it
-         * meant. Writing hands ownership to the consumer, which is what the
-         * attribute in `<helix-dialog open>` does as well: from then on the element
-         * announces changes and applies none of them.
-         *
-         * It reads as an accessor pair rather than a field because those are two
-         * different questions sharing one name, and the alternative was a second
-         * property answering the first. That worked for a boolean, where `isOpen`
-         * reads well; there is no such word for a value or an active item, so all
-         * four of these mixins now have this shape instead of two shapes.
+         * One property, not two, so `dialog.open` answers the question anyone
+         * asking it meant. Writing always applies; `<helix-dialog open>` is the
+         * same statement in markup.
          *
          * **Not reflected, and that is required rather than tidy.** Reflection
-         * writes the resolved state back as an attribute, and writing the attribute
-         * is how a consumer says they own it. So an uncontrolled element that
-         * opened itself would put `open` on its own host and, from the next thing
-         * that read it, be indistinguishable from one the consumer controls:
-         * cloned, serialised for hydration, or diffed by a framework, it would come
-         * back holding whatever the last reader did rather than what the author
-         * wrote. `:state(open)` carries the resolved state for stylesheets, which
-         * is what the mirror has always been for.
+         * writes the resolved state back as an attribute, so an element that opened
+         * itself would put `open` on its own host: cloned, serialized for
+         * hydration, or diffed by a framework, it comes back holding whatever the
+         * last reader did rather than what the author wrote. `:state(open)` carries
+         * the resolved state for stylesheets, which is what the mirror is for.
          */
         get open() {
             return this.openState ?? this.defaultOpen;
@@ -88,14 +75,14 @@ export const MixinControllerOpen = (Base) => {
         /**
          * Records the resolved state as the custom state `open`.
          *
-         * **A state and not `data-open`, which is what this wrote until 27 Aug
-         * 2026.** An `<helix-accordion-item default-open>` was served without the
-         * attribute and gained it on upgrade, which is a hydration mismatch a React
-         * consumer reports. See `HelixElement.toggleState`, and see `Toast.Item`
-         * for the other answer to the same fault: inverting the hook so the write
-         * falls on the side that only happens after somebody acts. Inversion works
-         * where the resting state is the loud one and cannot help here, `checked`
-         * and `open` being true only because a consumer asked for them.
+         * **A custom state and never `data-open`.** An attribute mirror is in the
+         * DOM, so an `<helix-accordion-item default-open>` served without it gains
+         * it on upgrade, which is a hydration mismatch a React consumer reports.
+         * See `HelixElement.toggleState`, and see `Toast.Item` for the other answer
+         * to the same fault: inverting the hook so the write falls on the side that
+         * only happens after somebody acts. Inversion works where the resting state
+         * is the loud one and cannot help here, `checked` and `open` being true
+         * only because a consumer asked for them.
          */
         willUpdate(changed) {
             super.willUpdate(changed);
@@ -109,7 +96,6 @@ export const MixinControllerOpen = (Base) => {
          * element opens or closes itself, whether or not a consumer declared
          * `open`: a declared property is a seed and a correction, and a consumer
          * who wants the decision for themselves refuses it and assigns their own.
-         * See 294.
          */
         requestOpen(next) {
             if (this.open === next) {
@@ -133,19 +119,17 @@ export const MixinControllerOpen = (Base) => {
         /**
          * Says the state moved, under the platform's own name and in its shape.
          *
-         * **`<details>` fires `toggle` and a popover fires `toggle`, and sixteen
-         * families here fired neither.** Two of them render a real `<dialog>` and
-         * ten show a `popover="manual"` panel, so the browser was already firing
-         * something on an element inside a shadow root, where `toggle` neither
-         * bubbles nor composes and so reaches nobody. The rest, the disclosures,
-         * have no native element to fire anything at all: `AccordionItem` and
-         * `TreeItem` are `aria-expanded` and `hidden` written by hand, which is
-         * `<details>`'s job done manually.
+         * **A native `toggle` from inside a shadow root reaches nobody**, because
+         * it neither bubbles nor composes, so the ten families showing a
+         * `popover="manual"` panel and the two rendering a real `<dialog>` announce
+         * nothing to a consumer. The disclosures have no native element to fire
+         * anything at all: `AccordionItem` and `TreeItem` are `aria-expanded` and
+         * `hidden` written by hand, which is `<details>`'s job done manually.
          *
-         * **From here rather than from `PopoverController`, which had it first.**
-         * The controller covers eleven families and the mixin covers sixteen, and
-         * the overlap is ten that would have announced twice. What `toggle` reports
-         * is the *state*, and the state is this mixin's; the controller is a way of
+         * **From here rather than from `PopoverController`.** The controller covers
+         * eleven families and the mixin covers sixteen, so announcing from both
+         * would announce twice on the ten they share. What `toggle` reports is the
+         * *state*, and the state is this mixin's; the controller is a way of
          * putting a panel on the screen.
          *
          * **`newState` and `oldState`, because that is the platform's shape**, so a