@fusion.dev/helix-core 0.0.0-dev

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

@@ -0,0 +1,157 @@
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+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.
+ *
+ * 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.
+ *
+ * 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.
+ */
+export const MixinControllerChecked = (Base) => {
+    // JSDoc is duplicated from MixinControllerCheckedInterface deliberately. The
+    // interface is what TypeScript consumers see; this class is what the manifest
+    // analyzer reads when resolving inherited members into dependent packages.
+    class CheckedElement extends Base {
+        constructor() {
+            super(...arguments);
+            /**
+             * Initial checked state for uncontrolled use, where nothing declared one.
+             */
+            this.defaultChecked = false;
+            /**
+             * 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.
+             */
+            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`.
+         *
+         * 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;
+        }
+        set checked(next) {
+            const previous = this.checked;
+            this.checkedState = next;
+            this.requestUpdate('checked', previous);
+        }
+        /**
+         * 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.
+         *
+         * 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.
+         */
+        willUpdate(changed) {
+            super.willUpdate(changed);
+            this.toggleState('checked', this.checked);
+        }
+        /**
+         * 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.
+         */
+        requestChecked(next) {
+            if (this.checked === next) {
+                return true;
+            }
+            const applied = requestChange({
+                apply: (checked) => {
+                    const previous = this.checked;
+                    this.checkedState = checked;
+                    this.requestUpdate('checked', previous);
+                },
+                event: (checked) => new HelixBeforeToggleEvent({ checked }),
+                host: this,
+                next,
+            });
+            if (applied) {
+                /* `input` here and `change` relayed from the inner control, which is
+                   the pair a native checkbox sends. Announced after `apply`, so a
+                   handler reading `currentTarget.checked` reads the new state. */
+                this.dispatchEvent(new Event('input', { bubbles: true, composed: true }));
+            }
+            return applied;
+        }
+        /** Requests the opposite of the current state. */
+        toggleChecked() {
+            return this.requestChecked(!this.checked);
+        }
+        /**
+         * 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.
+         *
+         * Through `checked` rather than the private state, so a controlled consumer
+         * is asked the same way every other change asks.
+         */
+        formStateRestoreCallback(state) {
+            this.checked = state !== null;
+        }
+        /**
+         * Drops the uncontrolled 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.
+         */
+        resetChecked() {
+            const previous = this.checked;
+            this.checkedState = undefined;
+            this.requestUpdate('checked', previous);
+        }
+    }
+    __decorate([
+        property({ type: Boolean })
+    ], CheckedElement.prototype, "checked", null);
+    __decorate([
+        property({ attribute: 'default-checked', type: Boolean })
+    ], CheckedElement.prototype, "defaultChecked", void 0);
+    return CheckedElement;
+};

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

@@ -0,0 +1,49 @@
+import type { HelixElement } from '../../helix-element/helix-element.js';
+type Constructor<T> = new (...args: any[]) => T;
+/**
+ * The public surface `MixinControllerOpen` adds.
+ *
+ * Declared separately because TypeScript cannot emit declarations for an
+ * anonymous class that has private members (TS4094). Casting the mixin's return
+ * to this interface keeps the internals private and the build working.
+ */
+export declare class MixinControllerOpenInterface {
+    /** Initial open state for uncontrolled use. Ignored once `open` is set. */
+    defaultOpen: boolean;
+    /**
+     * 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.
+     */
+    open: boolean;
+    /**
+     * Requests an open-state change, and reports whether it was applied.
+     *
+     * Announces before it acts: a listener calling `preventDefault()` on the
+     * `helix-before-open` or `helix-before-close` refuses the change, and nothing moves.
+     */
+    requestOpen(next: boolean): boolean;
+    /** Requests the opposite of the current state. */
+    toggleOpen(): boolean;
+}
+/**
+ * Grafts open state onto a base class, and says so twice.
+ *
+ * `helix-before-open` and `helix-before-close` announce the change while it is
+ * still a request, so `preventDefault()` refuses it and nothing moves. Native
+ * `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.
+ *
+ * `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
+ * reset returns to.
+ *
+ * Records `:state(open)` whenever the element is open. Styled tiers select on
+ * that rather than on `[open]`, which is absent until somebody writes it.
+ */
+export declare const MixinControllerOpen: <T extends Constructor<HelixElement>>(Base: T) => Constructor<MixinControllerOpenInterface> & T;
+export {};

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

@@ -0,0 +1,176 @@
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+import { property } from 'lit/decorators.js';
+import { HelixBeforeCloseEvent, HelixBeforeOpenEvent } from '../../events/events.js';
+import { requestChange } from '../../utils/request-change/request-change.js';
+/**
+ * Grafts open state onto a base class, and says so twice.
+ *
+ * `helix-before-open` and `helix-before-close` announce the change while it is
+ * still a request, so `preventDefault()` refuses it and nothing moves. Native
+ * `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.
+ *
+ * `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
+ * reset returns to.
+ *
+ * Records `:state(open)` whenever the element is open. Styled tiers select on
+ * that rather than on `[open]`, which is absent until somebody writes it.
+ */
+export const MixinControllerOpen = (Base) => {
+    // JSDoc is duplicated from MixinControllerOpenInterface deliberately. The interface is
+    // what TypeScript consumers see; this class is what the manifest analyzer
+    // reads when resolving inherited members into dependent packages.
+    class OpenElement extends Base {
+        constructor() {
+            super(...arguments);
+            /**
+             * Initial open state for uncontrolled use, where nothing declared one.
+             */
+            this.defaultOpen = false;
+            /**
+             * The state, whoever set it, and `undefined` until somebody has.
+             *
+             * Prefixed, and it has to be. These mixins compose onto one prototype
+             * chain, `Select` takes this one and `MixinControllerValue` together, and
+             * TypeScript's `private` is a compile-time fiction: two mixins with a field
+             * called `state` share one property on the instance, and the second one
+             * 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.
+             */
+            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.
+         *
+         * **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.
+         */
+        get open() {
+            return this.openState ?? this.defaultOpen;
+        }
+        set open(next) {
+            const previous = this.open;
+            this.openState = next;
+            this.requestUpdate('open', previous);
+        }
+        /**
+         * 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.
+         */
+        willUpdate(changed) {
+            super.willUpdate(changed);
+            this.toggleState('open', this.open);
+        }
+        /**
+         * Requests an open-state change, and reports whether it was applied.
+         *
+         * Announces before it acts, so `preventDefault()` on the `helix-before-open` or
+         * `helix-before-close` is a refusal and nothing moves. Nobody refusing means the
+         * 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) {
+                return true;
+            }
+            const applied = requestChange({
+                apply: (open) => {
+                    const previous = this.open;
+                    this.openState = open;
+                    this.requestUpdate('open', previous);
+                },
+                event: (open) => (open ? new HelixBeforeOpenEvent() : new HelixBeforeCloseEvent()),
+                host: this,
+                next,
+            });
+            if (applied) {
+                this.announceToggle(next);
+            }
+            return applied;
+        }
+        /**
+         * 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.
+         *
+         * **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
+         * putting a panel on the screen.
+         *
+         * **`newState` and `oldState`, because that is the platform's shape**, so a
+         * consumer arriving from `<details>` reads the same two words. Not
+         * cancelable: the before events are the request, and a second cancelable
+         * event for one transition is two answers to one question.
+         */
+        announceToggle(open) {
+            const event = new Event('toggle', { bubbles: false, cancelable: false, composed: false });
+            Object.assign(event, {
+                newState: open ? 'open' : 'closed',
+                oldState: open ? 'closed' : 'open',
+            });
+            this.dispatchEvent(event);
+        }
+        /** Requests the opposite of the current state. */
+        toggleOpen() {
+            return this.requestOpen(!this.open);
+        }
+    }
+    __decorate([
+        property({ type: Boolean })
+    ], OpenElement.prototype, "open", null);
+    __decorate([
+        property({ attribute: 'default-open', type: Boolean })
+    ], OpenElement.prototype, "defaultOpen", void 0);
+    return OpenElement;
+};

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

@@ -0,0 +1,73 @@
+import type { HelixFormElement } from '../../helix-form-element/helix-form-element.js';
+type Constructor<T> = new (...args: any[]) => T;
+/**
+ * The public surface `MixinControllerValue` adds.
+ *
+ * Declared separately because TypeScript cannot emit declarations for an
+ * anonymous class that has private members (TS4094).
+ */
+export declare class MixinControllerValueInterface {
+    /**
+     * The value the markup declared, which is where a reset returns to.
+     *
+     * Separate from `value`, which is where the control is now, and gone from the
+     * reader's view the moment they change anything.
+     */
+    defaultValue: string;
+    /**
+     * What the control holds now, and what its form submits.
+     *
+     * Reading gives the real value, in either mode. Writing hands ownership to
+     * the consumer: from then on the control announces changes and applies none
+     * of them, and waits to be told.
+     */
+    value: string;
+    /**
+     * Whether every edit is announced, rather than every settled value.
+     *
+     * A control the reader types or drags in moves continuously, and the platform
+     * calls that `input`: `<input type="text">` fires one per keystroke and fires
+     * `change` once, on commit. Five controls here are that shape, and the rest
+     * change in discrete steps where a step *is* the change.
+     *
+     * It selects the event rather than the timing. `requestValue` is called
+     * whenever the value moves either way; this decides whether the control sends
+     * `input` alone or `input` and `change` together, so a consumer can read the
+     * name and know how often to expect it.
+     */
+    protected readonly announcesInput: boolean;
+    /** Requests a new value, and reports whether the request stood. */
+    requestValue(next: string): boolean;
+    /** Returns the control to the value its markup declared. */
+    formResetCallback(): void;
+    /** Restores the value when the browser brings a form back. */
+    formStateRestoreCallback(state: string | null): void;
+}
+/**
+ * Grafts `value`, `defaultValue`, and the two callbacks that answer a form.
+ *
+ * Every control with a value had written this, and by the third it was three
+ * copies of the same four members and the same seeding rule: `Input`, then
+ * `Toggle.Group`, then `Radio.Group`. The copies had not diverged, which is the
+ * argument for the mixin rather than against it, because the next one would
+ * have.
+ *
+ * **Seeded in `willUpdate`, not `connectedCallback`.** SSR never calls the
+ * latter, so a control with a `default-value` would serve empty and fill itself
+ * at hydration, which is a flash for a reader and a mismatch for React. Seeding
+ * once, before the first render, is what makes the server and the client agree.
+ *
+ * **What it does not own is reporting.** `setFormValue` stays with the
+ * component, because what an empty value means is the component's business: a
+ * text field submits its emptiness, since `""` is an answer and the field was
+ * on the form, while a group with nothing chosen submits nothing at all. One
+ * mixin cannot hold both without a flag, and a flag would be this rule written
+ * down twice.
+ *
+ * `Checkbox` deliberately does not take this. Its `value` is what it submits
+ * *when it is on* rather than what it holds, so it is configuration rather than
+ * state, and the state it does have is `checked`, which is
+ * `MixinControllerChecked`'s.
+ */
+export declare const MixinControllerValue: <T extends Constructor<HelixFormElement>>(Base: T) => Constructor<MixinControllerValueInterface> & T;
+export {};

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

@@ -0,0 +1,173 @@
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+import { property } from 'lit/decorators.js';
+import { HelixBeforeChangeEvent } from '../../events/events.js';
+import { requestChange } from '../../utils/request-change/request-change.js';
+/**
+ * Grafts `value`, `defaultValue`, and the two callbacks that answer a form.
+ *
+ * Every control with a value had written this, and by the third it was three
+ * copies of the same four members and the same seeding rule: `Input`, then
+ * `Toggle.Group`, then `Radio.Group`. The copies had not diverged, which is the
+ * argument for the mixin rather than against it, because the next one would
+ * have.
+ *
+ * **Seeded in `willUpdate`, not `connectedCallback`.** SSR never calls the
+ * latter, so a control with a `default-value` would serve empty and fill itself
+ * at hydration, which is a flash for a reader and a mismatch for React. Seeding
+ * once, before the first render, is what makes the server and the client agree.
+ *
+ * **What it does not own is reporting.** `setFormValue` stays with the
+ * component, because what an empty value means is the component's business: a
+ * text field submits its emptiness, since `""` is an answer and the field was
+ * on the form, while a group with nothing chosen submits nothing at all. One
+ * mixin cannot hold both without a flag, and a flag would be this rule written
+ * down twice.
+ *
+ * `Checkbox` deliberately does not take this. Its `value` is what it submits
+ * *when it is on* rather than what it holds, so it is configuration rather than
+ * state, and the state it does have is `checked`, which is
+ * `MixinControllerChecked`'s.
+ */
+export const MixinControllerValue = (Base) => {
+    // JSDoc is duplicated from the interface deliberately. The interface is what
+    // TypeScript consumers see; this class is what the manifest analyzer reads
+    // when resolving inherited members into dependent packages.
+    class ValueElement extends Base {
+        constructor() {
+            super(...arguments);
+            /**
+             * The value the markup declared, which is where a reset returns to.
+             */
+            this.defaultValue = '';
+            /**
+             * 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.
+             */
+            this.valueState = undefined;
+            /**
+             * Whether a reader edits this continuously, which decides the native name.
+             *
+             * **It used to pick between `helix-input` and `helix-change`**, which was
+             * one mechanism under two names and said *phase* where it meant
+             * *granularity*. The request event is `helix-before-change` whatever the
+             * answer; this decides which native event announces the result, `input`
+             * while a reader is editing against `change` when they are done, which is
+             * the distinction the platform already draws. See 294.
+             *
+             * Discrete by default: only a control the reader edits continuously says
+             * otherwise.
+             */
+            this.announcesInput = false;
+        }
+        /**
+         * What the control holds now, and what its form submits.
+         *
+         * One property, not two. Reading gives the real value whichever mode the
+         * control is in, so `input.value` answers the question anyone asking it
+         * meant. Writing hands ownership to the consumer, which is what
+         * `<helix-input value="x">` says too, and matches what a controlled input
+         * means in React: the value is theirs and the control waits to be told.
+         * `default-value` is how markup seeds one it does not want to own.
+         *
+         * The same shape as the other three mixins, which is the point of them
+         * being four of a kind rather than four of three kinds.
+         *
+         * helix-input
+         */
+        get value() {
+            return this.valueState ?? this.defaultValue;
+        }
+        set value(next) {
+            const previous = this.value;
+            this.valueState = next;
+            this.requestUpdate('value', previous);
+        }
+        /**
+         * Announces the applied value under the platform's own name.
+         *
+         * **After `apply`, never before**, which is the whole reason this is
+         * separate from the request event: a native handler reads
+         * `event.target.value`, and it has to be the value that was just applied.
+         *
+         * **Both, for a discrete control, because that is what the platform does.**
+         * A native `<select>` sends `input` and then `change` from one choice: the
+         * value moved, and the reader is also done. A continuous control announces
+         * `input` here and relays `change` from its inner control when the reader
+         * is done, so the pair keeps the platform's timings rather than reporting a
+         * commit on every keystroke.
+         */
+        announceNatively() {
+            this.dispatchEvent(new Event('input', { bubbles: true, composed: true }));
+            if (!this.announcesInput) {
+                this.dispatchEvent(new Event('change', { bubbles: true, composed: false }));
+            }
+        }
+        /**
+         * Requests a new value, and reports whether the request stood.
+         *
+         * Announces before it acts, so `preventDefault()` on the `helix-before-change` is
+         * a refusal and nothing moves. Nobody refusing means the control updates
+         * itself, whether or not a consumer declared `value`: 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.
+         */
+        requestValue(next) {
+            if (this.value === next) {
+                return true;
+            }
+            const applied = requestChange({
+                apply: (value) => {
+                    const previous = this.value;
+                    this.valueState = value;
+                    this.requestUpdate('value', previous);
+                },
+                event: (value) => new HelixBeforeChangeEvent({ value }),
+                host: this,
+                next,
+            });
+            if (applied) {
+                this.announceNatively();
+            }
+            return applied;
+        }
+        /**
+         * Returns the control to the value its markup declared.
+         *
+         * Both halves are dropped, the consumer's and the control's, because a
+         * reset means the form is as it was served. Clearing only the internal one
+         * would leave a control that had been written to stuck at that value.
+         */
+        formResetCallback() {
+            const previous = this.value;
+            this.valueState = undefined;
+            this.requestUpdate('value', previous);
+        }
+        /**
+         * Restores the value when the browser brings a form back.
+         *
+         * Falling back to `defaultValue` rather than to empty, because a restore
+         * with no state is a form the browser has nothing recorded for, which is
+         * the same situation as a fresh one.
+         */
+        formStateRestoreCallback(state) {
+            const previous = this.value;
+            this.valueState = state ?? undefined;
+            this.requestUpdate('value', previous);
+        }
+    }
+    __decorate([
+        property({ attribute: 'default-value' })
+    ], ValueElement.prototype, "defaultValue", void 0);
+    __decorate([
+        property()
+    ], ValueElement.prototype, "value", null);
+    return ValueElement;
+};

package/dist/mixins/mixin-dismissible/mixin-dismissible.d.ts

@@ -0,0 +1,41 @@
+import type { LitElement } from 'lit';
+import { HelixDismissEvent } from '../../events/events.js';
+type Constructor<T> = new (...args: any[]) => T;
+/**
+ * The API a dismissible surface has, as TypeScript sees it.
+ */
+export declare class DismissibleElement {
+    /** Whether it offers a control to take it away. */
+    dismissible: boolean;
+    /** Accessible name for that control. */
+    dismissLabel: string;
+    /** Announces that it should go, and reports whether the request stood. */
+    dismiss(): boolean;
+    /** The event, built but not dispatched, for a caller that owns the timing. */
+    protected dismissEvent(): HelixDismissEvent;
+}
+/**
+ * Grafts `dismissible`, its label, and the event that says so.
+ *
+ * Three surfaces had written this: `Announcement`, `Tag` and `Toast.Item`, each
+ * with the same two properties, the same event, and the same expression for the
+ * label. They had not diverged, which is the argument for extracting rather than
+ * against it, because the fourth would have.
+ *
+ * **The label reads the default slot, not the whole element**, and that is a bug
+ * fix rather than a move. Every copy said `this.textContent`, which is every
+ * light-DOM descendant including the ones assigned elsewhere. On `Announcement`
+ * and `Tag` that is the same thing, because they have one slot. On `Toast.Item`
+ * it swept in the actions: a message reading "Could not reach the server" with a
+ * `Retry` button announced itself as "Could not reach the server Retry", and the
+ * consumer removing it from their list got that string to match on.
+ *
+ * **`dismissEvent()` is separate from `dismiss()` for the one that needs it.**
+ * `Announcement` and `Tag` dispatch and are done: they own no state, so a
+ * refusal is the whole of the consumer's answer. `Toast.Item` holds an `open`
+ * it may or may not own, so its event has to go through the controlled-change
+ * path with an `apply` beside it. Giving it the event rather than the method
+ * lets it keep the contract and skip the default.
+ */
+export declare const MixinDismissible: <T extends Constructor<LitElement>>(Base: T) => Constructor<DismissibleElement> & T;
+export {};