Prompt and scope
This question tests whether “place it beside the button” becomes a verifiable layout and interaction contract. Cover anchor-name, anchor(), candidate positions, overflow, scrolling, feature detection, and keyboard and focus behavior for a menu or dialog.
What the interviewer is evaluating
- A stable anchor relationship and the roles of
position-area,anchor(), and fallback positions. - Visibility under viewport edges, scroll containers, zoom, and dynamic content.
- Progressive enhancement rather than a hard dependency on JavaScript measurement.
- Correct semantics and behavior for menus, tooltips, and dialogs.
- Browser-matrix, visual-regression, keyboard, and screen-reader verification.
Recommended answer structure
Define the popover type, anchor, and minimum visible area. Give the CSS path with anchor naming, preferred position, fallbacks, and hiding rules. Then describe @supports fallback to the existing positioning component, followed by focus, scrolling, dynamic size, and tests.
Deep dive: usable and accessible positioning
Create a stable anchor
Give the trigger a unique anchor-name; use position-anchor or an explicit reference on the popover. For repeated rows, create a stable relationship per row and clear state on unmount instead of guessing from DOM adjacency.
Define candidates and overflow rules
Use position-area or anchor() for the preferred side, then position-try-fallbacks or equivalent rules for the opposite side, edge alignment, and reduced size. Set a maximum block size and internal scrolling. If it cannot fit, hide it or switch to a full-screen panel instead of clipping content.
Handle scrolling and dynamic size
When the anchor moves inside a scroll container, verify the containing block and stacking context. Recheck visibility after asynchronous content, font loading, and zoom changes. Avoid hand-written scroll measurement on the native path.
Add progressive enhancement
Use @supports (anchor-name: --trigger). Supported browsers use CSS; others reuse the existing portal and positioning logic with bounded measurements, cleanup, and flip handling. Both paths share menu state and accessibility rules.
Match semantics to the task
Menus use menu items and a documented arrow-key model. A tooltip must not contain required actions. Use a dialog only when the background is truly blocked; a modal manages entry focus, Tab behavior, Escape, and focus restoration.
Sample answer
“I would make the filter a non-modal menu. The button gets a stable anchor-name; the menu uses position-anchor below it, with fallbacks above and along the viewport edges and a maximum height for internal scrolling. If @supports fails, the existing portal positioner handles layout while state and keyboard behavior stay shared. Opening moves focus to the first item, arrows move within the menu, and Escape or outside click closes it and returns focus to the button. I would test narrow viewports, scroll containers, zoom, asynchronous content, and clipping with screenshots, keyboard checks, and screen-reader checks.”
Common failure modes and fixes
- Only setting
topandleft→ Explain candidates, overflow, size limits, and fallbacks. - Making every popover modal → Classify menus, tooltips, and dialogs by task.
- Ignoring unsupported browsers → Provide
@supportsand the existing positioning fallback. - Testing only a fixed desktop window → Include scrolling, zoom, narrow screens, dynamic content, and keyboard use.
- Treating focus as a CSS concern → Define open, move, close, and restore-focus states.
Scoring rubric and self-check
Strong answers include stable anchors, candidate positions, overflow and hide rules, progressive enhancement, scroll and dynamic-size boundaries, correct semantics, focus management, a test matrix, and observability.
Ask: Is the anchor stable? What if the menu does not fit? Who positions it in a scrolling container? What does an old browser do? Where does focus return? How do I prove no clipping, jumps, or unreachable content?
Follow-ups and extensions
How do anchor() and position-area differ?
position-area expresses a region relative to the anchor; anchor() exposes an edge or size for insets, offsets, and calculations. They can be combined, but still need fallbacks and size limits.
What if the menu is taller than the viewport?
Limit its block size and scroll its contents. On small screens, switch to a full-screen or bottom sheet when that better supports the task. Do not leave content outside the viewport.
How do you test positioning candidates?
Generate screenshots across viewport sizes, scroll positions, zoom, fonts, and content lengths. Assert the visible area, focus order, and the focus target after closing.
When is JavaScript positioning still appropriate?
Keep a JavaScript fallback for old browsers, complex portal boundaries, or business collision data. Let CSS handle supported browsers and use JavaScript only for the capability gap and state synchronization.