Tabs

Import

import {
  Tabs,
  TabsContent,
  TabsList,
  TabsTrigger,
} from "@mikenotthepope/substrateui"

Composition

Tabs
├── TabsList
│   └── TabsTrigger
└── TabsContent

Unstacking

A review screen wants both panes at once on a laptop and one at a time on a phone. unstackAtis that: the tabs pattern below the breakpoint, and at or above it every pane on screen with the tab strip gone. Narrow this page’s window past lg and back to watch it change.

Above the breakpoint it is not tabs, and it does not say it is

This is the part worth arguing about. A tablist whose panels are all on screen describes a control that is not there. There is no selection, so aria-selected has nothing to report; there is nothing to arrow between, so a roving tabIndex is a tab stop that does nothing; and aria-controls points at content already in front of you. Keeping the markup and hiding the strip with a class would leave every one of those claims in the accessibility tree, true of nothing.

So above the breakpoint there is no tablist. Each label becomes a heading, and each pane becomes a region named by that heading — through the same aria-labelledby, pointing at the same element, which was the tab a moment ago. That is the honest reading of two panes side by side: two pieces of content, each with a name, each reachable from a screen reader’s landmark and heading lists instead of from an arrow key.

Which is also the warning on the label. region is a landmark, and landmarks are for content worth jumping to. unstackAt earns its keep on two or three substantial panes — a résumé beside the notes about it. Six chips of settings are tabs at every width, and should stay tabs.

Why a class could not have done this

The request this shipped from said the blocker was Base UI’s TabsPanel setting the hidden attribute, which no breakpoint class can undo. That part is not right: [hidden] { display: none }is a user-agent rule, and any author class outranks it by origin. Base UI’s own Tailwind example depends on that — its panel carries [[hidden]]:hidden to put the hiding back after flex has undone it.

Two things underneath it are the blocker. A closed Base UI panel is also inert, which no class undoes. And one level up from either of them, role is not a property, so no media query can change what an element claims to be. The layout was never the hard part. The claim was.

Between first paint and hydration

The server cannot know the viewport, so the markup it sends is the regions form: headings and named regions, which is the weaker of the two claims and true at either width. The tabs pattern goes on one commit later, once the width is known and only if it is below the breakpoint. Below it, that leaves a moment where the headings name panes the stylesheet has not revealed — the same moment in which a tab would not have responded to a click either, because all of this is a client component.

The layout does not wait for any of that. Which pane shows is a class, so it is right in the first frame and nothing moves when the JavaScript lands. Semantics are JavaScript, layout is CSS, and they are allowed to disagree for exactly one commit.

What the keyboard does, below the breakpoint

The full pattern, unchanged from the tabs above: one tab stop for the whole strip, ArrowLeft and ArrowRight to move within it, Home and End for the ends, Enter or Space to select — or activateOnFocus on TabsList to select as focus lands. Arrow keys follow the reading direction, so under DirectionProvider dir="rtl" ArrowLeft moves to the next tab along. Disabled tabs are skipped.

Every pane stays mounted at every width, so nothing inside one is thrown away when the breakpoint is crossed: a half-typed note is still half-typed after a rotation. Below the breakpoint the inactive panes carry hidden and inert as well as the class that hides them — a pane kept out of the accessibility tree only by a stylesheet is a pane that comes back when the stylesheet does not load.

API Reference

Parts, under unstackAt