@fusion.dev/helix-headless 0.4.1 → 0.4.3

package/dist/pagination/summary/pagination-summary.d.ts

@@ -5,39 +5,18 @@ import { type TemplateResult } from 'lit';
  *
  * @description
  * Its own element rather than a part of `Pagination`, so a consumer decides
- * where it goes. Inside the run it could only ever be at one end of one row;
- * beside it, it goes above, below, in a table's caption, or on the other side of
- * the page, and the direction and order of the whole footer are the consumer's.
+ * where it goes: above, below, in a table's caption, or on the other side of
+ * the page. Inside the run it could only ever be at one end of one row.
  *
- * **It repeats `page`, `page-size` and `total`, and the cost of that is skew
- * rather than verbosity.** Those three come from the consumer's own query, so
- * writing them on two elements is one variable used twice; what it risks is the
- * two disagreeing, and a count reading `76-100 of 248` beside a run showing page
- * 7 is the same failure this element's own clamping exists to prevent, arriving
- * from the outside instead.
+ * **It repeats `page`, `page-size` and `total`, and the cost of that is skew.**
+ * Those three come from the consumer's own query, so writing them on two
+ * elements is one variable used twice; what it risks is the two disagreeing.
  *
- * **Nothing removes it at this level, and that was measured rather than
- * assumed.** A coordinating root can only reach children the consumer laid out
- * by writing attributes onto them, which a framework reports as a hydration
- * error, or through context, which is dead on a server: `@lit/context`
- * subscribes from `connectedCallback`, and Lit SSR does not call it, so every
- * value is `undefined` in exactly the render this element exists to be part of.
- * Confirmed against Lit SSR directly. The fork is real: children in the light
- * DOM mean the consumer owns the layout and no root can feed them; children in a
- * shadow root mean a root feeds them by ordinary binding and owns the layout.
- *
- * **It resolves one level up, at a composite, and the state is why.** `page`,
- * `page-size` and `total` are facts about a *result*, not about a pagination, so
- * the element that should hold them once is the one that holds the result: a
- * data table composing a pagination inside itself, rather than a pagination root
- * invented to hold three pagination elements together. That root would have been
- * plumbing; a table's paging state is the thing itself. And because a composite
- * renders its parts into its own shadow root, it lands on the side of the fork
- * where binding works and the server renders, at no cost to anyone.
- *
- * Renders nothing without a `total` and a `page-size`. A wrong count is worse
- * than none: it is the one number in a footer a reader cannot check against
- * anything else on screen.
+ * **Nothing removes that at this level, and it was measured.** A coordinating
+ * root can only reach light-DOM children by writing attributes onto them, which
+ * a framework reports as a hydration error, or through context, which is dead
+ * on a server: `@lit/context` subscribes from `connectedCallback`, and Lit SSR
+ * does not call it.
  *
  * @since 0.1.0
  * @status experimental

package/dist/progress/root/progress-root.d.ts

@@ -5,32 +5,15 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  *
  * @description
  * Determinate by default, and `indeterminate` for a task whose total is not
- * known yet. `Loader` is still the right answer where the wait is short or has
- * no place of its own on the page; a bar earns its width where the work is the
- * subject of the region it sits in.
+ * known yet. `Loader` is still right where the wait is short or has no place of
+ * its own on the page.
  *
  * A bar that fills at a made-up rate would be a bar that lies, so the
  * indeterminate one does not fill: it runs a segment across the track, which
- * says work is happening and claims no proportion at all. `aria-valuenow` is
- * omitted with it, which is the platform's own signal for the same thing.
+ * says work is happening and claims no proportion. `aria-valuenow` is omitted
+ * with it, which is the platform's own signal for the same thing.
  *
  * **The fill is a fraction of the track, written as a custom property.**
- * `--progress-fraction` is derived from `value` and `max` rather than measured,
- * so it renders on a server with no layout and needs nothing after upgrade. That
- * is what keeps it out of the class of geometry this library writes only on the
- * client. A consumer never sets it: it carries a number this element computed
- * and CSS cannot, which is what lets a stylesheet draw the thing without
- * measuring anything itself.
- *
- * **`value` is clamped, and out-of-range input is not an error.** A count that
- * runs past its own total is ordinary in real applications, and a bar that
- * overflows its track or reports `aria-valuenow` above `aria-valuemax` is worse
- * than one that reads as finished.
- *
- * Semantics are on the host through `ElementInternals`, the same as everywhere
- * else: a `role` in the shadow root announces correctly and leaves the host
- * anonymous to anything walking the light DOM, and a `role` written onto the
- * host as an attribute is one a server's markup never had.
  *
  * @since 0.1.0
  * @status stable

package/dist/rating/root/rating-root.d.ts

@@ -7,39 +7,16 @@ declare const HelixHeadlessRating_base: (new (...args: any[]) => import("@fusion
  * @description
  * **Half marks decide the shape.** Supporting them means the value is not an
  * integer and the targets are not the marks: five stars at a half step is ten
- * places to press, and a mark that is filled to the middle. The pointer handling
- * and `step` are both built around that rather than added over it.
+ * places to press. The pointer handling and `step` are built around that
+ * rather than added over it.
  *
- * **A partial mark is the whole mark, clipped.** Not a second glyph filled to
- * the middle: that needs a matching pair drawn for every mark anybody uses, and
- * the moment a consumer wants a heart or a circle they need to draw one too. The
- * fill is the same marks over the same marks, cut off partway, so any mark works
- * and any fraction does.
+ * **A partial mark is the whole mark, clipped**, not a second glyph filled to
+ * the middle: the fill is the same marks over the same marks, cut off partway,
+ * so any mark works and any fraction does.
  *
- * **Read-only is not this control grayed out, it is a different thing.** The
- * commoner use is showing a score nobody is being asked for, a product's
- * average, and that is not a control at all: it takes no focus, answers no keys,
- * has no options to choose between, and reads as one thing rather than as five.
- * So `readonly` is `role="img"` with the score in its name, where the control is
- * a radio group. A disabled control is still a control and still says so; this
- * is not one.
- *
- * **Moving is choosing here**, which is the radio group's reading and the
- * opposite of `Menu`'s: arriving at four stars *is* rating it four, because
- * nothing else follows and there is nothing to confirm. That is what
- * `KeyboardNavigationController` takes `selects` for, and why this can use it
- * where a menu cannot.
- *
- * **The mark is a stylesheet's, not a slot's.** A slot projects its content
- * once, and there are two layers of marks here: slotting a star would put it in
- * the track or the fill and leave the other empty. So the mark is a shape the
- * styled tier masks with, which is also what lets a partial one be a clip of the
- * whole rather than a second drawing of it.
- *
- * The properties below are written by this component and read by whoever draws
- * it. A consumer sets none of them: they carry a number this element computed
- * and CSS cannot, which is what lets a stylesheet on this tier draw the thing
- * without measuring anything itself.
+ * **Read-only is not this control grayed out.** The commoner use is showing a
+ * score nobody is being asked for, which is a reading rather than a disabled
+ * input, and it is announced as one.
  *
  * @since 0.1.0
  * @status experimental

package/dist/slider/root/slider-root.d.ts

@@ -6,45 +6,22 @@ declare const HelixHeadlessSlider_base: (new (...args: any[]) => import("@fusion
  *
  * @description
  * A real `<input type="range">`, so the drag, the arrow keys, Home and End, the
- * page keys and the touch target are all the platform's. Every one of those is
- * a thing a hand-built slider gets wrong, and the last is the one nobody
+ * page keys and the touch target are the platform's. The last is the one nobody
  * notices: a native range has a hit area larger than its thumb, sized by the
  * platform for a finger.
  *
  * **The value is a string, like every other form control's.** A range submits
  * text and `MixinControllerValue` holds text, so the number is a reading of the
- * value rather than the value itself. `valueAsNumber` is there for anything
- * doing arithmetic on it.
+ * value. `valueAsNumber` is there for arithmetic.
  *
- * **Marks are drawn rather than left to `<datalist>`.** A datalist's ticks
- * cannot be styled at all, and Firefox does not render them for a range at all,
- * so the platform's version is a mark that looks like someone else's design
- * where it appears and no mark where it does not. Drawing them costs the
- * semantics nothing, because a mark is decoration: what a reader can actually
- * land on is `step`, which the input enforces whether or not anything is drawn.
+ * **Marks are drawn rather than left to `<datalist>`**, whose ticks cannot be
+ * styled and which Firefox does not render for a range at all. A mark is
+ * decoration; what a reader can land on is `step`, which the input enforces
+ * whether or not anything is drawn. `markers` is a count rather than a flag, so
+ * a slider from zero to a hundred cannot silently ask for a hundred and one.
  *
- * `markers` is a count rather than a flag tied to `step`. A flag reads well
- * until a slider from zero to a hundred stepping by one asks for a hundred and
- * one ticks, and then it is either noise or a silent refusal to draw. A number
- * is what the reader sees, so it cannot surprise anyone.
- *
- * **A range is two of them, not a hand-built one.** There is no native
- * two-thumb range, so two are stacked on one track and each thumb keeps its own
- * drag, its own arrow keys, its own Home and End and its own finger-sized hit
- * area. Rebuilding would throw away every argument this component is made of,
- * to gain a second handle.
- *
- * Crossing is stopped in the handler rather than by the bounds, and that is not
- * the obvious way round. Giving the lower input `max` of the upper reads well
- * and breaks the drawing: an input's thumb sits at a fraction of *its own*
- * range, so a lower thumb bounded at the upper one paints against a shorter
- * track and the two stop lining up. Both inputs span the whole range and the
- * values are clamped against each other on the way in.
- *
- * The properties below are written by this component and read by whoever draws
- * it. A consumer sets none of them: they carry a number this element computed
- * and CSS cannot, which is what lets a stylesheet on this tier draw the thing
- * without measuring anything itself.
+ * **A range is two of them.** There is no native two-thumb range, so two are
+ * stacked on one track and each thumb keeps its own.
  *
  * @since 0.1.0
  * @status experimental

package/dist/splitter/root/splitter-root.d.ts

@@ -4,101 +4,33 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  * @summary Two panes and a divider the reader can move.
  *
  * @description
- * **One axis, and nesting is how you get two.** The sandbox this was taken from
- * moves a cross: a divider down the middle, another across the bottom, and a
- * corner that moves both. That is a layout rather than a component, and every
- * part of it that is worth sharing is one divider between two panes. A splitter
- * inside a splitter gives the cross back, and gives the three-pane and the
- * four-pane arrangements it never had.
+ * **One axis, and nesting is how you get two.** A splitter inside a splitter
+ * gives back the cross, and gives the three-pane and four-pane arrangements a
+ * single divider never had.
  *
  * **Where two of them cross there is a corner, and it moves both.** A splitter
- * slotted into a pane of another, at right angles to it, has one end of its
- * divider sitting exactly on the other's. That end grows a handle: `move` under
- * the pointer, both arrow axes on the keyboard, and a drag that carries the two
- * positions at once.
+ * slotted into a pane of another, at right angles to it, grows a handle at the
+ * crossing: `move` under the pointer, both arrow axes on the keyboard, and a
+ * drag that carries the two positions at once. It appears at `firstUpdated`
+ * rather than in the served markup, being an affordance rather than content,
+ * and a splitter with no corner yet is a splitter with two working dividers.
  *
- * **The outer splitter draws it and the nested one announces itself upward.**
- * The nested one drawing its own is the tempting version, since it already
- * knows where its divider begins and needs no measurement of the other, and it
- * is clipped: the crossing lies on the boundary between a pane and the divider
- * beside it, a handle centered there reaches back over the boundary, and a pane
- * is `overflow: auto`. Exactly half the corner is cut off. The outer separator
- * is the one element that already straddles the seam, so the corner belongs in
- * it.
- *
- * That makes the channel between the two a single call in a single direction:
- * `cross(child, at)` says where the child crosses, `moveTo` drives either one,
- * and neither reads the other's state. The child is what calls it, because a
- * parent cannot poll for a child that has not upgraded yet.
- *
- * The one number it carries is a percentage rather than a measurement, which is
- * what keeps either of them from measuring the other, and it assumes the nested
- * splitter fills its pane. That is what slotting one into a pane does. Give the
- * nested splitter its own inset, or wrap it in something smaller than the pane,
- * and the corner is drawn where the crossing would be rather than where it is.
- *
- * **It is a client-side enhancement and says so.** Finding the parent means
- * inspecting the tree, which a server cannot do, so the corner appears at
- * `firstUpdated` and never in the served markup. That is allowed for exactly
- * this: it is an affordance rather than content, and a splitter with no corner
- * yet is a splitter with two working dividers.
- *
- * Where two dividers are parallel there is no corner, because there is nothing
- * to take hold of. Where they cross without a corner, the inner divider takes
- * the pointer: every separator sits on the same layer, so a tie goes to document
- * order and a deeper splitter is always later.
- *
- * **A divider that is moving says so, whoever is moving it.** `:hover` cannot
- * carry that: a drag holds the pointer through capture and a fast one leaves the
- * target behind, and a corner moves the nested divider while the reader is on
- * the crossing, nowhere near it. So a drag in progress is a state, and both
- * dividers a corner moves are lit for as long as it moves them.
- *
- * **The divider is a real `role="separator"` with `aria-valuenow`, moved by the
- * arrow keys as well as by pointer.** A divider only a mouse can move is
- * unusable without one, which is the reason the sandbox's carries the same, and
- * `Home` and `End` take it to its bounds.
+ * **The divider is a real `role="separator"` with `aria-valuenow`**, moved by
+ * the arrow keys as well as by pointer, with `Home` and `End` taking it to its
+ * bounds. A drag in progress is a state rather than `:hover`, so both dividers
+ * a corner moves are lit for as long as it moves them.
  *
  * **It goes where it is put, all the way to either end.** `min` and `max` are
  * nothing and everything unless a consumer says otherwise, because a divider
- * that stops dead short of the edge gives a reader no way to put a pane away.
- * Where a pane should keep a sliver of itself, only whoever put the tabs on it
- * knows how much, so they say so.
+ * that stops short of the edge gives a reader no way to put a pane away.
  *
  * **A pane can be shut, and that is not the same as a divider at the edge.**
  * The geometry is identical and the knowledge is not: only a shut pane knows
  * where to open back to. So `collapsed` is a second state rather than a reading
- * of the position, and the position it opens to is simply the one collapsing
- * never overwrote. `collapsed-size` keeps a sliver showing where a pane has a
- * tab strip worth leaving, and collapse overrides `min` and `max`, which is
- * what those are for: they keep a pane from vanishing by accident, and this is
- * the deliberate version.
- *
- * The two are kept in step in one direction only: a drag that settles on the
- * collapsed size latches shut, and any move opens it again. Otherwise a reader
- * could drag a pane closed and the consumer's own button would still be
- * offering to close it.
- *
- * A pane shut to nothing is told apart from one shut to a sliver, because the
- * two want different dividers: a sliver still has a boundary worth drawing, and
- * nothing leaves the divider sitting on the container's own edge.
- *
- * **The box is measured once, when a drag starts.** Measuring per move is a
- * forced layout on every pointer event, in the middle of a gesture whose whole
- * job is to stay ahead of the pointer, and nothing about the box moves while the
- * divider does.
- *
- * **`helix-before-resize` fires when it settles, not while it moves.** A drag is a
- * stream of positions and only the one it ends at is a preference; announcing
- * each would ask a consumer to write to storage a hundred times to record one
- * decision. Nothing is stored here either: where a preference lives, and whether
- * it should be kept at all, is the consumer's to decide, and a component writing
- * to storage on its own would be deciding for all of them under a key it chose.
- *
- * The properties below are written by this component and read by whoever draws
- * it. A consumer sets none of them: they carry a number this element computed
- * and CSS cannot, which is what lets a stylesheet on this tier draw the thing
- * without measuring anything itself.
+ * of the position, and the position it opens to is the one collapsing never
+ * overwrote. `collapsed-size` keeps a sliver showing where a pane has a tab
+ * strip worth leaving, and collapse overrides `min` and `max`, which is what
+ * those are for.
  *
  * @since 0.1.0
  * @status experimental

package/dist/steps/root/steps-root.d.ts

@@ -5,34 +5,16 @@ declare const HelixHeadlessSteps_base: (new (...args: any[]) => import("@fusion.
  * @summary A sequence of stages, and where the reader is in it.
  *
  * @description
- * **`active` names where the reader is. `complete` stays on each step.** They
- * are two different facts and only one of them is positional. Deriving both
- * from a position is the obvious design and it is wrong the first time anybody
- * steps back: return to stage one of three and stages one and two are still
- * finished, while "everything before the active one" says only the first is.
- * So this element drives `current` and never touches `complete`.
+ * **`active` names where the reader is. `complete` stays on each step.** Only
+ * one of them is positional: return to stage one of three and stages one and
+ * two are still finished, where "everything before the active one" says only
+ * the first is. So this element drives `current` and never touches `complete`.
  *
  * **`active` is optional, and a sequence without it still renders.** Left
- * unset, each step's own `current` stands and nothing here overwrites it, which
- * is what lets the whole sequence be right in the server's markup: this element
- * would have to count its slotted children to know which one is third, and the
- * server has no children to count. Set it, and it wins, because it is a
- * statement about the sequence where the attribute on a step is a statement
- * about one step.
- *
- * That is also why the numbering is not JavaScript. It is a CSS counter in the
- * tier above, which the browser resolves at layout with no script at all, so
- * the third step reads "3" in the server's own markup.
- *
- * **The connector belongs to the step, not to the list.** Each one draws the
- * line that arrives at it and hides it when it is first, the same arrangement
- * Breadcrumbs uses for its separator and for the same reason: a line drawn
- * between items needs either an index or a parent that counts, and drawing it
- * on the item needs neither.
- *
- * `role="list"` on the host rather than an `<ol>` in the shadow root. The steps
- * are the consumer's elements in the light DOM, so an `<ol>` here would be a
- * list whose items are somewhere else.
+ * unset, each step's own `current` stands, which is what lets the whole
+ * sequence be right in the server's markup: this element would have to count
+ * its slotted children to know which is third, and the server has none to
+ * count.
  *
  * @since 0.1.0
  * @status experimental

package/dist/steps/step/step.d.ts

@@ -5,51 +5,21 @@ import '../../button/index.js';
  * @summary One stage in a sequence.
  *
  * @description
- * **The name is a button, and only the name.** A stepper is something a reader
- * goes back through, and the thing they reach for is the name of the stage. The
- * marker is `aria-hidden` decoration, so wrapping it in the button would add
- * hit area and no meaning: the accessible name would be the text either way,
- * and what is pressable would stop being the same shape as what is readable.
+ * **The name is a button, and only the name.** The marker is `aria-hidden`
+ * decoration, so wrapping it would add hit area and no meaning. It is
+ * `helix-button` rather than a `<button>` this element resets: the hover wash,
+ * the focus ring and the disabled treatment are decisions the button carries.
  *
- * It is `helix-button`, not a `<button>` this element resets and dresses: the
- * hover wash, the focus ring and the disabled treatment are decisions the
- * button already carries. `ghost` is the quiet shape, transparent until it is
- * pointed at.
- *
- * It says nothing about where a reader may go. Every step is pressable and
+ * **It says nothing about where a reader may go.** Every step is pressable and
  * announces itself with `helix-select`; refusing the ones ahead is `disabled`,
- * which the consumer sets because only the consumer knows whether a form can be
- * skipped. A component that guessed would be wrong on the first wizard that
- * lets you jump to the end.
+ * which the consumer sets, because only they know whether a form can be
+ * skipped.
  *
  * **The marker is a slot whose fallback is the state.** A finished stage shows
- * a check, the current one a target, and one not yet reached an empty ring:
- * three marks that say what a reader wants to know without a legend. A consumer
- * who wants their own fills the slot instead.
- *
- * The step renders exactly one of the three, chosen from its own two booleans.
- * Rendering all three and hiding two in CSS would work and is worse: the
- * accessibility tree would carry marks that are not there, and the markup would
- * say three things about a stage that is one.
- *
- * Numbering belongs to the tier above. `numeric` hides the mark and shows a CSS
- * counter, which the browser resolves at layout, so the digit costs no script
- * and is right in the server's markup however the steps are ordered. Nothing
- * here knows which appearance is in use.
- *
- * **`complete` and `current` are separate, and both can be false.** A stage
- * that is neither is one the reader has not reached, which is the majority of
- * any sequence and therefore the state that needs no attribute. They can also
- * both be true: a reader who steps back into a finished stage is in it and has
- * finished it, and a stepper that forgets the second is one that loses its
- * checks the moment somebody reviews their answers.
- *
- * **The `content` slot opens on the current step, and only down a column.** A
- * row has no room under a step to put a form in, and stretching one to fit
- * would set every step's height by the tallest. `current` is what opens it, so
- * the state that says where the reader is is also the state that shows them the
- * stage: one attribute, no second flag to keep in step with it, and it renders
- * open on the server rather than after hydration.
+ * a check, the current one a target, one not yet reached an empty ring. Exactly
+ * one is rendered, chosen from the step's own two booleans, rather than three
+ * with two hidden in CSS: the accessibility tree would otherwise carry marks
+ * that are not there.
  *
  * @since 0.1.0
  * @status experimental

package/dist/toast/item/toast-item.d.ts

@@ -6,40 +6,16 @@ declare const HelixHeadlessToastItem_base: (new (...args: any[]) => import("@fus
  *
  * @description
  * An element rather than a slot, because it carries a timeout, a tone, a
- * dismiss control and a lifetime that pauses: behavior, state and API, which
- * is the test for whether a region becomes an element in this library.
+ * dismiss control and a lifetime that pauses: behavior, state and API.
  *
  * **The timer is the item's own.** Held by the region, one message arriving
  * would restart another's, so a stack of three would go from three seconds each
- * to nine for the last one. Each message is on its own clock from the moment it
- * is rendered.
+ * to nine for the last.
  *
- * **A message is the opposite of the page it is over.** Inverted by default,
- * because a thing arriving in a corner has to be told apart from the page in
- * the moment before it is read, and inverting does that without spending a
- * color that means something. It is a flip of `color-scheme` rather than a
- * named inverse surface: every token in the subtree re-resolves, so a `Retry`
- * a consumer slots in comes out right without knowing where it is. `Tooltip`
- * can name the inverse surface directly because it holds no controls; this
- * cannot. Set `data-color-mode` on the region to take the page's mode instead.
- *
- * **No duration means it stays.** That is the safe default rather than the
- * common one: anything carrying an action has to still be there when the reader
- * decides to take it, and a component cannot tell from the outside whether the
- * message it was given is disposable.
- *
- * **The clock stops while it is being read.** Hover pauses it, and so does
- * focus landing anywhere inside, which is the case that matters more: a
- * keyboard reader tabbing towards the action in a toast is exactly the person a
- * timer must not race. Both resume where they left off rather than starting
- * again, so a message half-read does not get a full second life every time a
- * pointer crosses it.
- *
- * **Going away is a request, never an act.** It dispatches a cancelable
- * `helix-dismiss` and does nothing else: the consumer owns the list, so the
- * item removing itself would leave the two disagreeing. Auto-dismiss and the
- * dismiss control raise the same event, so a consumer handles one path and not
- * two.
+ * **A message is the opposite of the page it is over.** Inverted by default, so
+ * a thing arriving in a corner is told apart from the page before it is read,
+ * and by a flip of `color-scheme` rather than by spending a color that means
+ * something.
  *
  * @since 0.1.0
  * @status experimental

package/dist/toggle/group/toggle-group.d.ts

@@ -6,32 +6,14 @@ declare const HelixHeadlessToggleGroup_base: (new (...args: any[]) => import("@f
  *
  * @description
  * The indicator is one element that travels, not a background that appears on
- * whichever item is current. That difference is the whole point: a fill that
- * swaps is two things changing at once and reads as a flicker, while one that
- * moves is a single object the eye follows, and it says where the selection
- * came from as well as where it went.
+ * whichever item is current. A fill that swaps is two things changing at once
+ * and reads as a flicker; one that moves is a single object the eye follows,
+ * and it says where the selection came from as well as where it went.
  *
- * Its whole box is measured from the selected item and written onto
- * the indicator as custom properties, because labels are different lengths and
- * no proportion of the group is the right answer. Measurement is client-side by
- * necessity, so the server renders the indicator hidden and it fades in once it
- * has somewhere to be, which is the harmless direction: it appears rather than
- * jumping from a wrong place.
- *
- * A radio group, and only that. Navigation is links marked with `aria-current`
- * and styled by the `data-navigation-item` recipe: radio semantics would announce a
- * set of destinations as a set of choices. A tab controls a panel.
- *
- * Being a radio group, it is a form control, and it says so through
- * `HelixFormElement`: it reports its value under a `name`, comes back to the
- * markup's choice on reset, and restores the one a reader made when the browser
- * brings a form back.
- *
- * The semantics were already right: the host has carried `role="radiogroup"`
- * and the items `role="radio"` from the start. What none of it did was reach a
- * form. A button in a shadow root submits nothing whatever its role, so the
- * value has to be reported by the host, which is the only thing a form can
- * see.
+ * Its box is measured from the selected item and written onto the indicator as
+ * custom properties, labels being different lengths. Measurement is client-side
+ * by necessity, so the server renders the indicator hidden and it fades in once
+ * it has somewhere to be, which is the harmless direction.
  *
  * @since 0.1.0
  * @status experimental

package/dist/tooltip/root/tooltip-root.d.ts

@@ -7,57 +7,35 @@ declare const HelixHeadlessTooltip_base: (new (...args: any[]) => import("@fusio
  * @description
  * The trigger is slotted and stays the consumer's own element. The bubble is
  * rendered here, in the top layer through the popover API, so it clears any
- * ancestor with `overflow: hidden` without a `z-index` anywhere.
+ * ancestor with `overflow: hidden` without a `z-index` anywhere. Position comes
+ * from `FloatingController`, which flips to another side when the preferred one
+ * does not fit.
  *
- * Position comes from `FloatingController`, which flips to another side when
- * the preferred one does not fit and slides along it to stay in view.
- *
- * **Two forms, and they are not equivalent for a screen reader.**
- *
- * Wrapping is the convenience form and is right where the bubble decorates a
- * control that already says what it is. The trigger stays the consumer's own
- * element, slotted, and nothing here can describe it: an IDREF cannot cross a
- * shadow boundary, an element reference is valid only into the same tree or a
- * shadow-including *ancestor* (the bubble's tree is neither, it is inward), and
- * a string on the trigger means writing to markup the consumer server-rendered.
- * All three measured.
+ * **Two forms, and they are not equivalent for a screen reader.** Wrapping is
+ * the convenience form and is right where the bubble decorates a control that
+ * already says what it is: nothing here can describe a slotted trigger, an
+ * IDREF being unable to cross a shadow boundary.
  *
  * `for` is the form that works. The tooltip sits *beside* the trigger in the
- * consumer's own tree and names it by id, so both are in one tree and an IDREF
- * between them is legal in the ordinary way:
+ * consumer's own tree and names it by id, so an IDREF between them is legal in
+ * the ordinary way:
  *
  * ```html
  * <helix-button id="save" aria-describedby="save-tip">Save</helix-button>
  * <helix-tooltip id="save-tip" for="save" content="Save your work"></helix-tooltip>
  * ```
  *
- * Note that the reference points at *this host*, not at the bubble inside its
- * shadow root: the description is computed from the flat tree, which descends
- * into shadow content on its own.
+ * The reference points at *this host*, not at the bubble in its shadow root:
+ * the description is computed from the flat tree, which descends into shadow
+ * content on its own.
  *
  * **The consumer writes that `aria-describedby`, and nothing here writes it for
- * them.** WebAwesome and Spectrum Web Components both do write it, with
- * `setAttribute` on the trigger at runtime, which is the one thing this library
- * declines everywhere: React rendered that element on the server without the
- * attribute and reports a mismatch it will not patch up. Two ids in the markup
- * is the whole cost of the version that is correct before any JavaScript runs.
- *
- * Because it is the consumer's line to write, it is also theirs to forget, so
- * `for` audits itself on first open and says so once, rather than on every
- * open, since a warning that repeats is one people learn to filter out.
+ * them.** Setting it at runtime is a hydration mismatch React will not patch
+ * up. `for` audits itself on first open and warns once where it is missing.
  *
  * It shows on hover and on focus, and hides on leave, on blur, on Escape, and
  * once the trigger has been activated: the hint is spent when the control has
  * been used.
- * A tooltip that answers only the pointer is one a keyboard reader never sees.
- *
- * The pointer waits out `delay` first, or sweeping a row of controls flashes a
- * tooltip for each of them. Focus does not wait: a keyboard reader landing on a
- * control has already committed to it.
- *
- * Open state comes from `MixinControllerOpen`, so it announces `helix-before-open` and
- * `helix-before-close` like every other overlay here, and a consumer can drive it with
- * `open` where they need to.
  *
  * @since 0.1.0
  * @status experimental