# Tabs

Display tab content.

## Default

AppleOrangeMango

Show code

## Disabled

AppleOrangeMango

Show code

## Disable specific tabs

AppleOrangeMango

Show code

## With icons

GitHub  
GitLab  
  
Bitbucket

Show code

## Secondary

GitHubGitLabBitbucket

Show code

## Best Practices

### When to use

- Use Tabs to switch between sibling views inside a single page (`Overview`, `Logs`, `Settings`).
- For navigation between unrelated pages, use a sub-menu, not Tabs. Tabs imply the views share scope, URL parent, and data model.
- Cap a Tabs row at 5–7 entries on desktop and 3–4 on mobile. Past that, consolidate or move secondary views behind a Menu.

### Behavior

- Selecting a tab is instant; don’t trigger network confirmation or toast on tab change.
- Reflect the active tab in the URL (query param or path) so deep-links and refresh restore state.
- Disable individual tabs only for permission or empty-state reasons; pair the disabled tab with a `tooltip` that names the constraint.

### Content

- `tabs[].title` is Title Case, 1–2 words, and names the destination noun (`Overview`, `Logs`, `Settings`). Verbs belong on buttons; `View Logs` is wrong on a tab.
- `tabs[].tooltip` is sentence case and explains the constraint (`Only visible to project owners.`), not the tab’s purpose.
- Don’t append a count to the title (`Logs (12)`); use a badge slot instead and drop the badge at zero.

### Accessibility

- Keep Left/Right arrows moving focus across tabs and Enter/Space activating; don’t hijack with global shortcuts.
- Label the tablist with `aria-label` when no visible heading sits above it (`aria-label="Sections"`).
- Maintain a visible focus ring on the active tab; don’t suppress focus styles for visual polish.