Prompt and context
You maintain a highly reused tooltip component. CSS anchor positioning attaches it to a trigger and position-try fallbacks prevent overflow, but when the popover moves to another side its arrow, scroll area, and padding remain wrong.
Design a CSS-first solution that lets fallback placement drive styles, isolates repeated instances, and degrades safely when anchor positioning is unavailable.
What the interviewer tests
- Whether you understand anchor positioning relationships and fallback selection.
- Whether anchored container queries can read actual placement instead of copying JavaScript state.
- Whether accessibility, scroll boundaries, stacking, and repeated-component isolation are addressed.
- Whether feature detection, static layout, and progressive enhancement are included.
Questions to clarify
- Is the tooltip plain text, a menu, or an interactive dialog?
- Do fallbacks switch sides or enter a scrolling container?
- Do target browsers support anchor positioning and container queries?
- May JavaScript read dimensions, or must the solution be CSS-only?
30-second answer
I would make the trigger an anchor and the tooltip an anchor-positioned container with ordered position-try fallbacks. Each fallback uses an anchored container query to change the arrow, padding, and maximum height; internal styles depend only on the component container. Use @supports for feature detection, with static or existing JavaScript positioning as the fallback while preserving the accessible description relationship. Test viewport edges, zoom, scroll containers, and long text to prove no overflow or focus clipping.
Step-by-step deep dive
Establish the anchor and candidate positions
Declare anchor-name on the trigger and connect the tooltip with position-anchor and inset/anchor(). Describe candidate order with position-try fallbacks instead of hard-coding direction in component logic.
Make the popover a query container
Set container-type so an anchored container query inside the popover adapts to the selected fallback. Query the container condition associated with the anchored result rather than guessing from viewport width.
Synchronize arrow and scrolling
Use different arrow edges, transform-origin, max-block-size, and overflow for each placement. Long content scrolls inside the popover; the tooltip must not expand outside the viewport or clip keyboard focus.
Isolate repeated instances
Give each instance its own anchor name or naming scope so a list item cannot match another instance’s anchor. Keep stacking, position-area, and scrim rules local.
Feature-detect and degrade
Detect support with @supports (anchor-name: --x) and the required container-query capability. A fallback may use adjacent static content or an existing JavaScript positioner, but it keeps aria-describedby, keyboard dismissal, and focus order.
Verify boundaries and accessibility
Test narrow viewports, zoom, RTL, scroll containers, touch, and reduced motion. Use keyboard and screen readers to ensure the tooltip does not steal focus, get clipped, or become unreadable when fallback placement changes.
Model answer
I would declare the trigger as an anchor, make the tooltip a container, and provide ordered position-try fallbacks. An anchored container query inside the popover adapts the arrow, padding, maximum height, and scroll direction to actual placement; each instance isolates its anchor name and stacking rules. @supports provides progressive enhancement, while unsupported browsers use static or existing JavaScript positioning with the same aria-describedby, keyboard dismissal, and focus order. Test narrow viewports, zoom, RTL, scroll containers, long text, and screen readers.
Common mistakes
- Guessing fallback from viewport width in JavaScript instead of responding to actual placement.
- Sharing one anchor name across every tooltip and linking instances together.
- Changing top/left without synchronizing arrow, scroll, or transform-origin.
- Omitting
@supportsand leaving unsupported browsers with unusable popovers. - Testing only normal viewports and ignoring RTL, zoom, scroll containers, and keyboard focus.
- Treating a tooltip as a dialog without explicit accessible semantics.
Follow-up questions
How does an anchored container query differ from a normal container query?
It selects styles from the fallback placement of an anchor-positioned element; a normal container query primarily uses container size or style conditions.
What happens when anchor positioning is unsupported?
Use adjacent static layout or the existing JavaScript positioner with the same accessible name, dismissal, and content order; do not rely on a partial syntax path.
How do you stop a popover from covering focus?
Bound its size and scroll internally, then test Tab, Escape, screen readers, and the scroll parent so focused elements remain visible.
Why not use four directional media queries?
Media queries describe the viewport, not the actual anchor and container space; fallbacks also depend on scroll containers, fonts, and content length.