Tab View

FluereTabView + FluereTabViewItem map to WinUI 3 / Windows App SDK's Microsoft.UI.Xaml.Controls.TabView: a horizontally scrollable tab strip plus a content area that only shows the selected item, with close buttons, an add button and three width modes. Keys and focus behaviour follow the source item by item.

<FluereTabView v-model:selected-index="selected" label="Tabs">
  <FluereTabViewItem header="Documents" :is-closable="true">Panel content</FluereTabViewItem>
  <FluereTabViewItem header="Pictures">Panel content</FluereTabViewItem>
</FluereTabView>

<FluereTabView v-model:selected-index="selected" label="Example tabs">
  <FluereTabViewItem v-for="tab in tabs" :key="tab.title" :header="tab.title">
    <template #icon><component :is="tab.icon" :size="16" /></template>
    <div class="p-fluent-l">…</div>
  </FluereTabViewItem>
</FluereTabView>

Version and evidence baseline

perf2026 is not adopted: upstream ships TabView_perf2026.xaml (wired into TabView.vcxitems:43); this library keeps the 0.5.1 TitleBar ruling — not read, not referenced, no corresponding branch.

There is no TabViewItem.idl: the public API of TabViewItem / TabViewItemTemplateSettings / TabViewListView / both automation peers lives entirely in TabView.idl:203-285.

Template and metrics

Metric values come from TabView_themeresources.xaml:239-269:

Keyboard (item by item)

TabView has no OnKeyDown; it owns three KeyboardAccelerators (scope = this TabView, so they also fire while focus is inside the content) plus a KeyDown subscription on the add button. Arrow keys live on TabViewItem.

Keys the source does not implement (negative evidence, do not invent): Ctrl+T / Ctrl+W / Ctrl+1..9 / Home / End / Delete / Escape. Those belong to the host app (WinUI Gallery / Terminal bind them themselves).

Browser caveat: Chrome and Edge reserve Ctrl+Tab / Ctrl+F4 for switching and closing browser tabs, so the page may never see the keydown. The component implements them regardless; usability depends on the host.

Selection and closing semantics

• Focus movement does not change selection (SingleSelectionFollowsFocus=False): arrow keys only move focus; Ctrl+Tab, clicks, Space and Enter change selection.
• The component never removes tabs: the close button and Ctrl+F4 only raise tabCloseRequested (matching TabView.TabCloseRequested; TabViewItem.CloseRequested is folded into the same event). Whether to remove — and what to select next — is the consumer's decision.
• Removing the selected tab migrates the selection using TabView::OnItemsChanged: start = min(removedIndex, count - 1), then scan forward with wrapping for the first enabled tab; if the full loop finds none, nothing stays selected. In controlled mode the result is reported back through update:selectedIndex.
• Identity following: with a :key (or value) on the items, inserting or reordering in front of the selected tab keeps it selected (equivalent to WinUI's SelectedItem); without a stable identity the component falls back to index semantics.
• Focus restoration: when the focus sat inside the old panel (which gets unmounted), it is moved into the first focusable element of the new panel, falling back to the tab itself — matching UpdateTabContent.
• The add button only raises events and additionally announces "New tab added." through a polite aria-live region (mirroring upstream's UIA ItemAdded notification).

<FluereTabView
  v-model:selected-index="selected"
  label="Closable tabs"
  @tab-close-requested="onCloseRequested"
  @add-tab-button-click="onAddClick"
>
  <FluereTabViewItem v-for="(id, index) in openIds" :key="id" :header="titleOf(id, index)">
    …
  </FluereTabViewItem>
</FluereTabView>

Width modes (tabWidthMode)

<FluereTabView :tab-width-mode="mode" :default-selected-index="0" label="Width mode">
  <FluereTabViewItem header="Tab one">…</FluereTabViewItem>
  <FluereTabViewItem header="Tab two">…</FluereTabViewItem>
</FluereTabView>

Overflow scrolling

When space runs out the tabs are squeezed to their floor first, then overflow: in equal mode (the default) each tab is clamp(available / count, 100, 240), so tabs shrink to TabViewItemMinWidth = 100 before anything overflows; once they really do overflow (scrollWidth - clientWidth > 0.5) two scroll buttons appear — 50 px steps, with "backward" disabled at the left edge and "forward" disabled at the right edge (threshold 0.1), and holding a button scrolls continuously: one step on press, then a repeat every 100ms after a 50ms delay (matching the upstream RepeatButton's Delay="50" Interval="100", TabView.xaml:158,165).

No scrollbar is drawn while overflowing: the upstream TabScrollViewerStyle template (TabView.xaml:133-173) contains no scrollbar part — only the ScrollContentPresenter plus the two arrow containers. ScrollViewer.ComputedHorizontalScrollBarVisibility is bound solely to those two containers' Visibility (:157,163), i.e. it decides whether the arrows show, nothing else. This library mirrors that: overflow-x: auto keeps native scrolling (wheel / Shift + wheel / touch / horizontal wheel deltas) while scrollbar-width: none + ::-webkit-scrollbar hides the native scrollbar. The tab height therefore stays 32 and the strip row stays 40 (8 + 32): a classic scrollbar adds ≈ 15px to that row (measured 40 → 55 in a headful Chromium), inflating the strip and squeezing the content.

Both buttons are tabindex="-1" + aria-hidden="true" — out of the tab order and hidden from screen readers, matching WinUI's IsTabStop=False + AccessibilityView=Raw. With the scrollbar hidden the mouse has the arrows and the wheel (WinUI's strip has no scrollbar either, so this is alignment rather than a concession).

Known caveat: inside a FluereScrollView (such as this documentation site) vertical wheel input is claimed by the outer scroller under the "nearest scrollable container owns the wheel" rule — with the pointer over the tab strip, Shift + wheel will not scroll the strip (horizontal wheel deltas and trackpad horizontal swipes are unaffected). On a standalone page Shift + wheel scrolls the strip horizontally (verified with a minimal reproduction). That is pre-existing scroll-chain behaviour, not a consequence of hiding the scrollbar.

<div class="w-[480px] overflow-hidden">
  <FluereTabView :default-selected-index="0" label="Overflowing tab strip">
    <FluereTabViewItem v-for="title in titles" :key="title" :header="title">…</FluereTabViewItem>
  </FluereTabView>
</div>

States and the close button

Every state switches instantly: upstream's hover / pressed / selected / disabled are plain VisualState.Setters and every GoToState(..., false); the file contains no EasingFunction at all. The component therefore writes no transition.

closeButtonOverlayMode has three values: auto (default) and always take the same default: branch (always visible); only on-pointer-over hides the button until hover or selection. That is the literal source behaviour — do not read auto as "smart".

<FluereTabView :close-button-overlay-mode="overlayMode" :default-selected-index="0" label="States">
  <FluereTabViewItem header="Closable (selected)">…</FluereTabViewItem>
  <FluereTabViewItem header="Closable (unselected)">…</FluereTabViewItem>
  <FluereTabViewItem header="Not closable" :is-closable="false">…</FluereTabViewItem>
  <FluereTabViewItem header="Disabled" disabled>…</FluereTabViewItem>
</FluereTabView>

Differences from WinUI (item by item)

1. Items are data-only child components: FluereTabViewItem never mounts (the parent reads its props/slots during render), so it cannot emit; TabViewItem.CloseRequested is folded into the root tabCloseRequested. Item slots do not receive scope arguments (#header="{ … }" gets nothing).
2. Items must be direct children of FluereTabView (they may sit inside v-for / <template> / v-if). Wrapping them in an extra element or custom component makes them ignored, with a development warning.
3. No TabItemsSource / TabItemTemplate / virtualization: use v-for plus child components on the web.
4. No AddTabButtonCommand: only addTabButtonClick.
5. The base library renders disabled="false" on the role="tab" element: browsers and AT ignore that attribute on non-form elements, so disabled semantics are carried by aria-disabled (styles always key off [data-disabled]).
6. Ellipsis instead of hard clipping for long headers: WinUI's ContentPresenter sets no TextTrimming (text is clipped mid-glyph); the web side uses text-overflow: ellipsis. This is the only deliberate typography difference.
7. The 4×4 concave corners of the selected background are expressed with a CSS mask: upstream draws a runtime-generated path plus two arc patches — equivalent geometry, not pixel-identical (see "evidence gaps").
8. The TabViewBorderBrush mapping: in Light / Default it is an alias to CardStrokeColorDefault (a Color, not a Brush) and the implicit conversion cannot be proven from source; this library treats it as the same value and reuses the existing mapping --colorNeutralStrokeAlpha (what InfoBar / ContentDialog already do).
9. Not implemented: drag reordering, tear-out, middle-click close, TabStripDragOver / TabStripDrop / TabDrag* events, ItemContainerTransitions (their durations/keyframes are outside the control directory) and a high-contrast palette (only a forced-colors focus-ring fallback).

API

FluereTabView

FluereTabViewItem

Browser measurements (reproducible)

Playwright with the system Chrome (1280×900 / DPR 1) against this page: base geometry via temp/pw-tab-view.mjs (53 assertions), the overflow scrollbar / hold-to-repeat specifics via temp/pw-tab-view-overflow.mjs (21 assertions, headful required — overlay-scrollbar environments cannot reproduce that 15 px):

Two real bugs the browser run caught (all numeric assertions were green at the time): ① kebab-case template props (:is-closable="false") keep the key is-closable in the raw vnode props, so matching only camelCase treated false as "not passed" and the close button still rendered (see collection.ts#readProp); ② the selected background is a positioned pseudo-element and, by paint order, covered the in-flow icon and text, leaving the selected tab a solid block of colour (content is now lifted to the same layer, guarded by an elementFromPoint assertion).

Implementation notes and evidence gaps

• Items are collected during render (collection.ts): provide/inject registration only receives data after a descendant's setup(), which would leave the whole strip missing from SSR output; instead the parent reads the child vnodes' props/slots while rendering (equivalent to React's cloneElement), producing the full list in a single pass.
• Selection resolution is a pure function (resolveSelectedIndex): no reactive writes during render, so SSR and hydration agree; migration results are synced back or emitted from onUpdated.
• Equal widths are measured in code: upstream's UpdateTabWidths does the same. CSS cannot express it — the scroller's width derives from its content, so flex: 1 1 0 would be circular. Until a measurement exists, CSS falls back to inline-size: auto (still clamped by min / max).
• Evidence gaps: ① the selected-background path is generated at runtime with StringCchPrintf + XamlReader::Load, so no literal string exists in the repo to compare against; ② the durations/keyframes of the three ThemeTransitions (AddDeleteThemeTransition etc.) and the drag theme animations live outside the control directory; ③ high-contrast colours all come from the OS at runtime; ④ the Color → Brush implicit conversion for TabViewBorderBrush is unproven; ⑤ upstream's TabViewTests.KeyboardTest is marked Ignore (#7546), so Space-class semantics are reference only.