@fusion.dev/helix-headless 0.158.0 → 0.159.0

package/types/vue.d.ts

@@ -245,9 +245,9 @@ import type {
   HelixBeforeResizeEvent,
   HelixCollapseEvent,
   HelixResizedEvent,
+  HelixLoadEvent,
   HelixTourAskEvent,
   HelixTourStatusEvent,
-  HelixLoadEvent,
   HelixEndEvent,
   HelixNextEvent,
   HelixPreviousEvent,
@@ -530,9 +530,18 @@ export type HelixHeadlessAppHeaderElementEvent<E = Event> = TypedEvent<
   HelixHeadlessAppHeader,
   E
 >;
+/** `helix-before-close` event type */
+export type HelixHeadlessAppHeaderHelixBeforeCloseElementEvent =
+  HelixHeadlessAppHeaderElementEvent<HelixBeforeCloseEvent>;
+/** `helix-before-open` event type */
+export type HelixHeadlessAppHeaderHelixBeforeOpenElementEvent =
+  HelixHeadlessAppHeaderElementEvent<HelixBeforeOpenEvent>;
 /** `helix-scrolled` event type */
 export type HelixHeadlessAppHeaderHelixScrolledElementEvent =
   HelixHeadlessAppHeaderElementEvent<HelixScrolledEvent>;
+/** `toggle` event type */
+export type HelixHeadlessAppHeaderToggleElementEvent =
+  HelixHeadlessAppHeaderElementEvent<ToggleEvent>;
 
 export type HelixHeadlessAppHeaderVueProps = {
   /** Where the middle region sits in the bar.
@@ -582,11 +591,46 @@ page scrolls up. */
   /** The id of the element whose scrolling lifts the bar, for an app shell that
 scrolls a container instead of the window. Unset is the window. */
   scroller?: (HelixHeadlessAppHeader["scroller"]) | undefined;
+  /** Where the toggle that opens a folded middle region sits: at the end of the
+bar, after the trailing content, or with `start`, before the leading
+content.
+
+Optional, so the resting bar writes no attribute onto the host. */
+  "toggle-placement"?: (HelixHeadlessAppHeader["togglePlacement"]) | undefined;
+  /** Where the toggle that opens a folded middle region sits: at the end of the
+bar, after the trailing content, or with `start`, before the leading
+content.
+
+Optional, so the resting bar writes no attribute onto the host. */
+  togglePlacement?: (HelixHeadlessAppHeader["togglePlacement"]) | undefined;
+  /** Whether the element starts open. Ignored once `open` is written. */
+  "default-open"?: (HelixHeadlessAppHeader["defaultOpen"]) | undefined;
+  /** Whether the element starts open. Ignored once `open` is written. */
+  defaultOpen?: (HelixHeadlessAppHeader["defaultOpen"]) | undefined;
+  /** Whether the element is open.
+
+One property, not two, so `dialog.open` answers the question anyone
+asking it meant. Writing always applies; `<helix-dialog open>` is the
+same statement in markup.
+
+**Not reflected, and that is required rather than tidy.** Reflection
+writes the resolved state back as an attribute, so an element that opened
+itself would put `open` on its own host: cloned, serialized for
+hydration, or diffed by a framework, it comes back holding whatever the
+last reader did rather than what the author wrote. `:state(open)` carries
+the resolved state for stylesheets, which is what the mirror is for. */
+  open?: (HelixHeadlessAppHeader["open"]) | undefined;
 };
 
 export type HelixHeadlessAppHeaderVueEvents = {
+  /** The folded region is about to close. Cancelable: cancel it to keep it open. */
+  "helix-before-close": HelixHeadlessAppHeaderHelixBeforeCloseElementEvent;
+  /** The folded region is about to open. Cancelable: cancel it to keep it closed. */
+  "helix-before-open": HelixHeadlessAppHeaderHelixBeforeOpenElementEvent;
   /** Fired when the page crosses the scroll threshold, with the new state. A custom state cannot be observed the way an attribute can, so listen for this event to follow it. The event uses the header's own threshold and hysteresis, so you do not need a second scroll listener. */
   "helix-scrolled": HelixHeadlessAppHeaderHelixScrolledElementEvent;
+  /** The folded region opened or closed. The event carries `newState` and `oldState`. */
+  toggle: HelixHeadlessAppHeaderToggleElementEvent;
 };
 
 /** `HelixHeadlessAreaChart` component event */
@@ -1233,6 +1277,14 @@ export type HelixHeadlessButtonGroupHelixBeforeChangeElementEvent =
   HelixHeadlessButtonGroupElementEvent<HelixBeforeChangeEvent>;
 
 export type HelixHeadlessButtonGroupVueProps = {
+  /** Keeps at least one button pressed once one is, as React Aria's
+`disallowEmptySelection`: a press that would leave none pressed is
+refused. */
+  "disallow-empty-selection"?: (HelixHeadlessButtonGroup["disallowEmptySelection"]) | undefined;
+  /** Keeps at least one button pressed once one is, as React Aria's
+`disallowEmptySelection`: a press that would leave none pressed is
+refused. */
+  disallowEmptySelection?: (HelixHeadlessButtonGroup["disallowEmptySelection"]) | undefined;
   /** The group's name, read by screen readers.
 
 On the host through internals, so an author's `aria-label` still overrides
@@ -14862,7 +14914,19 @@ known by its place among the rows as written. */
 
 export type HelixHeadlessTableRowVueEvents = {};
 
+/** `HelixHeadlessTabPanel` component event */
+export type HelixHeadlessTabPanelElementEvent<E = Event> = TypedEvent<
+  HelixHeadlessTabPanel,
+  E
+>;
+/** `helix-load` event type */
+export type HelixHeadlessTabPanelHelixLoadElementEvent =
+  HelixHeadlessTabPanelElementEvent<HelixLoadEvent>;
+
 export type HelixHeadlessTabPanelVueProps = {
+  /** Whether the panel's content waits in a `<template>` until the panel is
+first shown. */
+  lazy?: (HelixHeadlessTabPanel["lazy"]) | undefined;
   /** Whether this panel is the visible one. */
   selected?: (HelixHeadlessTabPanel["selected"]) | undefined;
   /** Pairs the panel with the tab of the same value. */
@@ -14880,7 +14944,10 @@ the pattern names one anyway. */
   label?: (HelixHeadlessTabPanel["label"]) | undefined;
 };
 
-export type HelixHeadlessTabPanelVueEvents = {};
+export type HelixHeadlessTabPanelVueEvents = {
+  /** Fired the first time a `lazy` panel is shown, once its template's content is in. */
+  "helix-load": HelixHeadlessTabPanelHelixLoadElementEvent;
+};
 
 /** `HelixHeadlessTabs` component event */
 export type HelixHeadlessTabsElementEvent<E = Event> = TypedEvent<
@@ -16244,6 +16311,12 @@ consumer's server markup does not have. A sheet carries the resting
 arrangement in its own `:host` rule and the selectors describe only the
 departures, which is what `orientation` does. */
   placement?: (HelixHeadlessToast["placement"]) | undefined;
+  /** The edge a touch or a pen swipes a message toward to dismiss it: `end`,
+the end of the line, or `start`, `top` or `bottom`. Unset is `end`. */
+  "swipe-direction"?: (HelixHeadlessToast["swipeDirection"]) | undefined;
+  /** The edge a touch or a pen swipes a message toward to dismiss it: `end`,
+the end of the line, or `start`, `top` or `bottom`. Unset is `end`. */
+  swipeDirection?: (HelixHeadlessToast["swipeDirection"]) | undefined;
 };
 
 export type HelixHeadlessToastVueEvents = {
@@ -16744,6 +16817,14 @@ The shape is `Carousel`'s, which is the nearest thing in the library: a
   "next-label"?: (HelixHeadlessTour["nextLabel"]) | undefined;
   /** Label for the control that goes on. */
   nextLabel?: (HelixHeadlessTour["nextLabel"]) | undefined;
+  /** What a press outside the current stop and its target does while the tour
+runs. Unset, nothing: the page stays usable. `close` ends the tour, as
+Skip does, and `block` refuses the press. */
+  "outside-press"?: (HelixHeadlessTour["outsidePress"]) | undefined;
+  /** What a press outside the current stop and its target does while the tour
+runs. Unset, nothing: the page stays usable. `close` ends the tour, as
+Skip does, and `block` refuses the press. */
+  outsidePress?: (HelixHeadlessTour["outsidePress"]) | undefined;
   /** Draws each stop's place in the run in its panel, as well as saying it. */
   progress?: (HelixHeadlessTour["progress"]) | undefined;
   /** Each stop's place in the run, with `{index}` and `{count}` filled in and
@@ -16852,6 +16933,9 @@ heading. */
 Reflected, because the styled tier places a dialog and a floating panel by
 it, and unset at rest, so no default is written onto the host. */
   type?: (HelixHeadlessTourStop["type"]) | undefined;
+  /** Run as the tour reaches the stop, before it is shown: see the description
+above. A function, so it is set from script and has no attribute. */
+  effect?: (HelixHeadlessTourStop["effect"]) | undefined;
 };
 
 export type HelixHeadlessTourStopVueEvents = {
@@ -18128,6 +18212,8 @@ export type CustomCssProperties = {
   "--toast-duration"?: (string) | undefined;
   /** How far a swipe has moved the message across, in pixels, toward the right. */
   "--toast-swipe-x"?: (string) | undefined;
+  /** How far a swipe has moved the message down, in pixels, under a `swipe-direction` of `top` or `bottom`. */
+  "--toast-swipe-y"?: (string) | undefined;
   /** The lit box's height, in pixels, padding included. Written on the spotlight while it lights a target. */
   "--tour-spotlight-height"?: (string) | undefined;
   /** The lit box's width, in pixels, padding included. Written on the spotlight while it lights a target. */
@@ -18168,7 +18254,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessAnnouncementVueProps,
     HelixHeadlessAnnouncementVueEvents
   >;
-  /** Tracks whether the page has scrolled and sets the custom state 'scrolled', so the styled tier can lift the bar without a scroll handler of its own. The state is read when the element connects. A fresh load starts at the top, which matches the server markup, and a reload partway down the page is corrected on hydration.  The element uses a custom state because an attribute such as 'data-scrolled', written onto its own host, is one the server did not send. A hydrating framework would report a mismatch whenever the page reloads far enough down. 'ElementInternals.states' is not in the DOM, so hydration has nothing to compare. Select the state with ':state(scrolled)'.  The page is the window unless 'scroller' names the element that scrolls, for an app shell whose content scrolls inside a container.  **Set 'hide-on-scroll' for a bar that moves out of the way.** Scrolling down past the bar's own height hides it, and scrolling up shows it again, as does focus moving into it. The custom state 'hidden' is on the host while it is hidden, and the styled tier slides a 'sticky' bar up out of view.  **Set 'fold-below' to fold the middle region on a narrow screen.** Below that many pixels of the bar's own width, the middle region is hidden behind a toggle at the end of the bar, named by 'menu-label'. The toggle says whether the region is open with 'aria-expanded', and the region opens below the row. Escape closes it and puts focus back on the toggle. The custom state 'folded' is on the host while the bar is that narrow, and 'open' while the folded region is open. A server serves the bar unfolded, and the browser folds it once it has measured it.  The host is the page's 'banner' landmark. Placed inside 'main', 'article', 'aside', 'nav' or 'section', it is a plain box instead, as a native '<header>' is there, so a header inside a card or a pane does not add a second banner. The ancestors are read as the accessibility tree reads them, through the slots that take the header in, so one slotted into a component that draws a '<nav>', such as 'Navigation', is not a banner either. A server cannot see the ancestors, so it serves the banner and the browser corrects it when the element connects. */
+  /** Tracks whether the page has scrolled and sets the custom state 'scrolled', so the styled tier can lift the bar without a scroll handler of its own. The state is read when the element connects. A fresh load starts at the top, which matches the server markup, and a reload partway down the page is corrected on hydration.  The element uses a custom state because an attribute such as 'data-scrolled', written onto its own host, is one the server did not send. A hydrating framework would report a mismatch whenever the page reloads far enough down. 'ElementInternals.states' is not in the DOM, so hydration has nothing to compare. Select the state with ':state(scrolled)'.  The page is the window unless 'scroller' names the element that scrolls, for an app shell whose content scrolls inside a container.  **Set 'hide-on-scroll' for a bar that moves out of the way.** Scrolling down past the bar's own height hides it, and scrolling up shows it again, as does focus moving into it. The custom state 'hidden' is on the host while it is hidden, and the styled tier slides a 'sticky' bar up out of view.  **Set 'fold-below' to fold the middle region on a narrow screen.** Below that many pixels of the bar's own width, the middle region is hidden behind a toggle at the end of the bar, named by 'menu-label', or at its start with 'toggle-placement="start"'. The toggle says whether the region is open with 'aria-expanded', and the region opens below the row. The region follows the toggle's region in focus order, so Tab from the toggle at the end goes into the open region. The custom state 'folded' is on the host while the bar is that narrow, and 'open' while the folded region is open. A server serves the bar unfolded, and the browser folds it once it has measured it.  **'open' says whether the folded region is open, and setting it opens or closes the region.** 'requestOpen(true)' and 'requestOpen(false)' do the same and send 'helix-before-open' or 'helix-before-close' first, which you can cancel, and 'toggleOpen()' asks for the opposite. 'toggle' follows every change. The region closes on Escape, which puts focus back on the toggle, when focus moves to something outside the header, and on a press outside it. A bar that widens past 'fold-below' closes its region.  The host is the page's 'banner' landmark. Placed inside 'main', 'article', 'aside', 'nav' or 'section', it is a plain box instead, as a native '<header>' is there, so a header inside a card or a pane does not add a second banner. The ancestors are read as the accessibility tree reads them, through the slots that take the header in, so one slotted into a component that draws a '<nav>', such as 'Navigation', is not a banner either. A server cannot see the ancestors, so it serves the banner and the browser corrects it when the element connects. */
   "helix-headless-app-header": DefineCustomElement<
     HelixHeadlessAppHeader,
     HelixHeadlessAppHeaderVueProps,
@@ -18222,7 +18308,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessBreadcrumbsVueProps,
     HelixHeadlessBreadcrumbsVueEvents
   >;
-  /** Sets 'role="group"' on the host through internals, and 'label' names the group. Without a name, a screen reader announces the buttons as separate controls, and a development build warns once with the kind 'missing-name'.  The group does not manage focus, so each button keeps its own tab stop. For one tab stop with arrow keys between a mix of controls, the APG toolbar pattern, use Toolbar.  Buttons are slotted, so they stay your own elements and keep their own appearance and size.  **Buttons that stay pressed.** With 'selection-mode', each button with a 'value' is a toggle button: a press presses or releases it, and it says so with 'aria-pressed'. 'single' keeps one pressed at a time, and a press on the pressed one releases it. 'multiple' lets any number be pressed. 'value' is the pressed values, comma separated. A press sends a cancelable 'helix-before-change' with the value it would leave, then 'change'.  The pressed state is written on the control inside each button's shadow root, so the markup you rendered is never changed and a framework hydrating it sees what its server sent. That is also why only Helix buttons are toggles: a native '<button>' or a button without a 'value' stays a plain action button in the group, and a native one without its own 'aria-pressed' warns once, with the runtime kind 'untold-toggle'. The inner control also carries '--button-group-pressed', '1' or '0', for a '::part(button)' rule of yours.  Use Toggle Group instead for a choice that belongs in a form, or one where the arrow keys choose as they move: it is a 'radiogroup' of options with a form value, 'required' and validation. A Button Group in a selection mode is a set of actions that stay on, such as bold and italic, or a view that a press switches, and it submits nothing.  **Keyboard.** In a selection mode the group is one tab stop: the button focus was last on, then the first pressed one, then the first one.  | Key | What it does | |---|---| | Right, Down | Moves to the next button, from the last back to the first. | | Left, Up | Moves to the button before, from the first round to the last. | | Home, End | Moves to the first or the last button. | | Space, Enter | Presses or releases the focused button. |  Left and Right swap on a right-to-left page, and a disabled button is passed over. In a selection mode the group is a 'toolbar', with 'aria-orientation' under 'orientation="vertical"'. Inside a toolbar it stays a named 'group', and the toolbar's own arrow keys walk its buttons, so a reader meets one toolbar. */
+  /** Sets 'role="group"' on the host through internals, and 'label' names the group. Without a name, a screen reader announces the buttons as separate controls, and a development build warns once with the kind 'missing-name'.  The group does not manage focus, so each button keeps its own tab stop. For one tab stop with arrow keys between a mix of controls, the APG toolbar pattern, use Toolbar.  Buttons are slotted, so they stay your own elements and keep their own appearance and size.  **Buttons that stay pressed.** With 'selection-mode', each button with a 'value' is a toggle button: a press presses or releases it. 'multiple' lets any number be pressed, and each button says so with 'aria-pressed'. 'single' keeps one pressed at a time: the group is a 'radiogroup' and each button a 'radio' that says so with 'aria-checked', as React Aria's toggle button group is. A press on the pressed one releases it, unless 'disallow-empty-selection' keeps one pressed. 'value' is the pressed values, comma separated. A press sends a cancelable 'helix-before-change' with the value it would leave, then 'change'. A pressed Helix button has ':state(pressed)' on its own element.  The pressed state is written on the control inside each button's shadow root, so the markup you rendered is never changed and a framework hydrating it sees what its server sent. That is also why only Helix buttons are toggles: a native '<button>' or a button without a 'value' stays a plain action button in the group, and a native one without its own 'aria-pressed' warns once, with the runtime kind 'untold-toggle'. The inner control also carries '--button-group-pressed', '1' or '0', for a '::part(button)' rule of yours.  Use Toggle Group instead for a choice that belongs in a form, or one where the arrow keys choose as they move: it is a 'radiogroup' of options with a form value, 'required' and validation. A Button Group in a selection mode is a set of actions that stay on, such as bold and italic, or a view that a press switches, and it submits nothing.  **Keyboard.** In a selection mode the group is one tab stop: the button focus was last on, then the first pressed one, then the first one.  | Key | What it does | |---|---| | Right, Down | Moves to the next button, from the last back to the first. | | Left, Up | Moves to the button before, from the first round to the last. | | Home, End | Moves to the first or the last button. | | Space, Enter | Presses or releases the focused button. |  Left and Right swap on a right-to-left page, and a disabled button is passed over. Under 'multiple' the group is a 'toolbar', with 'aria-orientation' under 'orientation="vertical"'. Inside a toolbar it stays a named 'group', and the toolbar's own arrow keys walk its buttons, so a reader meets one toolbar. Under 'single' it is a 'radiogroup' either way. */
   "helix-headless-button-group": DefineCustomElement<
     HelixHeadlessButtonGroup,
     HelixHeadlessButtonGroupVueProps,
@@ -18504,13 +18590,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessLegendVueProps,
     HelixHeadlessLegendVueEvents
   >;
-  /** Wraps one piece of content in the lightbox, such as a picture, a video frame, or a chart. The lightbox shows one item at a time, and the root decides which.  Each item is a 'group' with the role description 'slide', named by its 'label' or, without one, by its place in the set, such as "2 of 5", as the APG carousel pattern names a slide. The lightbox supplies both words, so they are translated on the lightbox.  An item that is not current is hidden and stays in the DOM, as a 'TabPanel' does. Crawlers can read it, it is in the server-rendered markup, and an '<img>' that has decoded does not decode again when you go back to it. */
+  /** Wraps one piece of content in the lightbox, such as a picture, a video frame, or a chart. The lightbox shows one item at a time, and the root decides which.  Each item is a 'group' with the role description 'slide', named by its 'label' or, without one, by its place in the set, such as "2 of 5", as the APG carousel pattern names a slide. The lightbox supplies both words, so they are translated on the lightbox. A 'description', while there is one, describes the group, so a screen reader says it with the name.  An item that is not current is hidden and stays in the DOM, as a 'TabPanel' does. Crawlers can read it, it is in the server-rendered markup, and an '<img>' that has decoded does not decode again when you go back to it. */
   "helix-headless-lightbox-item": DefineCustomElement<
     HelixHeadlessLightboxItem,
     HelixHeadlessLightboxItemVueProps,
     HelixHeadlessLightboxItemVueEvents
   >;
-  /** The frame around content you open, such as a picture, a video frame, or a chart. The lightbox draws no content of its own. It provides the frame, the keyboard behavior, and text that states the current position in the set.  The modal behavior comes from a native '<dialog>' opened with 'showModal()', which provides the top layer, a backdrop, Escape to close, and 'inert' on the rest of the document. Every way of closing goes through 'requestOpen', as in 'Dialog' and 'Drawer'.  A lightbox shows one item at a time and has no scrolling track, so 'active' holds the current item, as in 'Tabs'. The arrow keys change the item while focus stays in the dialog.  Set 'controls' for the viewer's own previous, next and close controls, named by 'previous-label', 'next-label' and 'dismiss-label', whose glyphs you can replace in the 'previous-icon', 'next-icon' and 'dismiss-icon' slots. Without it, compose the chrome yourself in the 'header' and 'footer' slots, with buttons that send '--previous', '--next' and '--close'.  **Set 'max-zoom' to let a reader zoom into the shown item**, such as '3'. Two fingers pinch it, a double click or a double tap zooms all the way in about the point pressed and back out, and once zoomed one pointer drags it about. '+' and '-' zoom in and out from the keyboard, and '0' puts it back. The scale and the offset are on the 'viewport' part as '--lightbox-zoom', '--lightbox-pan-x' and '--lightbox-pan-y', written only while zoomed, and a swipe moves to the next item only while the item is at its own size. With 'controls', the viewer also draws zoom-out and zoom-in controls, for a pointer with no wheel and no second finger. Once a reader stops zooming, the live region says the new scale in the words of 'zoom-status-label', such as "Zoomed to 150%".  Each item is a slide: a 'group' with the role description in 'slide-role-label', named by its 'label' or by 'slide-label'. A touch or a pen swiped across the picture shows the next or the previous item, the way the line of text runs.  A press on the empty area around the item closes the viewer, as a press on the backdrop does. Under 'max-zoom', a press beside the item zooms on a double press and closes nothing, and only the space outside the viewport closes the viewer. A press that dragged closes nothing.  **Keyboard.** Opening moves focus to the viewer itself, which a screen reader names.  | Key | What it does | |---|---| | Right, Down | Shows the next item. On a right-to-left page, Left does. While the item is zoomed, the arrows move about it instead. | | Left, Up | Shows the previous item. | | Home, End | Shows the first or the last item. | | '+', '-', '0' | Zooms in, zooms out, and puts the item back at its own size, where 'max-zoom' allows zooming. | | Tab, Shift+Tab | Moves through the controls in the viewer, from the last round to the first and from the first round to the last. | | Escape | Closes the viewer. A 'helix-before-close' listener can refuse. |  A development build warns when a viewer opens with no 'label'.  The chrome hides when there is no input, through 'IdleController', and comes back on a pointer move, a key press, or a focus. It stays while focus is on a control in the header or the footer, so a keyboard reader is never left on a control that has gone. 'fullscreen' uses 'FullscreenController', as 'Video' does. While the viewer is open, the page behind it does not scroll. */
+  /** The frame around content you open, such as a picture, a video frame, or a chart. The lightbox draws no content of its own. It provides the frame, the keyboard behavior, and text that states the current position in the set.  The modal behavior comes from a native '<dialog>' opened with 'showModal()', which provides the top layer, a backdrop, Escape to close, and 'inert' on the rest of the document. Every way of closing goes through 'requestOpen', as in 'Dialog' and 'Drawer'.  A lightbox shows one item at a time and has no scrolling track, so 'active' holds the current item, as in 'Tabs'. The arrow keys change the item while focus stays in the dialog.  Set 'controls' for the viewer's own previous, next and close controls, named by 'previous-label', 'next-label' and 'dismiss-label', whose glyphs you can replace in the 'previous-icon', 'next-icon' and 'dismiss-icon' slots. Without it, compose the chrome yourself in the 'header' and 'footer' slots, with buttons that send '--previous', '--next' and '--close'.  **Set 'max-zoom' to let a reader zoom into the shown item**, such as '3'. Two fingers pinch it, and so does a trackpad pinch or the wheel with Ctrl held, about the point under the pointer. A double click or a double tap zooms all the way in about the point pressed and back out, and once zoomed one pointer drags it about and the wheel moves it. '+' and '-' zoom in and out from the keyboard, and '0' puts it back. The scale and the offset are on the 'viewport' part as '--lightbox-zoom', '--lightbox-pan-x' and '--lightbox-pan-y', written only while zoomed, and a swipe moves to the next item only while the item is at its own size. With 'controls', the viewer also draws zoom-out and zoom-in controls, for a pointer with no wheel and no second finger. Once a reader stops zooming, the live region says the new scale in the words of 'zoom-status-label', such as "Zoomed to 150%".  Each item is a slide: a 'group' with the role description in 'slide-role-label', named by its 'label' or by 'slide-label'. A touch or a pen swiped across the picture shows the next or the previous item, the way the line of text runs.  A press on the empty area around the item closes the viewer, as a press on the backdrop does. Under 'max-zoom', a press beside the item zooms on a double press and closes nothing, and only the space outside the viewport closes the viewer. A press that dragged closes nothing.  **Keyboard.** Opening moves focus to the viewer itself, which a screen reader names.  | Key | What it does | |---|---| | Right, Down | Shows the next item. On a right-to-left page, Left does. While the item is zoomed, the arrows move about it instead. | | Left, Up | Shows the previous item. | | Home, End | Shows the first or the last item. | | '+', '-', '0' | Zooms in, zooms out, and puts the item back at its own size, where 'max-zoom' allows zooming. | | Tab, Shift+Tab | Moves through the controls in the viewer, from the last round to the first and from the first round to the last. | | Escape | Closes the viewer. A 'helix-before-close' listener can refuse. |  A development build warns when a viewer opens with no 'label'.  The chrome hides when there is no input, through 'IdleController', and comes back on a pointer move, a key press, or a focus. It stays while focus is on a control in the header or the footer, so a keyboard reader is never left on a control that has gone. 'fullscreen' uses 'FullscreenController', as 'Video' does. While the viewer is open, the page behind it does not scroll. */
   "helix-headless-lightbox": DefineCustomElement<
     HelixHeadlessLightbox,
     HelixHeadlessLightboxVueProps,
@@ -18852,7 +18938,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessStepsVueProps,
     HelixHeadlessStepsVueEvents
   >;
-  /** Only the step's name is a button. The marker is 'aria-hidden' decoration, so it is outside the button. The name uses 'Button', so the hover wash, the focus ring, and the disabled style come from 'Button'.  Every step can be pressed and fires 'helix-select'. To stop the user from moving to a step, set 'disabled' on it.  The marker is a slot, and its fallback shows the step's state: a check for a finished stage, a target for the current stage, and an empty ring for a stage not reached yet. Only that one mark is rendered, so the accessibility tree has no hidden marks.  The half lines on each side of the mark are drawn on the step's '::before' and '::after' from properties the list sets, so the step renders no extra element for them.  A finished stage says so in words: the name's button is described by 'complete-label', "Complete" unless you translate it, and a stage that becomes complete while the page is open says it once in a polite live region. The current stage's button carries 'aria-current="step"', and only the button, so the state is said once, on the control. */
+  /** Only the step's name is a button. The marker is 'aria-hidden' decoration, so it is outside the button. The name uses 'Button', so the hover wash, the focus ring, and the disabled style come from 'Button'.  Every step can be pressed and fires 'helix-select'. To stop the user from moving to a step, set 'disabled' on it.  The marker is a slot, and its fallback shows the step's state: a check for a finished stage, a target for the current stage, and an empty ring for a stage not reached yet. Only that one mark is rendered, so the accessibility tree has no hidden marks.  The half lines on each side of the mark are drawn on the step's '::before' and '::after' from properties the list sets, so the step renders no extra element for them.  A finished stage says so in words: the name's button is described by 'complete-label', "Complete" unless you translate it, and a stage that becomes complete while the page is open says it once in a polite live region. The current stage's button carries 'aria-current="step"', and only the button, so the state is said once, on the control.  A stage's 'content', while it holds anything, is a group named by the stage's name, so a screen reader moving into it hears which stage it belongs to. */
   "helix-headless-step": DefineCustomElement<
     HelixHeadlessStep,
     HelixHeadlessStepVueProps,
@@ -18888,19 +18974,19 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTableRowVueProps,
     HelixHeadlessTableRowVueEvents
   >;
-  /** An inactive panel is hidden and stays mounted. Anything typed into it is still there when the person comes back, and the content of every panel is in the server-rendered markup for crawlers, whichever tab is open.  The host is the 'tabpanel' while its tab is selected, through 'ElementInternals', so the tab's 'aria-controls' can reach it from the tab's shadow root. The box inside is a tab stop only while the panel holds nothing focusable, as the ARIA tabs pattern and React Aria's tab panel do: Tab from the tab list lands on the panel's first link or control where there is one, and on the panel itself where there is none. */
+  /** An inactive panel is hidden and stays mounted. Anything typed into it is still there when the person comes back, and the content of every panel is in the server-rendered markup for crawlers, whichever tab is open.  The host is the 'tabpanel' while its tab is selected, through 'ElementInternals', so the tab's 'aria-controls' can reach it from the tab's shadow root. The box inside is a tab stop only while the panel holds nothing focusable, as the ARIA tabs pattern and React Aria's tab panel do: Tab from the tab list lands on the panel's first link or control where there is one, and on the panel itself where there is none.  **Set 'lazy' for a panel that is expensive to draw.** Its content waits in a '<template>' inside it, and goes into the panel the first time the panel is shown, so it costs nothing until a reader opens that tab. Once in, it stays. The panel sends 'helix-load' at the same moment, for content your code renders itself. */
   "helix-headless-tab-panel": DefineCustomElement<
     HelixHeadlessTabPanel,
     HelixHeadlessTabPanelVueProps,
     HelixHeadlessTabPanelVueEvents
   >;
-  /** Selection works through an event, the same as in the accordion and the tree. A tab dispatches 'helix-select', and the root pairs it with the panel of the same value. Nothing registers with anything, so tabs added later work with no extra setup.  The tab list is a single tab stop, and the arrow keys move between tabs through 'KeyboardNavigationController', the same as in the radio and toggle groups. Selection follows focus, which suits a small set where showing a panel is cheap. Set 'manual' when showing a panel is expensive, so focus can move without selecting.  'orientation="vertical"' sets the tabs in a column beside the panels, and the tab list says 'aria-orientation="vertical"'. The arrow keys of both axes move between tabs either way.  A tab with an 'href' is a link, for tabs that are pages of a site. Pressing it follows the link. Where any tab is a link, the arrow keys move focus without choosing on every tab of the list, as under 'manual', so arrowing past a tab never leaves the page and the list answers the keys one way. Mark the tab of the page you are on with 'selected', or set 'active' to its value.  Each tab says which panel it controls through 'aria-controls', set as an element reference to the panel's host, where the engine has reflection.  Keys, on the tab list: Left and Right Arrow move between tabs, and so do Up and Down; Home and End go to the first and the last. The horizontal arrows follow the reading direction, so on a right-to-left page Left moves on. Disabled tabs are passed over. Tab leaves the list for the selected panel, which is a tab stop only while it holds nothing focusable.  **Keyboard.**  | Key | What it does | |---|---| | Right, Down | Moves to the next tab, from the last round to the first. Selects it, unless 'manual' is set or a tab is a link. | | Left, Up | Moves to the tab before, from the first round to the last. | | Home, End | Moves to the first or the last tab. | | Enter, Space | Selects the tab with focus, or follows its link. | | Tab | Leaves the list for the selected panel. |  Removing the selected tab selects the first enabled tab that is left, and 'active' says so, with 'helix-activate'. Where the removed tab had focus, focus moves to the tab now selected.  **More tabs than fit.** With 'scroll-controls', a strip that scrolls shows a button at each end it can scroll toward, as Web Awesome's tab group does, and a press scrolls it most of its own length. The buttons are for the pointer, so they are out of the tab order and hidden from screen readers; the arrow keys already reach every tab, and the strip scrolls the selected tab into view. A strip scrolls once a stylesheet gives the 'tabs' part an 'overflow', as the styled tier does.  A tab with 'dismissible' can be closed: see 'Tabs.Tab'.  The 'indicator' part moves to the selected tab and carries its place and size, so a mark of your own can be drawn there: style the part, or slot an element into 'indicator', which sits inside the part and reads the same properties. */
+  /** Selection works through an event, the same as in the accordion and the tree. A tab dispatches 'helix-select', and the root pairs it with the panel of the same value. Nothing registers with anything, so tabs added later work with no extra setup.  The tab list is a single tab stop, and the arrow keys move between tabs through 'KeyboardNavigationController', the same as in the radio and toggle groups. Selection follows focus, which suits a small set where showing a panel is cheap. Set 'manual' when showing a panel is expensive, so focus can move without selecting.  'orientation="vertical"' sets the tabs in a column beside the panels, and the tab list says 'aria-orientation="vertical"'. The arrow keys of both axes move between tabs either way.  A tab with an 'href' is a link, for tabs that are pages of a site. Pressing it follows the link. Where any tab is a link, the arrow keys move focus without choosing on every tab of the list, as under 'manual', so arrowing past a tab never leaves the page and the list answers the keys one way. Mark the tab of the page you are on with 'selected', or set 'active' to its value.  Each tab says which panel it controls through 'aria-controls', set as an element reference to the panel's host, where the engine has reflection.  Keys, on the tab list: Left and Right Arrow move between tabs, and so do Up and Down; Home and End go to the first and the last. The horizontal arrows follow the reading direction, so on a right-to-left page Left moves on. Disabled tabs are passed over. Tab leaves the list for the selected panel, which is a tab stop only while it holds nothing focusable.  **Keyboard.**  | Key | What it does | |---|---| | Right, Down | Moves to the next tab, from the last round to the first. Selects it, unless 'manual' is set or a tab is a link. | | Left, Up | Moves to the tab before, from the first round to the last. | | Home, End | Moves to the first or the last tab. | | Enter, Space | Selects the tab with focus, or follows its link. | | Tab | Leaves the list for the selected panel. |  Removing the selected tab selects the enabled tab beside it, the next one or else the one before, and 'active' says so, with 'helix-activate'. Where the removed tab had focus, focus moves to the tab now selected.  **More tabs than fit.** With 'scroll-controls', a strip that scrolls shows a button at each end it can scroll toward, as Web Awesome's tab group does, and a press scrolls it most of its own length. The buttons are for the pointer, so they are out of the tab order and hidden from screen readers; the arrow keys already reach every tab, and the strip scrolls the selected tab into view. A strip scrolls once a stylesheet gives the 'tabs' part an 'overflow', as the styled tier does.  A tab with 'dismissible' can be closed: see 'Tabs.Tab'.  The 'indicator' part moves to the selected tab and carries its place and size, so a mark of your own can be drawn there: style the part, or slot an element into 'indicator', which sits inside the part and reads the same properties. */
   "helix-headless-tabs": DefineCustomElement<
     HelixHeadlessTabs,
     HelixHeadlessTabsVueProps,
     HelixHeadlessTabsVueEvents
   >;
-  /** A tab is an element, because it manages selection and its own tab stop.  With an 'href', the tab is a link: 'role="tab"' on an '<a>', which a press, Enter and the browser's own link gestures follow. 'helix-select' is sent first, and canceling it keeps the browser from following, so a client-side router follows it instead.  With 'dismissible', the tab can be closed, as Web Awesome's closable tab can: a press on its 'dismiss' mark, or Delete or Backspace while the tab has focus, sends 'helix-dismiss'. The tab does not remove itself, because your code owns the set, so remove the tab and its panel in your handler. Focus moves to the tab beside it, and the tab set selects a tab that is left. The tab says the key through 'aria-keyshortcuts', and the mark is for the pointer, hidden from screen readers. */
+  /** A tab is an element, because it manages selection and its own tab stop.  With an 'href', the tab is a link: 'role="tab"' on an '<a>', which a press, Enter and the browser's own link gestures follow. 'helix-select' is sent first, and canceling it keeps the browser from following, so a client-side router follows it instead.  With 'dismissible', the tab can be closed, as Web Awesome's closable tab can: a press on its 'dismiss' mark, or Delete or Backspace while the tab has focus, sends 'helix-dismiss'. The tab does not remove itself, because your code owns the set, so remove the tab and its panel in your handler. Focus moves to the tab beside it, and where the tab was selected, the tab set selects that same tab. The tab says the key through 'aria-keyshortcuts', and the mark is for the pointer, hidden from screen readers. */
   "helix-headless-tab": DefineCustomElement<
     HelixHeadlessTab,
     HelixHeadlessTabVueProps,
@@ -18954,13 +19040,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTimelineVueProps,
     HelixHeadlessTimelineVueEvents
   >;
-  /** Each message is an element because it has a timeout, a tone, a dismiss control, and a lifetime that pauses.  **Each item runs its own timer.** A timer held by the region would restart with each new message, and the last of three messages would stay for nine seconds. It pauses while the pointer or focus is on the message, and while the page is hidden, so a message is not spent in a background tab.  **Each message is an 'alertdialog' named by its words**, which is how a reader who moves into the stack hears which message they are on. Give it a 'heading' and a 'description', and the heading names it and the description describes it, for a message with a title and a line of detail. The region says each message once as it arrives, a 'danger' one assertively, so a message is never a live region of its own.  A touch or a pen swipes a message toward the end of the line, and past halfway, or quickly, dismisses it through the same 'helix-dismiss' as its control. While it moves, the distance is on the 'item' part as '--toast-swipe-x'.  **Escape dismisses the message holding focus**, through the same 'helix-dismiss', and focus moves to the next message.  **Messages are inverted by default.** The item flips 'color-scheme', so a new message stands out from the page without using a color that carries meaning. */
+  /** Each message is an element because it has a timeout, a tone, a dismiss control, and a lifetime that pauses.  **Each item runs its own timer.** A timer held by the region would restart with each new message, and the last of three messages would stay for nine seconds. It pauses while the pointer or focus is on the message or anywhere in the region's stack, and while the page is hidden, so a message is not spent in a background tab.  **Each message is an 'alertdialog' named by its words**, which is how a reader who moves into the stack hears which message they are on. Give it a 'heading' and a 'description', and the heading names it and the description describes it, for a message with a title and a line of detail. The region says each message once as it arrives, a 'danger' one assertively, so a message is never a live region of its own.  A touch or a pen swipes a message toward the end of the line, or toward the edge the region's 'swipe-direction' names, and past halfway, or quickly, dismisses it through the same 'helix-dismiss' as its control. While it moves, the distance is on the 'item' part as '--toast-swipe-x' or '--toast-swipe-y'.  **Escape dismisses the message holding focus**, through the same 'helix-dismiss', and focus moves to the next message.  **Messages are inverted by default.** The item flips 'color-scheme', so a new message stands out from the page without using a color that carries meaning. */
   "helix-headless-toast-item": DefineCustomElement<
     HelixHeadlessToastItem,
     HelixHeadlessToastItemVueProps,
     HelixHeadlessToastItemVueEvents
   >;
-  /** The region and its items are one family because a live region must be in the document before a message is added to it. Assistive technology often does not announce a region that arrives already holding its message. 'Radio.Group' is part of its family for the same reason.  **The region is a landmark named by 'label', and it says each message once as it arrives**: a 'danger' message assertively, and every other one politely. It says the word for the tone, the heading, the description and the text, and not the actions, through two live regions of its own, the 'live' parts, which it empties again a moment later. The stack itself is not a live region, so a message is never said twice, and changing the words of a message already showing says nothing. Each message is an 'alertdialog' named by its words, so a reader who moves into the stack hears which message they are on.  **'hotkey' takes focus to the stack and back**, F8 unless you set it, and 'label' says which key: '{hotkey}' in it is filled in, so the default name is "Notifications (F8)". Pressed while focus is in the stack, it gives focus back to where it was.  **The region never creates or removes items.** You render items and remove them. An item requests closing with a cancelable 'helix-dismiss' event. A dismissed item hides itself and stays in the DOM, so your framework's state and the DOM stay in sync. It hides on its own unless you set 'open', which makes the state yours.  **'add()' shows a message from script**, for a page with no framework state to render them from: it appends a message of the region's own tier and removes it once it has been dismissed and has finished leaving. Messages you render yourself stay yours, and the region never removes them. A touch or a pen swipes a message away toward the end of the line.  **The stack is in the top layer.** The 'region' part is a 'popover="manual"' shown while a message is showing, and shown again above a modal dialog that opened after it. Position the 'region' part, which is the box in the top layer. While a modal 'Dialog', 'Drawer' or 'Lightbox' is open, the browser makes everything outside it inert, the stack included, so a message stays visible and its actions cannot be pressed. Where the browser has 'ariaNotify', a message that arrives then is announced through it. For a message with an action, render a second region inside the dialog.  When a message with focus inside it is dismissed, focus moves to the next message, then the one before it, then back to where it was before it entered the stack.  **'max-visible' limits how many messages show at once**, as Zag's 'max' does. The messages after that many, in document order, wait: each is hidden, its timer has not started, and the region says it once it shows, when a message before it goes. A waiting message has ':state(waiting)'.  **Keyboard.**  | Key | What it does | |---|---| | F8, or your 'hotkey' | Moves focus to the first control in the stack, and back to where it was when pressed in the stack. | | Tab, Shift+Tab | Moves between the controls of the messages. | | Escape | Dismisses the message holding focus. Focus moves to the next message, then the one before it, then back to where it was. | */
+  /** The region and its items are one family because a live region must be in the document before a message is added to it. Assistive technology often does not announce a region that arrives already holding its message. 'Radio.Group' is part of its family for the same reason.  **The region is a landmark named by 'label', and it says each message once as it arrives**: a 'danger' message assertively, and every other one politely. It says the word for the tone, the heading, the description and the text, and not the actions, through two live regions of its own, the 'live' parts, which it empties again a moment later. The stack itself is not a live region, so a message is never said twice, and changing the words of a message already showing says nothing. Each message is an 'alertdialog' named by its words, so a reader who moves into the stack hears which message they are on.  **'hotkey' takes focus to the stack and back**, F8 unless you set it, and 'label' says which key: '{hotkey}' in it is filled in, so the default name is "Notifications (F8)". Pressed while focus is in the stack, it gives focus back to where it was.  **The region never creates or removes items.** You render items and remove them. An item requests closing with a cancelable 'helix-dismiss' event. A dismissed item hides itself and stays in the DOM, so your framework's state and the DOM stay in sync. It hides on its own unless you set 'open', which makes the state yours.  **'add()' shows a message from script**, for a page with no framework state to render them from: it appends a message of the region's own tier and removes it once it has been dismissed and has finished leaving. Messages you render yourself stay yours, and the region never removes them. A touch or a pen swipes a message away toward the end of the line, or toward the edge 'swipe-direction' names.  **Every message's timer waits while a pointer or focus is in the stack**, as React Aria's and Radix's regions do, so a reader moving from one message to the next does not lose the one behind them.  **The stack is in the top layer.** The 'region' part is a 'popover="manual"' shown while a message is showing, and shown again above a modal dialog that opened after it. Position the 'region' part, which is the box in the top layer. While a modal 'Dialog', 'Drawer' or 'Lightbox' is open, the browser makes everything outside it inert, the stack included, so a message stays visible and its actions cannot be pressed. Where the browser has 'ariaNotify', a message that arrives then is announced through it. For a message with an action, render a second region inside the dialog.  When a message with focus inside it is dismissed, focus moves to the next message, then the one before it, then back to where it was before it entered the stack.  **'max-visible' limits how many messages show at once**, as Zag's 'max' does. The messages after that many, in document order, wait: each is hidden, its timer has not started, and the region says it once it shows, when a message before it goes. A waiting message has ':state(waiting)'.  **Keyboard.**  | Key | What it does | |---|---| | F8, or your 'hotkey' | Moves focus to the first control in the stack, and back to where it was when pressed in the stack. | | Tab, Shift+Tab | Moves between the controls of the messages. | | Escape | Dismisses the message holding focus. Focus moves to the next message, then the one before it, then back to where it was. | */
   "helix-headless-toast": DefineCustomElement<
     HelixHeadlessToast,
     HelixHeadlessToastVueProps,
@@ -18990,13 +19076,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTooltipVueProps,
     HelixHeadlessTooltipVueEvents
   >;
-  /** The root holds the order of the stops: which stop is current, what Next and Back do, and when the tour is finished. Each stop holds its target, and you write all the text.  **The spotlight is a shadow.** The scrim is a box the size of the current target with a very large 'box-shadow' spread, and the shadow paints the darkness. A 'clip-path' on a full-screen scrim breaks as soon as an element between the scrim and the viewport is transformed.  The root measures the target's position in the browser. Nothing is measured on the server, because a tour starts only on request.  'open', 'default-open', 'helix-before-open', 'helix-before-close' and 'toggle' work as they do on 'Dialog'. Setting 'open' starts the run, and 'skip()' and 'requestOpen(false)' end it early.  The box the light falls on is on the 'spotlight' part as '--tour-spotlight-x', '--tour-spotlight-y', '--tour-spotlight-width' and '--tour-spotlight-height', for a sheet that draws its own light, such as a ring around the target.  Each stop is told its place in the run, from 'progress-label', such as "2 of 5". It describes the stop's panel, so a screen reader says it at every stop, and 'progress' draws it in the panel as well. A dialog or a floating stop, which has nothing to light, is shown over the 'backdrop' part. At a 'wait' stop the run waits for that stop's target to be on the page, and moves on by itself.  **Focus follows the run.** Opening moves focus to the first stop's panel, and moving on from a control in a stop moves it to the next one. Ending the tour puts focus back on the element that had it when the tour opened, unless you have moved it somewhere else on the page. A stop does not trap focus, so you can still 'Tab' out to the element it describes.  **The target is scrolled into view** before its stop is shown, by the least distance that brings it on screen, so the stop that points at it is on screen too.  **Keyboard.** Focus is on the current stop's panel, which is not in the 'Tab' order itself.  | Key | What it does | |---|---| | Right | Goes to the next stop. On the last stop it does nothing, and Next finishes the tour. | | Left | Goes back to the previous stop. | | Escape | Skips the tour, and puts focus back where it was when the tour opened. | | Tab, Shift+Tab | Moves through the controls in the stop, and on out to the page. A stop does not trap focus. | | Enter, Space | On Back, Next, or Skip, presses it. |  The arrow that points the way the line runs goes on, and the other goes back, so on a right-to-left page Left goes on and Right goes back. A text field in a stop keeps its own arrows.  The tour is a region named by 'label' while it runs. A development build warns when a tour opens with no 'label'. */
+  /** The root holds the order of the stops: which stop is current, what Next and Back do, and when the tour is finished. Each stop holds its target, and you write all the text.  **The spotlight is a shadow.** The scrim is a box the size of the current target with a very large 'box-shadow' spread, and the shadow paints the darkness. A 'clip-path' on a full-screen scrim breaks as soon as an element between the scrim and the viewport is transformed.  The root measures the target's position in the browser. Nothing is measured on the server, because a tour starts only on request.  'open', 'default-open', 'helix-before-open', 'helix-before-close' and 'toggle' work as they do on 'Dialog'. Setting 'open' starts the run, and 'skip()' and 'requestOpen(false)' end it early.  The box the light falls on is on the 'spotlight' part as '--tour-spotlight-x', '--tour-spotlight-y', '--tour-spotlight-width' and '--tour-spotlight-height', for a sheet that draws its own light, such as a ring around the target.  Each stop is told its place in the run, from 'progress-label', such as "2 of 5". It describes the stop's panel, so a screen reader says it at every stop, and 'progress' draws it in the panel as well. A dialog or a floating stop, which has nothing to light, is shown over the 'backdrop' part. At a 'wait' stop the run waits for that stop's target to be on the page, and moves on by itself.  **Focus follows the run.** Opening moves focus to the first stop's panel, and moving on from a control in a stop moves it to the next one. Ending the tour puts focus back on the element that had it when the tour opened, unless you have moved it somewhere else on the page. A stop does not trap focus, so you can still 'Tab' out to the element it describes.  **The target is scrolled into view** before its stop is shown, by the least distance that brings it on screen, so the stop that points at it is on screen too.  **A stop's 'effect' runs as the tour reaches it**, before it is shown, and the stop waits for a promise it returns, with ':state(preparing)' on the tour meanwhile. A function it returns runs when the tour leaves the stop.  **A press outside the current stop and its target does nothing by default**, so a reader can use the page the tour is describing. Set 'outside-press="close"' to end the tour on one, through 'helix-before-close' as Skip does, or 'outside-press="block"' to refuse it, so the stop and its target are all a pointer can reach while the tour runs, as Zag's 'preventInteraction' does.  **Keyboard.** Focus is on the current stop's panel, which is not in the 'Tab' order itself.  | Key | What it does | |---|---| | Right | Goes to the next stop. On the last stop it does nothing, and Next finishes the tour. | | Left | Goes back to the previous stop. | | Escape | Skips the tour, and puts focus back where it was when the tour opened. | | Tab, Shift+Tab | Moves through the controls in the stop, and on out to the page. A stop does not trap focus. | | Enter, Space | On Back, Next, or Skip, presses it. |  The arrow that points the way the line runs goes on, and the other goes back, so on a right-to-left page Left goes on and Right goes back. A text field in a stop keeps its own arrows.  The tour is a region named by 'label' while it runs. A development build warns when a tour opens with no 'label'. */
   "helix-headless-tour": DefineCustomElement<
     HelixHeadlessTour,
     HelixHeadlessTourVueProps,
     HelixHeadlessTourVueEvents
   >;
-  /** A stop names its target with 'for' and holds the content you put in it. The stop handles three things:  - **Placement.** The panel is anchored to the target by the same floating   positioning as the other Helix overlays. - **Stacking.** The panel is a popover, so it is in the top layer and shows   above dialogs, scrolling regions, and other stacking contexts. - **Visibility.** The stop shows when it is 'current', which the root sets.  Put any content in the stop, such as a 'Card', or a heading and a line of text. The 'heading' and 'description' slots are optional places for the title and the line under it, which then name and describe the panel.  **A stop has a type.** Without one it is a bubble pointing at its target. 'type="dialog"' is a panel in the middle of the window, over a backdrop, for a welcome or a summary with nothing to point at. 'type="floating"' is a panel in a corner of the window, which the styled tier puts at the end of the line, for a note that points at nothing in particular. 'type="wait"' shows nothing: the tour waits for the element 'for' names to be on the page, such as a menu the reader has to open, and moves on by itself.  **The buttons are slot fallback.** With nothing in the 'actions' slot, you get Back, Next, and Skip, already wired. Slot your own 'actions' and drive them with 'next()', 'back()', and 'skip()' on the root.  **'for' is an id, as with 'Tooltip'**, so you can point at a target elsewhere on the page from markup. It resolves against the stop's root node, so a stop inside a shadow tree points at a target in that tree.  The panel is a 'group', and a 'dialog' for a dialog stop, only while the stop is shown. It is named by the 'heading' slot, then by the first heading in the content, then by 'label', and otherwise by its place in the tour. It is described by the 'description' slot, or where that is empty by the words at the start of the content, and by its place, such as "2 of 5", so a screen reader says where the reader is at every stop. 'focus()' moves focus to the panel, which is what the tour does when it opens or moves on. */
+  /** A stop names its target with 'for' and holds the content you put in it. The stop handles three things:  - **Placement.** The panel is anchored to the target by the same floating   positioning as the other Helix overlays. - **Stacking.** The panel is a popover, so it is in the top layer and shows   above dialogs, scrolling regions, and other stacking contexts. - **Visibility.** The stop shows when it is 'current', which the root sets.  Put any content in the stop, such as a 'Card', or a heading and a line of text. The 'heading' and 'description' slots are optional places for the title and the line under it, which then name and describe the panel.  **A stop has a type.** Without one it is a bubble pointing at its target. 'type="dialog"' is a panel in the middle of the window, over a backdrop, for a welcome or a summary with nothing to point at. 'type="floating"' is a panel in a corner of the window, which the styled tier puts at the end of the line, for a note that points at nothing in particular. 'type="wait"' shows nothing: the tour waits for the element 'for' names to be on the page, such as a menu the reader has to open, and moves on by itself.  **The buttons are slot fallback.** With nothing in the 'actions' slot, you get Back, Next, and Skip, already wired. Slot your own 'actions' and drive them with 'next()', 'back()', and 'skip()' on the root.  **Set 'effect' to prepare the page for a stop**, such as opening the menu it points into or loading what it describes. It is a function, set from script, that the tour runs as it reaches the stop. Return a promise and the stop waits for it, and the tour has ':state(preparing)' meanwhile; return a function, or resolve to one, and the tour runs it when it leaves the stop. Zag's tour step has the same 'effect'.  **'for' is an id, as with 'Tooltip'**, so you can point at a target elsewhere on the page from markup. It resolves against the stop's root node, so a stop inside a shadow tree points at a target in that tree.  The panel is a 'group', and a 'dialog' for a dialog stop, only while the stop is shown. It is named by the 'heading' slot, then by the first heading in the content, then by 'label', and otherwise by its place in the tour. It is described by the 'description' slot, or where that is empty by the words at the start of the content, and by its place, such as "2 of 5", so a screen reader says where the reader is at every stop. 'focus()' moves focus to the panel, which is what the tour does when it opens or moves on. */
   "helix-headless-tour-stop": DefineCustomElement<
     HelixHeadlessTourStop,
     HelixHeadlessTourStopVueProps,