RFC: Bits UI v3

[huntabyte]

A thread of decisions/plans for Bits UI v3.

[huntabyte]

New Select.List & Combobox.List Components

Motivation

Both Select and Combobox components follow the ARIA "listbox" pattern. Currently, the role="listbox" attribute is applied directly to the *.Content component. This makes it impossible to insert additional elements within Content - for example, a search input to filter options - without breaking the ARIA role structure.

Because the entire content area is treated as a listbox, developers can't cleanly compose UI elements like headers, separators, or search fields alongside the options list. This limits flexibility and violates accessibility semantics when done manually.

Proposal

Introduce new Select.List and Combobox.List components that live inside their respective *.Content components. These *.List components will render the list of options and carry the role="listbox" attribute, while *.Content becomes a more general layout container.

This change makes it possible to add other elements inside Content - such as a search field, label, or custom header - without affecting ARIA correctness.

Example Usage:

<Select.Content>
    <label for="search">Search</label>
    <input id="search" type="text" placeholder="Search options" />
+    <Select.List>
        <Select.Item />
        <Select.Item />
+    </Select.List>
</Select.Content>

Alternatives Considered

• Keep role="listbox" on *.Content - Simplifies the markup but prevents accessible composition of additional content.
• Infer list semantics automatically based on child structure - Would introduce unnecessary complexity and unreliable ARIA inference, as well as potential for bugs when the child structure changes.

Impact

• Breaking Change: Developers must wrap Select.Item and Combobox.Item elements in a new *.List component.
• Improved accessibility: Ensures proper role="listbox" semantics while allowing flexible composition.
• Greater flexibility: Enables adding search inputs, headers, and other custom UI elements to the dropdown panel.
• Cleaner separation of concerns: *.Content manages layout and visibility; *.List manages option semantics and keyboard navigation.

[vladshcherbin]

would be so nice to have this, currently using command with hacks just for the same purpose

[Luca-Sett]

Hi @huntabyte, I was wondering if you had a rough timeline for if/when searchable selects will be supported as described in this discussion?

I'm hoping to be able to build something like NuxtUI's SelectMenu component.

I've tried both adding an input to a Select and using a Combobox but neither way seems quite right at the moment.

Cheers :)

[huntabyte]

Better Support for type="multiple" in Select/Combobox

Motivation

Currently, Bits UI leaves most of the behavior for handling multiple selected values up to the user. This works fine for simple cases, such as rendering a comma-separated string like "Option 1, +2 more" or "Option 1, Option 2, Option 3".

However, modern UIs often provide a richer multi-select experience where users can view and remove individual selections directly from the trigger (e.g., as removable chips or badges) without reopening the listbox. Implementing this today requires users to manually wire together custom markup, keyboard handling, and ARIA relationships, which more often than not results in accessibility regressions and inconsistent UX patterns.

We should handle this more elegantly at the primitive level, ensuring that advanced multi-select patterns remain composable, accessible, and predictable.

Proposal

Enhance Select and Combobox to include built-in support for displaying and managing multiple selected values within the trigger. This could take the form of new child components such as *.SelectedValue or *.ValueChip, which integrate cleanly with our internal selection and focus management logic.

For example:

<Select.Root type="multiple">
  <Select.Trigger>
    <Select.Value>
      <Select.ValueChip value="apple">Apple</Select.ValueChip>
      <Select.ValueChip value="banana">Banana</Select.ValueChip>
    </Select.Value>
  </Select.Trigger>

  <Select.Portal>
    <Select.Content>
      <Select.List>
        <Select.Item value="apple">Apple</Select.Item>
        <Select.Item value="banana">Banana</Select.Item>
        <Select.Item value="orange">Orange</Select.Item>
      </Select.List>
    </Select.Content>
  </Select.Portal>
</Select.Root>

Each chip would integrate with the selection model, including proper ARIA attributes, keyboard navigation, and focus handling for removal (e.g., pressing Backspace/Delete on a focused chip).

Exact component naming and structure will be refined after experimentation, but the goal is to make rich multi-select UX fully achievable within the primitives.

Impact

Breaking Change? No

Migration Example

Before (v2):

<Select.Root type="multiple" bind:value={selected}>
  <Select.Trigger>
    {selected.join(', ')}
  </Select.Trigger>

  <Select.Portal>
    <Select.Content>
      <Select.Item value="apple">Apple</Select.Item>
      <Select.Item value="banana">Banana</Select.Item>
      <Select.Item value="orange">Orange</Select.Item>
    </Select.Content>
  </Select.Portal>
</Select.Root>

After (v3):

<Select.Root type="multiple" bind:value={selected}>
  <Select.Trigger>
    <Select.ValueChips>
      {#each selected as fruit}
        <Select.ValueChip value={fruit}>{fruit}</Select.ValueChip>
      {/each}
    </Select.ValueChips>
  </Select.Trigger>

  <Select.Portal>
    <Select.Content>
      <Select.List>
        <Select.Item value="apple">Apple</Select.Item>
        <Select.Item value="banana">Banana</Select.Item>
        <Select.Item value="orange">Orange</Select.Item>
      </Select.List>
    </Select.Content>
  </Select.Portal>
</Select.Root>