Tooltip
Delayed entrance timing and collision-aware placement — the first component where *not* animating immediately is the actual lesson.
Hover across these quickly — only the first waits for the delay
Normal case — shows on your preferred side, no obstruction
Boxed in on purpose — watch it flip to whichever side actually fits
Tooltip knobs
ms
ms
ms
How this works
Every other component in this library reacts the instant you interact with it. A tooltip is the opposite: showing up instantly on every passing hover would be exhausting, so the interesting design decision here is entirely about when to wait and when not to.
- Hover-intent delay
- How long your mouse has to sit on the trigger before the tooltip appears. At 0ms, every mouse pass over the toolbar lights up a tooltip — noisy and distracting. At 1000ms, even a deliberate hover feels like it's ignoring you. The default, 400ms, is long enough to filter out 'just passing through' and short enough to still feel responsive to real intent.
- Group grace window
- Hover the toolbar buttons above one at a time, slowly — each one waits out the full delay. Now hover across them quickly — only the first one waits. This window is how long that 'you've already shown intent' grace period lasts after a tooltip closes. At 0ms, every tooltip in the row goes back to the full delay, even when scanning across them takes half a second. At 1000ms, the grace period outlives most people's actual scan time.
- Show/hide duration
- How long the fade + slight rise takes once the tooltip decides to show (and the reverse on hide, at about 70% of this length — exits are always faster than entrances in this library). This is a genuine motion duration, unlike the delay above, which is pure timing with no animation of its own.
- Preferred position
- The side you'd like the tooltip to appear on — but it's a preference, not a guarantee. The left demo has room in every direction, so it just shows wherever you asked. The right demo is boxed in on purpose: no matter which side you pick, the tooltip automatically flips to whichever one actually fits, rather than rendering off-screen or getting clipped. That collision check runs on a real positioning engine (Floating UI), not hand-rolled math, which is exactly the kind of solved problem not worth reinventing.
- Why keyboard focus matters here
- This tooltip shows on keyboard focus, not just mouse hover — a keyboard-only user tabbing through the toolbar needs the same information a mouse user gets from hovering. Skipping this is one of the most common tooltip accessibility failures.