Prompt and context
The product wants a lightweight preview when a user shows interest in a username, document link, or term, but the content must remain usable when hover disappears, the user navigates by keyboard, or the device is touch-only. Use HTML interest invokers and the Popover API, and explain delays, focus, dismissal, unsupported browsers, and failed data loads.
MDN describes interestfor as a declarative way to associate a button or link with a target element; when the target is a popover, the browser can show it automatically while interest is present. The Open UI explainer documents the motivation for hovercards. This article synthesizes public material and does not claim to be a company-specific interview question.
What the interviewer is testing
The interviewer wants to see whether you treat “hover” as one interest state covering pointer, focus, touch, and assistive technology. A strong answer mentions interest/loseinterest, interest-delay-*, the popover top layer, focus management, a no-JavaScript core path, and progressive enhancement; a weak answer only binds mouseenter/mouseleave.
Questions to clarify first
- Is the preview supplemental information or required to complete the task?
- Is the target content same-origin and cacheable, and may it load lazily?
- How should touch devices open and close it, and should a tap navigate to the detail page?
- How does the core link stay usable when the browser lacks interest invokers?
A 30-second answer
“I would keep the normal link pointing to the detail page and use interestfor to associate it with a popover preview. Interest delays reduce accidental activation; where supported, declarative behavior covers pointer and focus. Unsupported browsers do not lose the link, and a minimal JavaScript polyfill can add the preview. Preview data may load asynchronously but must not block navigation. Dismissal respects focus and Escape semantics, and reduced motion removes the animation.”
Step-by-step solution
Structurally, the link or button is the interest invoker, while the target has a stable id and popover. The invoker’s interestfor value references that id. If the target is a popover, the platform places it in the top layer and applies popover lifecycle behavior; the target can also be an ordinary element that the application shows after listening for interest events.
Delays prevent a fast pointer sweep across links from starting many requests. Use interest-delay-start and interest-delay-end, or equivalent application throttling, show a skeleton first, and fetch by a cache key. When interest leaves the invoker, enters the target popover, or moves to another link, cancel unfinished work and let the latest intent win.
Keyboard and touch cannot depend on hover. Focusing the link should expose the same preview, Escape should close it, and Tab order should still reach the detail page. On touch, the product can show the preview on the first tap and navigate on the second, or navigate directly while offering a separate preview control; choose one explicit rule to avoid gesture conflicts.
Accessibility requires a readable target name, correct relationships, and state feedback. When the preview is supplemental, do not force focus into the popover; if it contains interactive controls, define a clear focus-entry and return path. Screen-reader users must be able to reach the detail page directly, even when preview loading fails.
Capability detection and fallback protect the core path. Without interestfor or the Popover API, the link navigates normally, while the preview can degrade to click-to-open or be omitted. A polyfill should add display behavior only, rather than reimplementing every top-layer, focus, and security boundary; measure support rate, preview-open rate, load failures, and navigation conversion.
Example of a strong answer
I would make the link the core navigation and the interest invoker an optional preview layer. interestfor references a stable id and the target uses popover; the platform handles pointer/focus interest while delays and caching control requests. Keyboard focus works, Escape dismisses, and touch follows an explicit tap rule. Unsupported browsers keep the normal link, and a preview failure affects only the supplemental layer, not access to the detail page.
Common mistakes
- Symptom → Listen only to mouseenter; why it fails → Keyboard, touch, and assistive technology cannot trigger it; fix → Center interest and focus, while keeping navigation.
- Symptom → Move focus into the preview as soon as it appears; why it fails → It interrupts someone reading the link; fix → Move focus only when interactive controls and an explicit rule require it.
- Symptom → Fetch on every hover; why it fails → Fast sweeps create a request storm; fix → Use delays, cancellation, caching, and latest-intent-wins handling.
- Symptom → Block the link when unsupported; why it fails → An experimental API becomes a dependency for core content; fix → Keep the ordinary link as an unconditional fallback.
Follow-up questions and answers
Why does the preview target not always need popover?
interestfor can associate an invoker with an ordinary target, after which application code listens for interest events and controls display. A popover gives the platform top-layer and dismissal semantics. Choose based on whether native lifecycle behavior and lightweight declarative control are useful.
How do you stop the preview from covering another link?
Give the target stable positioning and collision rules, use an end delay when leaving, and treat entering the popover as continued interest. During a fast switch, cancel the old request, close the old target, and commit only the latest invoker’s result.
What should happen when preview loading fails?
Show a short retryable state inside the preview and provide a direct detail link; keep the error out of the page’s primary content. Record the failure reason and latency, and skip preview animation or navigate directly when the budget is exceeded.