21 CSS Tooltips

A tooltip is a small panel of additional information revealed on hover (or focus) over a trigger element. The simplest tooltips are single-line labels; the richest are full documentation cards with prose, code, links, charts, and metadata. The behavior is consistent — absolutely-positioned child, opacity transition on :hover — but the typography, density, and motion belong to each individual use case. This collection treats twenty-one different use cases as twenty-one different design opportunities rather than twenty-one skins of the same gray rectangle.

Every demo in this collection is namespaced under a unique numeric prefix — .tp-01, .tp-02, .tp-03 and so on through .tp-21 — with BEM-style children like .tp-01__paper, .tp-01__note, .tp-01__hot. No demo defines a .tooltip or .tip class that could collide with anything else. You can drop any two of these onto the same page with zero style bleed. Adding a twenty-second tooltip is a matter of picking .tp-22 and scoping every selector under it.

These demos are hover-only and that's a real limitation. For production, you must add :focus-visible (or :focus-within) to every hover selector so keyboard users can reach the tooltip, and you must wire aria-describedby on the trigger pointing at the tooltip's id so screen readers announce the content. Tooltips that carry meaningful information (not just labels) also need to be dismissible without leaving the trigger — that requires a small piece of JavaScript and the Escape key. The CSS scaffolding is the easy part; production-grade tooltip accessibility is non-trivial. The W3C ARIA Authoring Practices Guide has the full pattern.

All twenty-one demos in this collection are pure CSS — no JavaScript required for hover, transition, animation, or the embedded data visualizations (status uptime bars, segment breakdown bars, popularity bars, departures-board pulse, brightness gauges). The keycap-press loop on the keyboard demo is a CSS animation. The bar widths and stat values are inline style attributes so adapting them to your data is a string replacement. JavaScript only enters the picture for full keyboard support, focus management, and dismissibility — the things the W3C ARIA tooltip pattern requires for production use.

Use a tooltip when the content is supplementary (labels, shortcuts, brief definitions, lightweight metadata) and the user shouldn't have to interact with the panel itself. Use a popover when the content is interactive — buttons, forms, links to follow, copy-to-clipboard actions. The IDE function-hover, profile-card, team-avatar, and keyboard-shortcut-card demos in this collection contain action buttons or links and are technically popovers by that definition, but they're built on the same CSS scaffolding. The structural difference is pointer-events: none on a tooltip versus pointer-events: auto on a popover, plus keyboard / focus behavior for interactive panels.

About half the demos render embedded data — service uptime bars, RPG stat lines, schematic spec rows, data-table segment breakdowns, content-tag popularity bars, departures-board metrics, periodic-table properties, EXIF settings. Each demo's data is plain HTML — for the bar charts, widths are inline style="width:62%" so a templating engine swap is trivial. For the table cell and departures tooltips, the percentages and the change-vs-prior text are real strings, not generated. Keep the markup structure, replace the content.

Each demo's typography is part of its argument — Fraunces gives the editorial footnote its essay voice, Cinzel gives the RPG tooltip its medieval weight, JetBrains Mono gives the IDE and status demos their developer feel, EB Garamond gives the glossary card its dictionary look. System fonts would homogenize the collection into the same flat affect. The single @import declaration in the first demo loads every font family the collection needs, in one network round-trip. If you ship only one demo, drop the families you don't use from the @import URL.