Popover

Usage

Overview

A popover anchors floating content to a trigger without taking over the viewport like a Dialog does. It suits contextual actions, compact forms, filters, and explanatory content operators can finish and dismiss quickly. The mental model is "work beside your place on the page"—surrounding context stays visible and a single Escape returns the operator to their task.

Flag call for QAShares the call and transcript with the QA reviewer team.

When to use

Small forms (a few fields) tied to a specific element.
Filters or settings that should not navigate away.
Rich helper content too large for a Tooltip but smaller than a Dialog.
Menu-adjacent surfaces when the design calls for a floating panel rather than a strict dropdown menu.

When not to use

Mission-critical confirmations—use Dialog.
Long scrolling workflows—use Drawer or a full page.
Essential information with no other visible path. Surface it inline.
Single-line hints on desktop—a Tooltip is lighter; on mobile prefer inline text.

Anchor side

Side and alignment determine whether the popover collides with the viewport or the operator's focus target.

Bottom is the typical default in dispatch dense views; flip to top when the trigger sits near the bottom edge.
Left / right for vertically constrained rows (inspectors, sidebars).
Virtual anchor for calculated positions (pointer coordinates, computed cells); test scroll and resize so the popover doesn't drift.

Content guidelines

Keep copy tight. If operators must read more than a short paragraph, the container is wrong.
Titles are optional but useful when the panel has multiple sections.
Actions use verb-led labels; don't duplicate actions already visible on the page behind the popover.
Localize strings; verify translated labels don't clip at constrained widths.

Behavior and states

Focus on open. Move focus into the popover when it contains inputs. Read-only panels may leave focus on the trigger.
Dismissal. Outside click, Escape, and the explicit close button all work and restore focus to the trigger.
Scroll. Long content scrolls inside the panel; avoid stacked scrollbars with the page when possible.
Concurrent popovers. Opening one in a region typically closes others so operators don't get trapped in overlapping surfaces.

Best practices

Choose triggers that look interactive (button, icon button) and have accessible names.
Lazy-load heavy inner content if the popover is rarely opened.
Offset slightly so the trigger and content don't obscure each other.

Don't

Embed another full interactive app without managing focus and tab order.
Use popovers for errors that must be seen globally—those belong in toasts or banners.
Hide the only way to complete a task inside a popover on mobile where touch targets are unreliable.

Accessibility

Interactive content inside the popover must be keyboard reachable; hover-only opening is never sufficient for essential tasks. Triggers expose aria-expanded when the popover behaves as disclosure. See Accessibility for the full contract.

Tooltip for supplemental hints.
Dialog for blocking confirmation.
Drawer for longer contextual tasks.
Menu for action lists.

Pie Chart / Accessibility

Popover / API and Development

On this page

Popover

Usage

Overview

Flag call for QAShares the call and transcript with the QA reviewer team.

When to use

Small forms (a few fields) tied to a specific element.
Filters or settings that should not navigate away.
Rich helper content too large for a Tooltip but smaller than a Dialog.
Menu-adjacent surfaces when the design calls for a floating panel rather than a strict dropdown menu.

When not to use

Mission-critical confirmations—use Dialog.
Long scrolling workflows—use Drawer or a full page.
Essential information with no other visible path. Surface it inline.
Single-line hints on desktop—a Tooltip is lighter; on mobile prefer inline text.

Anchor side

Side and alignment determine whether the popover collides with the viewport or the operator's focus target.

Bottom is the typical default in dispatch dense views; flip to top when the trigger sits near the bottom edge.
Left / right for vertically constrained rows (inspectors, sidebars).
Virtual anchor for calculated positions (pointer coordinates, computed cells); test scroll and resize so the popover doesn't drift.

Content guidelines

Keep copy tight. If operators must read more than a short paragraph, the container is wrong.
Titles are optional but useful when the panel has multiple sections.
Actions use verb-led labels; don't duplicate actions already visible on the page behind the popover.
Localize strings; verify translated labels don't clip at constrained widths.

Behavior and states

Focus on open. Move focus into the popover when it contains inputs. Read-only panels may leave focus on the trigger.
Dismissal. Outside click, Escape, and the explicit close button all work and restore focus to the trigger.
Scroll. Long content scrolls inside the panel; avoid stacked scrollbars with the page when possible.
Concurrent popovers. Opening one in a region typically closes others so operators don't get trapped in overlapping surfaces.

Best practices

Choose triggers that look interactive (button, icon button) and have accessible names.
Lazy-load heavy inner content if the popover is rarely opened.
Offset slightly so the trigger and content don't obscure each other.

Don't

Embed another full interactive app without managing focus and tab order.
Use popovers for errors that must be seen globally—those belong in toasts or banners.
Hide the only way to complete a task inside a popover on mobile where touch targets are unreliable.

Accessibility

Tooltip for supplemental hints.
Dialog for blocking confirmation.
Drawer for longer contextual tasks.
Menu for action lists.

Pie Chart / Accessibility

Popover / API and Development

On this page