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

package/custom-elements.json

@@ -46,6 +46,15 @@
               "default": "new Set<string>()",
               "description": "Which state attributes this controller wrote, so only those are removed."
             },
+            {
+              "kind": "field",
+              "name": "recorded",
+              "type": {
+                "text": "HTMLElement | undefined"
+              },
+              "privacy": "private",
+              "description": "The control the record above is about, so a replacement resets it."
+            },
             {
               "kind": "method",
               "name": "forward",
@@ -149,7 +158,7 @@
                 "text": "'block' | 'inline' | 'none'"
               },
               "default": "'inline'",
-              "description": "Which axis the readings are laid out along.\n\n**An axis and not a boolean, because two of the four charts do not use x.**\nThis was `tracks = true`, and every reading was resolved from the pointer's\nx whatever the chart was doing. A horizontal bar chart runs its categories\n*down* the box, so moving the pointer from the first row to the last never\nchanged the answer: measured on four rows, all four reported the third,\nwhich is the slot the middle of the box falls in. It looked like a tooltip\nthat would not follow and was a tooltip reading the wrong axis.\n\n`none` is the ring. Its slices are real elements at every angle, so the\nreading under the pointer is the one the pointer is over, and arithmetic on\neither axis would answer with whichever slice shared a coordinate: at three\no'clock and at nine o'clock, x alone gives the same slice for opposite\nsides. The slices call `set` and this only holds the answer."
+              "description": "Which axis the readings are laid out along.\n\n**An axis and not a boolean, because two of the four charts do not use x.**\nA horizontal bar chart runs its categories *down* the box, so resolving\nevery reading from the pointer's x leaves a move from the first row to the\nlast never changing the answer: measured on four rows, all four reported\nthe third, which is the slot the middle of the box falls in. It looks like\na tooltip that will not follow and is a tooltip reading the wrong axis.\n\n`none` is the ring. Its slices are real elements at every angle, so the\nreading under the pointer is the one the pointer is over, and arithmetic on\neither axis would answer with whichever slice shared a coordinate: at three\no'clock and at nine o'clock, x alone gives the same slice for opposite\nsides. The slices call `set` and this only holds the answer."
             },
             {
               "kind": "method",
@@ -283,7 +292,7 @@
         },
         {
           "kind": "class",
-          "description": "Lets a control elsewhere on the page operate this one, declaratively.\n\n```html\n<helix-button commandfor=\"confirm\" command=\"--show\">Delete…</helix-button>\n<helix-dialog id=\"confirm\">…</helix-dialog>\n```\n\n**The platform's own invoker, not a convention of ours.** `commandfor` and\n`command` are attributes the browser understands: it resolves the id, wires\nthe two together, and dispatches a `command` event at the target when the\ntrigger is activated. That is a real event with a real source, so it works\nfor a click, for Enter, for Space, and for anything else the platform decides\ncounts as activation later.\n\nThe alternative was a `data-` recipe of our own with a delegated listener on\nthe document, and it is worse in every direction: a global listener a\nconsumer cannot see, an id lookup we would write ourselves, activation\nsemantics we would have to guess at, and a convention that is ours to\ndocument and theirs to learn.\n\n**Only custom commands reach a custom element.** The built-in ones —\n`show-modal`, `close`, `toggle-popover` — are defined against native elements\nand the browser applies them itself; pointed at a custom element they do\nnothing. So the names here start with `--`, which is the platform's marker\nfor \"the target decides what this means\", and the target deciding is exactly\nwhat this is.\n\nUnrecognized commands are left alone rather than swallowed, so a host that\nanswers `--show` does not quietly absorb a `--print` meant for something\nelse.",
+          "description": "Lets a control elsewhere on the page operate this one, declaratively.\n\n```html\n<helix-button commandfor=\"confirm\" command=\"--show\">Delete…</helix-button>\n<helix-dialog id=\"confirm\">…</helix-dialog>\n```\n\n**The platform's own invoker, not a convention of ours.** `commandfor` and\n`command` are attributes the browser understands: it resolves the id, wires\nthe two together, and dispatches a `command` event at the target when the\ntrigger is activated. That is a real event with a real source, so it works\nfor a click, for Enter, for Space, and for anything else the platform decides\ncounts as activation later.\n\nA `data-` recipe of our own would mean a delegated document listener a\nconsumer cannot see, an id lookup and activation semantics we would write\nourselves, and a convention that is ours to document and theirs to learn.\n\n**Only custom commands reach a custom element.** The built-in ones\n(`show-modal`, `close`, `toggle-popover`) are defined against native elements\nand the browser applies them itself; pointed at a custom element they do\nnothing. So the names here start with `--`, which is the platform's marker\nfor \"the target decides what this means\", and the target deciding is exactly\nwhat this is.\n\nUnrecognized commands are left alone rather than swallowed, so a host that\nanswers `--show` does not quietly absorb a `--print` meant for something\nelse.",
           "name": "CommandController",
           "members": [
             {
@@ -367,7 +376,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Puts text on the clipboard and holds a confirmation for a moment.\n\nA controller rather than a component, because copying is a behavior and not a\nshape. Color's chip is a swatch that copies, and a copy button is a button\nthat copies, and those two have nothing in common to look at: what they share\nis the write, the confirmation that follows it, the timer that ends it and the\nevent that announces it. Written twice, the second one would get the failure\ncase wrong.\n\n**There are two routes and both are tried**, because the modern one is gated\nin more places than it looks: an insecure origin, an unfocused document, and a\nPermissions Policy defaulting to `self`, which a sandboxed iframe is not. The\ncomponent using this reported as not working, and a control that does nothing\nis indistinguishable from a broken one. See `write` above.\n\n**Where neither route is allowed, the failure is silence.** The confirmation\ndoes not appear, which is the honest report: a message about a clipboard is\nworse than a chip that did not flash, and there is nothing a reader could do\nabout a permission policy anyway.\n\n**The event is announced after the write, not before it.** It is not\ncancelable for the same reason: by the time anything could be said, the text\nis already on the clipboard, and an event that cannot prevent what it\ndescribes should not pretend otherwise.\n\nThe timer is cleared when the host leaves the document, or a component removed\nmid-confirmation asks a detached element to re-render.",
+          "description": "Puts text on the clipboard and holds a confirmation for a moment.\n\nA controller rather than a component, because copying is a behavior and not a\nshape. Color's chip is a swatch that copies, and a copy button is a button\nthat copies, and those two have nothing in common to look at: what they share\nis the write, the confirmation that follows it, the timer that ends it and the\nevent that announces it. Written twice, the second one would get the failure\ncase wrong.\n\n**There are two routes and both are tried**, because the modern one is gated\nin more places than it looks and a control that does nothing is\nindistinguishable from a broken one. See `write` above.\n\n**Where neither route is allowed, the failure is silence.** The confirmation\ndoes not appear, which is the honest report: a message about a clipboard is\nworse than a chip that did not flash, and there is nothing a reader could do\nabout a permission policy anyway.\n\n**The event is announced after the write, not before it.** It is not\ncancelable for the same reason: by the time anything could be said, the text\nis already on the clipboard, and an event that cannot prevent what it\ndescribes should not pretend otherwise.\n\nThe timer is cleared when the host leaves the document, or a component removed\nmid-confirmation asks a detached element to re-render.",
           "name": "CopyController",
           "members": [
             {
@@ -445,7 +454,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Pushes a group's `disabled` onto its members, on every update, unasked.\n\n**The cascade itself is `inheritDisabled`, and this is what makes it\nautomatic.** Four groups called that function by hand from inside whichever\nmethod they happened to use for writing to their items: `place` in two of\nthem, `sync` in a third, `place` again in the fourth. That works, and it is\nthe wrong shape for three reasons.\n\nIt runs when that method runs. A group whose items changed without going\nthrough it left them holding the last answer, and which paths reach it is a\ndifferent set in each of the four.\n\nIt has to be remembered. A fifth group gets no cascade at all, and nothing\nsays so: the property exists, the attribute reflects, and the members simply\nignore it. That is the failure this exists to make impossible, because it is\ninvisible in review and only shows up when someone disables a set.\n\nAnd it adds no API. A group already has `disabled`, from `HelixFormElement`\nor from the consumer; nothing here introduces a property or a method for\nanyone to call. By this repo's own rule that makes it a controller and not a\nmixin: it reacts to a lifecycle and nothing else.\n\nSo a group states its members once, at construction, and never thinks about\nit again:\n\n    new DisabledCascadeController(this, { items: () => this.items })\n\n**Runs after every render, and on every `slotchange`.** The second half is\nnot an extra: a member arriving in the light DOM changes no property, so Lit\nschedules nothing, and a render-only cascade leaves a member slotted into an\nalready-disabled group enabled. Measured before it was added, on a radio\ngroup holding two disabled members with a third inserted: `110`, and the\nthird was live in a set nobody could use.\n\nThe listener is on the render root rather than on the host, because\n`slotchange` bubbles but is not composed: it reaches the shadow root that\nowns the slot and stops there. On the host it would never fire at all.\n\nAfter render rather than before, because the items are read from the DOM and\na newly slotted member is not there until the render that assigns it.\n\nIdempotent, so running on every update costs a comparison per member and\nnothing else: `inheritDisabled` writes only where the answer changed and\nremembers what each member said for itself, which is what lets a group be\nre-enabled without freeing a member that was disabled on its own.",
+          "description": "Pushes a group's `disabled` onto its members, on every update, unasked.\n\n**The cascade itself is `inheritDisabled`, and this is what makes it\nautomatic.** Called by hand it runs only when whichever method holds the call\nruns, so a group whose items changed by some other path leaves them holding\nthe last answer, and a group that forgets the call gets no cascade at all\nwith nothing to say so: the property exists, the attribute reflects, and the\nmembers simply ignore it. That is invisible in review and shows up only when\nsomeone disables a set.\n\nIt adds no API. A group already has `disabled`, from `HelixFormElement` or\nfrom the consumer; nothing here introduces a property or a method for anyone\nto call. By this repo's own rule that makes it a controller and not a mixin:\nit reacts to a lifecycle and nothing else.\n\nSo a group states its members once, at construction, and never thinks about\nit again:\n\n    new DisabledCascadeController(this, { items: () => this.items })\n\n**Runs after every render, and on every `slotchange`.** The second half is\nnot an extra: a member arriving in the light DOM changes no property, so Lit\nschedules nothing, and a render-only cascade leaves a member slotted into an\nalready-disabled group enabled. Measured before it was added, on a radio\ngroup holding two disabled members with a third inserted: `110`, and the\nthird was live in a set nobody could use.\n\nThe listener is on the render root rather than on the host, because\n`slotchange` bubbles but is not composed: it reaches the shadow root that\nowns the slot and stops there. On the host it would never fire at all.\n\nAfter render rather than before, because the items are read from the DOM and\na newly slotted member is not there until the render that assigns it.\n\nIdempotent, so running on every update costs a comparison per member and\nnothing else: `inheritDisabled` writes only where the answer changed and\nremembers what each member said for itself, which is what lets a group be\nre-enabled without freeing a member that was disabled on its own.",
           "name": "DisabledCascadeController",
           "members": [
             {
@@ -522,7 +531,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Closes an overlay on Escape or on a pointer press outside it.\n\nBoth, because they are different intentions with the same meaning: Escape is\nthe keyboard's way out and clicking away is the pointer's, and an overlay\nthat honours only one is one half its readers cannot dismiss.\n\nThe outside press is watched on `pointerdown` rather than `click`, so a press\nthat starts outside and drags across the overlay still counts as leaving\nrather than as interacting.\n\nA press inside a frame is the third case, and it needs its own signal. The\nframe swallows the event, so the document that owns the overlay never sees a\n`pointerdown` at all, and where the frame is cross-origin there is nothing to\nlisten to inside it either. What is observable is that the window lost focus\nand a frame on this page gained it, which is exactly a press the document\ncannot see. Leaving the browser altogether blurs the window too, so what took\nfocus is the part that distinguishes them.",
+          "description": "Closes an overlay on Escape or on a pointer press outside it.\n\nBoth, because they are different intentions with the same meaning: Escape is\nthe keyboard's way out and clicking away is the pointer's, and an overlay\nthat honors only one is one half its readers cannot dismiss.\n\nThe outside press is watched on `pointerdown` rather than `click`, so a press\nthat starts outside and drags across the overlay still counts as leaving\nrather than as interacting.\n\nA press inside a frame is the third case, and it needs its own signal. The\nframe swallows the event, so the document that owns the overlay never sees a\n`pointerdown` at all.\n\nWhere the frame is same-origin there is a document to listen to, and this\nlistens to it: the same handler, on every reachable frame document, so a\npress in there arrives as a press whose path holds nothing of the overlay,\nwhich is what it is.\n\n**The focus signal alone was not enough, and a browser difference is why.**\nA press in a frame moves focus into it in Chromium, so the window blurs and a\nframe is what took focus. WebKit does neither: focus stays on the menu item\nthe reader pressed to open the overlay, the window never blurs, and every\nobservable thing about that tap says nothing happened. Measured on the\nsandbox, whose preview is a frame filling half the tool, the settings menu\ncould not be dismissed by pressing the component it configures.\n\nBoth signals are kept, because they answer different frames. The listener\nonly reaches same-origin ones; the blur only fires where the browser moves\nfocus. A cross-origin frame in Chromium has the second and not the first.",
           "name": "DismissController",
           "members": [
             {
@@ -583,6 +592,28 @@
               "privacy": "private",
               "readonly": true
             },
+            {
+              "kind": "method",
+              "name": "frameDocuments",
+              "privacy": "private",
+              "static": true,
+              "return": {
+                "type": {
+                  "text": "Document[]"
+                }
+              },
+              "description": "Every frame document on the page this one is allowed to read.\n\nThrough the shadow roots as well, because a component that renders a frame\nrenders it inside itself: the sandbox's preview is one, and\n`document.querySelectorAll` cannot see it.\n\nA cross-origin frame throws on `contentDocument` rather than returning\nnull in some browsers, so the read is guarded and the frame is simply\nskipped. Nothing is lost by skipping it that was not already lost: there is\nno listener to add to a document this one may not touch."
+            },
+            {
+              "kind": "field",
+              "name": "frames",
+              "type": {
+                "text": "Document[]"
+              },
+              "privacy": "private",
+              "default": "[]",
+              "description": "The frame documents being listened to, held so the same ones are released.\n\nGathered when the overlay opens rather than watched for: an overlay is open\nfor as long as a reader is deciding something, and a frame that arrives\ninside that window is a page rebuilding itself under a menu, which is not a\ncase worth a `MutationObserver` on every open surface. Held rather than\nre-collected on the way out, because a frame removed while the overlay was\nopen would otherwise be missed and one navigated elsewhere would be a\ndifferent document."
+            },
             {
               "kind": "method",
               "name": "activate",
@@ -633,7 +664,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "One page of a nested set showing at a time, with a way back.\n\nA drill-down replaces the panel rather than opening a second one beside it.\nThat is the right shape wherever there is no room for two: on a phone there\nis no second column, and on a touch screen there is no hover to open one\nwith. What a reader gets instead is one panel, a title saying where they are,\nand a way back.\n\n**Extracted from `Menu`, which had all of this and did not say so.** The menu\nheld a `page`, derived the rows on it, read a title off the row that opened\nit, and reset on close; the sandbox's settings dropdown has been a drill-down\nfor as long as it has existed. None of that is about menus. Taking it out is\nwhat lets a settings panel, a filter stack or a navigation tree have the same\nbehavior without one of them being a menu that is pretending.\n\n**The tree is the state.** A row's page is its own children, assigned to a\nslot, so the controller holds one reference, the row currently drilled into,\nand derives everything else from the DOM. The alternative, an id per page and\na map beside it, is a second copy of the structure that a consumer can put\nout of step with the first.\n\n**A stack, not a pointer.** `back()` returns to the page above rather than to\nthe root, because a reader three levels down pressed one control and expects\none level. The stack is rebuilt from the DOM by walking up from the current\nrow, so it cannot disagree with the tree: a page removed while it was showing\ntakes its ancestors with it, and `atRoot` becomes true rather than the\ncontroller holding a reference to something detached.\n\nNothing here decides what a row *is*, what it renders, or what happens when\none is chosen. It answers where the reader is and what is on this page.",
+          "description": "One page of a nested set showing at a time, with a way back.\n\nA drill-down replaces the panel rather than opening a second one beside it.\nThat is the right shape wherever there is no room for two: on a phone there\nis no second column, and on a touch screen there is no hover to open one\nwith. What a reader gets instead is one panel, a title saying where they are,\nand a way back.\n\n**None of this is about menus.** A settings panel, a filter stack or a\nnavigation tree gets the same behavior without being a menu that is\npretending.\n\n**The tree is the state.** A row's page is its own children, assigned to a\nslot, so the controller holds one reference, the row currently drilled into,\nand derives everything else from the DOM. The alternative, an id per page and\na map beside it, is a second copy of the structure that a consumer can put\nout of step with the first.\n\n**A stack, not a pointer.** `back()` returns to the page above rather than to\nthe root, because a reader three levels down pressed one control and expects\none level. The stack is rebuilt from the DOM by walking up from the current\nrow, so it cannot disagree with the tree: a page removed while it was showing\ntakes its ancestors with it, and `atRoot` becomes true rather than the\ncontroller holding a reference to something detached.\n\nNothing here decides what a row *is*, what it renders, or what happens when\none is chosen. It answers where the reader is and what is on this page.",
           "name": "DrilldownController",
           "members": [
             {
@@ -827,7 +858,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Places one element against another, and keeps it there.\n\nPositioning is `@floating-ui/dom` rather than arithmetic written here. Two\nthings in particular are why. A `position: fixed` element inside an ancestor\ncarrying `transform`, `filter`, `will-change`, or `contain` is positioned\nagainst that ancestor and not the viewport, so viewport coordinates land it\nsomewhere else entirely. And an overlay has to clear its nearest *clipping*\nancestor, not just the window, or it is placed correctly inside a scrolling\npanel and clipped out of sight by it. Both are ordinary here, and both are a\nlong tail of browser behavior rather than a formula.\n\n`autoUpdate` keeps the position through scrolling on any ancestor, resizes of\neither element, and layout shifts.\n\nThe side the element actually landed on is written back as `data-placement`,\nso a styled tier can animate from it rather than from the side that was\nasked for.\n\n**The custom properties are declared here because this is what writes them.**\nEach carries a measurement taken against the viewport that no stylesheet can\ntake for itself, and `core` ships no CSS, so there is no reader inside this\npackage and none of them is private. `check:hooks` pairs a `@cssproperty`\nwith a rule that reads one, in both directions, and the underscore these used\nto carry was what exempted them from it.",
+          "description": "Places one element against another, and keeps it there.\n\nPositioning is `@floating-ui/dom` rather than arithmetic written here. Two\nthings in particular are why. A `position: fixed` element inside an ancestor\ncarrying `transform`, `filter`, `will-change`, or `contain` is positioned\nagainst that ancestor and not the viewport, so viewport coordinates land it\nsomewhere else entirely. And an overlay has to clear its nearest *clipping*\nancestor, not just the window, or it is placed correctly inside a scrolling\npanel and clipped out of sight by it. Both are ordinary here, and both are a\nlong tail of browser behavior rather than a formula.\n\n`autoUpdate` keeps the position through scrolling on any ancestor, resizes of\neither element, and layout shifts.\n\nThe side the element actually landed on is written back as `data-placement`,\nso a styled tier can animate from it rather than from the side that was\nasked for.\n\n**The custom properties are declared here because this is what writes them.**\nEach carries a measurement taken against the viewport that no stylesheet can\ntake for itself, and `core` ships no CSS, so there is no reader inside this\npackage and none of them is private. the `hooks` rule pairs a documented\nhook with a rule that reads one, in both directions.",
           "name": "FloatingController",
           "cssProperties": [
             {
@@ -874,7 +905,7 @@
               },
               "privacy": "private",
               "default": "0",
-              "description": "Which run of placements the results coming back belong to.\n\n`computePosition` is async, so a measurement started before `stop()` still\nresolves after it and wrote its result onto a surface that had just been\ntaken down: the inline `position` and `translate` went back on, and so did\n`data-placed`, which is the attribute five families gate visibility on.\nOpening and closing inside one task is all it takes, since the write lands\na microtask later.\n\nA counter rather than an `AbortController`, because there is nothing to\nabort: the work is already done by the time the answer arrives and the only\nquestion is whether anybody still wants it."
+              "description": "Which run of placements the results coming back belong to.\n\n`computePosition` is async, so a measurement started before `stop()` still\nresolves after it and would write its result onto a surface that had just\nbeen taken down: the inline `position` and `translate` back on, and with\nthem `data-placed`, which is the attribute five families gate visibility\non. Opening and closing inside one task is all it takes, since the write\nlands a microtask later.\n\nA counter rather than an `AbortController`, because there is nothing to\nabort: the work is already done by the time the answer arrives and the only\nquestion is whether anybody still wants it."
             },
             {
               "kind": "field",
@@ -1037,7 +1068,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Measures the marked child and writes the geometry onto a traveling mark.\n\n**Four components had written this and the copies had diverged.** `Navigation`,\n`Tabs`, `Toggle.Group` and `Outline` each measured an active child and wrote\na position onto an indicator, and two of them had bugs the others did not.\n`Outline`'s own comment counted the repetition rather than resolving it, and\nthe audit found the same shape independently in all four.\n\nWhat the copies disagreed about, and what this settles:\n\n**The inline axis is signed.** In a right-to-left document the distance is\nmeasured from the surface's right edge and applied as a negative translation,\nbecause the mark travels from the inline start and the inline start is on the\nright. `Navigation` measured from the physical left and applied it from the\ninline-start edge with an unsigned offset, so its marker went the wrong way\nin RTL. That is the bug this extraction exists to stop repeating.\n\n**The border has to come off both axes.** `getBoundingClientRect` gives the\nborder box and the containing block is the padding box, so a surface with a\nborder of its own puts the mark one border-width out. `Tabs` and\n`Toggle.Group` each did this arithmetic separately, `Outline` did the block\nhalf with `clientTop`, and `Navigation` did neither. `clientLeft` and `clientTop`\nare the border widths, already resolved, which is why they are used here\nrather than parsing `borderLeftWidth`.\n\n**Nothing is written until there is something to measure.** A zero-width box\nis a component whose children have not upgraded yet, and writing zeroes would\npark the mark at the origin and leave it there. The `data-placed` attribute is\nwhat a stylesheet waits for, so a mark fades in where it belongs rather than\nsliding from the corner on first paint.\n\nThe four custom properties are the contract. What a component does with them\nis its own business, which is how one controller serves a bar under a tab, a\npill filling it, and a rule down the side of a contents page.\n\n**Declared here because this is what writes them.** They carry a measurement\nno stylesheet can take, they are read by whoever draws the mark, and `core`\nships no CSS, so there is no reader inside this package and nothing about\nthem is private. `check:hooks` pairs a `@cssproperty` with a rule that reads\none, in both directions, and the underscore these used to carry was what\nexempted them from it.",
+          "description": "Measures the marked child and writes the geometry onto a traveling mark.\n\nServes `Navigation`, `Tabs`, `Toggle.Group` and `Outline`. The two things\nhand-written copies of this get wrong:\n\n**The inline axis is signed.** In a right-to-left document the distance is\nmeasured from the surface's right edge and applied as a negative translation,\nbecause the mark travels from the inline start and the inline start is on the\nright. Measuring from the physical left and applying an unsigned offset from\nthe inline-start edge sends the mark the wrong way in RTL.\n\n**The border has to come off both axes.** `getBoundingClientRect` gives the\nborder box and the containing block is the padding box, so a surface with a\nborder of its own puts the mark one border-width out. `clientLeft` and\n`clientTop` are the border widths, already resolved, which is why they are\nused here rather than parsing `borderLeftWidth`.\n\n**Nothing is written until there is something to measure.** A zero-width box\nis a component whose children have not upgraded yet, and writing zeroes would\npark the mark at the origin and leave it there. The `data-placed` attribute is\nwhat a stylesheet waits for, so a mark fades in where it belongs rather than\nsliding from the corner on first paint.\n\nThe four custom properties are the contract. What a component does with them\nis its own business, which is how one controller serves a bar under a tab, a\npill filling it, and a rule down the side of a contents page.\n\n**Declared here because this is what writes them.** `core` ships no CSS, so\nevery reader is outside this package and none of these is private.\nthe `hooks` rule pairs a documented hook with a rule that reads one, in both\ndirections.",
           "name": "IndicatorController",
           "cssProperties": [
             {
@@ -1139,7 +1170,7 @@
                 "text": "{ on: HTMLElement; settle: (event?: TransitionEvent) => void } | undefined"
               },
               "privacy": "private",
-              "description": "The listener currently waiting, so the next move can take it off first.\n\n**Without this, a move inside a second orphans a listener.** Each placement\nbuilt a fresh `settle` closure and then called `clearTimeout` on the timer\nbelonging to the *previous* one, which is the only thing that would have\nremoved it: the event itself never arrives under reduced motion, where\nthere is no transition to end. So a reader changing tabs quickly, or any\nreader at all with motion reduced, left one dead listener per selection on\nan element that lives as long as the page. The people who asked for less\nwork were the ones accumulating it."
+              "description": "The listener currently waiting, so the next move can take it off first.\n\n**Without this, a move inside a second orphans a listener.** Clearing the\ntimer is not enough on its own: the `transitionend` that would remove the\nlistener never arrives under reduced motion, where there is no transition\nto end, so a reader changing tabs quickly, or any reader at all with motion\nreduced, leaves one dead listener per selection on an element that lives as\nlong as the page."
             },
             {
               "kind": "method",
@@ -1182,7 +1213,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Moves through a set of items with the arrow keys, and chooses as it goes.\n\n**Moving and choosing are one act here, not two.** That is the radio group\npattern and it is the difference from a listbox: moving focus without\nchoosing leaves a keyboard reader sitting on an item they have not selected,\nwith nothing on screen saying which of the two is true. A pointer user\nchooses by arriving, so a keyboard user does too.\n\n**Both axes, always.** A vertical set still answers left and right, and a\nhorizontal one still answers up and down. Binding only the axis the items\nhappen to be laid out on means a reader who guesses wrong gets nothing, and\n`orientation` is presentation: the same set of choices reads the same way\nwhichever direction it runs.\n\nDisabled items are skipped rather than stopped at, so a set with a gap in it\nstill moves in one press.\n\nWritten because `Radio.Group` and `Toggle.Group` had this twice, identically,\ndown to the order of the branches. The second copy is what makes it a\ncontroller: one is a component's own business, two is a pattern, and the two\nhad not diverged only because nothing had touched them yet.\n\n**`Tabs` is the third, and it is what `origin` and `selects` are for.** It had\ndiverged, which is the case the paragraph above was worried about: it started\nfrom focus rather than from the selection, and it moved without choosing when\n`manual` was set. Both are real and neither is a tabs-only idea, so they are\noptions here rather than a reason to keep a fourth copy. What it does *not*\nkeep is its own key set: it bound the horizontal pair only, and both axes is\nthe house position, argued two paragraphs up. A reader on a tab who presses\nDown now moves along the row instead of getting nothing.",
+          "description": "Moves through a set of items with the arrow keys, and chooses as it goes.\n\n**Moving and choosing are one act here, not two.** That is the radio group\npattern and it is the difference from a listbox: moving focus without\nchoosing leaves a keyboard reader sitting on an item they have not selected,\nwith nothing on screen saying which of the two is true. A pointer user\nchooses by arriving, so a keyboard user does too.\n\n**Both axes, always.** A vertical set still answers left and right, and a\nhorizontal one still answers up and down. Binding only the axis the items\nhappen to be laid out on means a reader who guesses wrong gets nothing, and\n`orientation` is presentation: the same set of choices reads the same way\nwhichever direction it runs.\n\nDisabled items are skipped rather than stopped at, so a set with a gap in it\nstill moves in one press.\n\nA set that starts from focus rather than from the selection, or that moves\nwithout choosing, says so through `origin` and `selects`. Neither is a reason\nto keep a hand-written copy, and neither exempts a set from both axes.",
           "name": "KeyboardNavigationController",
           "members": [
             {
@@ -1290,7 +1321,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "A surface that floats against something, in the top layer, until dismissed.\n\nThree things always travel together and were written out longhand three\ntimes: the popover API, a `FloatingController` and a `DismissController`.\nIndividually each is small, which is exactly why the copies drifted rather\nthan being noticed. **`Select` never called `showPopover` at all**, so its\nlist was an ordinary positioned panel and any ancestor with `overflow:\nhidden` clipped it, while a menu two folders away in the same position did\nnot. That is not a difference anyone chose.\n\n**The top layer is the whole point.** A floating panel has to escape every\nclipping ancestor between it and the page, and `position: fixed` does not do\nthat: it is clipped by `overflow` on any ancestor and re-anchored entirely by\nan ancestor carrying `transform`, `filter` or `contain`. The popover API\nlifts the element out of the tree's paint order for real, and it is the only\nthing that does.\n\n`manual` rather than `auto`, because the host owns dismissal. `auto`\npopovers light-dismiss themselves and close each other, which is close to\nwhat is wanted and not the same: a select that closed itself before its own\nchange event landed, or a submenu that closed its parent, are both things the\nplatform would do here and neither is right.\n\n**The order matters on the way up.** `showPopover` first, then position:\nmeasuring an element that is still `display: none` gives zeroes, so a surface\npositioned before it is shown lands at the origin and slides into place on\nthe next frame. On the way down it is the reverse, and stopping the observer\nbefore hiding avoids a final measurement of an element on its way out.\n\nWhat this does not own is *when*. Opening is the host's, because a menu opens\non click, a tooltip on hover and a select on either, and none of that is\nabout surfaces.",
+          "description": "A surface that floats against something, in the top layer, until dismissed.\n\nBundles the three things that always travel together: the popover API, a\n`FloatingController` and a `DismissController`.\n\n**The top layer is the whole point.** A floating panel has to escape every\nclipping ancestor between it and the page, and `position: fixed` does not do\nthat: it is clipped by `overflow` on any ancestor and re-anchored entirely by\nan ancestor carrying `transform`, `filter` or `contain`. The popover API\nlifts the element out of the tree's paint order for real, and it is the only\nthing that does.\n\n`manual` rather than `auto`, because the host owns dismissal. `auto`\npopovers light-dismiss themselves and close each other, which is close to\nwhat is wanted and not the same: a select that closed itself before its own\nchange event landed, or a submenu that closed its parent, are both things the\nplatform would do here and neither is right.\n\n**The order matters on the way up.** `showPopover` first, then position:\nmeasuring an element that is still `display: none` gives zeroes, so a surface\npositioned before it is shown lands at the origin and slides into place on\nthe next frame. On the way down it is the reverse, and stopping the observer\nbefore hiding avoids a final measurement of an element on its way out.\n\nWhat this does not own is *when*. Opening is the host's, because a menu opens\non click, a tooltip on hover and a select on either, and none of that is\nabout surfaces.",
           "name": "PopoverController",
           "members": [
             {
@@ -1422,7 +1453,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Resolves the element a chart reads from, and follows it.\n\n**Three charts had written this out separately before it was one thing**, and\nthe drift had already started: two of them called the lookup `#table` and one\ncalled it `#source`, for the same method with the same body. Every chart that\ntakes a `for` wants exactly this, and wants it to behave identically, so it is\na controller rather than a paragraph in each of them.\n\nA controller and not a pure function, by the test the rules set: it reacts to\nthe host's lifecycle. It has to start watching when the host connects, stop\nwhen it leaves, and re-resolve when `for` changes.\n\n**What it refuses is as much the point as what it accepts.** A `<table>` or\nanything built from grid roles, including this library's own `helix-table`,\nwhose roles live in `ElementInternals` and therefore write no attribute at\nall. Anything else resolves to null, so a `for` pointed at a paragraph draws\nnothing rather than something arbitrary.\n\nThe element is watched for `childList` and `characterData` alike, because\nrenaming a series edits a text node in place rather than replacing a cell,\nand nothing in a page has reason to know a chart is reading it.",
+          "description": "Resolves the element a chart reads from, and follows it.\n\nEvery chart that takes a `for` wants exactly this, and wants it to behave\nidentically, so it is a controller rather than a paragraph in each of them.\n\nA controller and not a pure function, by the test the rules set: it reacts to\nthe host's lifecycle. It has to start watching when the host connects, stop\nwhen it leaves, and re-resolve when `for` changes.\n\n**What it refuses is as much the point as what it accepts.** A `<table>` or\nanything built from grid roles, including this library's own `helix-table`,\nwhose roles live in `ElementInternals` and therefore write no attribute at\nall. Anything else resolves to null, so a `for` pointed at a paragraph draws\nnothing rather than something arbitrary.\n\nThe element is watched for `childList` and `characterData` alike, because\nrenaming a series edits a text node in place rather than replacing a cell,\nand nothing in a page has reason to know a chart is reading it.",
           "name": "SourceController",
           "members": [
             {
@@ -1509,7 +1540,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Reads a design token as the sRGB triple a shader or a 2D canvas can take, and\ntells the host when the palette underneath it moves.\n\n**Two hops, and both are load-bearing.** A custom property's own value is the\nunevaluated function text, so `getComputedStyle` on a probe is the only way\nto see what it resolves to. And what it resolves to is not `rgb()`: the\npalette derives from an `oklch()` seed, and Chrome answers `lab(100 0 0)` for\nwhite. Parsing that with a regular expression for numbers reads the three\nchannels as 100, 0 and 0, which divided by 255 is a dark red.\n\nThat is not hypothetical. It shipped, and `--helix-color-foreground` arrived\nas a dark red that painted a warm streak down a shader for an afternoon. It\nsurvived review because a warm cast on a saturated gradient is also what a\nscreenshot's chroma subsampling produces, so the picture agreed with the bug.\n\nThe conversion is therefore the browser's own: fill a pixel and read it back.\nThat holds for `lab()`, `oklch()`, `color-mix()` and whatever a token is\nwritten in next, which is the property worth having in a design system whose\npalette is derived rather than listed.\n\n**A controller and not a mixin**, by this repository's own line: it adds no\nproperty or method a consumer sets. It reacts to lifecycle, holding a probe\nthat has to be created after the host connects and removed when it leaves,\nand it watches for the color mode changing so the host can repaint.\n\n**Client only, and that is the contract rather than a limitation.** There is\nno computed style on a server and no canvas to convert with, so `read`\nanswers the fallback there. Every caller is drawing into a canvas, which does\nnot exist on a server either.",
+          "description": "Reads a design token as the sRGB triple a shader or a 2D canvas can take, and\ntells the host when the palette underneath it moves.\n\n**Two hops, and both are load-bearing.** A custom property's own value is the\nunevaluated function text, so `getComputedStyle` on a probe is the only way\nto see what it resolves to. And what it resolves to is not `rgb()`: the\npalette derives from an `oklch()` seed, and Chrome answers `lab(100 0 0)` for\nwhite. Parsing that with a regular expression for numbers reads the three\nchannels as 100, 0 and 0, which divided by 255 is a dark red.\n\nA screenshot cannot catch that: a warm cast on a saturated gradient is also\nwhat chroma subsampling produces, so the picture agrees with the bug.\n\nThe conversion is therefore the browser's own: fill a pixel and read it back.\nThat holds for `lab()`, `oklch()`, `color-mix()` and whatever a token is\nwritten in next, which is the property worth having in a design system whose\npalette is derived rather than listed.\n\n**A controller and not a mixin**, by this repository's own line: it adds no\nproperty or method a consumer sets. It reacts to lifecycle, holding a probe\nthat has to be created after the host connects and removed when it leaves,\nand it watches for the color mode changing so the host can repaint.\n\n**Client only, and that is the contract rather than a limitation.** There is\nno computed style on a server and no canvas to convert with, so `read`\nanswers the fallback there. Every caller is drawing into a canvas, which does\nnot exist on a server either.",
           "name": "TokenColorController",
           "members": [
             {
@@ -1620,7 +1651,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Works out which slice of a long set is worth rendering.\n\n**A controller and not an element, which is the whole reason it is here.**\nTable, Listbox, Combobox and Tree each need windowing *inside* themselves,\nand an element would make each of them nest one in its own shadow root: a\nlistbox whose options are inside a `<helix-virtual-list>` is a listbox whose\noptions are no longer its children, so its own keyboard, its own selection\nand its own ARIA all have a stranger in the middle of them.\n\n**A windowed set still reports its true length, and each row its true\nposition.** This is the part virtualization usually gets wrong and the reason\nthe arithmetic lives somewhere shared. A reader on row 4,000 of 10,000 must\nhear \"4,000 of 10,000\", so `aria-setsize` is the count and `aria-posinset` is\nthe real index, never the position within the rendered slice. The window is a\nrendering decision and the set is a fact, and a component that lets the first\noverwrite the second has told a screen reader the list is twelve long.\n\n**The spacers are what make the scrollbar honest.** Rendering twelve rows in\na box that should scroll for ten thousand gives a thumb the size of the\ntrack, so the room the absent rows would have taken is left as padding before\nand after. A reader dragging that thumb is dragging against the real length.\n\n**What it does not do, and the reason is narrower than it first looks.** True\nvirtualization means never creating the rows that are not on screen, and that\nneeds the set as *data*. Two channels are shut: a consumer's items arrive as\nlight-DOM children, which exist by the time this could decide not to create\nthem, and an `items` property cannot survive React hydration, which skips\nevery property it would have to apply imperatively (see `bindReactHandler`,\nand the note in the rules that objects and functions have that bug and are\nnot fixed).\n\n**A third is open, and this said otherwise until 21 Aug 2026.** Data as *text*\nin the markup, a `<script type=\"application/json\">` child or an attribute, is\nneither a property nor a node per row: React's hydration bug cannot touch text\nit renders as a child, a server emits it, and the node count is one. The\ncharts already read data out of the document this way, `for=\"<id>\"` at a real\n`<table>`, so the pattern is in the library rather than being invented for\nthis.\n\nSo the thing actually blocked is the *row template*. Turning an item into\nmarkup wants either a render function, which is a function property and dies\non the same bug, or a `<template>` with named holes, which survives because it\nis markup and which no component here asks anyone to write. That is a decision\nabout what this library is willing to look like, not a platform limit, and it\nis open at #71.\n\nSo what this buys is the expensive half rather than all of it: the rows\noutside the window are not laid out and not painted, which is where the time\ngoes in a long list, and the node count stays. That is worth having and it is\nnot worth calling something it is not. An element that windows children it\nwas handed is not a virtual list, whatever it is named.\n\n**One estimate, not per-row measurement.** Measuring every row to place it is\nhow a virtual list ends up reading the layout it is trying to avoid, and it\nis what makes them jump: a row taller than its estimate shifts everything\nafter it at the moment it renders. A fixed estimate is a straight line\nbetween scroll offset and index, which never disagrees with itself. Rows of\ngenuinely different heights are a different component and a harder one.",
+          "description": "Works out which slice of a long set is worth rendering.\n\n**A controller and not an element, which is the whole reason it is here.**\nTable, Listbox, Combobox and Tree each need windowing *inside* themselves,\nand an element would make each of them nest one in its own shadow root: a\nlistbox whose options are inside a `<helix-virtual-list>` is a listbox whose\noptions are no longer its children, so its own keyboard, its own selection\nand its own ARIA all have a stranger in the middle of them.\n\n**A windowed set still reports its true length, and each row its true\nposition.** This is the part virtualization usually gets wrong and the reason\nthe arithmetic lives somewhere shared. A reader on row 4,000 of 10,000 must\nhear \"4,000 of 10,000\", so `aria-setsize` is the count and `aria-posinset` is\nthe real index, never the position within the rendered slice. The window is a\nrendering decision and the set is a fact, and a component that lets the first\noverwrite the second has told a screen reader the list is twelve long.\n\n**The spacers are what make the scrollbar honest.** Rendering twelve rows in\na box that should scroll for ten thousand gives a thumb the size of the\ntrack, so the room the absent rows would have taken is left as padding before\nand after. A reader dragging that thumb is dragging against the real length.\n\n**What it does not do, and the reason is narrower than it first looks.** True\nvirtualization means never creating the rows that are not on screen, and that\nneeds the set as *data*. Two channels are shut: a consumer's items arrive as\nlight-DOM children, which exist by the time this could decide not to create\nthem, and an `items` property cannot survive React hydration, which skips\nevery property it would have to apply imperatively (see `bindReactHandler`,\nand the note in the rules that objects and functions have that bug and are\nnot fixed).\n\n**A third channel is open.** Data as *text*\nin the markup, a `<script type=\"application/json\">` child or an attribute, is\nneither a property nor a node per row: React's hydration bug cannot touch text\nit renders as a child, a server emits it, and the node count is one. The\ncharts already read data out of the document this way, `for=\"<id>\"` at a real\n`<table>`, so the pattern is in the library rather than being invented for\nthis.\n\nSo the thing actually blocked is the *row template*. Turning an item into\nmarkup wants either a render function, which is a function property and dies\non the same bug, or a `<template>` with named holes, which survives because it\nis markup and which no component here asks anyone to write. That is a decision\nabout what this library is willing to look like, not a platform limit, and it\nis open at #71.\n\nSo what this buys is the expensive half rather than all of it: the rows\noutside the window are not laid out and not painted, which is where the time\ngoes in a long list, and the node count stays. That is worth having and it is\nnot worth calling something it is not. An element that windows children it\nwas handed is not a virtual list, whatever it is named.\n\n**One estimate, not per-row measurement.** Measuring every row to place it is\nhow a virtual list ends up reading the layout it is trying to avoid, and it\nis what makes them jump: a row taller than its estimate shifts everything\nafter it at the moment it renders. A fixed estimate is a straight line\nbetween scroll offset and index, which never disagrees with itself. Rows of\ngenuinely different heights are a different component and a harder one.",
           "name": "VirtualizeController",
           "members": [
             {
@@ -1931,7 +1962,7 @@
         },
         {
           "kind": "class",
-          "description": "A stop asking the tour to move.\n\nComposed and bubbling, because a stop is slotted into the root and the root\nhas to hear it across that boundary.\n\n**A class rather than the raw `CustomEvent` this was.** It dispatched, it\nbubbled, and it was invisible: `check:events` matches `new HelixSomethingEvent(`,\nso a hand-rolled `CustomEvent` was not held to being declared, and nothing\ncarried it into the manifest. Consumers could hear it and could not find it,\nwhich is the trap #75 is about, in its purest form.",
+          "description": "A stop asking the tour to move.\n\nComposed and bubbling, because a stop is slotted into the root and the root\nhas to hear it across that boundary.\n\n**A class rather than a hand-rolled `CustomEvent`.** A dispatch is matched as\n`new HelixSomethingEvent(`, so a raw `CustomEvent` is not held to being\ndeclared and nothing carries it into the manifest: consumers can hear it and\ncannot find it.",
           "name": "HelixTourAskEvent",
           "members": [
             {
@@ -1953,7 +1984,7 @@
         },
         {
           "kind": "class",
-          "description": "The eyedropper opening, and closing again.\n\nTwo events rather than one carrying a flag, because what a consumer does with\nthem is not symmetrical: the surface holding the picker has to get out of the\nway for the sample and come back afterwards, and those are two moments with\ndifferent work in each.\n\n**A class rather than the bare `Event` these were.** They dispatched, they\nbubbled, `ColorInput` bound both, and `check:events` matched\n`new CustomEvent(` and so held neither to being declared: two pieces of\npublic API that a consumer could hear and could not find. The check reads\n`new Event(` now as well.\n\nNo detail, because there is nothing to say beyond that it happened.",
+          "description": "The eyedropper opening, and closing again.\n\nTwo events rather than one carrying a flag, because what a consumer does with\nthem is not symmetrical: the surface holding the picker has to get out of the\nway for the sample and come back afterwards, and those are two moments with\ndifferent work in each.\n\n**A class rather than a bare `Event`.** The check that holds an event to being\ndeclared reads `new Event(` as well as `new HelixSomethingEvent(`, so a\nhand-rolled one is public API a consumer can hear and cannot find.\n\nNo detail, because there is nothing to say beyond that it happened.",
           "name": "HelixSampleStartEvent",
           "members": [
             {
@@ -2019,7 +2050,7 @@
         },
         {
           "kind": "class",
-          "description": "A set is about to make a different child current, and can be refused.\n\n**The generic `helix-change` covered this and should not have.** Eleven\nfamilies that are not form controls announced their state under the word the\nplatform uses for a committed value, which is 294's whole complaint read from\nthe other end: `Tabs` moving to another tab, `Tree` marking another row and\n`Steps` advancing are not a value changing, they are a set choosing. One word\nfor four questions is what `appearance` was before `check:axes`.\n\n`active` names which child is current, so `activate` is the verb, and unlike\n`change` the platform has no claim on it.\n\n**It has a notification half now, and this said it did not.** *Reversed 28 Aug\n2026.* The paragraph here read \"there is no notification half: a native\n`change` would be a lie about what moved, and no other native event means\nthis. The before event is the whole channel.\" The first half of that is still\nexactly right, which is why the pair is `helix-activate` and not `change`. The\nconclusion did not follow: that no *native* word fits is an argument against\nborrowing one, not an argument against having a notification at all.\n\nWhat the missing half cost is the thing 294 fixed for values and left here.\nA consumer who only wants to know which child is current now had one channel,\nand it fires *before* `apply`: `currentTarget.active` still holds the previous\nvalue inside the handler, and `detail.value` is a proposal another listener may\nrefuse. Measured across the four families taking this mixin, nothing at all was\nannounced afterwards. `Tabs` and `Tree` looked covered because `helix-select`\nbubbles up from a child, which fires when an item is *chosen* and not when\n`active` is assigned; `Steps` and `Video Playlist` had nothing.\n\nSo the shape is the one `MixinControllerOpen` already has, a cancelable\nrequest and a plain notification after the state has moved. See #325.",
+          "description": "A set is about to make a different child current, and can be refused.\n\n**Not a generic `helix-change`.** `Tabs` moving to another tab, `Tree` marking\nanother row and `Steps` advancing are not a value changing, they are a set\nchoosing, and the platform's word for a committed value would say the wrong\nthing. `active` names which child is current, so `activate` is the verb, and\nunlike `change` the platform has no claim on it.\n\n**This fires before the state moves.** Inside a handler `currentTarget.active`\nstill holds the previous value, and `detail.value` is a proposal another\nlistener may refuse, so a consumer who only wants to know which child is\ncurrent listens for `helix-activate` instead. `helix-select` is not that\nnotification either: it fires when an item is *chosen*, not when `active` is\nassigned.\n\nThe shape is the one `MixinControllerOpen` already has, a cancelable request\nand a plain notification after the state has moved.",
           "name": "HelixBeforeActivateEvent",
           "members": [
             {
@@ -2041,7 +2072,7 @@
         },
         {
           "kind": "class",
-          "description": "A set has made a different child current.\n\nThe notification half of `helix-before-activate`, dispatched after the state\nhas moved, so `currentTarget.active` is the new value and the detail is a fact\nrather than a proposal.\n\n**Not cancelable**, for the reason every notification here is not: the\ndecision was taken by the event before it, and a second refusable event for\none transition is two answers to one question.\n\n**Prefixed, and it has to be.** `activate` unprefixed is not in any\n`*EventMap` in the DOM library, checked rather than assumed, but the prefix is\nwhat stops an event dispatched inside a shadow root and retargeted to the host\nbeing mistaken for something the host's own contents sent. That is the same\nargument `helix-select` and `helix-resize` are excused under.",
+          "description": "A set has made a different child current.\n\nThe notification half of `helix-before-activate`, dispatched after the state\nhas moved, so `currentTarget.active` is the new value and the detail is a fact\nrather than a proposal.\n\n**Not cancelable**, for the reason every notification here is not: the\ndecision was taken by the event before it, and a second refusable event for\none transition is two answers to one question.\n\n**Prefixed, and it has to be.** `activate` unprefixed is not in any\n`*EventMap` in the DOM library, checked rather than assumed, but the prefix is\nwhat stops an event dispatched inside a shadow root and retargeted to the host\nbeing mistaken for something the host's own contents sent.",
           "name": "HelixActivateEvent",
           "members": [
             {
@@ -2107,7 +2138,7 @@
         },
         {
           "kind": "class",
-          "description": "The divider between a sandbox's panes is about to move, and can be refused.\n\nIts own verb rather than a `helix-before-resize` carrying which divider moved:\na sandbox has two, and they were told apart by a field on a detail every other\nrequest in this file also carries. See 306.",
+          "description": "The divider between a sandbox's panes is about to move, and can be refused.\n\nIts own verb rather than a `helix-before-resize` carrying which divider moved:\na sandbox has two, and they were told apart by a field on a detail every other\nrequest in this file also carries.",
           "name": "HelixBeforeSplitEvent",
           "members": [
             {
@@ -2195,7 +2226,7 @@
         },
         {
           "kind": "class",
-          "description": "A value is about to change, and the change can be refused.\n\n**The request half of every value control.** It announces the value being\n*proposed*, before anything moves, so a listener calling `preventDefault()`\nrefuses it and the control stays where it was. That is how a consumer takes\none decision without declaring a mode, which is what 294 settled: the element\nalways owns and applies its state, and refusing is the way to take it over.\n\n**The notification is native and separate.** Once this has gone out and the\nvalue has moved, the control announces it again under the platform's own\nname, `input` while a reader is editing and `change` when they are done, so\n`onChange` in React and `onchange=` in HTML both reach it and\n`currentTarget.value` is correct by the time a handler reads it. This event\ncarries the detail because at the moment it fires the value is not on the\nelement yet.\n\n**It replaced `helix-change` and `helix-input` on the value controls**, which\nwere one mechanism under two names chosen by `announcesInput`. The name said\n*phase* and the flag meant *granularity*, so a consumer reading \"change\" as\n\"the reader is done\" wired a request to `onhelix-change` and got one per\ncharacter. Granularity is now what the platform already says it is, `input`\nagainst `change`, and `announcesInput` picks which native one fires rather\nthan which name this carries. See 294.",
+          "description": "A value is about to change, and the change can be refused.\n\n**The request half of every value control.** It announces the value being\n*proposed*, before anything moves, so a listener calling `preventDefault()`\nrefuses it and the control stays where it was. That is how a consumer takes\none decision without declaring a mode, which is what 294 settled: the element\nalways owns and applies its state, and refusing is the way to take it over.\n\n**The notification is native and separate.** Once this has gone out and the\nvalue has moved, the control announces it again under the platform's own\nname, `input` while a reader is editing and `change` when they are done, so\n`onChange` in React and `onchange=` in HTML both reach it and\n`currentTarget.value` is correct by the time a handler reads it. This event\ncarries the detail because at the moment it fires the value is not on the\nelement yet.\n\n**`announcesInput` picks which native notification fires, not which name this\ncarries.** Granularity is the platform's own distinction, `input` against\n`change`; the request is always this one event.",
           "name": "HelixBeforeChangeEvent",
           "members": [
             {
@@ -2217,7 +2248,7 @@
         },
         {
           "kind": "class",
-          "description": "A checked state is about to change, and the change can be refused.\n\n**Its own event rather than a `helix-before-change` carrying a boolean**, and\nthe reason is recorded rather than aesthetic. Reported through the value\nevent the state arrived as `String(checked)`, so a consumer received the\nstring `\"false\"`, which is truthy, and this library's own checkbox group\ndecoded it with `detail.value === 'true'`. A test asserting the value would\nhave passed on that bug. A control whose state is a boolean wants an event\nwith a typed boolean in it.\n\nThe notification is native, as it is for a value: the control relays `change`\nfrom the inner input and announces `input` beside it, so `onChange` reads\n`currentTarget.checked` and gets a boolean from the platform.\n\nIt also ends a collision. Checkbox Group listened for its boxes' change and\ndispatched its own under the same name from the same host, so it had to call\n`stopImmediatePropagation` to keep a consumer from receiving one box's\nboolean alongside the whole set. Two names, two facts.",
+          "description": "A checked state is about to change, and the change can be refused.\n\n**Its own event rather than a `helix-before-change` carrying a boolean.**\nThrough the value event the state arrives as `String(checked)`, so a consumer\nreceives the string `\"false\"`, which is truthy, and a test asserting the value\npasses on that bug. A control whose state is a boolean wants an event with a\ntyped boolean in it.\n\nThe notification is native, as it is for a value: the control relays `change`\nfrom the inner input and announces `input` beside it, so `onChange` reads\n`currentTarget.checked` and gets a boolean from the platform.\n\nIt also ends a collision: Checkbox Group listened for its boxes' change and\ndispatched its own under the same name from the same host, so it needed\n`stopImmediatePropagation` to keep a consumer from receiving one box's boolean\nalongside the whole set. Two names, two facts.",
           "name": "HelixBeforeToggleEvent",
           "members": [
             {
@@ -2327,7 +2358,7 @@
         },
         {
           "kind": "class",
-          "description": "Fired when a header crosses the threshold between resting at the top of the\npage and floating over it.\n\n**State a consumer used to read off an attribute, said out loud instead.**\nThe header reflected this as `data-scrolled` on its own host, which is an\nattribute nobody rendered: a server sends the element without it and the\nelement adds it on upgrade, so a framework hydrating the page finds markup\nthat no longer matches what it sent. The threshold now lives in a custom\nstate, which is deliberately not in the DOM and therefore not something a\nhydration pass can disagree with.\n\nThat closes the observability the attribute accidentally provided. A\n`MutationObserver` can watch an attribute and there is no equivalent for\n`ElementInternals.states`, so a component holding a boolean nothing can read\nis a component with a private opinion its consumers demonstrably need: the\nbar's own backdrop is drawn by the page around it, and the page has to know\nwhen to light it.\n\nNot cancelable. It reports where the page is rather than asking permission to\nbe there, and refusing it would leave the state and the announcement\ndisagreeing.\n\nThe hysteresis stays inside the header, which is the point of announcing at\nall: a consumer listening to `scroll` itself would be a second opinion on\nwhen the page counts as scrolled, and the two would part company at the eight\npixels of travel this waits for.",
+          "description": "Fired when a header crosses the threshold between resting at the top of the\npage and floating over it.\n\n**The threshold lives in a custom state, and is announced rather than\nreflected.** A `data-scrolled` on the host is an attribute nobody rendered: a\nserver sends the element without it and the element adds it on upgrade, so a\nframework hydrating the page finds markup that no longer matches what it sent.\nA custom state is deliberately not in the DOM and therefore not something a\nhydration pass can disagree with.\n\nThat closes the observability an attribute would accidentally provide. A\n`MutationObserver` can watch an attribute and there is no equivalent for\n`ElementInternals.states`, so a component holding a boolean nothing can read\nis a component with a private opinion its consumers demonstrably need: the\nbar's own backdrop is drawn by the page around it, and the page has to know\nwhen to light it.\n\nNot cancelable. It reports where the page is rather than asking permission to\nbe there, and refusing it would leave the state and the announcement\ndisagreeing.\n\nThe hysteresis stays inside the header, which is the point of announcing at\nall: a consumer listening to `scroll` itself would be a second opinion on\nwhen the page counts as scrolled, and the two would part company at the eight\npixels of travel this waits for.",
           "name": "HelixScrolledEvent",
           "members": [
             {
@@ -2459,7 +2490,7 @@
         },
         {
           "kind": "class",
-          "description": "Fired when the reader asks for a different order.\n\nCancelable, and refusing it leaves the order alone, which is what makes a\nserver-side sort expressible: the consumer refuses the local reorder, fetches,\nand hands back a new set. In controlled mode nothing is written whatever the\nanswer, and this is the element reporting that a heading was clicked.\n\nNot `helix-change`: nothing about the data changed, only the order it is read\nin, and a consumer listening for changes to a value should not hear a sort.\nThat is the same distinction `helix-filter` is drawn on.",
+          "description": "Fired when the reader asks for a different order.\n\nCancelable, and refusing it leaves the order alone, which is what makes a\nserver-side sort expressible: the consumer refuses the local reorder, fetches,\nand hands back a new set. This is the element reporting that a heading was\nclicked, before it acts on it.\n\nNot `helix-change`: nothing about the data changed, only the order it is read\nin, and a consumer listening for changes to a value should not hear a sort.\nThat is the same distinction `helix-filter` is drawn on.",
           "name": "HelixSortEvent",
           "members": [
             {
@@ -2839,7 +2870,7 @@
               },
               "static": true,
               "default": "'helix-headless-'",
-              "description": "The prefix this tier registers its elements under.\n\n**A component that renders another renders its own tier's version of it**,\nso `helix-headless-pagination-size` composes `helix-headless-select` and\n`helix-pagination-size` composes `helix-select`. One template says\n`${this.tag('select')}` and each tier answers with its own name.\n\nIt was the public tag in both tiers, on the argument that each imports its\nown element under that name. That works and costs three things: the name\nmeans two different things depending on what a consumer imported, the\nheadless tier composes an element it does not ship, and the composition\ncannot be tested there at all, because there is no `helix-select` on that\ntier to test it against. Thirty-nine specs had to be moved back to\n`helix/styled` for exactly that reason.\n\n**A prefix rather than an override per composition**, which was the first\nplan and does not compile. An override re-renders the fragment from the\nsubclass, and the fragment reads members the base keeps private:\n`PaginationSize` alone would have had to widen `options`, `current` and\n`handleChange` to `protected` so a subclass could say the same thing again.\nSixteen families of that is a lot of encapsulation spent on saying one\nword differently."
+              "description": "The prefix this tier registers its elements under.\n\n**A component that renders another renders its own tier's version of it**,\nso `helix-headless-pagination-size` composes `helix-headless-select` and\n`helix-pagination-size` composes `helix-select`. One template says\n`${this.tag('select')}` and each tier answers with its own name.\n\n**The public tag may not be the composed one, in either tier.** Using it\ncosts three things: the name means two different things depending on what a\nconsumer imported, the headless tier composes an element it does not ship,\nand the composition cannot be tested there at all, because there is no\n`helix-select` on that tier to test it against.\n\n**A prefix rather than an override per composition**, which was the first\nplan and does not compile. An override re-renders the fragment from the\nsubclass, and the fragment reads members the base keeps private:\n`PaginationSize` alone would have had to widen `options`, `current` and\n`handleChange` to `protected` so a subclass could say the same thing again.\nSixteen families of that is a lot of encapsulation spent on saying one\nword differently."
             },
             {
               "kind": "method",
@@ -2893,7 +2924,7 @@
                   }
                 }
               ],
-              "description": "Records a boolean fact about this element as a custom state.\n\n**The host belongs to whoever rendered it, and a component's own\nbookkeeping may not be kept there.** An attribute written on the first\nupdate is markup a consumer's server never sent, so a React consumer\nhydrates a DOM that has gained attributes since and reports a mismatch it\nwill not patch up. A custom state is not in the DOM at all: it carries the\nfact to a stylesheet through `:state()` and leaves the markup alone, so the\nserver's output and the client's agree by construction.\n\n`SETTLED` carries the long version of that argument and was the first to\nmove. `checked`, `open`, `invalid` and `has-label` followed it on 27 Aug\n2026, after the same fault was reported once more from the landing page's\nshowcase: a `default-checked` switch, a `default-checked` checkbox and a\n`default-open` accordion item, each writing its own resolved state onto\nitself before React reached the node.\n\n**The deferral that had been holding it is not a fix and could not be.**\nThe site imports the definitions from an effect so the upgrades fall the\nother side of hydration, which works only while hydration is one pass:\nanything that splits it, a streamed segment or a suspended boundary, puts\nan upgrade back inside the window. Timing cannot be the guarantee when the\nfact is kept somewhere React reconciles.\n\nFeature-tested rather than assumed, the way `hostAria` tests element\nreferences. An engine without `CustomStateSet` records nothing and keeps\nwhatever the resting rule draws, which is the safe direction to fail, and\nLit's server shim is one of them: a custom state is a fact about a running\nelement, and a server has nothing to say about it."
+              "description": "Records a boolean fact about this element as a custom state.\n\n**The host belongs to whoever rendered it, and a component's own\nbookkeeping may not be kept there.** An attribute written on the first\nupdate is markup a consumer's server never sent, so a React consumer\nhydrates a DOM that has gained attributes since and reports a mismatch it\nwill not patch up. A custom state is not in the DOM at all: it carries the\nfact to a stylesheet through `:state()` and leaves the markup alone, so the\nserver's output and the client's agree by construction.\n\n`SETTLED` carries the long version of that argument; `checked`, `open`,\n`invalid` and `has-label` are recorded the same way, each of them a state a\n`default-*` attribute resolves before React reaches the node.\n\n**Deferring the definitions is not a fix and could not be.** Importing them\nfrom an effect so the upgrades fall the other side of hydration works only\nwhile hydration is one pass: anything that splits it, a streamed segment or\na suspended boundary, puts an upgrade back inside the window. Timing cannot\nbe the guarantee when the fact is kept somewhere React reconciles.\n\nFeature-tested rather than assumed, the way `hostAria` tests element\nreferences. An engine without `CustomStateSet` records nothing and keeps\nwhatever the resting rule draws, which is the safe direction to fail.\n\n**Lit's server shim is no longer one of them**, and this said it was.\n`@lit-labs/ssr-dom-shim@1.6.0` sets `this.states = new Set()` in its\n`ElementInternals` constructor, so the guard passes on the server and a\ncustom state is recorded where nothing reads it, which is harmless. The\nengines the test is for are browsers: Safari below 17.4 and Firefox below\n126. There the write is a `TypeError`, so a component that bypasses this\nfails to render rather than rendering without whatever the state draws."
             },
             {
               "kind": "field",
@@ -2902,7 +2933,7 @@
                 "text": "Promise<void>"
               },
               "readonly": true,
-              "description": "Resolves a frame after the first update, when transitions are switched on.\n\n**Named `whenSettled` because `settled` was taken four times over.** Image\nand Splitter each have a private `settle`, and both color controls carry a\n`settled` of their own, all of them older than this and none of them about\ntransitions. A base class takes the name every subclass then cannot use, so\nit takes the one nobody wanted.\n\n**The state it reports cannot be watched, which is why this exists.** A\n`MutationObserver` could see `[data-settled]` arrive and there is no\nequivalent for `ElementInternals.states`: a custom state is deliberately not\nin the DOM, which is the whole reason it replaced the attribute. Anything\nthat used to wait on the attribute waits on this instead, and gets a better\nsignal for it, an awaited promise being what the callers wanted rather than\na mutation they had to interpret.\n\nSeparate from `updateComplete`, which resolves in the microtask checkpoint\nthe suppression is still active in. That is the distinction `readyToMove`\nin `@fusion.dev/helix-testing` was written around and the reason two checkbox specs\nwere misread as a token fault for days.\n\nIt never resolves where `requestAnimationFrame` never fires, which is a\nserver, a hidden tab, and happy-dom. Callers that must not hang race it\nagainst a timeout; `readyToMove` does exactly that.",
+              "description": "Resolves a frame after the first update, when transitions are switched on.\n\n**Named `whenSettled` because `settled` was taken four times over.** Image\nand Splitter each have a private `settle`, and both color controls carry a\n`settled` of their own, all of them older than this and none of them about\ntransitions. A base class takes the name every subclass then cannot use, so\nit takes the one nobody wanted.\n\n**The state it reports cannot be watched, which is why this exists.** A\n`MutationObserver` could see `[data-settled]` arrive and there is no\nequivalent for `ElementInternals.states`: a custom state is deliberately not\nin the DOM, which is the whole reason it replaced the attribute. Anything\nthat used to wait on the attribute waits on this instead, and gets a better\nsignal for it, an awaited promise being what the callers wanted rather than\na mutation they had to interpret.\n\nSeparate from `updateComplete`, which resolves in the microtask checkpoint\nthe suppression is still active in. That is the distinction `readyToMove`\nin `@fusion.dev/helix-testing` is written around.\n\nIt never resolves where `requestAnimationFrame` never fires, which is a\nserver, a hidden tab, and happy-dom. Callers that must not hang race it\nagainst a timeout; `readyToMove` does exactly that.",
               "default": "new Promise<void>((resolve) => { this.resolveSettled = resolve })"
             },
             {
@@ -3022,7 +3053,7 @@
                 "text": "boolean"
               },
               "default": "false",
-              "description": "Whether the control is non-interactive.\n\nReflected, because the styled tier selects on it, and mirrored to\n`aria-disabled` rather than removing the element from the accessibility\ntree, so a screen reader can still announce that the control exists.\n\nThe mirror is below and was for a while only a sentence: this paragraph\ndescribed it, four components had their own copies of it, and the class\nitself did nothing. Here is where it belongs, because here is where\n`disabled` is.",
+              "description": "Whether the control is non-interactive.\n\nReflected, because the styled tier selects on it, and mirrored to\n`aria-disabled` rather than removing the element from the accessibility\ntree, so a screen reader can still announce that the control exists.\n\nThe mirror itself is in `willUpdate` below, here rather than in each\ncontrol, because here is where `disabled` is.",
               "attribute": "disabled",
               "reflects": true
             },
@@ -3034,7 +3065,7 @@
               },
               "privacy": "protected",
               "default": "false",
-              "description": "Whether an ancestor `<fieldset disabled>` has switched this control off.\n\nThe platform tells a form-associated element through `formDisabledCallback`\nand nothing here implemented it, so a control inside a disabled fieldset\nstayed fully typeable and announced itself as enabled. Measured: a\n`helix-input` in one accepted text, reported `disabled` as false, and\ncarried no `aria-disabled`.\n\nWhat the platform already did on its own is the submission half. The same\nmeasurement showed the fieldset's controls absent from the form's entry\nlist and the host matching `:disabled`, so the value never went anywhere.\nWhat was missing is everything a reader can see or touch.\n\nState rather than the `disabled` property. Writing that would reflect an\nattribute the consumer's server markup does not have, which React reports\non hydration and does not patch up, and it would also silently overwrite\nwhat the consumer set."
+              "description": "Whether an ancestor `<fieldset disabled>` has switched this control off.\n\nThe platform tells a form-associated element through `formDisabledCallback`\nand nothing else does, so without this a control inside a disabled fieldset\nstays fully typeable and announces itself as enabled.\n\nThe submission half is already the platform's: measured, the fieldset's\ncontrols are absent from the form's entry list and the host matches\n`:disabled`, so the value never goes anywhere. What is missing without this\nis everything a reader can see or touch.\n\nState rather than the `disabled` property. Writing that would reflect an\nattribute the consumer's server markup does not have, which React reports\non hydration and does not patch up, and it would also silently overwrite\nwhat the consumer set."
             },
             {
               "kind": "method",
@@ -3061,7 +3092,7 @@
                 "text": "string"
               },
               "default": "''",
-              "description": "Name submitted with the form.\n\n**Reflected, and it is the exception to \"reflect only what CSS selects\non\".** The platform builds a form's entry list from the `name` *content\nattribute*, not from the property, so a control named through the property\nsubmitted under no name at all and was silently dropped. Measured: two\ninputs in one form, one named by attribute and one by property, and the\nform carried a single entry.\n\nSafe for a React consumer, which is what the rule is protecting: React\nrenders a custom element's props as attributes on the server, so the name\nis already in the markup being hydrated and reflecting it writes what is\nthere. It is only a change to the markup when a consumer assigns it\nimperatively later, and nothing is hydrating by then.\n\nHere rather than on each control, where it was declared eight times and\nreflected none of them.",
+              "description": "Name submitted with the form.\n\n**Reflected, and it is the exception to \"reflect only what CSS selects\non\".** The platform builds a form's entry list from the `name` *content\nattribute*, not from the property, so a control named through the property\nsubmitted under no name at all and was silently dropped. Measured: two\ninputs in one form, one named by attribute and one by property, and the\nform carried a single entry.\n\nSafe for a React consumer, which is what the rule is protecting: React\nrenders a custom element's props as attributes on the server, so the name\nis already in the markup being hydrated and reflecting it writes what is\nthere. It is only a change to the markup when a consumer assigns it\nimperatively later, and nothing is hydrating by then.\n\nHere rather than on each control.",
               "attribute": "name",
               "reflects": true
             },
@@ -3107,7 +3138,7 @@
               },
               "static": true,
               "default": "'helix-headless-'",
-              "description": "The prefix this tier registers its elements under.\n\n**A component that renders another renders its own tier's version of it**,\nso `helix-headless-pagination-size` composes `helix-headless-select` and\n`helix-pagination-size` composes `helix-select`. One template says\n`${this.tag('select')}` and each tier answers with its own name.\n\nIt was the public tag in both tiers, on the argument that each imports its\nown element under that name. That works and costs three things: the name\nmeans two different things depending on what a consumer imported, the\nheadless tier composes an element it does not ship, and the composition\ncannot be tested there at all, because there is no `helix-select` on that\ntier to test it against. Thirty-nine specs had to be moved back to\n`helix/styled` for exactly that reason.\n\n**A prefix rather than an override per composition**, which was the first\nplan and does not compile. An override re-renders the fragment from the\nsubclass, and the fragment reads members the base keeps private:\n`PaginationSize` alone would have had to widen `options`, `current` and\n`handleChange` to `protected` so a subclass could say the same thing again.\nSixteen families of that is a lot of encapsulation spent on saying one\nword differently.",
+              "description": "The prefix this tier registers its elements under.\n\n**A component that renders another renders its own tier's version of it**,\nso `helix-headless-pagination-size` composes `helix-headless-select` and\n`helix-pagination-size` composes `helix-select`. One template says\n`${this.tag('select')}` and each tier answers with its own name.\n\n**The public tag may not be the composed one, in either tier.** Using it\ncosts three things: the name means two different things depending on what a\nconsumer imported, the headless tier composes an element it does not ship,\nand the composition cannot be tested there at all, because there is no\n`helix-select` on that tier to test it against.\n\n**A prefix rather than an override per composition**, which was the first\nplan and does not compile. An override re-renders the fragment from the\nsubclass, and the fragment reads members the base keeps private:\n`PaginationSize` alone would have had to widen `options`, `current` and\n`handleChange` to `protected` so a subclass could say the same thing again.\nSixteen families of that is a lot of encapsulation spent on saying one\nword differently.",
               "inheritedFrom": {
                 "name": "HelixElement",
                 "module": "src/helix-element/helix-element.ts"
@@ -3173,7 +3204,7 @@
                   }
                 }
               ],
-              "description": "Records a boolean fact about this element as a custom state.\n\n**The host belongs to whoever rendered it, and a component's own\nbookkeeping may not be kept there.** An attribute written on the first\nupdate is markup a consumer's server never sent, so a React consumer\nhydrates a DOM that has gained attributes since and reports a mismatch it\nwill not patch up. A custom state is not in the DOM at all: it carries the\nfact to a stylesheet through `:state()` and leaves the markup alone, so the\nserver's output and the client's agree by construction.\n\n`SETTLED` carries the long version of that argument and was the first to\nmove. `checked`, `open`, `invalid` and `has-label` followed it on 27 Aug\n2026, after the same fault was reported once more from the landing page's\nshowcase: a `default-checked` switch, a `default-checked` checkbox and a\n`default-open` accordion item, each writing its own resolved state onto\nitself before React reached the node.\n\n**The deferral that had been holding it is not a fix and could not be.**\nThe site imports the definitions from an effect so the upgrades fall the\nother side of hydration, which works only while hydration is one pass:\nanything that splits it, a streamed segment or a suspended boundary, puts\nan upgrade back inside the window. Timing cannot be the guarantee when the\nfact is kept somewhere React reconciles.\n\nFeature-tested rather than assumed, the way `hostAria` tests element\nreferences. An engine without `CustomStateSet` records nothing and keeps\nwhatever the resting rule draws, which is the safe direction to fail, and\nLit's server shim is one of them: a custom state is a fact about a running\nelement, and a server has nothing to say about it.",
+              "description": "Records a boolean fact about this element as a custom state.\n\n**The host belongs to whoever rendered it, and a component's own\nbookkeeping may not be kept there.** An attribute written on the first\nupdate is markup a consumer's server never sent, so a React consumer\nhydrates a DOM that has gained attributes since and reports a mismatch it\nwill not patch up. A custom state is not in the DOM at all: it carries the\nfact to a stylesheet through `:state()` and leaves the markup alone, so the\nserver's output and the client's agree by construction.\n\n`SETTLED` carries the long version of that argument; `checked`, `open`,\n`invalid` and `has-label` are recorded the same way, each of them a state a\n`default-*` attribute resolves before React reaches the node.\n\n**Deferring the definitions is not a fix and could not be.** Importing them\nfrom an effect so the upgrades fall the other side of hydration works only\nwhile hydration is one pass: anything that splits it, a streamed segment or\na suspended boundary, puts an upgrade back inside the window. Timing cannot\nbe the guarantee when the fact is kept somewhere React reconciles.\n\nFeature-tested rather than assumed, the way `hostAria` tests element\nreferences. An engine without `CustomStateSet` records nothing and keeps\nwhatever the resting rule draws, which is the safe direction to fail.\n\n**Lit's server shim is no longer one of them**, and this said it was.\n`@lit-labs/ssr-dom-shim@1.6.0` sets `this.states = new Set()` in its\n`ElementInternals` constructor, so the guard passes on the server and a\ncustom state is recorded where nothing reads it, which is harmless. The\nengines the test is for are browsers: Safari below 17.4 and Firefox below\n126. There the write is a `TypeError`, so a component that bypasses this\nfails to render rather than rendering without whatever the state draws.",
               "inheritedFrom": {
                 "name": "HelixElement",
                 "module": "src/helix-element/helix-element.ts"
@@ -3186,7 +3217,7 @@
                 "text": "Promise<void>"
               },
               "readonly": true,
-              "description": "Resolves a frame after the first update, when transitions are switched on.\n\n**Named `whenSettled` because `settled` was taken four times over.** Image\nand Splitter each have a private `settle`, and both color controls carry a\n`settled` of their own, all of them older than this and none of them about\ntransitions. A base class takes the name every subclass then cannot use, so\nit takes the one nobody wanted.\n\n**The state it reports cannot be watched, which is why this exists.** A\n`MutationObserver` could see `[data-settled]` arrive and there is no\nequivalent for `ElementInternals.states`: a custom state is deliberately not\nin the DOM, which is the whole reason it replaced the attribute. Anything\nthat used to wait on the attribute waits on this instead, and gets a better\nsignal for it, an awaited promise being what the callers wanted rather than\na mutation they had to interpret.\n\nSeparate from `updateComplete`, which resolves in the microtask checkpoint\nthe suppression is still active in. That is the distinction `readyToMove`\nin `@fusion.dev/helix-testing` was written around and the reason two checkbox specs\nwere misread as a token fault for days.\n\nIt never resolves where `requestAnimationFrame` never fires, which is a\nserver, a hidden tab, and happy-dom. Callers that must not hang race it\nagainst a timeout; `readyToMove` does exactly that.",
+              "description": "Resolves a frame after the first update, when transitions are switched on.\n\n**Named `whenSettled` because `settled` was taken four times over.** Image\nand Splitter each have a private `settle`, and both color controls carry a\n`settled` of their own, all of them older than this and none of them about\ntransitions. A base class takes the name every subclass then cannot use, so\nit takes the one nobody wanted.\n\n**The state it reports cannot be watched, which is why this exists.** A\n`MutationObserver` could see `[data-settled]` arrive and there is no\nequivalent for `ElementInternals.states`: a custom state is deliberately not\nin the DOM, which is the whole reason it replaced the attribute. Anything\nthat used to wait on the attribute waits on this instead, and gets a better\nsignal for it, an awaited promise being what the callers wanted rather than\na mutation they had to interpret.\n\nSeparate from `updateComplete`, which resolves in the microtask checkpoint\nthe suppression is still active in. That is the distinction `readyToMove`\nin `@fusion.dev/helix-testing` is written around.\n\nIt never resolves where `requestAnimationFrame` never fires, which is a\nserver, a hidden tab, and happy-dom. Callers that must not hang race it\nagainst a timeout; `readyToMove` does exactly that.",
               "default": "new Promise<void>((resolve) => { this.resolveSettled = resolve })",
               "inheritedFrom": {
                 "name": "HelixElement",
@@ -3280,7 +3311,7 @@
                 "text": "boolean"
               },
               "default": "false",
-              "description": "Whether the control is non-interactive.\n\nReflected, because the styled tier selects on it, and mirrored to\n`aria-disabled` rather than removing the element from the accessibility\ntree, so a screen reader can still announce that the control exists.\n\nThe mirror is below and was for a while only a sentence: this paragraph\ndescribed it, four components had their own copies of it, and the class\nitself did nothing. Here is where it belongs, because here is where\n`disabled` is.",
+              "description": "Whether the control is non-interactive.\n\nReflected, because the styled tier selects on it, and mirrored to\n`aria-disabled` rather than removing the element from the accessibility\ntree, so a screen reader can still announce that the control exists.\n\nThe mirror itself is in `willUpdate` below, here rather than in each\ncontrol, because here is where `disabled` is.",
               "fieldName": "disabled"
             },
             {
@@ -3289,7 +3320,7 @@
                 "text": "string"
               },
               "default": "''",
-              "description": "Name submitted with the form.\n\n**Reflected, and it is the exception to \"reflect only what CSS selects\non\".** The platform builds a form's entry list from the `name` *content\nattribute*, not from the property, so a control named through the property\nsubmitted under no name at all and was silently dropped. Measured: two\ninputs in one form, one named by attribute and one by property, and the\nform carried a single entry.\n\nSafe for a React consumer, which is what the rule is protecting: React\nrenders a custom element's props as attributes on the server, so the name\nis already in the markup being hydrated and reflecting it writes what is\nthere. It is only a change to the markup when a consumer assigns it\nimperatively later, and nothing is hydrating by then.\n\nHere rather than on each control, where it was declared eight times and\nreflected none of them.",
+              "description": "Name submitted with the form.\n\n**Reflected, and it is the exception to \"reflect only what CSS selects\non\".** The platform builds a form's entry list from the `name` *content\nattribute*, not from the property, so a control named through the property\nsubmitted under no name at all and was silently dropped. Measured: two\ninputs in one form, one named by attribute and one by property, and the\nform carried a single entry.\n\nSafe for a React consumer, which is what the rule is protecting: React\nrenders a custom element's props as attributes on the server, so the name\nis already in the markup being hydrated and reflecting it writes what is\nthere. It is only a change to the markup when a consumer assigns it\nimperatively later, and nothing is hydrating by then.\n\nHere rather than on each control.",
               "fieldName": "name"
             }
           ],
@@ -4648,7 +4679,7 @@
             "text": "number"
           },
           "default": "24",
-          "description": "How many colours the series palette has, and so where it starts over.\n\nHere rather than in each chart, which is what it was. Four families held the\nsame `const PALETTE = 24` and the legend held a fifth: when the palette went\nfrom eight to twenty-four, one of them was missed and drew every ninth series\nin the first color again while the legend beside it named the ninth. A\nnumber two files have to agree on is a number that will stop agreeing."
+          "description": "How many colors the series palette has, and so where it starts over.\n\nHere rather than in each chart, because a number two files have to agree on\nis a number that will stop agreeing: when the palette went from eight to\ntwenty-four, one of five copies was missed and drew every ninth series in the\nfirst color while the legend beside it named the ninth."
         },
         {
           "kind": "function",
@@ -4670,7 +4701,7 @@
         },
         {
           "kind": "class",
-          "description": "The public surface `MixinChartSource` adds.\n\nDeclared separately because TypeScript cannot emit declarations for an\nanonymous class that has private or protected members (TS4094), and every\nclass extending `HelixElement` inherits protected `willUpdate` and `updated`.\nReturning the class directly was tried and refused for exactly that.\n\n**Every member here is documented twice, and that is the convention rather\nthan an oversight.** TypeScript reads this interface; the analyzer reads the\ninner class. Documented only here, `helix-convention-lint` failed the build\nwith six `Public member has no description` on three charts that had just\nbeen given a shared, fully documented property.\n\n**The protected members are declared here too, and have to be.** Cast to an\ninterface holding only `for` and `label`, `series` and `named` vanished from\nthe emitted `.d.ts` and every chart failed with `Property 'series' does not\nexist`. A mixin's interface is not its public API, it is everything a\nsubclass can see.\n\n**The series palette, and the one property every chart's mark reads.** A\nchart knows which series a bar belongs to and CSS cannot count it, so the\nheadless tier writes `--chart-series: var(--chart-series-3)` onto the\nrectangle and each styled sheet is one rule rather than twenty-four.\n\nDeclared here because this is where `seriesIndex` and `PALETTE` live, and\nbecause a hook repeated on four families is a hook four families have to keep\nagreeing about, which is the mistake the `PALETTE` comment above already\nrecords somebody making.\n\nThe numbered twenty-four are the seam between the tiers: `chart/series.css`\npoints each at a semantic token, which is a decision and so belongs to the\nstyled tier, and a consumer on `headless` sets the same names to whatever\nthey like. The headless examples set them to a ramp of grays.",
+          "description": "The public surface `MixinChartSource` adds.\n\nDeclared separately because TypeScript cannot emit declarations for an\nanonymous class that has private or protected members (TS4094), and every\nclass extending `HelixElement` inherits protected `willUpdate` and `updated`.\nReturning the class directly was tried and refused for exactly that.\n\n**Every member here is documented twice, and that is the convention rather\nthan an oversight.** TypeScript reads this interface; the analyzer reads the\ninner class. Documented only here, `helix-convention-lint` failed the build\nwith six `Public member has no description` on three charts that had just\nbeen given a shared, fully documented property.\n\n**The protected members are declared here too, and have to be.** Cast to an\ninterface holding only `for` and `label`, `series` and `named` vanished from\nthe emitted `.d.ts` and every chart failed with `Property 'series' does not\nexist`. A mixin's interface is not its public API, it is everything a\nsubclass can see.\n\n**The series palette, and the one property every chart's mark reads.** A\nchart knows which series a bar belongs to and CSS cannot count it, so the\nheadless tier writes `--chart-series: var(--chart-series-3)` onto the\nrectangle and each styled sheet is one rule rather than twenty-four.\n\nDeclared here because this is where `seriesIndex` and `PALETTE` live, and\nbecause a hook repeated on four families is a hook four families have to keep\nagreeing about.\n\nThe numbered twenty-four are the seam between the tiers: `chart/series.css`\npoints each at a semantic token, which is a decision and so belongs to the\nstyled tier, and a consumer on `headless` sets the same names to whatever\nthey like. The headless examples set them to a ramp of grays.",
           "name": "MixinChartSourceInterface",
           "cssProperties": [
             {
@@ -4840,7 +4871,7 @@
         },
         {
           "kind": "mixin",
-          "description": "The half of a chart that is about finding its numbers rather than drawing.\n\nFour families had written this out separately, and the row that asked for it\nset the bar: two copies is a coincidence and three is a pattern. There were\nfive copies of `for`, four of `label` and three of the caption fallback by the\ntime the line and donut charts landed, which is why this arrives now and not\nwhen the second chart did.\n\n**A mixin rather than a controller**, by the rule the tier notes give: it\nintroduces `for` and `label`, which a consumer writes. `SourceController` is\nthe other half and stays a controller, because resolving an id and watching\nfor changes is behavior nobody calls.\n\n**`Legend` deliberately does not take this.** It reads a table and has no\ndrawing to title, so `label` would be API it never uses, and a mixin applied\nfor four fifths of a fit is how a shared thing starts drifting.",
+          "description": "The half of a chart that is about finding its numbers rather than drawing.\n\n**A mixin rather than a controller**, by the rule the tier notes give: it\nintroduces `for` and `label`, which a consumer writes. `SourceController` is\nthe other half and stays a controller, because resolving an id and watching\nfor changes is behavior nobody calls.\n\n**`Legend` deliberately does not take this.** It reads a table and has no\ndrawing to title, so `label` would be API it never uses, and a mixin applied\nfor four fifths of a fit is how a shared thing starts drifting.",
           "name": "MixinChartSource",
           "members": [
             {
@@ -4902,7 +4933,7 @@
               "type": {
                 "text": "Row[]"
               },
-              "description": "Every row of the table, with each cell's text as well as its number.\n\nThis is where a tooltip's content comes from, and it is deliberately not\n`series`. A chart draws numbers; a reader resting a pointer on one wants\nwhat the table says, which is `$128k` and not `128000`, and often wants\nthe column beside it that nothing plotted at all.\n\n**Not `rows`, and the rename is the whole point of this paragraph.** It\nis the source table's rows, and `rows` on a chart is a name a chart\nwants for itself: `helix-heatmap` takes `rows=\"7\"` to mean a calendar\nweek, and declaring that against a base class whose `rows` is a `Row[]`\ngetter is a type error at best. The same fault `MixinCollection` had,\nwhere a slot counter called `rows` would have shared one field with a\nconsumer's data property. Name the member for what it holds rather than\nfor the shortest word available.",
+              "description": "Every row of the table, with each cell's text as well as its number.\n\nThis is where a tooltip's content comes from, and it is deliberately not\n`series`. A chart draws numbers; a reader resting a pointer on one wants\nwhat the table says, which is `$128k` and not `128000`, and often wants\nthe column beside it that nothing plotted at all.\n\n**Not `rows`.** It is the source table's rows, and `rows` on a chart is a\nname a chart wants for itself: `helix-heatmap` takes `rows=\"7\"` to mean a\ncalendar week, and declaring that against a base class whose `rows` is a\n`Row[]` getter is a type error at best. Name the member for what it holds\nrather than for the shortest word available.",
               "readonly": true
             },
             {
@@ -5089,9 +5120,19 @@
         },
         {
           "kind": "mixin",
-          "description": "Grafts the two states a collection has that are not its content.\n\n**Empty and loading are different answers and a reader can tell them apart.**\n\"No results\" under a spinner is a lie for as long as the request is in\nflight, and a blank box is not an answer at all: a reader cannot know whether\na list is empty, still arriving, or broken. Six components each rendered rows\nand none of them said either thing, so every consumer wrote their own and\nwrote it differently.\n\n**`aria-busy` on the collection, not on the message.** A reader with a screen\nreader is told the region is changing and then told once, politely, what it\nsettled on: a live region that fires on every intermediate state is a reader\nbeing read a progress bar.\n\n**The status replaces the rows rather than sitting above them.** A list that\nshows \"Loading\" over the last request's results is a list that lies about\nwhich question it is answering, and this is the point in a component's life\nwhen a consumer is most likely to be looking at stale content.\n\nListbox had `empty-text` and nothing else, and Combobox forwarded it. Both\nkeep the name, so nothing a consumer wrote has moved.\n\n\n**`empty` and `loading` are documented on each of the five families that\napply this, rather than here.** See `MixinField` for why a class-level tag on\na mixin reaches no manifest.",
+          "description": "Grafts the two states a collection has that are not its content.\n\n**Empty and loading are different answers and a reader can tell them apart.**\n\"No results\" under a spinner is a lie for as long as the request is in\nflight, and a blank box is not an answer at all: a reader cannot know whether\na list is empty, still arriving, or broken.\n\n**`aria-busy` on the collection, not on the message.** A reader with a screen\nreader is told the region is changing and then told once, politely, what it\nsettled on: a live region that fires on every intermediate state is a reader\nbeing read a progress bar.\n\n**The status replaces the rows rather than sitting above them.** A list that\nshows \"Loading\" over the last request's results is a list that lies about\nwhich question it is answering, and this is the point in a component's life\nwhen a consumer is most likely to be looking at stale content.\n\n**`empty` and `loading` are documented on each of the five families that\napply this, rather than here.** See `MixinField` for why a class-level tag on\na mixin reaches no manifest.",
           "name": "MixinCollection",
           "members": [
+            {
+              "kind": "field",
+              "name": "emptyText",
+              "type": {
+                "text": "string"
+              },
+              "default": "'Nothing to show'",
+              "description": "What is said where there are none, and none are coming.",
+              "attribute": "empty-text"
+            },
             {
               "kind": "field",
               "name": "loading",
@@ -5113,16 +5154,6 @@
               "description": "What is said while they are on their way.",
               "attribute": "loading-text"
             },
-            {
-              "kind": "field",
-              "name": "emptyText",
-              "type": {
-                "text": "string"
-              },
-              "default": "'Nothing to show'",
-              "description": "What is said where there are none, and none are coming.",
-              "attribute": "empty-text"
-            },
             {
               "kind": "field",
               "name": "slotCounted",
@@ -5141,7 +5172,7 @@
               },
               "privacy": "private",
               "default": "0",
-              "description": "How many there were, the last time anyone looked.\n\n**Not `rows`, and the rename is the whole point of this comment.**\nTypeScript's `private` is a compile-time claim and the runtime field is\nwhatever it is named, so a subclass declaring `@property() rows` for the\ndata a consumer hands it would share one field with this counter: the\nslot count would overwrite the consumer's array on every `updated`, and\n`hasRows` would read the array's length as a slot count. Nothing would\nthrow. `helix-data-table` takes exactly that property, which is what\nfound this before it happened."
+              "description": "How many there were, the last time anyone looked.\n\n**Never name this `rows`.** TypeScript's `private` is a compile-time\nclaim and the runtime field is whatever it is named, so a subclass\ndeclaring `@property() rows` for the data a consumer hands it would share\none field with this counter: the slot count would overwrite the\nconsumer's array on every `updated`, and `hasRows` would read the array's\nlength as a slot count. Nothing would throw. `helix-data-table` takes\nexactly that property."
             },
             {
               "kind": "method",
@@ -5160,7 +5191,7 @@
                   }
                 }
               ],
-              "description": "Counts what a rows slot was given.\n\nEmptiness is a fact about light DOM children and the server has none to\ncount. `slotchange` never fires there, so `counted` is false exactly when\nthe answer is unknown, and an unknown answer is not \"empty\": a list that\nshipped \"Nothing to show\" over markup about to have rows in it is the one\nthing an empty state must never do. Listbox's spec caught precisely that."
+              "description": "Counts what a rows slot was given.\n\nEmptiness is a fact about light DOM children and the server has none to\ncount. `slotchange` never fires there, so `counted` is false exactly when\nthe answer is unknown, and an unknown answer is not \"empty\": a list that\nshipped \"Nothing to show\" over markup about to have rows in it is the one\nthing an empty state must never do."
             },
             {
               "kind": "field",
@@ -5192,6 +5223,15 @@
             }
           ],
           "attributes": [
+            {
+              "name": "empty-text",
+              "type": {
+                "text": "string"
+              },
+              "default": "'Nothing to show'",
+              "description": "What is said where there are none, and none are coming.",
+              "fieldName": "emptyText"
+            },
             {
               "name": "loading",
               "type": {
@@ -5209,15 +5249,6 @@
               "default": "'Loading'",
               "description": "What is said while they are on their way.",
               "fieldName": "loadingText"
-            },
-            {
-              "name": "empty-text",
-              "type": {
-                "text": "string"
-              },
-              "default": "'Nothing to show'",
-              "description": "What is said where there are none, and none are coming.",
-              "fieldName": "emptyText"
             }
           ],
           "parameters": [
@@ -5264,7 +5295,7 @@
               "type": {
                 "text": "string"
               },
-              "description": "Which item is current, by its `value`.\n\nReading gives the real one, in either mode. Writing hands ownership to the\nconsumer: from then on the set announces changes and applies none of them."
+              "description": "Which item is current, by its `value`.\n\nReading gives the real one. Writing always applies, and is a seed and a\ncorrection rather than a claim of ownership: a consumer who wants the\ndecision refuses the `helix-before-activate`."
             },
             {
               "kind": "field",
@@ -5309,14 +5340,14 @@
                   }
                 }
               ],
-              "description": "Which item is current, given what there is to choose from.\n\nThe first enabled one when `value` names nothing, which is a set before its\nconsumer has chosen and a set whose current item has just been removed."
+              "description": "Which item is current, given what there is to choose from.\n\nThe first enabled one when `active` names nothing, which is a set before\nits consumer has chosen and a set whose current item has just been removed."
             }
           ],
           "helix": {}
         },
         {
           "kind": "mixin",
-          "description": "Grafts \"which one of these is the current one\" onto a container.\n\nFor a set where one member is current and the set is not a form control:\ntabs, a tree, a nav bar, a carousel. Where it *is* a form control the value\nis submitted and belongs to `MixinControllerValue`, which is why these are\ntwo mixins and not one with a flag.\n\n**Announcing before applying is the part worth sharing.** `Tabs` and `Tree`\nboth wrote the current value straight from the item's event, so a consumer\nhad no way to refuse a change, while `Radio.Group` announced first. Neither\nwas wrong on its own and the two together are: whether a selection can be\nrefused should not depend on which component a reader is looking at.\n\n**The fallback is the other half.** Four components had written\n`items.find(match) ?? items[0]`, and it is not the obvious line it looks\nlike: it is what makes a set with a `value` naming nothing still show\nsomething, which is every set before its consumer has set one and every set\nwhose current item has just been removed. `resolveActive` also skips disabled\nitems, which the hand-written copies did not, so a set opening on a disabled\nfirst item showed it as current.",
+          "description": "Grafts \"which one of these is the current one\" onto a container.\n\nFor a set where one member is current and the set is not a form control:\ntabs, a tree, a nav bar, a carousel. Where it *is* a form control the value\nis submitted and belongs to `MixinControllerValue`, which is why these are\ntwo mixins and not one with a flag.\n\n**Announcing before applying is the part worth sharing.** Writing the current\nvalue straight from the item's event leaves a consumer no way to refuse a\nchange, and whether a selection can be refused must not depend on which\ncomponent a reader is looking at.\n\n**The fallback is the other half.** `items.find(match) ?? items[0]` is not\nthe obvious line it looks like: it is what makes a set whose `active` names\nnothing still show something, which is every set before its consumer has set\none and every set whose current item has just been removed. `resolveActive`\nalso skips disabled items in that fallback, or a set opening on a disabled\nfirst item shows it as current.",
           "name": "MixinControllerActive",
           "members": [
             {
@@ -5325,7 +5356,7 @@
               "type": {
                 "text": "string"
               },
-              "description": "Which item is current, by its `value`.\n\nCalled `active`, which is what this mixin is named for and what it was\nnot: it declared `value`, so the one mixin whose whole subject is which\nitem is active had no such property, and `active` meant something else\nentirely elsewhere in the library. It still does, and only there now:\n`option.active` is the option the keyboard is on, which is a different\nquestion from which one is chosen.\n\nAn accessor pair, the same shape as the other three. Reading gives the\nreal item; writing hands ownership to the consumer, so `<helix-tabs\nactive=\"one\">` is a set that stays on that tab and `default-active` is\nhow markup says where to start.",
+              "description": "Which item is current, by its `value`.\n\nNot `option.active`, which is the option the keyboard is on: that is a\ndifferent question from which one is chosen.\n\nWriting always applies, so `<helix-tabs active=\"one\">` starts on that\ntab, and `default-active` is how markup says where to start without\nnaming the current one.",
               "attribute": "active"
             },
             {
@@ -5346,7 +5377,7 @@
               },
               "privacy": "private",
               "default": "undefined",
-              "description": "The state, whoever set it, and `undefined` until somebody has.\n\nOne field and not two. Writing always applies, the way a native control\ndoes when a script assigns to it. What the write does not do is change\nwhich mode the element is in."
+              "description": "The state, whoever set it, and `undefined` until somebody has.\n\nOne field and not two. Writing always applies, the way a native control\ndoes when a script assigns to it."
             },
             {
               "kind": "method",
@@ -5364,7 +5395,7 @@
                   }
                 }
               ],
-              "description": "Requests a new current item, and reports whether the request stood.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-activate` is\na refusal and nothing moves. Unlike a native control, nothing has moved\nby the time this runs, so refusing is simply not writing: there is\nnothing to put back. Nobody refusing means the set updates itself,\nwhether or not a consumer declared `active`, a declared property being a\nseed and a correction. See 294."
+              "description": "Requests a new current item, and reports whether the request stood.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-activate` is\na refusal and nothing moves. Unlike a native control, nothing has moved\nby the time this runs, so refusing is simply not writing: there is\nnothing to put back. Nobody refusing means the set updates itself,\nwhether or not a consumer declared `active`, a declared property being a\nseed and a correction."
             },
             {
               "kind": "method",
@@ -5383,7 +5414,7 @@
                   }
                 }
               ],
-              "description": "Says the current child moved, once it has.\n\n**This was the only one of the four mixins with no notification**, and the\nevent class said so deliberately: no native word means \"a set chose a\ndifferent member\", so borrowing `change` would be a lie about what moved.\nThat half still holds, and is why the pair is `helix-activate`. What did\nnot follow is that a set should therefore announce nothing.\n\nThe cost is the one 294 fixed for values and left here. A consumer who\nonly wants to know which child is current had one channel and it fires\n*before* `apply`, so `currentTarget.active` is the previous value inside\nthe handler and `detail.value` is a proposal another listener may refuse.\nMeasured across the four families taking this: `Tabs` and `Tree` looked\ncovered because `helix-select` bubbles up from a child, which fires when an\nitem is *chosen* and not when `active` is assigned, and `Steps` and\n`Video Playlist` announced nothing at all.\n\n**After `apply`, which is the whole reason it is a second event**, so the\nstate is on the element by the time a handler reads it. Not cancelable:\nthe decision was taken by the event before this one, and two refusable\nevents for one transition are two answers to one question. See #325."
+              "description": "Says the current child moved, once it has.\n\n`helix-activate` rather than a native word: nothing on the platform means\n\"a set chose a different member\", and borrowing `change` would be a lie\nabout what moved.\n\nA consumer who only wants to know which child is current cannot use\n`helix-before-activate` for it, that one firing *before* `apply`, so\n`currentTarget.active` is the previous value inside the handler and\n`detail.value` is a proposal another listener may refuse. `helix-select`\nis no substitute either: it fires when an item is *chosen* and not when\n`active` is assigned.\n\n**After `apply`, which is the whole reason it is a second event**, so the\nstate is on the element by the time a handler reads it. Not cancelable:\nthe decision was taken by the event before this one, and two refusable\nevents for one transition are two answers to one question."
             },
             {
               "kind": "method",
@@ -5402,7 +5433,7 @@
                   }
                 }
               ],
-              "description": "Which item is current, given what there is to choose from.\n\nThe first enabled one when `value` names nothing, which is a set before\nits consumer has chosen and a set whose current item has just been\nremoved. Disabled items are skipped in the fallback but not in the match:\na consumer who names a disabled item meant it, and quietly moving to\nanother would be the component overruling them."
+              "description": "Which item is current, given what there is to choose from.\n\nThe first enabled one when `active` names nothing, which is a set before\nits consumer has chosen and a set whose current item has just been\nremoved. Disabled items are skipped in the fallback but not in the match:\na consumer who names a disabled item meant it, and quietly moving to\nanother would be the component overruling them."
             }
           ],
           "events": [
@@ -5418,7 +5449,7 @@
               "type": {
                 "text": "string"
               },
-              "description": "Which item is current, by its `value`.\n\nCalled `active`, which is what this mixin is named for and what it was\nnot: it declared `value`, so the one mixin whose whole subject is which\nitem is active had no such property, and `active` meant something else\nentirely elsewhere in the library. It still does, and only there now:\n`option.active` is the option the keyboard is on, which is a different\nquestion from which one is chosen.\n\nAn accessor pair, the same shape as the other three. Reading gives the\nreal item; writing hands ownership to the consumer, so `<helix-tabs\nactive=\"one\">` is a set that stays on that tab and `default-active` is\nhow markup says where to start.",
+              "description": "Which item is current, by its `value`.\n\nNot `option.active`, which is the option the keyboard is on: that is a\ndifferent question from which one is chosen.\n\nWriting always applies, so `<helix-tabs active=\"one\">` starts on that\ntab, and `default-active` is how markup says where to start without\nnaming the current one.",
               "fieldName": "active"
             },
             {
@@ -5475,7 +5506,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the control is checked.\n\nReading gives the real state, in either mode. Writing hands ownership to\nthe consumer: from then on the control announces changes and applies none\nof them."
+              "description": "Whether the control is checked.\n\nReading gives the real state. Writing always applies, and is a seed and a\ncorrection rather than a claim of ownership: a consumer who wants the\ndecision refuses the `helix-before-toggle`."
             },
             {
               "kind": "field",
@@ -5521,14 +5552,14 @@
                   "text": "void"
                 }
               },
-              "description": "Drops the uncontrolled state, so the control reads `defaultChecked` again.\n\nA form reset has to return a control to what its markup declared. Clearing\n`checked` alone cannot do it: that only leaves controlled mode, and the\nuncontrolled value the element has been keeping is private to the mixin\nand would still be what `checked` reports."
+              "description": "Drops the recorded state, so the control reads `defaultChecked` again.\n\nA form reset has to return a control to what its markup declared, and\nassigning `checked` cannot do it: any assignment records a state, and the\nrecorded state is private to the mixin. This is the only way to clear it."
             }
           ],
           "helix": {}
         },
         {
           "kind": "mixin",
-          "description": "Grafts controlled and uncontrolled checked state onto a base class.\n\nWhich mode it is in is read once, at the first update, from whether anything\nhad set `checked` by then: markup, a hydrating server's attributes and a\nframework's initial properties have all arrived, and nothing else has\nhappened yet. Set, and the consumer owns it and the element only announces.\nUnset, and the element owns it and `defaultChecked` says where it starts.\n\nRecords `:state(checked)` whenever the element is checked, in either mode.\nStyled tiers select on that rather than on `[checked]`, which is absent for\nuncontrolled consumers.",
+          "description": "Grafts checked state onto a base class.\n\n`checked` is a seed and a correction rather than a claim: the element applies\nits own changes from wherever markup started it, `defaultChecked` is what a\nreset returns to, and a consumer takes the decision by refusing the\n`helix-before-toggle`.\n\nRecords `:state(checked)` whenever the element is checked. Styled tiers\nselect on that rather than on `[checked]`, which is absent until somebody\nwrites it.",
           "name": "MixinControllerChecked",
           "members": [
             {
@@ -5537,7 +5568,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the control is checked.\n\nOne property rather than two. Reading gives the real state whichever\nmode the control is in; writing hands ownership to the consumer, which\nis what the attribute in `<helix-checkbox checked>` does as well. The\nsame shape all four of these mixins have, for the reason given on\n`MixinControllerOpen.open`.\n\nNot reflected: the attribute is the consumer's input and stays as they\nwrote it, and `:state(checked)` carries the resolved state for\nstylesheets.",
+              "description": "Whether the control is checked.\n\nOne property rather than two. Writing always applies;\n`<helix-checkbox checked>` is the same statement in markup.\n\nNot reflected: the attribute is the consumer's input and stays as they\nwrote it, and `:state(checked)` carries the resolved state for\nstylesheets.",
               "attribute": "checked"
             },
             {
@@ -5558,7 +5589,7 @@
               },
               "privacy": "private",
               "default": "undefined",
-              "description": "The state, whoever set it, and `undefined` until somebody has.\n\nOne field and not two. Writing always applies, the way a native control\ndoes when a script assigns to it. What the write does not do is change\nwhich mode the element is in."
+              "description": "The state, whoever set it, and `undefined` until somebody has.\n\nOne field and not two. Writing always applies, the way a native control\ndoes when a script assigns to it."
             },
             {
               "kind": "method",
@@ -5576,7 +5607,7 @@
                   }
                 }
               ],
-              "description": "Requests a checked change, and reports whether it was applied.\n\nAnnounces before it acts, so `preventDefault()` on the\n`helix-before-toggle` is a refusal and nothing moves. Nobody refusing means the element updates itself, whether or not a consumer\ndeclared the property: a declared property is a seed and a correction,\nthe way `<input value>` is, and a consumer who wants the change for\nthemselves refuses it and assigns their own. See 294."
+              "description": "Requests a checked change, and reports whether it was applied.\n\nAnnounces before it acts, so `preventDefault()` on the\n`helix-before-toggle` is a refusal and nothing moves. Nobody refusing\nmeans the element updates itself, whether or not a consumer declared the\nproperty: a declared property is a seed and a correction, the way\n`<input value>` is, and a consumer who wants the change for themselves\nrefuses it and assigns their own."
             },
             {
               "kind": "method",
@@ -5604,7 +5635,7 @@
                   }
                 }
               ],
-              "description": "Restores the control when the browser brings a form back.\n\nHand-written on the checkbox and nowhere else, so `Switch`, the mixin's\nonly other consumer, had no restore at all: a reader who navigated away\nand came back to a restored form found their switch flipped off. The\nmixin owns `checked`, so the mixin owns putting it back.\n\nThrough `checked` rather than the private state, so a controlled consumer\nis asked the same way every other change asks."
+              "description": "Restores the control when the browser brings a form back.\n\nThe mixin owns `checked`, so the mixin owns putting it back: written on\none consumer and not the other, a reader who navigates away and comes\nback to a restored form finds that control flipped off.\n\nThrough the public accessor rather than the private field, so a restore\ntakes the same path a script assignment does."
             },
             {
               "kind": "method",
@@ -5614,7 +5645,7 @@
                   "text": "void"
                 }
               },
-              "description": "Drops the uncontrolled state, so the control reads `defaultChecked`\nagain.\n\nA form reset has to return a control to what its markup declared, and\nclearing `checked` alone only leaves controlled mode. The value the\nelement has been keeping lives here, so this is where it is dropped."
+              "description": "Drops the recorded state, so the control reads `defaultChecked` again.\n\nA form reset has to return a control to what its markup declared, and no\nassignment to `checked` can do that: any assignment records a state. The\nrecorded state lives here, so this is where it is dropped."
             }
           ],
           "events": [
@@ -5631,7 +5662,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the control is checked.\n\nOne property rather than two. Reading gives the real state whichever\nmode the control is in; writing hands ownership to the consumer, which\nis what the attribute in `<helix-checkbox checked>` does as well. The\nsame shape all four of these mixins have, for the reason given on\n`MixinControllerOpen.open`.\n\nNot reflected: the attribute is the consumer's input and stays as they\nwrote it, and `:state(checked)` carries the resolved state for\nstylesheets.",
+              "description": "Whether the control is checked.\n\nOne property rather than two. Writing always applies;\n`<helix-checkbox checked>` is the same statement in markup.\n\nNot reflected: the attribute is the consumer's input and stays as they\nwrote it, and `:state(checked)` carries the resolved state for\nstylesheets.",
               "fieldName": "checked"
             },
             {
@@ -5696,7 +5727,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the element is open.\n\nReading gives the real state, in either mode. Writing hands ownership to\nthe consumer: from then on the element announces changes and applies none\nof them, and waits to be told."
+              "description": "Whether the element is open.\n\nReading gives the real state. Writing always applies, and is a seed and a\ncorrection rather than a claim of ownership: a consumer who wants the\ndecision refuses the `helix-before-open` or `helix-before-close`."
             },
             {
               "kind": "method",
@@ -5731,7 +5762,7 @@
         },
         {
           "kind": "mixin",
-          "description": "Grafts open state onto a base class, and says so twice.\n\n`helix-before-open` and `helix-before-close` announce the change while it is\nstill a request, so `preventDefault()` refuses it and nothing moves. Native\n`toggle` announces it afterwards, once the state has actually gone, carrying\n`newState` and `oldState` the way the platform does on `<details>` and on a\npopover. The first is how a consumer takes the decision; the second is what\nthey bind when they only want to know. See 294 and 296.\n\n`open` is a seed and a correction rather than a claim: the element applies\nits own changes from wherever markup started it, and `defaultOpen` is what a\nreset returns to.\n\nRecords `:state(open)` whenever the element is open. Styled tiers select on\nthat rather than on `[open]`, which is absent until somebody writes it.",
+          "description": "Grafts open state onto a base class, and says so twice.\n\n`helix-before-open` and `helix-before-close` announce the change while it is\nstill a request, so `preventDefault()` refuses it and nothing moves. Native\n`toggle` announces it afterwards, once the state has actually gone, carrying\n`newState` and `oldState` the way the platform does on `<details>` and on a\npopover. The first is how a consumer takes the decision; the second is what\nthey bind when they only want to know.\n\n`open` is a seed and a correction rather than a claim: the element applies\nits own changes from wherever markup started it, and `defaultOpen` is what a\nreset returns to.\n\nRecords `:state(open)` whenever the element is open. Styled tiers select on\nthat rather than on `[open]`, which is absent until somebody writes it.",
           "name": "MixinControllerOpen",
           "members": [
             {
@@ -5740,7 +5771,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the element is open.\n\nOne property, not two. Reading gives the real state whichever mode the\nelement is in, so `dialog.open` answers the question anyone asking it\nmeant. Writing hands ownership to the consumer, which is what the\nattribute in `<helix-dialog open>` does as well: from then on the element\nannounces changes and applies none of them.\n\nIt reads as an accessor pair rather than a field because those are two\ndifferent questions sharing one name, and the alternative was a second\nproperty answering the first. That worked for a boolean, where `isOpen`\nreads well; there is no such word for a value or an active item, so all\nfour of these mixins now have this shape instead of two shapes.\n\n**Not reflected, and that is required rather than tidy.** Reflection\nwrites the resolved state back as an attribute, and writing the attribute\nis how a consumer says they own it. So an uncontrolled element that\nopened itself would put `open` on its own host and, from the next thing\nthat read it, be indistinguishable from one the consumer controls:\ncloned, serialised for hydration, or diffed by a framework, it would come\nback holding whatever the last reader did rather than what the author\nwrote. `:state(open)` carries the resolved state for stylesheets, which\nis what the mirror has always been for.",
+              "description": "Whether the element is open.\n\nOne property, not two, so `dialog.open` answers the question anyone\nasking it meant. Writing always applies; `<helix-dialog open>` is the\nsame statement in markup.\n\n**Not reflected, and that is required rather than tidy.** Reflection\nwrites the resolved state back as an attribute, so an element that opened\nitself would put `open` on its own host: cloned, serialized for\nhydration, or diffed by a framework, it comes back holding whatever the\nlast reader did rather than what the author wrote. `:state(open)` carries\nthe resolved state for stylesheets, which is what the mirror is for.",
               "attribute": "open"
             },
             {
@@ -5761,7 +5792,7 @@
               },
               "privacy": "private",
               "default": "undefined",
-              "description": "The state, whoever set it, and `undefined` until somebody has.\n\nPrefixed, and it has to be. These mixins compose onto one prototype\nchain, `Select` takes this one and `MixinControllerValue` together, and\nTypeScript's `private` is a compile-time fiction: two mixins with a field\ncalled `state` share one property on the instance, and the second one\nsilently overwrites the first. Measured, as a select whose `value` came\nback holding its `open` boolean.\n\nOne field and not two. Writing always applies, which is what a native\ncontrol does when a script assigns to it, and is the behavior an\nimperative `element.open = true` should have whatever mode the element is\nin. What the write does *not* do is change which mode that is."
+              "description": "The state, whoever set it, and `undefined` until somebody has.\n\nPrefixed, and it has to be. These mixins compose onto one prototype\nchain, `Select` takes this one and `MixinControllerValue` together, and\nTypeScript's `private` is a compile-time fiction: two mixins with a field\ncalled `state` share one property on the instance, and the second one\nsilently overwrites the first. Measured, as a select whose `value` came\nback holding its `open` boolean.\n\nOne field and not two. Writing always applies, the way a native control\ndoes when a script assigns to it."
             },
             {
               "kind": "method",
@@ -5779,7 +5810,7 @@
                   }
                 }
               ],
-              "description": "Requests an open-state change, and reports whether it was applied.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-open` or\n`helix-before-close` is a refusal and nothing moves. Nobody refusing means the\nelement opens or closes itself, whether or not a consumer declared\n`open`: a declared property is a seed and a correction, and a consumer\nwho wants the decision for themselves refuses it and assigns their own.\nSee 294."
+              "description": "Requests an open-state change, and reports whether it was applied.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-open` or\n`helix-before-close` is a refusal and nothing moves. Nobody refusing means the\nelement opens or closes itself, whether or not a consumer declared\n`open`: a declared property is a seed and a correction, and a consumer\nwho wants the decision for themselves refuses it and assigns their own."
             },
             {
               "kind": "method",
@@ -5798,7 +5829,7 @@
                   }
                 }
               ],
-              "description": "Says the state moved, under the platform's own name and in its shape.\n\n**`<details>` fires `toggle` and a popover fires `toggle`, and sixteen\nfamilies here fired neither.** Two of them render a real `<dialog>` and\nten show a `popover=\"manual\"` panel, so the browser was already firing\nsomething on an element inside a shadow root, where `toggle` neither\nbubbles nor composes and so reaches nobody. The rest, the disclosures,\nhave no native element to fire anything at all: `AccordionItem` and\n`TreeItem` are `aria-expanded` and `hidden` written by hand, which is\n`<details>`'s job done manually.\n\n**From here rather than from `PopoverController`, which had it first.**\nThe controller covers eleven families and the mixin covers sixteen, and\nthe overlap is ten that would have announced twice. What `toggle` reports\nis the *state*, and the state is this mixin's; the controller is a way of\nputting a panel on the screen.\n\n**`newState` and `oldState`, because that is the platform's shape**, so a\nconsumer arriving from `<details>` reads the same two words. Not\ncancelable: the before events are the request, and a second cancelable\nevent for one transition is two answers to one question."
+              "description": "Says the state moved, under the platform's own name and in its shape.\n\n**A native `toggle` from inside a shadow root reaches nobody**, because\nit neither bubbles nor composes, so the ten families showing a\n`popover=\"manual\"` panel and the two rendering a real `<dialog>` announce\nnothing to a consumer. The disclosures have no native element to fire\nanything at all: `AccordionItem` and `TreeItem` are `aria-expanded` and\n`hidden` written by hand, which is `<details>`'s job done manually.\n\n**From here rather than from `PopoverController`.** The controller covers\neleven families and the mixin covers sixteen, so announcing from both\nwould announce twice on the ten they share. What `toggle` reports is the\n*state*, and the state is this mixin's; the controller is a way of\nputting a panel on the screen.\n\n**`newState` and `oldState`, because that is the platform's shape**, so a\nconsumer arriving from `<details>` reads the same two words. Not\ncancelable: the before events are the request, and a second cancelable\nevent for one transition is two answers to one question."
             },
             {
               "kind": "method",
@@ -5817,7 +5848,7 @@
               "type": {
                 "text": "boolean"
               },
-              "description": "Whether the element is open.\n\nOne property, not two. Reading gives the real state whichever mode the\nelement is in, so `dialog.open` answers the question anyone asking it\nmeant. Writing hands ownership to the consumer, which is what the\nattribute in `<helix-dialog open>` does as well: from then on the element\nannounces changes and applies none of them.\n\nIt reads as an accessor pair rather than a field because those are two\ndifferent questions sharing one name, and the alternative was a second\nproperty answering the first. That worked for a boolean, where `isOpen`\nreads well; there is no such word for a value or an active item, so all\nfour of these mixins now have this shape instead of two shapes.\n\n**Not reflected, and that is required rather than tidy.** Reflection\nwrites the resolved state back as an attribute, and writing the attribute\nis how a consumer says they own it. So an uncontrolled element that\nopened itself would put `open` on its own host and, from the next thing\nthat read it, be indistinguishable from one the consumer controls:\ncloned, serialised for hydration, or diffed by a framework, it would come\nback holding whatever the last reader did rather than what the author\nwrote. `:state(open)` carries the resolved state for stylesheets, which\nis what the mirror has always been for.",
+              "description": "Whether the element is open.\n\nOne property, not two, so `dialog.open` answers the question anyone\nasking it meant. Writing always applies; `<helix-dialog open>` is the\nsame statement in markup.\n\n**Not reflected, and that is required rather than tidy.** Reflection\nwrites the resolved state back as an attribute, so an element that opened\nitself would put `open` on its own host: cloned, serialized for\nhydration, or diffed by a framework, it comes back holding whatever the\nlast reader did rather than what the author wrote. `:state(open)` carries\nthe resolved state for stylesheets, which is what the mirror is for.",
               "fieldName": "open"
             },
             {
@@ -5882,7 +5913,7 @@
               "type": {
                 "text": "string"
               },
-              "description": "What the control holds now, and what its form submits.\n\nReading gives the real value, in either mode. Writing hands ownership to\nthe consumer: from then on the control announces changes and applies none\nof them, and waits to be told."
+              "description": "What the control holds now, and what its form submits.\n\nReading gives the real value. Writing always applies, and is a seed and a\ncorrection rather than a claim of ownership: a consumer who wants the\ndecision refuses the `helix-before-change`."
             },
             {
               "kind": "field",
@@ -5892,7 +5923,7 @@
               },
               "privacy": "protected",
               "readonly": true,
-              "description": "Whether every edit is announced, rather than every settled value.\n\nA control the reader types or drags in moves continuously, and the platform\ncalls that `input`: `<input type=\"text\">` fires one per keystroke and fires\n`change` once, on commit. Five controls here are that shape, and the rest\nchange in discrete steps where a step *is* the change.\n\nIt selects the event rather than the timing. `requestValue` is called\nwhenever the value moves either way; this decides whether the control sends\n`input` alone or `input` and `change` together, so a consumer can read the\nname and know how often to expect it."
+              "description": "Whether every edit is announced, rather than every settled value.\n\nA control the reader types or drags in moves continuously, and the platform\ncalls that `input`: `<input type=\"text\">` fires one per keystroke and fires\n`change` once, on commit. Five controls here are that shape, and the rest\nchange in discrete steps where a step *is* the change.\n\nIt selects the event rather than the timing. `requestValue` is called\nwhenever the value moves either way; this decides whether the control sends\n`input` alone or `input` and `change` together."
             },
             {
               "kind": "method",
@@ -5945,7 +5976,7 @@
         },
         {
           "kind": "mixin",
-          "description": "Grafts `value`, `defaultValue`, and the two callbacks that answer a form.\n\nEvery control with a value had written this, and by the third it was three\ncopies of the same four members and the same seeding rule: `Input`, then\n`Toggle.Group`, then `Radio.Group`. The copies had not diverged, which is the\nargument for the mixin rather than against it, because the next one would\nhave.\n\n**Seeded in `willUpdate`, not `connectedCallback`.** SSR never calls the\nlatter, so a control with a `default-value` would serve empty and fill itself\nat hydration, which is a flash for a reader and a mismatch for React. Seeding\nonce, before the first render, is what makes the server and the client agree.\n\n**What it does not own is reporting.** `setFormValue` stays with the\ncomponent, because what an empty value means is the component's business: a\ntext field submits its emptiness, since `\"\"` is an answer and the field was\non the form, while a group with nothing chosen submits nothing at all. One\nmixin cannot hold both without a flag, and a flag would be this rule written\ndown twice.\n\n`Checkbox` deliberately does not take this. Its `value` is what it submits\n*when it is on* rather than what it holds, so it is configuration rather than\nstate, and the state it does have is `checked`, which is\n`MixinControllerChecked`'s.",
+          "description": "Grafts `value`, `defaultValue`, and the two callbacks that answer a form.\n\n**Derived on read, never seeded in a lifecycle hook.** `value` falls back to\n`defaultValue`, so the server and the client agree without either running a\nhook. Seeding in `connectedCallback` is the trap: SSR never calls it, so a\ncontrol with a `default-value` would serve empty and fill itself at\nhydration, a flash for a reader and a mismatch for React.\n\n**What it does not own is reporting.** `setFormValue` stays with the\ncomponent, because what an empty value means is the component's business: a\ntext field submits its emptiness, since `\"\"` is an answer and the field was\non the form, while a group with nothing chosen submits nothing at all.\n\n`Checkbox` deliberately does not take this. Its `value` is what it submits\n*when it is on* rather than what it holds, so it is configuration rather than\nstate, and the state it does have is `checked`, which is\n`MixinControllerChecked`'s.",
           "name": "MixinControllerValue",
           "members": [
             {
@@ -5964,7 +5995,7 @@
               "type": {
                 "text": "string"
               },
-              "description": "What the control holds now, and what its form submits.\n\nOne property, not two. Reading gives the real value whichever mode the\ncontrol is in, so `input.value` answers the question anyone asking it\nmeant. Writing hands ownership to the consumer, which is what\n`<helix-input value=\"x\">` says too, and matches what a controlled input\nmeans in React: the value is theirs and the control waits to be told.\n`default-value` is how markup seeds one it does not want to own.\n\nThe same shape as the other three mixins, which is the point of them\nbeing four of a kind rather than four of three kinds.\n\nhelix-input",
+              "description": "What the control holds now, and what its form submits.\n\nOne property, not two, so `input.value` answers the question anyone\nasking it meant. Writing always applies; `<helix-input value=\"x\">` is the\nsame statement in markup, and `default-value` is how markup seeds a value\na reset should return to.",
               "attribute": "value"
             },
             {
@@ -5986,7 +6017,7 @@
               "privacy": "protected",
               "readonly": true,
               "default": "false",
-              "description": "Whether a reader edits this continuously, which decides the native name.\n\n**It used to pick between `helix-input` and `helix-change`**, which was\none mechanism under two names and said *phase* where it meant\n*granularity*. The request event is `helix-before-change` whatever the\nanswer; this decides which native event announces the result, `input`\nwhile a reader is editing against `change` when they are done, which is\nthe distinction the platform already draws. See 294.\n\nDiscrete by default: only a control the reader edits continuously says\notherwise."
+              "description": "Whether a reader edits this continuously, which decides the native name.\n\nThe request event is `helix-before-change` whatever the answer; this\ndecides which native event announces the result, `input` while a reader\nis editing against `change` when they are done, which is the distinction\nthe platform already draws.\n\nDiscrete by default: only a control the reader edits continuously says\notherwise."
             },
             {
               "kind": "method",
@@ -6015,7 +6046,7 @@
                   }
                 }
               ],
-              "description": "Requests a new value, and reports whether the request stood.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-change` is\na refusal and nothing moves. Nobody refusing means the control updates\nitself, whether or not a consumer declared `value`: a declared property\nis a seed and a correction, the way `<input value>` is, and a consumer\nwho wants the change for themselves refuses it and assigns their own.\nSee 294."
+              "description": "Requests a new value, and reports whether the request stood.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-change` is\na refusal and nothing moves. Nobody refusing means the control updates\nitself, whether or not a consumer declared `value`: a declared property\nis a seed and a correction, the way `<input value>` is, and a consumer\nwho wants the change for themselves refuses it and assigns their own."
             },
             {
               "kind": "method",
@@ -6075,7 +6106,7 @@
               "type": {
                 "text": "string"
               },
-              "description": "What the control holds now, and what its form submits.\n\nOne property, not two. Reading gives the real value whichever mode the\ncontrol is in, so `input.value` answers the question anyone asking it\nmeant. Writing hands ownership to the consumer, which is what\n`<helix-input value=\"x\">` says too, and matches what a controlled input\nmeans in React: the value is theirs and the control waits to be told.\n`default-value` is how markup seeds one it does not want to own.\n\nThe same shape as the other three mixins, which is the point of them\nbeing four of a kind rather than four of three kinds.\n\nhelix-input",
+              "description": "What the control holds now, and what its form submits.\n\nOne property, not two, so `input.value` answers the question anyone\nasking it meant. Writing always applies; `<helix-input value=\"x\">` is the\nsame statement in markup, and `default-value` is how markup seeds a value\na reset should return to.",
               "fieldName": "value"
             }
           ],
@@ -6159,7 +6190,7 @@
         },
         {
           "kind": "mixin",
-          "description": "Grafts `dismissible`, its label, and the event that says so.\n\nThree surfaces had written this: `Announcement`, `Tag` and `Toast.Item`, each\nwith the same two properties, the same event, and the same expression for the\nlabel. They had not diverged, which is the argument for extracting rather than\nagainst it, because the fourth would have.\n\n**The label reads the default slot, not the whole element**, and that is a bug\nfix rather than a move. Every copy said `this.textContent`, which is every\nlight-DOM descendant including the ones assigned elsewhere. On `Announcement`\nand `Tag` that is the same thing, because they have one slot. On `Toast.Item`\nit swept in the actions: a message reading \"Could not reach the server\" with a\n`Retry` button announced itself as \"Could not reach the server Retry\", and the\nconsumer removing it from their list got that string to match on.\n\n**`dismissEvent()` is separate from `dismiss()` for the one that needs it.**\n`Announcement` and `Tag` dispatch and are done: they own no state, so a\nrefusal is the whole of the consumer's answer. `Toast.Item` holds an `open`\nit may or may not own, so its event has to go through the controlled-change\npath with an `apply` beside it. Giving it the event rather than the method\nlets it keep the contract and skip the default.",
+          "description": "Grafts `dismissible`, its label, and the event that says so.\n\n**The label reads the default slot, never `this.textContent`**, which is\nevery light-DOM descendant including the ones assigned elsewhere. On\n`Announcement` and `Tag` the two are the same thing, because they have one\nslot. On `Toast.Item` the second sweeps in the actions: a message reading\n\"Could not reach the server\" with a `Retry` button announces itself as \"Could\nnot reach the server Retry\", and the consumer removing it from their list\ngets that string to match on.\n\n**`dismissEvent()` is separate from `dismiss()` for the one that needs it.**\n`Announcement` and `Tag` dispatch and are done: they own no state, so a\nrefusal is the whole of the consumer's answer. `Toast.Item` holds an `open`\nand applies the change itself, so its event goes through `requestChange` with\nan `apply` beside it. Giving it the event rather than the method lets it keep\nthe contract and skip the default.",
           "name": "MixinDismissible",
           "members": [
             {
@@ -6278,7 +6309,7 @@
                 "text": "string | undefined"
               },
               "readonly": true,
-              "description": "Ids of the description nodes, for `aria-describedby` on the control.\n\n`undefined` when there is nothing to point at, so the attribute is absent\nrather than pointing at an id that renders nothing."
+              "description": "Id of the description node, for `aria-describedby` on the control.\n\n`undefined` when there is nothing to point at, so the attribute is absent\nrather than pointing at an id that renders nothing."
             },
             {
               "kind": "field",
@@ -6399,7 +6430,7 @@
                   }
                 }
               ],
-              "description": "Reports \"required and empty\" against a rendered part, or clears it.\n\n`empty` is the control's own answer to whether it holds nothing, `message`\nis what to say about it, and `anchor` names the part the browser should\npoint its bubble at. Seven families wrote this out by hand."
+              "description": "Reports \"required and empty\" against a rendered part, or clears it.\n\n`empty` is the control's own answer to whether it holds nothing, `message`\nis what to say about it, and `anchor` names the part the browser should\npoint its bubble at."
             },
             {
               "kind": "field",
@@ -6415,28 +6446,28 @@
         },
         {
           "kind": "mixin",
-          "description": "Grafts a label, help text, and a validation message onto a control.\n\n**Over `HelixElement` rather than `HelixFormElement`, because not every\ncontrol that wants a label is form-associated.** A checkbox group is the\ncase: each box in it submits itself already, so the group deliberately\nreports no value of its own, and every form-related member of\n`ElementInternals` throws `NotSupportedError` on an element that is not\nform-associated. Measured, and the ARIA members are fine on the same\nelement, which is why the naming and describing work there and only the\nvalidity has to ask first.\n\nEvery form control wants the same three things around it and wants them in a\ndifferent arrangement: a label above an input, beside a checkbox, and over a\ngroup. So this owns the properties, the parts, and the wiring, and each\ncontrol places the nodes where its own geometry needs them. Same part names\neither way, so one stylesheet in the styled tier dresses all of them.\n\n**Not a wrapping `Field` component, and that is not a style preference.** A\nwrapper cannot name what it wraps. Its label would live in its own shadow\nroot and the control in another, and measured in Chrome 148: an\n`aria-labelledby` IDREF cannot see across, and\n`control.ariaLabelledByElements = [labelInTheWrapper]` reads back as zero\nelements, the reference dropped. The same assignment with a label in the\ncontrol's own tree is kept. That pattern works in React libraries because\nthey have no shadow boundary; bringing it here brings the ergonomics and none\nof the conditions that made it work.\n\n**A control whose label is its content renders its own.** A checkbox is named\nby the words beside it, inside the `<label>` that forwards the press, so it\nuses its default slot and nesting `renderLabel`'s `<label>` in there would be\ninvalid markup. `label` is that slot's fallback either way.\n\nWorth knowing, because it costs a label and gives no warning: **a\nwhitespace-only text node is assigned to the default slot and defeats its\nfallback.** Measured in Chrome 148, and a newline between the tags is enough,\nso `<helix-checkbox label=\"Accept\">` closed on the next line renders no label\nat all. A named slot does not have this problem, because `slot=\"label\"` is an\nattribute and a text node has none. It is the platform's behavior rather\nthan ours, and the same is already true of every slot fallback here.\n\n**The ids are fixed rather than generated.** IDREFs resolve within the tree\nthat holds them, so two controls on a page each carrying `helix-hint` in\ntheir own shadow root do not collide. That also removes the usual hydration\nhazard, since there is no generated value for a server and a client to\ndisagree about.\n\n**A group has to say it differently.** A control's `<input>` and its hint\nare both in the shadow root, so a plain `aria-describedby` resolves. A\ngroup's host is in the light DOM and its hint is not, so the IDREF cannot\nreach and `element.ariaDescribedByElements` drops the reference. Only\n`internals.ariaDescribedByElements` keeps it, which is what `describeHost`\nuses. Measured the same way, and the failure is silent either way: the\ndescription simply never reaches the accessibility tree.\n\n\n**The label, the hint and the feedback are documented on each component that\napplies this, rather than here.** Eight of the eighteen did and ten did not,\nwhich is what `check:parts` now refuses in both directions. Declaring them\nonce on this mixin is the obvious fix and does not work: the analyzer reads\n`@csspart` off a custom element class, so a class-level tag here reaches the\nmanifest as nothing at all, on this JSDoc and on the inner class alike.\nMeasured both ways, and the inner-class version is the dangerous one, since\nit satisfies `check:parts` while every API page stays exactly as wrong as\nbefore. Members are different and do inherit, which is what the note about\nthe inner class in the area rules is about.",
+          "description": "Grafts a label, help text, and a validation message onto a control.\n\n**Over `HelixElement` rather than `HelixFormElement`, because not every\ncontrol that wants a label is form-associated.** A checkbox group is the\ncase: each box in it submits itself already, so the group deliberately\nreports no value of its own, and every form-related member of\n`ElementInternals` throws `NotSupportedError` on an element that is not\nform-associated. Measured, and the ARIA members are fine on the same\nelement, which is why the naming and describing work there and only the\nvalidity has to ask first.\n\nEvery form control wants the same three things around it and wants them in a\ndifferent arrangement: a label above an input, beside a checkbox, and over a\ngroup. So this owns the properties, the parts, and the wiring, and each\ncontrol places the nodes where its own geometry needs them. Same part names\neither way, so one stylesheet in the styled tier dresses all of them.\n\n**Not a wrapping `Field` component, and that is not a style preference.** A\nwrapper cannot name what it wraps. Its label would live in its own shadow\nroot and the control in another, and measured in Chrome 148: an\n`aria-labelledby` IDREF cannot see across, and\n`control.ariaLabelledByElements = [labelInTheWrapper]` reads back as zero\nelements, the reference dropped. The same assignment with a label in the\ncontrol's own tree is kept. That pattern works in React libraries because\nthey have no shadow boundary; bringing it here brings the ergonomics and none\nof the conditions that made it work.\n\n**A control whose label is its content renders its own.** A checkbox is named\nby the words beside it, inside the `<label>` that forwards the press, so it\nuses its default slot and nesting `renderLabel`'s `<label>` in there would be\ninvalid markup. `label` is that slot's fallback either way.\n\nWorth knowing, because it costs a label and gives no warning: **a\nwhitespace-only text node is assigned to the default slot and defeats its\nfallback.** Measured in Chrome 148, and a newline between the tags is enough,\nso `<helix-checkbox label=\"Accept\">` closed on the next line renders no label\nat all. A named slot does not have this problem, because `slot=\"label\"` is an\nattribute and a text node has none. It is the platform's behavior rather\nthan ours, and the same is already true of every slot fallback here.\n\n**The ids are fixed rather than generated.** IDREFs resolve within the tree\nthat holds them, so two controls on a page each carrying `helix-hint` in\ntheir own shadow root do not collide. That also removes the usual hydration\nhazard, since there is no generated value for a server and a client to\ndisagree about.\n\n**A group has to say it differently.** A control's `<input>` and its hint\nare both in the shadow root, so a plain `aria-describedby` resolves. A\ngroup's host is in the light DOM and its hint is not, so the IDREF cannot\nreach and `element.ariaDescribedByElements` drops the reference. Only\n`internals.ariaDescribedByElements` keeps it, which is what `describeHost`\nuses. Measured the same way, and the failure is silent either way: the\ndescription simply never reaches the accessibility tree.\n\n**The label, the hint and the feedback are documented on each component that\napplies this, rather than here.** Declaring them once on this mixin is the\nobvious fix and does not work: the analyzer reads `@csspart` off a custom\nelement class, so a class-level tag here reaches the manifest as nothing at\nall, on this JSDoc and on the inner class alike. Measured both ways, and the\ninner-class version is the dangerous one, since it satisfies the rule while\nevery API page stays exactly as wrong as before. Members are different and\ndo inherit, which is what the note about the inner class in the area rules\nis about.",
           "name": "MixinField",
           "members": [
             {
               "kind": "field",
-              "name": "hint",
+              "name": "feedback",
               "type": {
                 "text": "string"
               },
               "default": "''",
-              "description": "Help under the control, shown while there is nothing wrong.",
-              "attribute": "hint"
+              "description": "What is wrong, in the reader's words rather than the browser's.",
+              "attribute": "feedback"
             },
             {
               "kind": "field",
-              "name": "feedback",
+              "name": "hint",
               "type": {
                 "text": "string"
               },
               "default": "''",
-              "description": "What is wrong, in the reader's words rather than the browser's.",
-              "attribute": "feedback"
+              "description": "Help under the control, shown while there is nothing wrong.",
+              "attribute": "hint"
             },
             {
               "kind": "field",
@@ -6467,7 +6498,7 @@
               },
               "privacy": "private",
               "default": "false",
-              "description": "Whether the reader has had a go at the field yet.\n\nThis was `:user-invalid`, which is the platform's own answer to \"is this\nfield wrong *yet*\" and is the right idea. It does not work here, and the\nreason is structural rather than a browser bug: `:user-invalid` tracks\ninteraction with the element it is on, and nobody interacts with this\nelement. The reader types into an `<input>` inside its shadow root, so\nthe host's interaction flag is never set and the selector never matches.\nMeasured after submitting an invalid required field and again after\nediting one and leaving it: false both times, while `:invalid` matched\nboth times.\n\nSo the moments are listened for instead, and both of them demonstrably\nreach the host: `invalid` when a form is submitted with this control\nfailing, and `change` when the reader has edited and committed. Focus\nalone is deliberately not one of them. Tabbing past an empty required\nfield should not be answered with an error.\n\n**A composite control has to construct its own `change`, and this mixin\ndeliberately does not do it for them.** A native `change` is\n`composed: false`, so a control built from several inner inputs never\nrelays one to its host: `Input` gets this free from its one control, and\n`PinInput` had four boxes, none of whose `change` means the code is\nentered, so a half-entered code was never `touched` and could never say\nwhat was wrong with it. See 311.\n\n**The obvious shared fix is for `touched` to take a `focusout`, and it is\nthe wrong one**, because it is the paragraph above undone: a `focusout`\nfires on the reader who tabbed past and typed nothing, which is exactly\nthe case this refuses to call an error. What a composite needs is not a\nfocus moment, it is the native meaning of `change`, \"edited, then left\",\nand the editing half is the part a mixin up here cannot see.\n\n**Nor is there one shape to extract yet.** The two composites in the\nlibrary solve it differently and both are right: `PinInput` is\nfocus-driven, taking a baseline when focus arrives from outside the row\nand announcing on the way out if it moved, and `DateInput` is\nvalue-driven, stopping its inner `change` and announcing once the date\nitself moves. Generalizing from those two would be generalizing from one,\nsince only one of them has a leaving moment at all. The trigger for\nlifting it is a third control that needs the focus-driven shape, at which\npoint what moves up is the baseline-and-commit pair rather than `touched`."
+              "description": "Whether the reader has had a go at the field yet.\n\n**Not `:user-invalid`**, which is the platform's own answer to \"is this\nfield wrong *yet*\" and cannot work here, for a structural reason rather\nthan a browser bug: it tracks interaction with the element it is on, and\nnobody interacts with this element. The reader types into an `<input>`\ninside its shadow root, so the host's interaction flag is never set and\nthe selector never matches. Measured after submitting an invalid required\nfield and again after editing one and leaving it: false both times, while\n`:invalid` matched both times.\n\nSo the moments are listened for instead, and both of them demonstrably\nreach the host: `invalid` when a form is submitted with this control\nfailing, and `change` when the reader has edited and committed. Focus\nalone is deliberately not one of them. Tabbing past an empty required\nfield should not be answered with an error.\n\n**A composite control has to construct its own `change`, and this mixin\ndeliberately does not do it for them.** A native `change` is\n`composed: false`, so a control built from several inner inputs never\nrelays one to its host: `Input` gets this free from its one control,\nwhile a `PinInput` of four boxes has no inner `change` that means the\ncode is entered, so a half-entered code is never `touched` and can never\nsay what is wrong with it.\n\n**The obvious shared fix is for `touched` to take a `focusout`, and it is\nthe wrong one**, because it is the paragraph above undone: a `focusout`\nfires on the reader who tabbed past and typed nothing, which is exactly\nthe case this refuses to call an error. What a composite needs is not a\nfocus moment, it is the native meaning of `change`, \"edited, then left\",\nand the editing half is the part a mixin up here cannot see.\n\n**Nor is there one shape to extract yet.** The two composites solve it\ndifferently and both are right: `PinInput` is focus-driven, taking a\nbaseline when focus arrives from outside the row and announcing on the\nway out if it moved, and `DateInput` is value-driven, stopping its inner\n`change` and announcing once the date itself moves. Only one of them has\na leaving moment at all, so generalizing from the pair is generalizing\nfrom one. The trigger for lifting it is a third control that needs the\nfocus-driven shape, at which point what moves up is the\nbaseline-and-commit pair rather than `touched`."
             },
             {
               "kind": "field",
@@ -6499,7 +6530,7 @@
                   "text": "TemplateResult | typeof nothing"
                 }
               },
-              "description": "A label above the control, pointing at it.\n\nA real `<label for>`, so pressing the words focuses the field and the\nbrowser does the forwarding. It resolves because `for` looks within the\nsame tree, and the control it names is in this shadow root.\n\n**Nothing at all when there is no label**, which is the same rule the\nhint and the feedback follow: none of the three is always used, and an\nelement rendered empty is not free. It still generates a box, so it still\ntakes a row of the grid and a gap on either side of it, which is a field\nthat has moved down the page for a label nobody wrote. `nothing` leaves\ncomment markers rather than a node, so the gap has nothing to sit between.\n\n**`aria-label` names without showing**, and it is forwarded rather than\nleft where the consumer put it. A custom element has no way to delegate a\nlabel to the control inside it, so an `aria-label` on the host reaches\nnothing: measured, the inner input came back with no label and no name of\nits own while the attribute sat on the wrapper. What happens instead is\nthat the label is rendered and clipped, so the name arrives through the\nsame `<label for>` a visible one does.\n\nThis replaced `hide-label`, which was a second attribute to say what the\nabsence of the first should have said. The rule is now `label` means a\nlabel, `aria-label` means a name, and neither means an unnamed field a\nscreen reader announces as \"edit text\""
+              "description": "A label above the control, pointing at it.\n\nA real `<label for>`, so pressing the words focuses the field and the\nbrowser does the forwarding. It resolves because `for` looks within the\nsame tree, and the control it names is in this shadow root.\n\n**Nothing at all when there is no label**, which is the same rule the\nhint and the feedback follow: none of the three is always used, and an\nelement rendered empty is not free. It still generates a box, so it still\ntakes a row of the grid and a gap on either side of it, which is a field\nthat has moved down the page for a label nobody wrote. `nothing` leaves\ncomment markers rather than a node, so the gap has nothing to sit between.\n\n**`aria-label` names without showing**, and it is forwarded rather than\nleft where the consumer put it. A custom element has no way to delegate a\nlabel to the control inside it, so an `aria-label` on the host reaches\nnothing: measured, the inner input came back with no label and no name of\nits own while the attribute sat on the wrapper. What happens instead is\nthat the label is rendered and clipped, so the name arrives through the\nsame `<label for>` a visible one does.\n\nThe rule is that `label` means a label, `aria-label` means a name, and\nneither means an unnamed field a screen reader announces as \"edit text\"."
             },
             {
               "kind": "method",
@@ -6584,27 +6615,27 @@
                   }
                 }
               ],
-              "description": "Reports \"required and empty\" and refreshes the message, or clears both.\n\nSeven families had this written out: the same `valueMissing`, the same\nanchor lookup, the same `refreshFeedback` under the same comment about\nvalidity moving without a property moving. Seven copies of a five-line\nshape is the threshold at which this mixin itself was extracted, and two\nof them had already drifted, `checkbox-group` having no validity at all\nuntil yesterday.\n\nWhat differs between them is exactly two things, so those are the\narguments: whether the control is empty, which only it can say, and the\nsentence to say about it, which is different for a box, a switch and a\nset. The anchor is looked up here because every one of them anchored on a\nrendered part and the browser needs somewhere to point the bubble.\n\nThe message is not derived from the control's kind, deliberately. \"Tick\nthis box\" and \"Choose one\" are not the same instruction and a lookup\ntable would be one more thing to keep in step with the components."
+              "description": "Reports \"required and empty\" and refreshes the message, or clears both.\n\nTwo things differ between the controls that call this, so those are the\narguments: whether the control is empty, which only it can say, and the\nsentence to say about it, which is different for a box, a switch and a\nset. The anchor is looked up here because every one of them anchors on a\nrendered part and the browser needs somewhere to point the bubble.\n\nThe message is not derived from the control's kind, deliberately. \"Tick\nthis box\" and \"Choose one\" are not the same instruction and a lookup\ntable would be one more thing to keep in step with the components."
             }
           ],
           "attributes": [
             {
-              "name": "hint",
+              "name": "feedback",
               "type": {
                 "text": "string"
               },
               "default": "''",
-              "description": "Help under the control, shown while there is nothing wrong.",
-              "fieldName": "hint"
+              "description": "What is wrong, in the reader's words rather than the browser's.",
+              "fieldName": "feedback"
             },
             {
-              "name": "feedback",
+              "name": "hint",
               "type": {
                 "text": "string"
               },
               "default": "''",
-              "description": "What is wrong, in the reader's words rather than the browser's.",
-              "fieldName": "feedback"
+              "description": "Help under the control, shown while there is nothing wrong.",
+              "fieldName": "hint"
             },
             {
               "name": "label",
@@ -6720,7 +6751,7 @@
               }
             }
           ],
-          "description": "Takes the pointer for a drag, and carries on if the platform refuses.\n\n**Capture is an enhancement, and the drag has to survive losing it.** What it\nbuys is events continuing to arrive once the pointer leaves the target, which\nmatters because a thin divider is easy to outrun. What it costs, called bare,\nis the rest of the handler: `setPointerCapture` throws `NotFoundError` when\nthe id names no active pointer, and every one of these calls sits above the\nlines that set the dragging flag and call `preventDefault`. So a refusal did\nnot degrade the drag, it canceled it.\n\nThat is reachable outside a test: a pointer released between the event being\nqueued and the handler running is gone by the time this is called, and a\nsynthetic `pointerdown` has no active pointer at all. The browser spec run\nreported four of those as uncaught page errors, and three splitter specs had\neach stubbed the method to get past it, which is the shape of a workaround\nthat has been in place long enough to read as setup.\n\nReturns whether it took, for the callers that then ask `hasPointerCapture`\nbefore believing a move belongs to them."
+          "description": "Takes the pointer for a drag, and carries on if the platform refuses.\n\n**Capture is an enhancement, and the drag has to survive losing it.** What it\nbuys is events continuing to arrive once the pointer leaves the target, which\nmatters because a thin divider is easy to outrun. What it costs, called bare,\nis the rest of the handler: `setPointerCapture` throws `NotFoundError` when\nthe id names no active pointer, and every one of these calls sits above the\nlines that set the dragging flag and call `preventDefault`. So a refusal did\nnot degrade the drag, it canceled it.\n\nThat is reachable outside a test: a pointer released between the event being\nqueued and the handler running is gone by the time this is called, and a\nsynthetic `pointerdown` has no active pointer at all.\n\nReturns whether it took, for the callers that then ask `hasPointerCapture`\nbefore believing a move belongs to them."
         }
       ],
       "exports": [
@@ -6760,7 +6791,7 @@
               }
             }
           ],
-          "description": "The nearest ancestor that is an instance of a class, crossing shadow roots.\n\n**Identity rather than tag name, and the rule already existed.** `Accordion`'s\nroot states it two files from a violation of it: \"Items are matched with\n`instanceof`, never by tag name. Matching `helix-accordion-item` would tie\nthis tier to the styled one.\" Nine headless families resolve their\nrelationships that way; two did it by tag, and both named `helix-*` tags that\nonly `@fusion.dev/helix` registers, which is a headless package depending on a\nstyled one by string.\n\nThe consequence is silent rather than loud. Subclassing a headless element under\na different tag is exactly what the headless tier exists to allow, and it is\nwhat `helix/styled` itself does. Under a third tag the lookup returned `null`,\nso an accordion's `mode` was ignored and every section behaved as `multiple`\nwith no error anywhere.\n\n**`closest()` alone is not enough**, which is why this walks rather than\ndelegating. `closest()` stops at a shadow boundary: a component slotted into\nanother component's shadow root has a `parentNode` chain that ends at a\n`ShadowRoot`, and `closest` will not step across it. Following `host` is what\nmakes a nested arrangement resolve, and nesting through a slot is the\nordinary case for anything composable."
+          "description": "The nearest ancestor that is an instance of a class, crossing shadow roots.\n\n**Identity rather than tag name.** Matching `helix-accordion-item` ties the\nheadless tier to the styled one by string, and only `@fusion.dev/helix`\nregisters a `helix-*` tag.\n\nThe consequence is silent rather than loud. Subclassing a headless element under\na different tag is exactly what the headless tier exists to allow, and it is\nwhat `helix/styled` itself does. Under a third tag a lookup by tag returns\n`null`, so an accordion's `mode` is ignored and every section behaves as\n`multiple` with no error anywhere.\n\n**`closest()` alone is not enough**, which is why this walks rather than\ndelegating. `closest()` stops at a shadow boundary: a component slotted into\nanother component's shadow root has a `parentNode` chain that ends at a\n`ShadowRoot`, and `closest` will not step across it. Following `host` is what\nmakes a nested arrangement resolve, and nesting through a slot is the\nordinary case for anything composable."
         }
       ],
       "exports": [
@@ -6794,7 +6825,7 @@
               }
             }
           ],
-          "description": "Builds a stylesheet from CSS authored in a `.css` file.\n\nComponent styles live in real `.css` files rather than `css` tagged\ntemplates, so they get CSS tooling: syntax highlighting, formatters, the\ntoken linter, and a diff that reads as CSS. `bun run styles` compiles each\none into a sibling `.css.ts` that calls this.\n\nThe `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a\nstylesheet. That is not what happens here: the argument is a build-time\nconstant read from a file in this repo, never a runtime value. Wrapping it\nkeeps the warning where it belongs, on `unsafeCSS` itself, and gives one seam\nto change if constructable stylesheets become the better primitive."
+          "description": "Builds a stylesheet from CSS authored in a `.css` file.\n\nComponent styles live in real `.css` files rather than `css` tagged\ntemplates, so they get CSS tooling: syntax highlighting, formatters, the\ntoken linter, and a diff that reads as CSS. `turbo run styles` compiles each\none into a sibling `.css.ts` that calls this.\n\nThe `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a\nstylesheet. That is not what happens here: the argument is a build-time\nconstant read from a file in this repo, never a runtime value. Wrapping it\nkeeps the warning where it belongs, on `unsafeCSS` itself, and gives one seam\nto change if constructable stylesheets become the better primitive."
         }
       ],
       "exports": [
@@ -6907,7 +6938,7 @@
               }
             }
           ],
-          "description": "Draws an icon that was imported by name, rather than looked up by string.\n\n**`<helix-icon name=\"play\">` indexes the whole icon set at runtime.** Its\nrender is `icons[this.name]`, and no bundler can shake a dynamic index, so\nevery consumer of any component that renders one ships all of the generated\npath data: measured at 50,814 bytes raw and 15,010 gzipped for 102 icons, and\ngrowing about 147 gzipped bytes per icon added. A named import ships one path\nand is checked when the package compiles rather than when `check:icons` runs.\n\nThat element still earns its place as *public* API, where a consumer writes a\nname in markup and a lookup is the only thing that can work. What it should\nnot be is how this library draws its own marks.\n\n**There is no `part` option, and there cannot be.** A part name behind an\ninterpolation is a part the manifest cannot see, so `check:selectors` reports\nthe component's own stylesheet as matching nothing and the part stops being\nAPI. `Trend` needs one and therefore writes its `<svg>` out with a literal\n`part=\"icon\"`, which is the honest cost: a helper can carry everything except\nthe thing static analysis has to read.\n\n`data-glyph` rather than a class, because the sizing lives in\n`helix/styled/src/icon/glyph.css` and a component's own `--icon-size`\ndeclarations have to keep working untouched: the variable was read by\n`helix-icon`, and now it is read by the rule that sheet carries. Without it\nevery one of those declarations would go quietly dead and every mark in six\nfamilies would change size."
+          "description": "Draws an icon that was imported by name, rather than looked up by string.\n\n**`<helix-icon name=\"play\">` indexes the whole icon set at runtime.** Its\nrender is `icons[this.name]`, and no bundler can shake a dynamic index, so\nevery consumer of any component that renders one ships all of the generated\npath data: measured at 50,814 bytes raw and 15,010 gzipped for 102 icons, and\ngrowing about 147 gzipped bytes per icon added. A named import ships one path\nand is checked when the package compiles rather than by a name lookup later.\n\nThat element still earns its place as *public* API, where a consumer writes a\nname in markup and a lookup is the only thing that can work. What it should\nnot be is how this library draws its own marks.\n\n**There is no `part` option, and there cannot be.** A part name behind an\ninterpolation is a part the manifest cannot see, so the component's own\nstylesheet matches nothing and the part stops being\nAPI. `Trend` needs one and therefore writes its `<svg>` out with a literal\n`part=\"icon\"`, which is the honest cost: a helper can carry everything except\nthe thing static analysis has to read.\n\n`data-glyph` rather than a class, because the sizing lives in\n`helix/styled/src/icon/glyph.css` and a component's own `--icon-size`\ndeclarations have to keep working untouched: the variable was read by\n`helix-icon`, and now it is read by the rule that sheet carries. Without it\nevery one of those declarations would go quietly dead and every mark in six\nfamilies would change size."
         }
       ],
       "exports": [
@@ -7062,7 +7093,7 @@
               }
             }
           ],
-          "description": "Whether `node` sits inside `root`, following shadow boundaries upward.\n\n`Node.contains` walks `parentNode` and a shadow root's `parentNode` is null,\nso it answers false for anything inside a component. Paired with\n`deepActiveElement`, which returns exactly such a node, that pairing is a trap\nof its own: the two look like they belong together and one of them crosses.\n\n`FocusTrapController` had precisely that, `contains(deepActiveElement())`,\nand it is why every dialog and drawer in the library leaked. Focus on a\n`helix-button` reports as the `<button>` in its shadow root, which is in no\nlight-DOM container anywhere, so the trap read every reader as already\noutside it.\n\n`host` is reached without naming `ShadowRoot`, which the server has no global\nfor. This runs from a keydown handler and would never execute there, but a\nbare reference is the kind that surfaces as a crash in Lit's result collector\nthe first time something calls it early."
+          "description": "Whether `node` sits inside `root`, following shadow boundaries upward.\n\n`Node.contains` walks `parentNode` and a shadow root's `parentNode` is null,\nso it answers false for anything inside a component. Paired with\n`deepActiveElement`, which returns exactly such a node, that pairing is a trap\nof its own: the two look like they belong together and one of them crosses.\n\n`contains(deepActiveElement())` is the shape to avoid: focus on a\n`helix-button` reports as the `<button>` in its shadow root, which is in no\nlight-DOM container anywhere, so a trap written that way reads every reader\nas already outside it.\n\n`host` is reached without naming `ShadowRoot`, which the server has no global\nfor. This runs from a keydown handler and would never execute there, but a\nbare reference is the kind that surfaces as a crash in Lit's result collector\nthe first time something calls it early."
         }
       ],
       "exports": [
@@ -7151,7 +7182,7 @@
               }
             }
           ],
-          "description": "Writes a host's semantics onto its `ElementInternals`.\n\nOnto internals rather than onto the host, which is the whole point: an\nattribute written at upgrade is markup a React consumer's server output never\nhad, and hydration reports the difference. Internals carry the same meaning\nto the accessibility tree and leave the element as the consumer wrote it.\n\n**Empty means absent, and that is the trap this exists for.** Assigning `''`\nto `ariaLabel` is not the same as not naming the element: it is a name of no\ncharacters, which a screen reader announces as an unnamed control while every\ncheck for \"is it labeled\" passes. Every caller had written\n`this.label === '' ? null : this.label` and one of them would eventually not.\n\n**Element references are feature-tested rather than assumed.** They are the\nonly way a host in the light DOM can point at a node in its own shadow root,\nan IDREF cannot cross that boundary, and the plain `element.aria*Elements`\nreflection drops the reference where `ElementInternals` keeps it. Older\nengines have neither, and assigning to a property they do not implement is a\nsilent no-op rather than an error, so the guard is what makes the absence\nvisible to anything reading this.\n\nOmitted keys are left alone, so a component that sets its role once in\n`willUpdate` and its references later in `updated` does not have to repeat\nitself or risk clearing what the other call wrote."
+          "description": "Writes a host's semantics onto its `ElementInternals`.\n\nOnto internals rather than onto the host, which is the whole point: an\nattribute written at upgrade is markup a React consumer's server output never\nhad, and hydration reports the difference. Internals carry the same meaning\nto the accessibility tree and leave the element as the consumer wrote it.\n\n**Empty means absent, and that is the trap this exists for.** Assigning `''`\nto `ariaLabel` is not the same as not naming the element: it is a name of no\ncharacters, which a screen reader announces as an unnamed control while every\ncheck for \"is it labeled\" passes. Clearing is `null`, and this is the one\nplace that has to remember it.\n\n**Element references are feature-tested rather than assumed.** They are the\nonly way a host in the light DOM can point at a node in its own shadow root,\nan IDREF cannot cross that boundary, and the plain `element.aria*Elements`\nreflection drops the reference where `ElementInternals` keeps it. Older\nengines have neither, and assigning to a property they do not implement is a\nsilent no-op rather than an error, so the guard is what makes the absence\nvisible to anything reading this.\n\nOmitted keys are left alone, so a component that sets its role once in\n`willUpdate` and its references later in `updated` does not have to repeat\nitself or risk clearing what the other call wrote."
         }
       ],
       "exports": [
@@ -7283,7 +7314,7 @@
             "text": "ComplexAttributeConverter<boolean>"
           },
           "default": "{ fromAttribute: (value: string | null): boolean => value !== null && value !== 'false', /* Written out so it survives being reflected later. `''` rather than `'true'`, which is what a boolean attribute looks like everywhere else. */ toAttribute: (value: boolean): string | null => (value ? '' : 'false'), }",
-          "description": "For a boolean property that is on unless a consumer says otherwise.\n\n**Lit's boolean converter cannot express false, and that is the whole\nproblem.** It answers `value !== null`, so an attribute is true by being\nthere: `modal` is true, `modal=\"\"` is true, and `modal=\"false\"` is true as\nwell, because it is present. A property defaulting to `true` therefore has no\nattribute that turns it off at all, and a consumer who writes the obvious\nthing gets the opposite of what they asked for, silently.\n\nFound on `Drawer.modal`, where it mattered: a tour cannot point inside a\nmodal, so `modal=\"false\"` is exactly what a consumer reaches for, and it left\nthe drawer modal. Two others have the same shape, `Video.playsInline` and the\nsandbox source's `tabIndents`.\n\nSo: absent is the default, present is on, and the one string that means off\nis the one a consumer would write. `\"false\"` only, and not `\"0\"` or `\"no\"`,\nbecause a converter that accepts a vocabulary invites a consumer to guess at\nit, and the one they guess wrong is the one that silently means on.\n\n**The other answer is to invert the property, and it is worse.** `Drawer`\nwould take `modeless`, absent meaning modal, which satisfies the rule that a\nreflected property takes no default. It also renames the thing every consumer\nalready writes, to a word nobody reaches for, so that markup can express a\nstate that is rare. The name stays and the attribute learns to say no."
+          "description": "For a boolean property that is on unless a consumer says otherwise.\n\n**Lit's boolean converter cannot express false, and that is the whole\nproblem.** It answers `value !== null`, so an attribute is true by being\nthere: `modal` is true, `modal=\"\"` is true, and `modal=\"false\"` is true as\nwell, because it is present. A property defaulting to `true` therefore has no\nattribute that turns it off at all, and a consumer who writes the obvious\nthing gets the opposite of what they asked for, silently.\n\nSo: absent is the default, present is on, and the one string that means off\nis the one a consumer would write. `\"false\"` only, and not `\"0\"` or `\"no\"`,\nbecause a converter that accepts a vocabulary invites a consumer to guess at\nit, and the one they guess wrong is the one that silently means on.\n\n**The other answer is to invert the property, and it is worse.** `Drawer`\nwould take `modeless`, absent meaning modal, which satisfies the rule that a\nreflected property takes no default. It also renames the thing every consumer\nalready writes, to a word nobody reaches for, so that markup can express a\nstate that is rare. The name stays and the attribute learns to say no."
         }
       ],
       "exports": [
@@ -7316,7 +7347,8 @@
                 "text": "Element"
               }
             }
-          ]
+          ],
+          "description": "Reads a table as series, one per data column.\n\n**The table is the chart's accessible representation, not a fallback for\none.** Every chart here takes its numbers from real markup rather than from a\nproperty, so the page is readable with no script at all, sortable by anything\nthat sorts tables, and correct in a screen reader without a parallel\ndescription that has to be kept in step by hand. A `values` array would be\neasier to pass and would make the accessible version the thing nobody\nmaintains.\n\nThe shape is the ordinary one: a header row naming the series, a first column\nof row headers, and numbers in the rest. A single-column table has one series\nand takes its name from the caption, since a header row of one is usually\nabsent.\n\n`data-value` wins over the cell's text, because `$1.2k` is what a reader\nshould see and is not a number. `Number()` rather than `parseFloat`, because\nthe second reads `12abc` as 12: a value that is nearly a number is a mistake\nworth dropping rather than rounding off, and a dropped point is visible where\na silently truncated one is not."
         },
         {
           "kind": "function",
@@ -7449,7 +7481,7 @@
               }
             }
           ],
-          "description": "Which item a value names, or the first that could stand in for it.\n\n`items.find(match) ?? items[0]` was written by hand in four components and it\nis not the obvious line it looks like. It is what makes a set whose `value`\nnames nothing still show something, which is every set before its consumer\nhas chosen and every set whose current item has just been removed.\n\nThe fallback skips disabled items and the match does not. A consumer who\nnames a disabled item meant it, and quietly moving to another would be the\ncomponent overruling them; but falling back *onto* a disabled item is the\ncomponent choosing, and it should not choose something out of play. Every\nhand-written copy took `items[0]` either way, so a set opening on a disabled\nfirst item showed it as current.\n\nA plain function rather than only a method on `MixinControllerActive`,\nbecause the components that need it are split across two mixins: a set whose\nvalue is submitted takes `MixinControllerValue` and cannot also take the\nactive one without two properties called `value`."
+          "description": "Which item a value names, or the first that could stand in for it.\n\n`items.find(match) ?? items[0]` was written by hand in four components and it\nis not the obvious line it looks like. It is what makes a set whose `value`\nnames nothing still show something, which is every set before its consumer\nhas chosen and every set whose current item has just been removed.\n\nThe fallback skips disabled items and the match does not. A consumer who\nnames a disabled item meant it, and quietly moving to another would be the\ncomponent overruling them; but falling back *onto* a disabled item is the\ncomponent choosing, and it should not choose something out of play. Taking\n`items[0]` either way opens a set on a disabled first item and shows it as\ncurrent.\n\nA plain function rather than only a method on `MixinControllerActive`,\nbecause the components that need it are split across two mixins: a set whose\nvalue is submitted takes `MixinControllerValue` and cannot also take the\nactive one without two properties called `value`."
         }
       ],
       "exports": [
@@ -7692,7 +7724,7 @@
               }
             }
           ],
-          "description": "Whether a consumer put anything in a slot.\n\n**There is no selector for this**, which is why it is script. `slot:empty`\nlooks like the answer and is not: a slot's children are its *fallback*, and\nassigned nodes are not children, so `:empty` is true whenever the fallback is\nabsent whether or not the consumer slotted anything. `:host(:has(...))` is\ninvalid CSS, and the server has no children to inspect.\n\nThe answer matters because an empty wrapper is not free. A region that\ngenerates a box is a flex item or a grid item whether or not it holds\nanything, so it takes the container's gap: an announcement with no actions\npaid the row gap twice, a switch with no label took one for a label that was\nnot there, and a blockquote with no attribution reserved a full space below\nevery quote. `display: none` is the only fix, because only a box that is not\ngenerated has no gap beside it.\n\nText or an element, because neither alone is the test. An element on its own\ncounts a whitespace-only span as content; text on its own counts an icon as\nnothing.\n\n`flatten` is deliberate here, unlike the tooltip's emptiness test: this asks\n\"will anything render\", where that one asks \"did the consumer provide\nanything\", and a slot showing its fallback does render."
+          "description": "Whether a consumer put anything in a slot.\n\n**There is no selector for this**, which is why it is script. `slot:empty`\nlooks like the answer and is not: a slot's children are its *fallback*, and\nassigned nodes are not children, so `:empty` is true whenever the fallback is\nabsent whether or not the consumer slotted anything. `:host(:has(...))` is\ninvalid CSS, and the server has no children to inspect.\n\nThe answer matters because an empty wrapper is not free. A region that\ngenerates a box is a flex item or a grid item whether or not it holds\nanything, so it takes the container's gap: an announcement with no actions\npays the row gap twice. `display: none` is the only fix, because only a box\nthat is not generated has no gap beside it.\n\nText or an element, because neither alone is the test. An element on its own\ncounts a whitespace-only span as content; text on its own counts an icon as\nnothing.\n\n`flatten` is deliberate here, unlike the tooltip's emptiness test: this asks\n\"will anything render\", where that one asks \"did the consumer provide\nanything\", and a slot showing its fallback does render."
         }
       ],
       "exports": [
@@ -7732,7 +7764,7 @@
               }
             }
           ],
-          "description": "Tells a slotted trigger that it opens something, and whether it is open.\n\n**Two components answered this by writing `aria-expanded` onto the consumer's\nelement, and that is a hydration mismatch.** `Megamenu` and `SpeedDial` both\ndid, each with a note saying why: a consumer who has to mirror `open` back\nonto their own trigger is a consumer who will forget, and the failure is\nsilent to everyone who can see the screen. Both notes are right about the\ngap. `Popover` refused to write anything, from the day it was written, on the\ngrounds that a component decorating a consumer's markup after upgrading is\none whose output a React consumer's hydration disagrees with.\n\n**Popover was right, measured 28 Aug 2026 against React 19.2.8.** Four\nfamilies were server-rendered as React emits them and hydrated with the\nelement definitions loaded either side of `hydrateRoot`:\n\n```\ncase        writes to trigger   hydration mismatch\nmegamenu    aria-expanded       yes, both load orders\nspeed dial  aria-expanded       yes, both load orders\npopover     nothing             no\nmenu        nothing             no\n```\n\nReact reports \"some attributes of the server rendered HTML didn't match the\nclient properties. This won't be patched up\", and the cost is not the console\nline: it answers a mismatch by discarding the server's HTML for that subtree\nand rebuilding it, which is what the carousel's own note records blinding an\n`<helix-aura>` two sections away.\n\n**A property crosses the gap that an attribute cannot, and this library\nalready knew it.** `Menu` tells its items by property \"rather than an\nattribute for that reason\", in those words. React diffs the attributes it\nrendered and never looks at a property, so the state reaches the trigger,\nlands as `aria-expanded` inside *that element's* shadow root, and the\nconsumer's markup is exactly what they served. Both positions get what they\nwere protecting: nothing is written onto the consumer's element, and the\nreader is still told what the control does.\n\n**Set before upgrade is safe**, which is what lets this run without waiting\nfor a definition: `ReactiveElement` captures an instance property assigned\nbefore it upgrades and re-applies it, so a trigger whose module has not\nloaded yet still ends up with the value.\n\n**A plain element is warned about rather than written to.** A\n`<button slot=\"trigger\">` has no shadow root to keep the state out of the\nmarkup and no property to take it, and a consumer cannot mirror it themselves\nbecause the open state belongs to the component. Saying so once is the same\nanswer `Tooltip` gives about the link it will not write for them. See #322."
+          "description": "Tells a slotted trigger that it opens something, and whether it is open.\n\n**Writing `aria-expanded` onto the consumer's element is a hydration\nmismatch, so it is not written.** The gap that answer was reaching for is\nreal: a consumer who has to mirror `open` back onto their own trigger is a\nconsumer who will forget, and the failure is silent to everyone who can see\nthe screen. It is still the wrong answer, because a component decorating a\nconsumer's markup after upgrading is one whose output a React consumer's\nhydration disagrees with.\n\n**Measured 28 Aug 2026 against React 19.2.8.** Four\nfamilies were server-rendered as React emits them and hydrated with the\nelement definitions loaded either side of `hydrateRoot`:\n\n```\ncase        writes to trigger   hydration mismatch\nmegamenu    aria-expanded       yes, both load orders\nspeed dial  aria-expanded       yes, both load orders\npopover     nothing             no\nmenu        nothing             no\n```\n\nReact reports \"some attributes of the server rendered HTML didn't match the\nclient properties. This won't be patched up\", and the cost is not the console\nline: it answers a mismatch by discarding the server's HTML for that subtree\nand rebuilding it, which is what the carousel's own note records blinding an\n`<helix-aura>` two sections away.\n\n**A property crosses the gap that an attribute cannot.** React diffs the\nattributes it rendered and never looks at a property, so the state reaches\nthe trigger, lands as `aria-expanded` inside *that element's* shadow root,\nand the consumer's markup is exactly what they served. Both positions get\nwhat they were protecting: nothing is written onto the consumer's element,\nand the reader is still told what the control does.\n\n**Set before upgrade is safe**, which is what lets this run without waiting\nfor a definition: `ReactiveElement` captures an instance property assigned\nbefore it upgrades and re-applies it, so a trigger whose module has not\nloaded yet still ends up with the value.\n\n**A plain element is warned about rather than written to.** A\n`<button slot=\"trigger\">` has no shadow root to keep the state out of the\nmarkup and no property to take it, and a consumer cannot mirror it themselves\nbecause the open state belongs to the component. Saying so once is the same\nanswer `Tooltip` gives about the link it will not write for them."
         }
       ],
       "exports": [
@@ -7797,7 +7829,7 @@
             "text": "Record<HelixStatusTone, ToneMark>"
           },
           "default": "{ danger: { icon: xCircleFill, label: 'Error' }, info: { icon: infoFill, label: 'Information' }, success: { icon: checkCircleFill, label: 'Success' }, warning: { icon: warningFill, label: 'Warning' }, }",
-          "description": "The one status vocabulary.\n\nIt was two, defined identically in `Callout` and in `Toast.Item`, and only one\nof the copies carried the comment saying the two must not drift. A reader\nmeets these marks in a passage and in a message and has to read them as the\nsame four things, so there is one place they come from.\n\n**Filled at every tone**, which is what it already was at one of them.\n`danger` took `xCircleFill` and the other three took outlines, so a set meant\nto be read as one vocabulary had one member drawn a different way. Filled\nbecause a tone mark is a status indicator and not an action: it wants to\nread at a glance and at a small size, where an outline at this weight loses\nits interior.\n\n**The label is not the tone name.** `danger` is announced as \"Error\",\nbecause that is the word a reader understands and `danger` is the word the API\nuses. Both matter and they are not the same string."
+          "description": "The one status vocabulary.\n\nA reader meets these marks in a passage and in a message and has to read them\nas the same four things, so there is one place they come from.\n\n**Filled at every tone**, or a set meant to be read as one vocabulary has a\nmember drawn a different way. Filled because a tone mark is a status\nindicator and not an action: it wants to read at a glance and at a small\nsize, where an outline at this weight loses its interior.\n\n**The label is not the tone name.** `danger` is announced as \"Error\",\nbecause that is the word a reader understands and `danger` is the word the API\nuses. Both matter and they are not the same string."
         },
         {
           "kind": "function",