# @xds/core # 0.7.4 #### New Features - `BottomSheetSwitcher` presents each step in its own native ``. Every child `BottomSheet` owns a dialog exactly like a standalone sheet; the switcher presents the selected sheet's dialog (`showModal()` with a scrim, `show()` without), keeps the previous sheet's dialog open and inert beneath the entering one through the handoff, and closes it once its panel has faded. One backdrop paints at a time: the retained dialog keeps the scrim until it closes, then the new dialog takes it over without a fade, so the page is never dimmed twice and the previous panel is never dimmed. Focus containment is the browser's own modal-dialog containment (as for `Dialog`) instead of a script trap; the page scroll lock (the shared body lock, held once by the switcher for the whole modal flow, through a handoff and until after the exit), Escape and platform-close routing, `purpose` dismissal rules, and focus return to the opener are unchanged. Going back to a sheet whose dialog is still fading closes and re-presents that dialog so the interactive sheet is the topmost layer again. (#7720) Public props, defaults, and exports are unchanged. Two observable details move with the structure: The switcher's `ref` resolves to the dialog hosting the flow — the active sheet's dialog, which changes on a handoff; the exiting sheet's through its exit; and, while the flow is closed, the dialog that hosted it last (or the first mounted sheet's) — instead of one persistent element; it is never `null` while a sheet is mounted, from the first commit on, and a callback ref's returned cleanup runs on each detach. `onCancel` and the forwarded dialog props apply to each sheet's dialog (a `role` given to the switcher included, except on a `required` step, which is an `alertdialog` as before), except `id` and `data-testid`, which render once, on the dialog the `ref` resolves to, from the first commit's synchronous re-render on; server markup of a flow that mounts closed carries them on no element (the shared dialog carried them). A non-modal flow orders its sheet dialogs inside a switcher-owned isolated wrapper that carries the one overlay value the shared dialog carried before. #### Fixes - `TextInput`, `TextArea`, `Selector` and `MultiSelector` announce "Loading" once, politely, through the shared announcement channel when they become busy, and the Spinner they show while busy is hidden from assistive technology. Before, the Spinner mounted as its own `role="status"` region already holding its name, which screen readers often skip, and it competed with the control's own `aria-busy` as a second owner of the same feedback. A rerender or StrictMode replay does not repeat the announcement; settling and becoming busy again announces again. Tests that found the busy Spinner with `getByRole('status', {name: 'Loading'})` should check the control's `aria-busy` instead. (#7920) - Carousel: when the focused edge scroll button runs out (the carousel reached that edge), focus now moves to the scroll area without scrolling it, instead of to the opposite scroll button. No API changes. (#7926) - `CheckboxInput` announces its busy start ("Loading") once, politely, through the shared announcement channel. The Spinner it shows in place of the check mark while busy sits inside the decorative, hidden indicator, so before this nothing told screen-reader users that the checkbox had become busy beyond its `aria-busy`. Inside an open modal dialog the announcement goes to a status region in the dialog. (#7948) - `CommandPaletteItem` now reflects its highlighted, selected, and disabled states on the `command-palette-item` theme target as `data-highlighted="highlighted"`, `data-selected="selected"`, and `data-disabled="disabled"`. A theme can now style the active keyboard result, the chosen value, or an unavailable command, for example `.astryx-command-palette-item[data-selected]`. States derived from CommandPalette are reflected too. Rendering, semantics, and props are unchanged. (#7967) - `CommandPalette` announces each busy start ("Loading"), including its load on opening or clearing the query, once from a status region inside its dialog, and its search Spinner is hidden from assistive technology. Before, the Spinner mounted as its own `role="status"` region already named "Loading", and the palette's own "Loading" went to the page-level announcement channel, which an open native modal hides from assistive technology. Result-count announcements are unchanged. Tests that found the Spinner with `getByRole('status')` should query the Spinner element instead. (#7956) - A busy `DateInput` (`isLoading`, or a pending `changeAction`) no longer looks disabled. On the popover, native, and bottom-sheet surfaces the field keeps its ordinary paint and shows its Spinner while new commits are blocked; only `isDisabled` dims the field. The busy field still takes no hover ring and keeps its keyboard focus ring. Props, semantics, and announcements are unchanged. (#7968) - `DateInput` (popover, native and bottom-sheet presentations) and `DateRangeInput` announce their busy start ("Loading") once, politely, through the shared announcement channel, and the Spinner they show while busy is hidden from assistive technology. Before, that Spinner mounted as its own `role="status"` region already named "Loading", which screen readers often skip, and it was a second owner beside the field's `aria-busy`. Inside an open modal dialog the announcement goes to a status region in the dialog. Tests that found the busy Spinner with `getByRole('status', {name: 'Loading'})` should check the field's `aria-busy` instead. (#7939) - `DateTimeInput` and `TimeInput` (popover, native and bottom-sheet presentations) announce their busy start ("Loading") once, politely, through the shared announcement channel, and the Spinner they show while busy is hidden from assistive technology. Before, that Spinner mounted as its own `role="status"` region already named "Loading", which screen readers often skip, and it was a second owner beside the field's `aria-busy`. A change made inside the open bottom sheet under a pending `changeAction` is announced from inside the sheet. Tests that found the busy Spinner with `getByRole('status', {name: 'Loading'})` should check the field's `aria-busy` instead. (#7942) - `FileInput` announces its busy start ("Loading") once, politely, through the shared announcement channel, and the Spinner it shows while busy is hidden from assistive technology. Before, that Spinner mounted as its own `role="status"` region already named "Loading", which screen readers often skip. A file pick keeps its single "file selected" announcement, because it is one user action, even when it starts a busy period (`changeAction`, or `isLoading` set from `onChange`). Other busy starts, such as `isLoading` on its own or a clear under `changeAction`, announce "Loading". Inside an open modal dialog the announcement goes to a status region in the dialog. Tests that found the busy Spinner with `getByRole('status', {name: 'Loading'})` should check the field's `aria-busy` instead. (#7954) - Selector, DropdownMenu and ContextMenu: clicking an option inside a shadow root (open, closed or nested) selects it. The menus used to read the document's view of the click, which names the shadow host, so the click closed the menu without selecting anything. (#7914) - `DropdownMenuSubMenu` (with `hasSpinner`), an uploading `Thumbnail`, and `ChatMessageList` while it loads older messages announce their busy start ("Loading") once, politely, through the shared announcement channel. The Spinner each one shows is hidden from assistive technology. Before, that Spinner mounted as its own `role="status"` region already named "Loading", which screen readers often skip; in `ChatMessageList` it was also a second live role inside the log. Tests that found these Spinners with `getByRole('status', {name: 'Loading'})` should query the Spinner element or the owner's busy state instead. (#7950) - ChatComposerInput: the trigger menu's loading row no longer mounts as a `role="status"` region already holding its text, which screen readers could skip. The loading text is announced once per pending search through the shared polite channel instead, and a search that returns its results before the loading row is painted, such as `createStaticSource` or a cached result, announces nothing; the visible row and its `loadingText` are unchanged. (#7900) Fixes #7859. - useTypeahead clears its pending buffer reset when its component unmounts or an `` boundary hides it, so a menu, list or selector removed within 750 ms of a typed character leaves no timer running behind it, and a hidden one comes back with an empty buffer (#7938) - `ComplexSelector`, `Typeahead`, `Tokenizer` and a directly used `BaseTypeahead` announce their busy start ("Loading") once, politely, through the shared announcement channel, and the Spinner they show while busy or while a search is in flight is no longer a live region: ComplexSelector's is hidden from assistive technology, and the search Spinner of Typeahead, Tokenizer and BaseTypeahead stays named as an image ("Loading") so the search's busy feedback keeps its name. Before, that Spinner mounted as its own `role="status"` region already named "Loading", which screen readers often skip, and it was a second owner beside the control's `aria-busy`. Inside an open modal dialog the announcement goes to a status region in the dialog. Tests that found the busy Spinner with `getByRole('status', {name: 'Loading'})` should check the control's `aria-busy`, or find the search Spinner with `getByRole('img', {name: 'Loading'})`. (#7930) #### Documentation - `BottomSheetSwitcher` anatomy names its host part `Sheet dialogs` — one native dialog per child sheet, the one hosting the active sheet carrying the flow's ref, id, modality, and dismissal — instead of `Shared dialog`. (#7720) #### Contributors Thanks to everyone who contributed to this release: - @cixzhang - @HelloOjasMutreja - @imdreamrunner - @vjeux --- # 0.7.3 #### New Features - `DropdownMenuSubMenu` takes `header` and `footer`, as the root `DropdownMenu` does, so a sub-menu can have a filter field above its rows, or an action such as "New folder" below them, outside the sub-menu's menu itself. With either, the sub-menu's surface (the flyout, or the drilled-in view on a phone) is a modal dialog named by its row: the row says `aria-haspopup="dialog"`, Tab and Shift+Tab walk the header, the rows and the footer and wrap, Escape returns to the row, and a pointer leaving the flyout closes it only once focus leaves too. A `ContextMenu` does not show a sub-menu's `header` or `footer`. Without them nothing changes. ```diff } + footer={