Recommended pattern for tabs that exceed parent container

[DocMoebiuz]

Question

When using Tabs, they might need more than the available space. Tabs cannot shrink indefinitely, so some kind of pagination, scrolling, swiping is required to allow for horizontal displacement and making hidden tabs available.

I was wondering what UX pattern is common and which radix primitives are considered a good fit?

[chrisjcthomas]

I would start with ordinary horizontal scrolling. It works with touch/trackpads, preserves one real tablist containing every trigger, and lets Radix keep its arrow-key, Home, and End behavior. Tabs does not need a special overflow primitive for this.

<Tabs.Root defaultValue="overview">
  <div className="tabsScroller">
    <Tabs.List className="tabsList" aria-label="Project sections">
      <Tabs.Trigger value="overview">Overview</Tabs.Trigger>
      {/* more triggers */}
    </Tabs.List>
  </div>

  {/* Tabs.Content elements */}
</Tabs.Root>

.tabsScroller {
  overflow-x: auto;
  overscroll-behavior-inline: contain;
  scroll-snap-type: x proximity;
}

.tabsList {
  display: flex;
  width: max-content;
  min-width: 100%;
}

.tabsList [role="tab"] {
  flex: 0 0 auto;
  scroll-snap-align: start;
}

Browsers normally scroll a focused tab into view. If the active value can change programmatically, keep refs to the triggers and call scrollIntoView({ inline: "nearest", block: "nearest" }) for the newly active one. A ScrollArea wrapper is reasonable if you specifically want a custom scrollbar, but native overflow is the simpler default.

I would switch to a select/combobox or a different navigation pattern once the list is long enough that people cannot recognize the labels at a glance. Pagination arrows still leave keyboard and screen-reader users with a long tablist, so they are usually a less helpful first choice.

https://www.radix-ui.com/primitives/docs/components/tabs