Chrome and containers

The design-system shell — the one frame every app screen sits in, claiming the Material `Scaffold` archetype and morphing by M3 window class. Two hosting modes, chosen by which constructor is used: * AppScaffold.new — the original single-body render-prop mode: nav *data* (navItems / selectedIndex / onNavSelect / navFooter) plus one body render-prop that receives the resolved AppWindowClass. Correct when the caller already owns its own destination-switching (e.g. a router-driven shell). * AppScaffold.destinations — full `AppShell` hosting parity: a TREE of AppScaffoldDestinations and AppScaffoldDestinationGroups, each leaf built lazily and kept alive; a syncStatus slot; the transient modeline band under the bar (the active destination's AppHeaderBand contribution, rendered only while a message is carried); drawerActions; and trailing actions. Both modes share the same window-class morph (see AppWindowClass). The scaffold measures its **own** width via LayoutBuilder (not the raw viewport), so it classifies correctly inside split views and specimens, not only full screens. **ONE ROW** (`Scaffold.d.ts`, 2026-10-05, #1186 § 9 — the Google Admin console's frame, without a second band). At ≥960: ```text ┌ rail head (--bar-h) ┬ view bar (--bar-h) ─────────────────────────┐ │ ≡ ■ Console │ Records searchFilter │ ⟳ │ │ │ North Plant ⌄ · 8 records │ ├─────────────────────┼────────────────────────────────────────────┤ │ ⌂ Home │ transient band · WORKSPACE (cards) │ │ ▸ Directory • │ │ │ ─────────────────── │ │ │ ⚙ Settings │ │ │ ✉ Send feedback │ │ │ [org logo] │ │ └─────────────────────┴────────────────────────────────────────────┘ ``` * The **rail** runs the window's full height (56 ⇄ 256). Its pinned **head**, `--bar-h` tall, reads `[≡][■ mark]title` in BOTH postures (§ 10, THE MARK NEVER MOVES): the MENU BUTTON (centered in the 56 column, on the glyph line), which TOGGLES the posture — "Collapse navigation" / "Expand navigation", with its expanded state — then the railMark at start 65 (center 79) in both postures, then title (honoring brandTitle), which fades out collapsed. The collapsed head's mark OVERHANGS the 56 rail by 52, and every bar beside it — the view bar, or a pushed screen's own — leads by that much. Its pinned **footer group** (§ 12) holds the footerDestinations, the footerActions, the footerAccount and the footerBrand. The rail mounts EXTENDED at AppWindowClass.large and collapsed from 960 to 1199; the user's toggle sticks for the scaffold's life. * The **view bar** heads the content column, level with the head so the two read as one band: the view's title and, beneath it, the scope then the meta; the contributed cluster, the destination's and the shell's actions, then the divider and syncStatus LAST. It has no leading slot. Below 960 there is no rail: the single bar's managed menu button opens the overlay drawer — its header band (the brand), the SAME tree in the extended geometry and the footer group — and sync is the bar's last action. The scope leads the bar's subtitle there too. **Paint** (`Scaffold.d.ts`, #1100 re-scoped by #1186 § 9): under `chrome: accent | deep` the rail HEAD, the view bar (or a pushed bar in its place), the compact bar and the compact bottom bar paint the chrome and are chrome hosts — the head and the bar one colored band across the top. The rail's tree and footer, the workspace and the drawer stay on the ground or the card. Under `chrome: ground` every band is the ground. **THE FRAME RECEDES** (`Scaffold.d.ts`, 2026-09-29, #892): the WORKSPACE is the destination body inset by DesignTokens.workspaceGutter (14) on its inline-end and block-end edges (its inline-start meets the rail, its block-start the view bar). Below 960 the workspace takes the gutter on its inline-start too; below 600 the phone's DesignTokens.workspaceGutterC (8). The scaffold owns the inset and nothing else: a floorplan lays its content in cards inside it. **Nav data, not a nav widget.** The scaffold takes the nav *data* and constructs the AppNavRail itself with the posture the window class dictates. Selecting a destination from the drawer closes it, then fires the selection callback. **The bar's leading slot is managed below 960.** The scaffold injects the drawer's menu button into the bar's leading position only when the bar has no leading of its own — it never overwrites a caller-supplied leading. In body mode that applies to an AppHeaderBar appBar; any other PreferredSizeWidget is hosted verbatim. In destinations mode the scaffold builds its own bar internally. **THE SHORT WINDOW** (`Scaffold.d.ts`, 2026-10-13, #1270): below 960 on a window under kAppWindowShortMax tall (a phone in landscape), the destinations-mode view bar collapses UPWARD on AppMotion.move the moment the active destination's body scrolls vertically off its top, and returns when that body is back at its top — per destination. A body overflowing by no more than the bar keeps it, search mode keeps it, a horizontal scroll never toggles it, the top safe-area inset stays painted in the bar's fill, and a collapsed bar is out of the focus order and the semantics tree. The transient band, the Fab and the bottom nav stay. Body mode's appBar is the host's and is unchanged (only `DetailScreen`'s page opts in). **The sync/persistence split button** is the consumer's to wire into syncStatus (or, in body mode, the bar's own `syncStatus` SLOT, never its `actions` list) — the scaffold hosts it, it does not synthesize the control. Direction-agnostic: the rail sits at the layout start edge, the drawer slides from the start edge, and the FAB floats at the end edge — all via logical positioning, so RTL mirrors them with zero edits. ```dart // Body mode. AppScaffold( title: 'Records', appBar: const AppHeaderBar(title: 'Records', meta: '128'), navItems: const [ AppNavItem(glyph: KitGlyph.table, label: 'Records'), AppNavItem(glyph: KitGlyph.map, label: 'Map'), ], selectedIndex: index, onNavSelect: (i) => setState(() => index = i), navFooter: const [AppNavItem(glyph: KitGlyph.gear, label: 'Settings')], syncStatus: SyncStatusButton(...), fab: AppFab(glyph: KitGlyph.plus, tooltip: 'New record', onPressed: create), body: (context, windowClass) => RecordsView(windowClass: windowClass), ) // Destinations mode — a tree. AppScaffold.destinations( title: 'Console', destinations: [ AppScaffoldDestination( glyph: KitGlyph.house, label: 'Home', builder: (context) => const HomeView(), ), AppScaffoldDestinationGroup( key: 'directory', glyph: KitGlyph.users, label: 'Directory', items: [ AppScaffoldDestination( label: 'Users', badge: const AppNavBadge.count(3), builder: (context) => const UsersView(), ), AppScaffoldDestination( label: 'Groups', builder: (context) => const GroupsView(), ), ], ), ], // Settings has one home: the footer group, below the tree. footerDestinations: [ AppScaffoldDestination( glyph: KitGlyph.gear, label: 'Settings', builder: (context) => const SettingsView(), ), ], footerActions: [ AppScaffoldFooterAction( glyph: KitGlyph.message, label: 'Send feedback', onSelect: sendFeedback, ), ], syncStatus: SyncStatusButton(...), railMark: const AppRailMark(glyph: KitGlyph.check), scope: AppScaffoldScope( kind: 'Project', label: activeProject.name, onSelect: (anchor) => pickProject(anchor), ), ) ```

Projects header-bar actions from a destination's BODY into the hosting AppScaffold.destinations view bar — the seam behind the Table View v3 bar posture, where a records surface's search + view controls live in the header at medium/expanded width while their STATE stays inside the surface. Mount it anywhere in a destination's subtree (it renders nothing in place); the scaffold renders children at the bar's inline end, ahead of AppScaffoldDestination.actions, AppScaffold.actions and the sync control, so the constitution's ordering (sync last) is preserved — as the bar's view cluster (AppHeaderBar.center, divided from sync) in the resting-field and search postures, and as the leading bar actions in the resting-glyph posture. The seam is view-agnostic: any records view — table, map, deck, gallery, dashboard — contributes the same chrome cluster against its own row stream. Each destination has its own registration; switching destinations swaps the contributed set with the body. Re-building with new children updates the header; unmounting clears it. It also carries the bar's POSTURE: a contribution declaring searchMode takes the whole bar for the duration (`back · children · syncStatus`), which is how a records surface expands its search on demand instead of resting a toolbar in the chrome (`AppBar.d.ts` resting rule). ONE contributor per destination surface — a second mount overwrites the first (last-in wins), which is never what you want. Outside a destinations-mode AppScaffold (body mode, tests, a bare route) there is no scope and the widget is inert — check AppHeaderActions.availableIn to fall back to an in-body toolbar, as `RecordsTableScaffold` does. The band under the bar is the sibling seam: AppHeaderBand.

Projects a destination's TRANSIENT message into the scaffold's modeline BAND — the 28px strip under the app bar (`Scaffold.d.ts` THE BAND, transient-only since 2026-08-24): the band exists only while a message (or its paired action) is in flight, and a destination messaging through it renders no footer modeline. The standing segments and the scope segment are DELETED — the counts restated what the surface shows, and the scope leads the bar's subtitle (AppScaffold.scope). Mount it anywhere in a destination's subtree; it renders nothing in place, exactly like AppHeaderActions, and follows the same rules: ONE contributor per destination surface (a second mount overwrites the first), each destination keeps its own registration, and re-building with new values repaints the band while unmounting clears it. Outside a destinations-mode AppScaffold — body mode, a bare route, a test — the widget is inert; check availableIn and keep a footer AppModeline there instead, mounted for as long as the surface can message (`Modeline.d.ts` SILENT REGION): silent, it draws nothing.

Hides the scaffold's header seams from a subtree — after this widget, AppHeaderActions.availableIn and AppHeaderBand.availableIn both read FALSE, and a contributor mounted inside is inert. It exists for the one case where a surface is inside a destination's body and must NOT reach that destination's bar: a whole-screen composition nested inside another one (a records view embedded in a detail screen's related slot). Without it the nested surface contributes its search field to the HOST screen's bar — the scope is perfectly visible from inside a docked pane, because a pane is a sibling in the body — and the two surfaces then fight over one bar, last-in wins. The subtree keeps its in-body fallbacks, which is exactly what the seam's own contract says happens where there is no host: an in-body toolbar and a footer modeline (`Scaffold.d.ts`, "a bare route, a test").

The design-system Sheet — a themed, token-driven modal surface claiming the M3 bottom-sheet archetype (bottom posture) or a hand-built end-anchored panel (side posture, no M3 equivalent shipped in Flutter yet). Renders the shared anatomy for both postures: the required title + an optional quiet meta annotation in the header (e.g. a live result count "14 match" — filters apply LIVE; this is quiet header metadata, never a staged "Show N records" commit control), the body content, and an optional footer of quiet actions (e.g. a ghost "Clear all" — **no slab inside a sheet**; the accent stays with the view's primary action elsewhere). The `bottom` posture additionally renders a grab bar above the header; the `side` posture renders a hairline start-edge instead. Use showKitSheet rather than constructing this widget directly in app code — it wires posture selection, the scrim, and focus/dismiss. This widget is exposed publicly so goldens and composed call sites can render the chrome directly (e.g. to specimen both postures without an overlay). ```dart KitSheet( posture: KitSheetPosture.bottom, title: 'Filter', meta: const Text('14 match'), footer: AppButton(label: 'Clear all', onPressed: clearAll), body: filterRows, ) ```

The design-system Dialog — a themed, token-driven destructive-confirm surface with the M3 alert dialog's anatomy, lifted by DesignTokens.sh3. **Destructive confirms only.** Anatomy is fixed: a factual title stating the consequence with a count where relevant (e.g. "Delete 3 records?"), a message naming the consequence in DesignTokens.body / ink60 (e.g. "Removes 3 records permanently."), a ghost **Cancel** action, and a **confirm** action whose confirmLabel is a verb (e.g. "Delete") rendered as AppButton with `variant: AppButtonVariant.outline, tone: AppButtonTone.danger` — the danger-outline confirm is the only sanctioned destructive affordance; a danger *slab* does not exist in this system. Use showAppDialog rather than constructing this widget directly in app code — it wires the scrim, focus management, and barrier/Esc-cancels-false contract. This widget is exposed publicly so goldens and composed call sites (e.g. a caller building its own host around the anatomy) can render it standalone. ```dart AppDialog( title: 'Delete 3 records?', message: 'Removes 3 records permanently.', confirmLabel: 'Delete', onConfirm: doDelete, onCancel: () => Navigator.of(context).pop(false), ) ```

The design-system Menu — a themed, token-driven hairline popover claiming the M3 menu archetype. Anchors a caller-built trigger to a MenuAnchor popover listing items in order. trigger wires its own tap (typically `onPressed: toggle` on an `AppIconButton` or `AppButton`) rather than AppMenu wrapping it in a second gesture detector — the trigger keeps full ownership of its own press/hover/focus state, exactly as it would unwrapped. AppMenu merges the popover's `expanded` state onto the trigger's own Semantics node (so a plain `AppIconButton(active: open, onPressed: toggle)` trigger reports `button: true, expanded:` correctly with no extra wiring); MenuAnchor gives native arrow-key navigation between items for free. An item with AppMenuItem.dividerBefore gets a hairline Divider rendered immediately above it — the spec's item-grouping grammar. The current item (AppMenuItem.checked) carries a trailing ✓ in the data font AND reports its checkable state to a screen reader; AppMenuItem.danger items paint DesignTokens.danger — never a red slab. ```dart AppMenu( trigger: (context, controller, toggle, open) => AppIconButton( glyph: KitGlyph.dots, title: 'More', active: open, expanded: open, onPressed: toggle, ), items: [ AppMenuItem(label: 'Rename view', onSelected: rename), AppMenuItem( label: 'Density: compact', checked: true, onSelected: toggleDensity, ), AppMenuItem( label: 'Delete view', danger: true, dividerBefore: true, onSelected: delete, ), ], ) ```

The design-system Tooltip: the name an icon-only child carries, shown on hover after kAppTooltipHoverDelay, at once on keyboard focus, and on a long press on touch (which does not press the control). message is the control's own accessible name, repeated — the child keeps its own label (an explicit `Semantics(label:)` over an excluded subtree, as every kit control does). enabled false wires nothing (the label is on screen already, as in the extended rail). ```dart AppTooltip(message: 'Filter', child: pressable) AppTooltip(message: 'Inbox', side: AppTooltipSide.end, child: row) AppTooltip(message: 'Reorder tile', longPress: false, child: grip) AppTooltip(message: 'Due date', excludeSemantics: true, child: head) ```

The design-system AppBar — the view's top bar, claiming the M3 top-app-bar archetype. Slots: optional leading (nav toggle / back — typically an `AppIconButton`), title (the **view's** name, not the app's — rendered in the headline role, DesignTokens.headline), optional meta (a quiet line BENEATH the title — "46 of 68 work orders · synced 2 min ago" — in the label role at DesignTokens.ink40, the UI font, never mono), optional center (the view cluster), actions (a row of widgets laid out inline-end in the given order — typically `AppIconButton`s or at most one slab `AppButton`), and syncStatus (the sync control, always rendered last). Consumer guidance (documented, not mechanically enforced — this widget takes any Widgets in actions and does not inspect them): at most **one** slab among actions, the constitution's one-accent-slab-per- surface rule. **The sync control is NOT one of actions.** It has its own syncStatus slot and the widget renders it after everything in actions, so "sync is always the last inline-end action" is structural rather than a rule each host has to remember — which is exactly how it went missing from every route-pushed screen in the suite while every scaffold-hosted one had it. Implements PreferredSizeWidget so it drops directly into `Scaffold.appBar`. **THE CONTAINED BAR** (`AppBar.d.ts`, 2026-09-29, #892): the bar IS the ground (DesignTokens.sur) — no rule beneath it, no shadow, elevation 0 — the same contract `appTheme()` wires onto Material's own `AppBarTheme`. Its height is `--bar-h` (DesignTokens.barH: 64 comfortable, 56 at the desk) and its controls take `--ctl` like every bar control — nothing inside re-scopes the density. When it carries both a view cluster (center) and syncStatus, a 1 × 20 DesignTokens.hairS divider separates them: the view's controls on one side, the app's one global control on the other. **The bar shares the workspace's edges** (`AppBar.d.ts`, 2026-09-29): it carries no inline padding of its own beyond the workspace inset, so under an `AppScaffold` destination its first control starts on the workspace's inline-start edge and its last ends on the inline-end edge — 0 on the rail side and DesignTokens.workspaceGutter at the window edge at >=960, the gutter on both sides from 600 to 959, and DesignTokens.workspaceGutterC on both below 600. The scaffold hands those edges down; a bar with no scaffold workspace under it (a body-mode host, a route-pushed floorplan) keeps the symmetric `--appbar-px` (10). Its icon controls sit on the ground, so a ghost one hovers with DesignTokens.groundHover rather than the card's DesignTokens.ink4. **Owns its top safe area**, exactly as Material's `AppBar` does: on an edge-to-edge window (Android 15 enforces it) the bar's surface extends up behind the status bar while the content row lays out below the inset, and an `AnnotatedRegion` keeps the status icons contrasting against DesignTokens.sur. preferredSize is the comfortable bar height — the slot's CAP: the bar lays itself out at DesignTokens.barH, and `Scaffold` starts its body where the bar actually ends, so the desk's 56 bar gives its 8px back to the body. A primary `Scaffold` adds `MediaQuery.padding.top` to the app-bar slot itself. Hosted under an ancestor `SafeArea` (the form view's body) the inset is already consumed and the bar renders at spec height unchanged. **Adaptation strategy: scale.** This widget renders exactly the slots it's given at every window class; it does not decide what moves where. The spec's compact-class swap (primary actions leaving the bar for a FAB cluster, the action row collapsing to essentials + overflow) is the future `AppScaffold`'s job — it composes AppHeaderBar and decides, per window class, which action-tier widgets it hands to actions versus routes elsewhere. AppHeaderBar itself never inspects window class. Direction-agnostic: leading sits at the layout start edge, actions at the end edge, via `EdgeInsetsDirectional` / `Row` (which already mirrors under RTL) — no physical left/right ever appears here. ```dart Scaffold( appBar: AppHeaderBar( leading: AppIconButton(glyph: KitGlyph.menu, title: 'Navigation', onPressed: openDrawer), title: 'Records', meta: '128', actions: [ AppButton(variant: AppButtonVariant.slab, icon: const KitIcon(KitGlyph.plus), label: 'New', onPressed: create), ], syncStatus: SyncStatusButton(state: syncState, pending: pending, onSyncNow: syncNow), ), body: ..., ) ```

The canonical back affordance for AppHeaderBar.leading — a quiet AppIconButton on KitGlyph.back that `maybePop`s its route. Promoted 2026-08-05 from six identical hand-built blocks (two of which had drifted onto Material's `arrow_back`). The slot stays a slot: this is an atom the caller drops in, not a `showBack` knob.

The design-system NavRail — the app's left spine, claiming the M3 navigation-rail archetype (with a drawer-hosted overlay form for narrower window classes) — and THE TREE RAIL (`NavRail.d.ts`, #1186): a tree of leaf destinations (AppNavItem) and disclosure groups (AppNavGroup). Three postures share one widget and one selection grammar (see AppNavRailPosture): AppNavRailPosture.rail (56, glyphs alone), AppNavRailPosture.extended (256, the tree) and AppNavRailPosture.drawer (the tree at a drawer's width). **THE RAIL'S BODY IS THE GROUND** (`Scaffold.d.ts` ONE ROW, #1186 § 9). It paints nothing of its own — no fill, no rule against the workspace. Its optional pinned head (the host's menu button and brand, `--bar-h` tall) is the one band in it: under `chrome: accent | deep` the head takes the chrome and reads as one band with the view bar beside it, while the tree stays on the plain ground. The footer keeps its DesignTokens.hairS rule: it divides the rail's own regions. **THE FOOTER GROUP** (`Scaffold.d.ts` § 12): behind that rule, top to bottom, the footer DESTINATIONS (pages, which can be lit), the footerActions (commands, never lit), the footerAccount (the signed-in person, opening a menu at itself) and the footerBrand (a logo, never focusable) — each optional, all pinned. **THE SELECTION is Google's pill.** Extended and in the drawer the lit leaf's row carries an DesignTokens.accentSel pill flush to the rail's inline-start edge, fully rounded on its inline-end side and ending 8 short of the rail's inline-end edge; its glyph takes DesignTokens.accentInk, its label DesignTokens.ink (text floor 4.5:1, #1747), the label at 600. Collapsed it is a 40 × 40 circle centered on the glyph. A lit leaf hidden inside a closed group (or any group, collapsed) lends the pill to its nearest VISIBLE ancestor, so the selection is never invisible. Inactive rows: the glyph in DesignTokens.ink60, the label in DesignTokens.ink at 500. The pill's shape is the rail's, never a role radius — the `corners` knob does not touch it. **THE GLYPH IS ANCHORED.** One glyph size (glyphSize, 20) in both postures, and a depth-0 glyph's horizontal center sits glyphAnchor (28) from the rail's inline-start edge in both, so a toggle never moves a glyph sideways. Extended, the row reads: the chevron column (a depth-0 group's 12px chevron centered 9 in), the glyph, the label at labelStart (52), the badge 8 after the label. A child row (depth ≥ 1) is text only, its label at `52 + (depth − 1) × 24`, a child group's chevron centered 12 before it. **Groups are folders.** More than one may be open. The rail holds the open set itself: SEEDED, and RE-SEEDED whenever the lit leaf changes, so every ancestor of the lit leaf is open (ancestors are added; nothing is removed), while the user's own toggles last for the life of the rail. **COLLAPSED RAIL ICON-ONLY.** Each collapsed row's accessible name is its label with the badge's description appended ("Inbox, 3 new"), and it carries the kit AppTooltip at AppTooltipSide.end, its words the label alone (`NavRail.d.ts` ACCESSIBILITY, #1896) — labels hide only here, and only because the host's menu button one tap away restores every label. State contract (all honored) per row: enabled · hover (DesignTokens.groundHover in the pill or circle shape) · focus-visible (1px accent ring on the row's shape) · pressed (1px translateY) · selected (the pill) · Semantics: a leaf is a button, `selected` when lit; a group is a button with `expanded`. Enter and Space activate. The whole rail is a `Semantics(container: true)` region labeled "Navigation". **The destination list scrolls** (`NavRail.d.ts`, #406, simplified by #1186): the items in their own bounded scroller between the pinned head above and the pinned footer group below. The lit row is scrolled into view by the nearest edge after first layout (a settle), whenever selectedIndex changes from outside the rail, after a group auto-opens and across a posture change; a tap never moves the list under the finger. The rail therefore needs a BOUNDED height, which every scaffold host gives it. ```dart AppNavRail( posture: extended ? AppNavRailPosture.extended : AppNavRailPosture.rail, onPostureChange: (p) => setState(() => extended = true), items: const [ AppNavItem(glyph: KitGlyph.house, label: 'Home'), AppNavGroup( glyph: KitGlyph.users, label: 'Directory', children: [ AppNavItem(label: 'Users', badge: AppNavBadge.count(3)), AppNavItem(label: 'Groups'), ], ), ], selectedIndex: selected, // the LEAF index, depth-first onSelect: (i) => setState(() => selected = i), footer: const [AppNavItem(glyph: KitGlyph.gear, label: 'Settings')], ) ```

The canonical brand/app mark — the shell's `railMark` (`NavRail.d.ts` `RailMark`): a small accent block carrying one glyph in the on-accent ink — or, via mark, the app's AppBrandMark image, which brings its own paint. **IDENTITY ONLY** (`Scaffold.d.ts` § 11, #1186). The mark says whose app this is and nothing else: it is never a control, never the scope picker (the active scope leads the view bar's subtitle — `AppScaffold.scope`), never the selection grammar and never a badge. Decorative to a screen reader: the rail head's title (or, with the title hidden, the head's own heading node) names the region. Size and radius are component geometry (28px block, 16px glyph, DesignTokens.rS corner); paint is token-only.

Draws an AppBrandMark contain-fit inside a width × height box, in the variant the ambient theme's brightness calls for — never tinted (no color or blend is ever applied to the image). semanticLabel names the mark for assistive technology (typically the app's name); null leaves it decorative, which is right wherever a text line beside it already says the name.

The design-system Tabs — one start-aligned row of label-width tabs over a hairline rail, the selected one at full ink and weight 600 over an accent underline that overlaps the rail. **THE CONTAINED TAB** (Tabs.d.ts, #893): the underline runs under the LABEL only — inset by `--tab-px` from both inline edges of the tab, so the line is exactly the label's width — while the hover wash and the hit region keep the whole tab. Unselected labels are ink60 at 500. Switches between VIEWS of one surface. It never edits a value — that is `AppSegmentGroup`'s job, and the two are not interchangeable. **The underline is a transparent border on every tab**, so selection never changes the row's height and nothing below the row shifts when the selection moves. A pane whose content jumps as the user changes tabs is the defect this anatomy is shaped to prevent. **Overflow scrolls inline** — start-pinned. It never wraps (a second rail under the first stops reading as one tablist) and never ellipsizes a label (a truncated view name is unreadable navigation). Three riders (Tabs.d.ts OVERFLOW, 2026-09-29): each edge the row can still scroll toward FADES its tabs out over `--tab-fade` (an alpha mask; the rail never fades); the selected tab is SCROLLED INTO VIEW after the first layout and on every change of value; and selection never changes a tab's WIDTH — each tab reserves its label's selected (600) width. **inset** pads the scroll content inline, so the first tab can sit on a host's gutter while the rail still spans the whole row. **Keyboard**: arrow keys move the selection to the next/previous non-disabled tab AND select it, wrapping past the ends; focus follows (roving tabindex). Enter/Space select the focused tab. Tabs never un-select — tapping the selected one is a no-op. ```dart AppTabs<String>( semanticLabel: 'View options', value: tab, onChanged: (v) => setState(() => tab = v), options: const [ AppTabOption(value: 'filter', label: 'Filter'), AppTabOption(value: 'group', label: 'Group'), AppTabOption(value: 'columns', label: 'Columns', count: 4), ], ) ```