@fusion.dev/helix-headless 0.151.0 → 0.152.0

package/types/vue.d.ts

@@ -563,6 +563,22 @@ the wordmark and the actions happen to measure.
 takes a search field or a breadcrumb trail as readily as a `Navigation`, so
 the property carries the part's name, `content`. */
   contentAlign?: (HelixHeadlessAppHeader["contentAlign"]) | undefined;
+  /** The width of the bar, in pixels, below which the middle region folds behind
+a toggle. Unset, it never folds. */
+  "fold-below"?: (HelixHeadlessAppHeader["foldBelow"] | `${number}`) | undefined;
+  /** The width of the bar, in pixels, below which the middle region folds behind
+a toggle. Unset, it never folds. */
+  foldBelow?: (HelixHeadlessAppHeader["foldBelow"]) | undefined;
+  /** Hides the bar as the page scrolls down past it, and shows it again as the
+page scrolls up. */
+  "hide-on-scroll"?: (HelixHeadlessAppHeader["hideOnScroll"]) | undefined;
+  /** Hides the bar as the page scrolls down past it, and shows it again as the
+page scrolls up. */
+  hideOnScroll?: (HelixHeadlessAppHeader["hideOnScroll"]) | undefined;
+  /** The name of the toggle that opens a folded middle region. */
+  "menu-label"?: (HelixHeadlessAppHeader["menuLabel"]) | undefined;
+  /** The name of the toggle that opens a folded middle region. */
+  menuLabel?: (HelixHeadlessAppHeader["menuLabel"]) | undefined;
   /** 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;
@@ -5515,8 +5531,14 @@ first, `handleCancel` prevents it, and `requestOpen` decides. So
 `closedby="any"` gains light dismiss without giving up the refusal, which is
 the property this component exists to keep.
 
+The press on the backdrop that this element handles itself follows it too:
+`closerequest` and `none` leave the dialog open on that press, as the
+platform does, and `none` also keeps it open on Escape in a browser without
+`closedby`.
+
 Absent by default, which is the platform's `auto` and this library's rule
-that a resting value is an attribute's absence. */
+that a resting value is an attribute's absence. Absent, a press on the
+backdrop closes the dialog. */
   closedby?: (HelixHeadlessDialog["closedBy"]) | undefined;
   /** Which close requests the browser handles on its own.
 
@@ -5526,8 +5548,14 @@ first, `handleCancel` prevents it, and `requestOpen` decides. So
 `closedby="any"` gains light dismiss without giving up the refusal, which is
 the property this component exists to keep.
 
+The press on the backdrop that this element handles itself follows it too:
+`closerequest` and `none` leave the dialog open on that press, as the
+platform does, and `none` also keeps it open on Escape in a browser without
+`closedby`.
+
 Absent by default, which is the platform's `auto` and this library's rule
-that a resting value is an attribute's absence. */
+that a resting value is an attribute's absence. Absent, a press on the
+backdrop closes the dialog. */
   closedBy?: (HelixHeadlessDialog["closedBy"]) | undefined;
   /** Draws a control that closes the dialog, in the corner where the title is.
 
@@ -5794,6 +5822,12 @@ lost its focus trap because a consumer forgot a word would be worse than an
 attribute on the host, and nothing selects on it: the scrim is rendered or
 not, rather than shown or hidden by CSS. */
   modal?: (HelixHeadlessDrawer["modal"]) | undefined;
+  /** Stops Escape, a press outside, and a swipe from closing the drawer, for a
+drawer that has to be answered.
+
+The close control and `close()` still close it, as on `Dialog`: a panel
+with no way out at all is a trap. */
+  persistent?: (HelixHeadlessDrawer["persistent"]) | undefined;
   /** Which edge the drawer comes from.
 
 Unset is `end`, and it stays unset rather than being written down: a
@@ -12965,6 +12999,9 @@ Reading gives where it is; writing declares it the consumer's, and
 `default-position` seeds one this element owns. The same accessor pair
 `Pagination.page` and the calendar's `month` carry. */
   position?: (HelixHeadlessSplitter["position"]) | undefined;
+  /** The pane that keeps its size when the splitter's own size changes. The
+other pane takes all of the change. Unset, both keep their share. */
+  primary?: (HelixHeadlessSplitter["primary"]) | undefined;
   /** Where a dragged divider snaps, comma separated, as Web Awesome's split
 panel does: a bare number is a percentage and a length such as `240px` is
 measured along the splitter, so `snap="25, 50, 75"` or `snap="240px, 50"`.
@@ -16803,7 +16840,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.  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'. 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. */
   "helix-headless-app-header": DefineCustomElement<
     HelixHeadlessAppHeader,
     HelixHeadlessAppHeaderVueProps,
@@ -16845,13 +16882,13 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessBlockquoteVueProps,
     HelixHeadlessBlockquoteVueEvents
   >;
-  /** Each crumb renders its separator and sets its list-item role. It hides its own separator with ':host(:first-child)', so the trail needs no index from the parent.  Set 'href' to make the whole crumb an anchor, which works with Enter, middle click, and the status bar, and before any JavaScript runs. A router cannot reach an anchor inside a shadow root, so intercept the click for client-side navigation, as with 'Tree.Item' and 'List.Item'. A trail that collapses also reads 'href' to rebuild its hidden crumbs elsewhere.  Without 'href', the crumb renders a plain '<span>' around what you slot, including your own anchor.  The current page is plain text, and 'aria-current="page"' on the host conveys the position. */
+  /** Each crumb renders its separator and sets its list-item role. It hides its own separator with ':host(:first-child)', so the trail needs no index from the parent.  Set 'href' to make the whole crumb an anchor, which works with Enter, middle click, and the status bar, and before any JavaScript runs. A router cannot reach an anchor inside a shadow root, so intercept the click for client-side navigation, as with 'Tree.Item' and 'List.Item'. A trail that collapses also reads 'href' to rebuild its hidden crumbs elsewhere.  Without 'href', the crumb renders a plain '<span>' around what you slot, including your own anchor.  The current page is plain text, and 'aria-current="page"' on the host conveys the position. In a trail where no crumb is 'current', the last one is said to be the current page, and keeps its link. An 'aria-current' you write on the host, such as 'aria-current="location"', replaces the one the crumb gives itself. */
   "helix-headless-breadcrumb": DefineCustomElement<
     HelixHeadlessBreadcrumb,
     HelixHeadlessBreadcrumbVueProps,
     HelixHeadlessBreadcrumbVueEvents
   >;
-  /** The host is the navigation landmark, named "Breadcrumb" by default. An 'aria-label' on the host names the trail instead, and so does 'label'. When a page has more than one navigation landmark, screen reader users choose between them by name.  The '<ol>' has an explicit 'role="list"', because Safari removes list semantics from a list with 'list-style: none', and the trail always hides its markers.  The items are slotted directly, so they are '<ol>' children in the flat tree, and each item sets 'role="listitem"' on itself.  The trail does not measure itself, and you write its overflow in markup: put the crumb that holds the folded items where the gap should appear.  A trail built from data, such as a router's matched routes, takes 'items': an array of '{ label, href }', drawn as crumbs in order, the last one as the current page. Slotted crumbs follow them. Use one way or the other in a trail.  With 'max-items', a trail drawn from 'items' that is longer folds its middle into one crumb: the first crumb, a button, then the last 'max-items' less one. The button is named by 'expand-label' and shows the whole trail, moving focus to the first crumb it brought back. A new 'items' folds again. Slotted crumbs do not fold; write the folded crumb where the gap should be. */
+  /** The host is the navigation landmark, named "Breadcrumb" by default. An 'aria-label' on the host names the trail instead, and so does 'label'. When a page has more than one navigation landmark, screen reader users choose between them by name.  The '<ol>' has an explicit 'role="list"', because Safari removes list semantics from a list with 'list-style: none', and the trail always hides its markers.  The items are slotted directly, so they are '<ol>' children in the flat tree, and each item sets 'role="listitem"' on itself. Where no slotted crumb is 'current', the last one is said to be the current page.  The trail does not measure itself, and you write its overflow in markup: put the crumb that holds the folded items where the gap should appear.  A trail built from data, such as a router's matched routes, takes 'items': an array of '{ label, href }', drawn as crumbs in order, the last one as the current page. Slotted crumbs follow them. Use one way or the other in a trail.  With 'max-items', a trail drawn from 'items' that is longer folds its middle into one crumb: the first crumb, a button, then the last 'max-items' less one. The button is named by 'expand-label' and shows the whole trail, moving focus to the first crumb it brought back. A new 'items' folds again. Slotted crumbs do not fold; write the folded crumb where the gap should be.  **Keyboard.** Each crumb with an 'href' is a link and one tab stop, and Enter follows it. The current page and the separators are not in the tab order. In a folded trail, Enter or Space on the fold's button shows the whole trail and moves focus to the first crumb it brought back. */
   "helix-headless-breadcrumbs": DefineCustomElement<
     HelixHeadlessBreadcrumbs,
     HelixHeadlessBreadcrumbsVueProps,
@@ -17007,7 +17044,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessDescriptionListVueProps,
     HelixHeadlessDescriptionListVueEvents
   >;
-  /** Renders a native '<dialog>' opened with 'showModal()'. The platform provides:  - the top layer, so the dialog is above everything whatever the 'z-index' - a backdrop - closing with Escape - an inert page behind the dialog, unreachable by pointer, keyboard, or   virtual cursor  The dialog adds one thing to those: 'Tab' from its last control goes to its first, and 'Shift+Tab' from its first to its last. A native modal lets 'Tab' past its last control out to the browser's own controls.  'open' calls 'showModal()', and every way the dialog closes goes through 'requestOpen'. A native dialog closes three ways: the property, Escape, and a '<form method="dialog">' submit. Routing all three through 'requestOpen' keeps your state in step, so the dialog never closes while your state still says it is open, which would leave it impossible to reopen.  The dialog's name is 'label' when you set it. Otherwise it is the heading in the 'header' slot, or the elements an 'aria-labelledby' on the host names, and 'fallback-label' where nothing names it. While it is open, the page behind it does not scroll.  The dialog is described by the words at the start of its body: the elements in the default slot before the first one that is or holds a control. A question above a form describes the dialog, and the form does not. A Helix component that draws words and no control, such as 'Text', counts as words. An 'aria-describedby' on the host replaces it.  Set 'alert' for a dialog that interrupts to ask for an answer, such as a confirmation before a deletion. It is an 'alertdialog', which a screen reader announces with its description as it opens. Set 'dismissible' to draw a close control, labeled by 'dismiss-label'. */
+  /** Renders a native '<dialog>' opened with 'showModal()'. The platform provides:  - the top layer, so the dialog is above everything whatever the 'z-index' - a backdrop - closing with Escape - an inert page behind the dialog, unreachable by pointer, keyboard, or   virtual cursor  The dialog adds one thing to those: 'Tab' from its last control goes to its first, and 'Shift+Tab' from its first to its last. A native modal lets 'Tab' past its last control out to the browser's own controls.  'open' calls 'showModal()', and every way the dialog closes goes through 'requestOpen'. A native dialog closes three ways: the property, Escape, and a '<form method="dialog">' submit. Routing all three through 'requestOpen' keeps your state in step, so the dialog never closes while your state still says it is open, which would leave it impossible to reopen.  The dialog's name is 'label' when you set it. Otherwise it is the heading in the 'header' slot, or the elements an 'aria-labelledby' on the host names, and 'fallback-label' where nothing names it. While it is open, the page behind it does not scroll.  The dialog is described by the words at the start of its body: the elements in the default slot before the first one that is or holds a control. A question above a form describes the dialog, and the form does not. A Helix component that draws words and no control, such as 'Text', counts as words. An 'aria-describedby' on the host replaces it.  Set 'alert' for a dialog that interrupts to ask for an answer, such as a confirmation before a deletion. It is an 'alertdialog', which a screen reader announces with its description as it opens. Set 'dismissible' to draw a close control, labeled by 'dismiss-label'.  **Keyboard.** Opening moves focus to the first control in the dialog.  | Key | What it does | |---|---| | Tab, Shift+Tab | Moves through the controls in the dialog, from the last round to the first and from the first round to the last. | | Escape | Asks to close the dialog. A 'helix-before-close' listener can refuse, and 'persistent' or 'closedby="none"' keeps it open. | | Enter, Space | On the close control, closes the dialog. |  Closing puts focus back on the element that had it before the dialog opened. */
   "helix-headless-dialog": DefineCustomElement<
     HelixHeadlessDialog,
     HelixHeadlessDialogVueProps,
@@ -17025,7 +17062,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessDonutChartVueProps,
     HelixHeadlessDonutChartVueEvents
   >;
-  /** Uses 'MixinControllerOpen', so 'open', 'defaultOpen', and the 'helix-before-open' and 'helix-before-close' events work the same way as on an accordion item.  The drawer is modal by default, which means four things:  - focus is trapped inside: 'Tab' from the last control goes to the first,   and 'Shift+Tab' from the first to the last, as in 'Dialog' - Escape and a press outside close it - the page behind is covered - the page behind does not scroll  A drawer with 'modal="false"' leaves the page usable and still closes on Escape, in a browser without 'closedby' as well.  **A touch or a pen swipes it away**, toward the edge it came from, resolved against the writing direction. A swipe past halfway, or a quick one, closes it through the same request as every other way out. 'snap-points' lists the fractions of the panel a reader can leave on screen, such as '0.5 1' for a sheet that rests half open: it opens at the smallest, and a swipe settles at the nearest. While a swipe moves the panel, the distance is written on it as '--drawer-swipe-x' and '--drawer-swipe-y'. 'swipe="false"' turns swiping off.  'snap' is the snap point the panel rests at, and ':state(snapped)' is on the host while that is less than the whole panel. 'snapTo()' moves it to another. **Focus moving to a control past the window's edge opens the panel to its largest snap point**, so a reader moving through a half open sheet with 'Tab' never lands on a control they cannot see.  Set 'dismissible' to draw a close control in the corner, labeled by 'dismiss-label', as 'Dialog' draws one.  The panel's name is 'label' when you set it. Otherwise it is the heading in the 'header' slot, or the elements an 'aria-labelledby' on the host names, and 'fallback-label' where nothing names it.  Content stays mounted when the drawer is closed, so it is in the server markup and can animate. A closed '<dialog>' is already out of the tab order and the accessibility tree, so the drawer does not write 'inert'. The 'role', 'aria-modal', and the scrim also come from the '<dialog>' element. 'drawer-root.ssr.spec.ts' checks that the panel has no hand-written 'inert' or 'role'.  Open the drawer declaratively with the platform's invoker attributes:  '''html <helix-headless-button commandfor="nav" command="--toggle">Menu</helix-headless-button> <helix-headless-drawer id="nav">…</helix-headless-drawer> ''' */
+  /** Uses 'MixinControllerOpen', so 'open', 'defaultOpen', and the 'helix-before-open' and 'helix-before-close' events work the same way as on an accordion item.  The drawer is modal by default, which means four things:  - focus is trapped inside: 'Tab' from the last control goes to the first,   and 'Shift+Tab' from the first to the last, as in 'Dialog' - Escape and a press outside close it - the page behind is covered - the page behind does not scroll  A drawer with 'modal="false"' leaves the page usable and still closes on Escape, in a browser without 'closedby' as well.  Set 'persistent' for a drawer that has to be answered: Escape, a press outside, and a swipe leave it open, and the close control and 'close()' still close it. 'closedby="none"' keeps it open on all three as well, and 'closedby="closerequest"' keeps it open on a press outside.  **A touch or a pen swipes it away**, toward the edge it came from, resolved against the writing direction. A swipe past halfway, or a quick one, closes it through the same request as every other way out. 'snap-points' lists the fractions of the panel a reader can leave on screen, such as '0.5 1' for a sheet that rests half open: it opens at the smallest, and a swipe settles at the nearest. While a swipe moves the panel, the distance is written on it as '--drawer-swipe-x' and '--drawer-swipe-y'. 'swipe="false"' turns swiping off.  'snap' is the snap point the panel rests at, and ':state(snapped)' is on the host while that is less than the whole panel. 'snapTo()' moves it to another. **Focus moving to a control past the window's edge opens the panel to its largest snap point**, so a reader moving through a half open sheet with 'Tab' never lands on a control they cannot see.  Set 'dismissible' to draw a close control in the corner, labeled by 'dismiss-label', as 'Dialog' draws one.  The panel's name is 'label' when you set it. Otherwise it is the heading in the 'header' slot, or the elements an 'aria-labelledby' on the host names, and 'fallback-label' where nothing names it. A development build warns when a drawer opens with nothing but 'fallback-label' to name it.  The panel is described by the words at the start of its body, as 'Dialog' is: the elements in the default slot before the first one that is or holds a control. An 'aria-describedby' on the host replaces it.  **Keyboard.** Opening moves focus to the first control in the panel.  | Key | What it does | |---|---| | Tab, Shift+Tab | In a modal drawer, moves through the controls in the panel, from the last round to the first and from the first round to the last. In a drawer that is not modal, moves on to the page. | | Escape | Asks to close the drawer. A 'helix-before-close' listener can refuse, and 'persistent' or 'closedby="none"' keeps it open. | | Enter, Space | On the close control, closes the drawer. |  Content stays mounted when the drawer is closed, so it is in the server markup and can animate. A closed '<dialog>' is already out of the tab order and the accessibility tree, so the drawer does not write 'inert'. The 'role', 'aria-modal', and the scrim also come from the '<dialog>' element. 'drawer-root.ssr.spec.ts' checks that the panel has no hand-written 'inert' or 'role'.  Open the drawer declaratively with the platform's invoker attributes:  '''html <helix-headless-button commandfor="nav" command="--toggle">Menu</helix-headless-button> <helix-headless-drawer id="nav">…</helix-headless-drawer> ''' */
   "helix-headless-drawer": DefineCustomElement<
     HelixHeadlessDrawer,
     HelixHeadlessDrawerVueProps,
@@ -17145,7 +17182,7 @@ export interface WcToolkitVueGlobalComponents {
     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.  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, 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. */
   "helix-headless-lightbox": DefineCustomElement<
     HelixHeadlessLightbox,
     HelixHeadlessLightboxVueProps,
@@ -17277,7 +17314,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessMeterVueProps,
     HelixHeadlessMeterVueEvents
   >;
-  /** Renders a real '<nav>', the landmark that screen reader users jump to. Navigation is its own component, separate from 'AppHeader', so you can use it in a header, a footer, or a sidebar.  **It renders no links.** Bring your own, mark the current one with 'aria-current="page"', and style them with the 'data-navigation-item' recipe. A router renders its own anchors and cannot render them inside the component's shadow root.  The component moves a marker to the current item. It finds the current item by reading 'aria-current', so the attribute that screen readers announce also places the marker. Any value but 'false' counts, so a sidebar of sections on one page can mark the section in view with 'aria-current="location"'. Where several are marked, 'page' wins.  Set 'orientation="vertical"' to stack the destinations in a column, for a sidebar.  Set 'arrows' and the arrow keys move focus between the destinations, as Radix's navigation menu does: left and right along a row, up and down a column, Home and End to the ends. A 'Megamenu' among them is reached at its trigger. Tab still stops at every link, since a navigation is a list of links and not a single control, and the keys across the other axis are left to the page and to an open panel. */
+  /** Renders a real '<nav>', the landmark that screen reader users jump to. Navigation is its own component, separate from 'AppHeader', so you can use it in a header, a footer, or a sidebar.  **It renders no links.** Bring your own, mark the current one with 'aria-current="page"', and style them with the 'data-navigation-item' recipe. A router renders its own anchors and cannot render them inside the component's shadow root.  The component moves a marker to the current item. It finds the current item by reading 'aria-current', so the attribute that screen readers announce also places the marker. Any value but 'false' counts, so a sidebar of sections on one page can mark the section in view with 'aria-current="location"'. Where several are marked, 'page' wins.  **The destinations can be a list.** Slot a '<ul>' or an '<ol>' of '<li>' elements, each holding a link, and a screen reader says how many there are and where each one is, as in Radix's 'NavigationMenu.List'. The marker and the arrow keys work on the list items as they do on bare links. Give the list 'role="list"' as well, since Safari drops the semantics of a list drawn without bullets.  Set 'orientation="vertical"' to stack the destinations in a column, for a sidebar.  Set 'arrows' and the arrow keys move focus between the destinations, as Radix's navigation menu does: left and right along a row, up and down a column, Home and End to the ends. A 'Megamenu' among them is reached at its trigger. Tab still stops at every link, since a navigation is a list of links and not a single control, and the keys across the other axis are left to the page and to an open panel. */
   "helix-headless-navigation": DefineCustomElement<
     HelixHeadlessNavigation,
     HelixHeadlessNavigationVueProps,
@@ -17295,7 +17332,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessNotificationVueProps,
     HelixHeadlessNotificationVueEvents
   >;
-  /** Notifications are slotted children. Each one is your own markup, with an avatar, a link, or a button in it. Feeds usually hold tens of items, so writing them out lets an item hold anything.  The list does not virtualize. Windowing needs the list to own the data, and here you own it, so N notifications are N elements. For a feed of thousands, use a data table with a custom cell.  Read state is reported to you. Marking read goes from the root to the item and from the item to you, so a canceled 'helix-read' changes nothing, and if you own 'read', nothing changes until you set it. 'unread' is derived from the items and written to an attribute, so a stylesheet and a badge can both use it without counting.  **The feed is one 'Tab' stop for its rows.** Each row takes focus itself and is read by its label. 'ArrowDown' and 'ArrowUp' move to the next and the previous row, 'Home' and 'End' to the first and the last, and 'PageDown' and 'PageUp' move a row on or back from anywhere inside one, as in the APG feed pattern. The controls inside a row stay in the 'Tab' order. Set 'total' when the feed holds one page of a longer list, and each row says its place in the whole of it.  **'load-more' adds a button after the list** that sends 'helix-load-more', for a feed that holds one page of a longer list. Append the next page, set 'loading' while it is on its way, and take 'load-more' off once there is nothing more. While the feed is loading the button stays, so focus stays on it, and it is 'aria-disabled' and sends nothing.  **'load-error' says a page could not be fetched**, such as "Could not load notifications": it shows under the rows there are, in the 'error' part, in place of the empty and loading lines, and a screen reader hears it. Clear it when you ask again. */
+  /** Notifications are slotted children. Each one is your own markup, with an avatar, a link, or a button in it. Feeds usually hold tens of items, so writing them out lets an item hold anything.  The list does not virtualize. Windowing needs the list to own the data, and here you own it, so N notifications are N elements. For a feed of thousands, use a data table with a custom cell.  Read state is reported to you. Marking read goes from the root to the item and from the item to you, so a canceled 'helix-read' changes nothing, and if you own 'read', nothing changes until you set it. 'unread' is derived from the items and written to an attribute, so a stylesheet and a badge can both use it without counting.  **The feed is one 'Tab' stop for its rows.** Each row takes focus itself and is read by its label. 'ArrowDown' and 'ArrowUp' move to the next and the previous row, 'Home' and 'End' to the first and the last, and 'PageDown' and 'PageUp' move a row on or back from anywhere inside one, as in the APG feed pattern. The controls inside a row stay in the 'Tab' order. Set 'total' when the feed holds one page of a longer list, and each row says its place in the whole of it.  **Keyboard.**  | Key | What it does | |---|---| | Down, Up | On a row, moves to the next or the previous row. | | Home, End | On a row, moves to the first or the last row. | | Page Down, Page Up | From anywhere in a row, moves to the next or the previous row. | | Control+End | From anywhere in the feed, moves to the first control after it on the page. | | Control+Home | From anywhere in the feed, moves to the nearest control before it on the page. | | Tab | Moves through the controls in a row, and on out of the feed. |  **'load-more' adds a button after the list** that sends 'helix-load-more', for a feed that holds one page of a longer list. Append the next page, set 'loading' while it is on its way, and take 'load-more' off once there is nothing more. While the feed is loading the button stays, so focus stays on it, and it is 'aria-disabled' and sends nothing.  **'load-error' says a page could not be fetched**, such as "Could not load notifications": it shows under the rows there are, in the 'error' part, in place of the empty and loading lines, and a screen reader hears it. Clear it when you ask again. */
   "helix-headless-notifications": DefineCustomElement<
     HelixHeadlessNotifications,
     HelixHeadlessNotificationsVueProps,
@@ -17361,7 +17398,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessPinInputVueProps,
     HelixHeadlessPinInputVueEvents
   >;
-  /** Popover is the general overlay that the specific ones build on. 'Menu' holds commands, 'Select' holds options, and 'Tooltip' holds a description. Popover holds any content you put in it, so it has no keyboard handling of its own.  The trigger is slotted and stays your own element. A Helix trigger is told whether the popover is open inside its own shadow root. On a plain element, such as a '<button>', the popover writes 'aria-expanded' only once a reader has pressed it, which is after any hydration, and never where you wrote 'aria-expanded' yourself. It writes nothing else onto your markup.  The panel is in the top layer through the popover API, so it needs no 'z-index', and an ancestor with 'overflow: hidden', 'transform', 'filter', or 'contain' does not clip or move it.  It opens on click and from a command. 'command="--show"' and the related commands work as they do on 'Dialog' and 'Drawer', so a button anywhere on the page can open the popover with no script.  **Opening moves focus into the panel**, to the first control in it, or to the panel itself where it holds none, and closing from inside gives it back to the trigger. It closes on Escape, on a press outside it, and when focus moves out of the trigger and the panel to somewhere else on the page.  'modal' keeps 'Tab' inside the panel while it is open and says so with 'aria-modal', for a panel that has to be answered before the page goes on. The rest of the page is hidden from screen readers with 'aria-hidden' while it is open, so the virtual cursor stays in the panel too. Without it the popover does not trap focus.  The panel's name is 'label' when you set it. Otherwise it is the first heading in the panel, or the elements an 'aria-labelledby' on the host names.  'arrow' draws a point on the panel's edge facing the trigger. The side the panel landed on is on the host as ':state(placed-top)' and its kin, and the trigger's width is on the panel as '--floating-anchor-inline-size', for a panel as wide as its trigger:  '''css helix-popover::part(popover) {   min-inline-size: var(--floating-anchor-inline-size); } ''' */
+  /** Popover is the general overlay that the specific ones build on. 'Menu' holds commands, 'Select' holds options, and 'Tooltip' holds a description. Popover holds any content you put in it, so it has no keyboard handling of its own.  The trigger is slotted and stays your own element. A Helix trigger is told whether the popover is open inside its own shadow root. On a plain element, such as a '<button>', the popover writes 'aria-expanded', from a frame after its own first render, or from the first press where that comes sooner. It never writes it where you wrote 'aria-expanded' yourself, and writes nothing else onto your markup.  The panel is in the top layer through the popover API, so it needs no 'z-index', and an ancestor with 'overflow: hidden', 'transform', 'filter', or 'contain' does not clip or move it.  It opens on click and from a command. 'command="--show"' and the related commands work as they do on 'Dialog' and 'Drawer', so a button anywhere on the page can open the popover with no script.  **Opening moves focus into the panel**, to the first control in it, or to the panel itself where it holds none, and closing from inside gives it back to the trigger. It closes on Escape, on a press outside it, and when focus moves out of the trigger and the panel to somewhere else on the page.  'modal' keeps 'Tab' inside the panel while it is open and says so with 'aria-modal', for a panel that has to be answered before the page goes on. The rest of the page is hidden from screen readers with 'aria-hidden' while it is open, so the virtual cursor stays in the panel too. Without it the popover does not trap focus.  The panel's name is 'label' when you set it. Otherwise it is the first heading in the panel, or the elements an 'aria-labelledby' on the host names. A development build warns when a popover opens with nothing but 'fallback-label' to name it.  **Keyboard.** Opening moves focus to the first control in the panel, or to the panel where it holds none.  | Key | What it does | |---|---| | Enter, Space | On the trigger, opens the panel, or closes it while it is open. | | Escape | Closes the panel and puts focus back on the trigger. | | Tab, Shift+Tab | Moves through the controls in the panel. Leaving the panel and the trigger closes it. With 'modal', moves from the last control round to the first and from the first round to the last. |  'arrow' draws a point on the panel's edge facing the trigger. The side the panel landed on is on the host as ':state(placed-top)' and its kin, and the trigger's width is on the panel as '--floating-anchor-inline-size', for a panel as wide as its trigger:  '''css helix-popover::part(popover) {   min-inline-size: var(--floating-anchor-inline-size); } ''' */
   "helix-headless-popover": DefineCustomElement<
     HelixHeadlessPopover,
     HelixHeadlessPopoverVueProps,
@@ -17463,7 +17500,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessSpeedDialVueProps,
     HelixHeadlessSpeedDialVueEvents
   >;
-  /** A splitter has one axis. Nest splitters to get two axes and three-pane or four-pane layouts.  When a splitter is slotted into a pane of another at a right angle, a corner handle appears where the dividers cross. It shows the 'move' cursor, responds to both arrow axes, and a drag moves both dividers at once. The corner is added at 'firstUpdated' and is not in the server markup. Before it appears, both dividers work on their own.  The divider has 'role="separator"' and 'aria-valuenow', with 'aria-valuetext' saying the start pane's share as a percentage in the nearest 'lang', or in the reader's locale where no 'lang' is set, and 'aria-controls' names the start pane. Drag it with a pointer or move it with the arrow keys, press 'Home' or 'End' to move it to its bounds, and press 'Enter' to collapse the start pane and open it again. A drag in progress is tracked as a state, so both dividers a corner moves stay lit for as long as they move.  By default, 'min' and 'max' let the divider reach either edge, so you can drag a pane fully closed. Set them to limit the range.  A pane can be collapsed, which is a separate state from a divider at the edge. 'collapsed' names the shut pane, 'start' or 'end', and the pane opens back to the position where the collapsing gesture began. A drag records that position on press, and every other way of collapsing records it in 'settle'. 'collapsed-size' keeps a sliver of the pane visible, such as a tab strip. Collapsing overrides 'min' and 'max'. */
+  /** A splitter has one axis. Nest splitters to get two axes and three-pane or four-pane layouts.  When a splitter is slotted into a pane of another at a right angle, a corner handle appears where the dividers cross. It shows the 'move' cursor, responds to both arrow axes, and a drag moves both dividers at once. The corner is added at 'firstUpdated' and is not in the server markup. Before it appears, both dividers work on their own.  The divider has 'role="separator"' and 'aria-valuenow', with 'aria-valuetext' saying the start pane's share as a percentage in the nearest 'lang', or in the reader's locale where no 'lang' is set, and 'aria-controls' names the start pane. Drag it with a pointer or move it with the arrow keys, press 'Home' or 'End' to move it to its bounds, and press 'Enter' to collapse the start pane and open it again. A drag in progress is tracked as a state, so both dividers a corner moves stay lit for as long as they move.  By default, 'min' and 'max' let the divider reach either edge, so you can drag a pane fully closed. Set them to limit the range.  A pane can be collapsed, which is a separate state from a divider at the edge. 'collapsed' names the shut pane, 'start' or 'end', and the pane opens back to the position where the collapsing gesture began. A drag records that position on press, and every other way of collapsing records it in 'settle'. 'collapsed-size' keeps a sliver of the pane visible, such as a tab strip. Collapsing overrides 'min' and 'max'.  Set 'primary' to the pane that keeps its size when the splitter's own size changes, such as a sidebar beside a window being resized. The other pane takes all of the change, as Web Awesome's split panel does. Without it, both panes keep their share.  **Keyboard.** The divider is one tab stop.  | Key | What it does | |---|---| | Left, Right | Moves a side-by-side divider by 'step'. On a right-to-left page, Left moves it toward the end. | | Up, Down | Moves a stacked divider by 'step'. | | Home, End | Moves the divider to its bounds. | | Enter | Collapses the start pane, and opens it again. | | F6 | Moves focus from one pane to the first control in the other, and from the divider to the start pane. | */
   "helix-headless-splitter": DefineCustomElement<
     HelixHeadlessSplitter,
     HelixHeadlessSplitterVueProps,
@@ -17529,7 +17566,7 @@ export interface WcToolkitVueGlobalComponents {
     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.  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 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.  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,
@@ -17625,13 +17662,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 arrow keys move between stops** while focus is in one: the arrow that points the way the line runs goes on, and the other goes back, so on a right-to-left page 'ArrowLeft' goes on. Neither finishes the tour at the last stop, and a text field in a stop keeps its own arrows. 'Escape' skips the tour. */
+  /** 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'. */
   "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 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.  **'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,
@@ -17643,7 +17680,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTreeItemVueProps,
     HelixHeadlessTreeItemVueEvents
   >;
-  /** The tree is a single tab stop, and arrow keys move focus between items, as the tree pattern requires, so Tab moves past a long sidebar in one press. The tree moves the tab stop to the focused item, so the browser's focus order stays intact.  Items are found with 'instanceof', never by tag name, so the headless tier does not depend on the styled one.  Typing a letter moves to the next visible item whose name starts with it, and '*' opens every branch beside the focused item.  'selection-mode="multiple"' draws a check mark on every row and lets a reader check many, as Web Awesome's and Ark UI's checkbox trees do. Checking a branch checks every item under it, and a branch some of whose items are checked is partly checked. Space or a press on the mark checks the focused row, and Enter or a press on a branch's row opens it. 'active' then holds the checked values, comma separated, which 'values' also gives as a list, and the tree says 'aria-multiselectable'.  'selection-mode="leaf"' chooses one item at a time and only the items at the ends: a press, Enter or Space on a branch opens or closes it and chooses nothing, as Web Awesome's 'leaf' mode does.  Keys: Up and Down Arrow move between the items a reader can see; Right Arrow opens a shut branch and then moves into it, and Left Arrow shuts an open one and then moves to its parent, the two swapping on a right-to-left page. Home and End go to the first and the last item, Enter and Space choose or open, and the tree's one tab stop stays on the item last reached. In a tree of check marks, Control+A (Command+A on an Apple keyboard) checks every item or clears them all, and Shift with Up or Down Arrow moves and checks.  **'reorderable' lets you move items among their siblings.** Alt with Up or Down moves the focused item a place, and Alt with Home or End to the first or the last place among its siblings, as the APG's rearrangeable listbox does. Each row gets a grip at its far end: drag it to move the item, and the tree scrolls near an edge. A click on a grip picks the item up and a click on one of its siblings drops it there, which needs no drag. The arrows move an item picked up that way, Enter or Space drops it, and Escape puts it back. The tree says each step in its 'live' region. A drop sends 'helix-before-reorder', which you can refuse, and then 'helix-reorder', whose 'keys' hold the siblings in the new order. **You move the items**: the tree moves no element of yours, and focus follows the moved item once you have. Moving an item into another branch is not part of this. */
+  /** The tree is a single tab stop, and arrow keys move focus between items, as the tree pattern requires, so Tab moves past a long sidebar in one press. The tree moves the tab stop to the focused item, so the browser's focus order stays intact.  Items are found with 'instanceof', never by tag name, so the headless tier does not depend on the styled one.  Typing a letter moves to the next visible item whose name starts with it, and '*' opens every branch beside the focused item.  'selection-mode="multiple"' draws a check mark on every row and lets a reader check many, as Web Awesome's and Ark UI's checkbox trees do. Checking a branch checks every item under it, and a branch some of whose items are checked is partly checked. Space or a press on the mark checks the focused row, and Enter or a press on a branch's row opens it. 'active' then holds the checked values, comma separated, which 'values' also gives as a list, and the tree says 'aria-multiselectable'.  'selection-mode="leaf"' chooses one item at a time and only the items at the ends: a press, Enter or Space on a branch opens or closes it and chooses nothing, as Web Awesome's 'leaf' mode does.  Keys: Up and Down Arrow move between the items a reader can see; Right Arrow opens a shut branch and then moves into it, and Left Arrow shuts an open one and then moves to its parent, the two swapping on a right-to-left page. Home and End go to the first and the last item, Enter and Space choose or open, and the tree's one tab stop stays on the item last reached. In a tree of check marks, Control+A (Command+A on an Apple keyboard) checks every item or clears them all, and Shift with Up or Down Arrow moves and checks.  Removing the item that has focus moves focus to the item after it among its siblings, or the one before, or its parent, so focus stays in the tree.  **'reorderable' lets you move items among their siblings.** Alt with Up or Down moves the focused item a place, and Alt with Home or End to the first or the last place among its siblings, as the APG's rearrangeable listbox does. Each row gets a grip at its far end: drag it to move the item, and the tree scrolls near an edge. A click on a grip picks the item up and a click on one of its siblings drops it there, which needs no drag. The arrows move an item picked up that way, Enter or Space drops it, and Escape puts it back. The tree says each step in its 'live' region. A drop sends 'helix-before-reorder', which you can refuse, and then 'helix-reorder', whose 'keys' hold the siblings in the new order. **You move the items**: the tree moves no element of yours, and focus follows the moved item once you have. Moving an item into another branch is not part of this. */
   "helix-headless-tree": DefineCustomElement<
     HelixHeadlessTree,
     HelixHeadlessTreeVueProps,

package/types/words.d.ts

@@ -22,6 +22,14 @@ declare module '@fusion.dev/helix-core' {
        */
       label: Message
     }
+    'helix-app-header': {
+      /**
+       * The name of the toggle that opens a folded middle region.
+       *
+       * English: `Menu`
+       */
+      menuLabel: Message
+    }
     'helix-area-chart': {
       /**
        * Where a reading the keys moved to stands among the readings, said after