{"id":10678,"date":"2026-08-13T16:31:22","date_gmt":"2026-08-13T21:31:22","guid":{"rendered":"https:\/\/master.dev\/blog\/?p=10678"},"modified":"2026-08-13T16:31:23","modified_gmt":"2026-08-13T21:31:23","slug":"delayed-then-instant-tooltips-with-html-css-alone","status":"publish","type":"post","link":"https:\/\/master.dev\/blog\/delayed-then-instant-tooltips-with-html-css-alone\/","title":{"rendered":"Delayed-Then-Instant Tooltips with HTML & CSS Alone"},"content":{"rendered":"\n

Hey! This post is a response to Abhishek Jakhar’s post about delayed tooltips<\/a>, or, perhaps better put, a second part showing an alternative approach to the same problem.<\/p>\n\n\n\n

I really like Abhishek’s focus on the UX of the tooltips in his app. Both are true: a tooltip that comes up too fast is annoying for just-passing-by mouse cursors, and if you add a delay, they come up too slowly for someone intentionally mousing between them.<\/p>\n\n\n\n

That’s just good UX thinking, and I like to see it.<\/p>\n\n\n\n

But also, the solutions are quite deep into JavaScript land. The core of the solution is a setTimeout<\/code>\/clearTimeout<\/code> which sets a “warmed” state that determines the tooltip’s open timing. It’s all done in React, so the React components need to share and pass around state. There is useRef<\/code>, useState<\/code>, useEffect<\/code>, useMemo<\/code>, and even createContext<\/code>\/useContext<\/code> all being used to do this.<\/p>\n\n\n\n

I would push back against that if that was the technology being used just<\/em> for this, but that’s almost surely not the case. Abhishek said it’s a part of his larger app, which surely has much more going on, and just so happens to already be in React with Radix and Motion. So he’s implementing a solution within the context of what is already going on, which is understandable.<\/p>\n\n\n\n

What I’d like to say is:<\/strong> you don’t need all that just for the UX we’re shooting for here. We can do all this in HTML and CSS with no JavaScript at all. And that solution would work in React-and-friends too, so ultimately might be a better solution overall. <\/p>\n\n\n\n

A Master developer has many tools \ud83d\ude09.<\/p>\n\n\n\n

A Semantic HTML Foundation<\/h2>\n\n\n\n

Here’s a decent tooltip setup:<\/p>\n\n\n

<button<\/span>\n  interestfor<\/span>=\"tip-1\"<\/span>\n  aria-labelledby<\/span>=\"tip-1\"<\/span>\n><\/span>\n  <svg<\/span> ...<\/span>><\/span><\/svg<\/span>><\/span>\n<\/button<\/span>><\/span>\n<span<\/span> id<\/span>=\"tip-1\"<\/span> popover<\/span>=\"hint\"<\/span>><\/span>\n  I'm the tooltip.\n<\/span<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
Believe it or not, this HTML alone produces a working tooltip. Hover over the button; you’ll see the HTML tooltip. Hover off, and it’s gone. <\/p>\n\n\n\n
That’s the magic of popovers, and the additional magic of popover=\"hint\"<\/code> and interestfor<\/code> which deals with “interest”, meaning hovers essentially (or other fancy stuff like you’re clearly gazing<\/em> at a bit of UI in the metaverse or some crap, which is why web standards is cool: they think of stuff like that). <\/p>\n\n\n\n
Anchoring the Tooltip (and Dealing with Edge Detection)<\/h2>\n\n\n\n
Another lovely little thing is that when a popover is opened, the “default” anchor is the element that opened it. So we can just use anchor positioning and assume the anchor is the button.<\/p>\n\n\n\n
So with just this:<\/p>\n\n\n
[popover]<\/span> {\n  position<\/span>: fixed;\n  background<\/span>: red;\n  color<\/span>: white;\n  position-area<\/span>: block-start;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
We’ll get a popover that opens above the button on hover:<\/p>\n\n\n\n