Tooltips need a delay, and then they need to skip it
blog.master.dev
August 25, 2026
8 min read
54/100
Summary
FrontPrep changed its company-logo tooltips to avoid opening during incidental cursor movement while keeping navigation among adjacent logos responsive. A logo tooltip now waits 200ms before opening, so cursors that pass across a trigger quickly do not display it. Leaving an open tooltip closes it immediately and starts a 300ms “warm” window. During that 300ms window, hovering another logo opens its tooltip instantly and skips the entrance animation. Each newly opened tooltip cancels the prior cooldown, keeping the page warm while users move between nearby triggers. When the cooldown expires, the page returns to a cold state and the next tooltip again requires the 200ms hover delay. The implementation shares warm-state data through a React provider, stores it in refs to avoid re-rendering every tooltip, and clears pending open timers when the cursor leaves before a tooltip opens. The implementation uses Radix and Motion in FrontPrep, with a simpler React example showing the timing logic. The author recommends 200ms as a balance: delays below 150ms can allow unintended cursor passes to open tooltips, while delays above 250ms can feel slow. A Claude skill is provided to audit tooltip timing across codebases, specifying a 200ms opening delay, 300ms warm window, and zero close delay.
Key Takeaways
- FrontPrep tooltips wait 200ms before opening, preventing brief cursor passes over company logos from triggering pop-ups.
- After an open tooltip closes, a 300ms warm window lets tooltips on nearby triggers open instantly without entrance animation.
- The shared warm state is stored in React refs and read by event handlers, avoiding page-wide tooltip re-renders when the state changes.
- A Claude skill defines tooltip timing guidance with a 200ms opening delay, 300ms warm window, and immediate close behavior.
What the discussion said
The discussion was overwhelmingly about conventional interface design rather than AI or machine learning, so there is very little AI-specific sentiment to extract. Commenters focused on delayed hover behavior, older desktop-interface precedents, and whether tooltip timing should adapt to pointer movement. Those observations do not bear on model capability, AI products, training, safety, or AI-driven developer tooling and are therefore excluded from the sentiment lists. The sole AI-adjacent thread questioned whether the article’s solution section had been produced with Claude or a similar language model. That reader’s objection was stylistic rather than evidentiary: the prose felt unusually procedural and impersonal, like an automated agent’s write-up rather than a human explanation. No one supplied confirmation, challenged the claim, or turned it into a broader argument about AI-authored technical content. As a result, the thread offers neither meaningful enthusiasm for AI nor a substantive critique of an AI system’s performance or impact. The limited negative signal is skepticism that LLM-shaped writing can feel uncanny and weaken confidence in technical exposition, even when the underlying interface idea may be sound.
Community Sentiment
Concerns
- One reader found the solution prose unnervingly similar to an LLM agent report, suggesting AI-shaped technical writing can feel impersonal enough to undermine trust in the explanation.