Skip to content

Tooltip

Width Open in a tab
The classes below, on plain markup, in their own document — so what you are looking at is core's stylesheet and nothing else.
The markup
<span class="aparte-tooltip-anchor" style="margin-block-start: 2.5rem; margin-inline-start: 5rem">
<div class="aparte-tooltip" data-side="top" role="tooltip">
Copy to clipboard
<span class="aparte-tooltip__arrow"></span>
</div>
<button class="aparte-btn aparte-btn--icon" aria-label="Copy"><aparte-icon name="copy"></aparte-icon></button>
</span>

A short label, with an arrow

A tooltip has to be legible against whatever it happens to sit on top of — a bright image, a dark code block, either app theme — so its colours are fixed literals rather than the themed surface/text tokens. This box does NOT follow the palette, on purpose, and skips the dark-theme override block for that reason; the artifact “paper” tokens are the same decision made for the same reason.

data-side places it — top, bottom, start or end — against the .aparte-tooltip-anchor that wraps the trigger, --aparte-tooltip-gap away, and turns the arrow to match. The two inline styles that used to do this in the example were a knob missing, not a division of labour: a demo that needs inline styles to work is a recipe with a parameter it forgot. What stays yours is the viewport: nothing here flips a tooltip that would leave the screen — that needs script, a positioning library’s job. Without data-side the box is not positioned at all, as before, and its placement is yours (the one inline style left in the example is the demo’s own margin).

pointer-events: none is not a detail: a tooltip describes what the pointer is over, so it must never itself become that thing, or hovering it re-triggers the hover that produced it.

.aparte-tabs--segmented · .aparte-tabs__tab · .aparte-tooltip · .aparte-tooltip-anchor · .aparte-tooltip__arrow

The tokens these read are on the CSS variables reference; every class of the kit, on one page, is the classes reference.