Prompt and context
You need a profile preview that appears on pointer hover, keyboard focus, or a long press, then hides when interest ends. Explain how you would use interestfor and handle compatibility, focus, delays, and content that should not be hover-triggered.
The Popover API interest invoker lets a button or link point to a target ID in the same tree with interestfor. The target can be a popover="hint" preview card. The browser shows it when the invoker becomes interesting through hover, focus, or long press and hides it when interest ends. This fits brief, non-critical help; it must not be the only way to discover information or an action.
What the interviewer is testing
The interviewer wants to see whether you distinguish interest from activation, understand the target ID, popover state, and InterestEvent, and can cover keyboard, touch, delay, compatibility, accessibility, and the cases where an explicit click or normal link is safer.
Clarifying questions
Confirm whether the surface is a hint, preview, or menu with controls; the browser support matrix; touch requirements; whether the content is critical; and whether the target is in the same DOM tree. Also clarify whether users may enter and remain in the surface, the show and hide delays, focus-return rules, and the minimum no-JavaScript experience.
30-second answer
“I would use a native button or link with interestfor pointing at a Popover hint, while keeping the profile name and normal link as the primary path. The interest invoker supplies hover, focus, and long-press visibility; I would use interest-delay, or an equivalent strategy, to reduce flicker. I would feature-detect support and fall back to focus and click listeners. Preview text must remain available to keyboard and touch users, and anything with side effects or a full interaction model should use explicit activation.”
Deep-dive answer
Step 1: Create the interest relationship
The interestfor value points to the target element's ID, and the target and invoker must be in the same tree. A minimal example is:
<button interestfor="profile-preview" aria-label="Read Ada's profile">
Ada Lovelace
</button>
<article id="profile-preview" popover="hint">
Early computing pioneer; the profile page contains the full biography.
</article>The button remains a focusable native control; the preview is supplementary and is not the only route to the profile.
Step 2: Separate interest from activation
Interest is transient feedback for previews, explanations, and extra context. A click or Enter key is activation for navigation, submission, or an irreversible action. Do not hide delete, purchase, or confirmation controls inside a surface that appears only through interest.
Step 3: Respect the Popover boundary
The browser owns the display state of a popover="hint" target. Avoid another script forcing the same state, because two owners can race. If the surface needs a menu keyboard model, focus trapping, or complex state, evaluate an explicit menu, dialog, or component pattern.
Step 4: Control delay and flicker
The pointer can cross a boundary between the invoker and the preview quickly. Use interest-delay for show and hide timing, and design a continuous hit area between the trigger and target. Calibrate delays with pointer, keyboard, and touch tests instead of assuming one value fits every device.
Step 5: Cover keyboard and screen-reader paths
The native button or link can receive focus. The preview should have a clear name relationship without unexpectedly stealing focus. Keep the preview text available through a visible name, destination, or other static content; do not replace focus indication with hover or put an important error only in the preview.
Step 6: Account for touch and long press
Touch has no traditional hover. Long-press interest can provide a preview, but it must not block a normal tap or scrolling. Keep a direct tap path for important actions, and test small screens for occlusion, viewport overflow, and closing behavior.
Step 7: Feature-detect and degrade
Do not assume every runtime supports interestfor. Feature-detect HTMLButtonElement.prototype.interestForElement; when absent, retain ordinary HTML content and links, then add a basic preview with focus, pointer, or click listeners. The fallback should add capability without rendering a second source of truth.
Step 8: Test lifecycle and boundaries
Test pointer enter and leave, moving from invoker to preview, Tab and Shift+Tab, long press, scrolling, Escape, rapid re-entry, and dynamic target removal. Verify the accessibility tree, boundaries, delay, no-JavaScript content, and the target browser matrix; an MDN availability label is not a substitute for project testing.
Model answer
I would make the avatar a native link or button and point interestfor at a popover="hint" preview in the same tree. The preview adds context, while the name and profile link remain visible in static content. Interest covers pointer, focus, and long press; interest-delay and a continuous hit area reduce flicker. Before implementation I would detect interestForElement; unsupported browsers keep the ordinary content and receive the same focus, pointer, or click behavior through a fallback. Delete, purchase, menu, or other side-effecting content should use explicit activation rather than an interest-only surface. I would verify keyboard, touch, screen reader, scrolling, Escape, dynamic removal, and the target browser matrix.
Common mistakes
Treating interestfor as a generic tooltip attribute
It establishes an interest-invoker relationship and relies on Popover-related browser behavior. A target that needs a menu model or complex state needs the appropriate component semantics.
Implementing only hover CSS
Keyboard users do not have pointer hover, and touch has a different gesture model. Keep focus behavior, a tap path, and static information.
Making the preview the only source of critical content
Users may run an unsupported browser, disable scripts, or be unable to long-press. Critical names, status, and actions must remain in primary content or an explicit activation path.
Follow-up questions and answers
What if the browser does not support interestfor?
Keep ordinary HTML, links, and focus styles complete first, then feature-detect. The fallback adds preview behavior without changing navigation or the information structure, and it is tested in the support matrix.
How do you prevent flicker between the invoker and preview?
Use a continuous hit area, show and hide delays, and preserve interest while entering the target. Do not let multiple scripts own the Popover state; log enter, leave, and removal order when diagnosing races.
Should focus move into the preview when the invoker receives focus?
For a pure preview, usually no: keep focus on the invoker and expose a clear accessible name. If the surface contains controls, switch to an explicitly activated menu or dialog with defined entry, Escape, and return behavior.
How do you handle long press versus tap?
Long-press preview must not block tap navigation or scrolling. Keep a tap target for important actions and test long press, short tap, scroll, and viewport edges on real devices.
What value should interest-delay use?
There is no universal cross-device value. Measure entry, exit, and rapid-movement cases against content density and accidental-trigger cost. Provide immediate focus feedback so keyboard users are not waiting for a pointer-oriented delay.
When should you avoid interest invokers?
Avoid them when content is critical, actions have side effects, focus management is complex, coordination crosses trees, or older browsers are mandatory. Interest invokers are best for low-risk, transient supplementary previews.