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.