Restructure ToolTip component - #333
Conversation
davinotdavid
left a comment
There was a problem hiding this comment.
Thanks for the work so far!
I think we could explore the Popover API a bit for this since even though the tooltip is absolute positioned and its size is not counted in the trigger's parent containers, the space is still being counted on the page causing scrollbars / overflow even when closed.
Screen.Recording.2026-09-24.at.4.07.48.PM.mov
|
@davinotdavid Great feedback, thank you! Feel free to look at it again. Edit: Oh and I forgot your suggestion of the Popover API - I will investigate this and report back. |
|
@davinotdavid I looked into the Popover API and believe this would be a bigger but non-breaking change (internal use / rewiring to the Popover API with fallback to the current implementation). Therefore I'd like to do this in a separate issue, if that's ok. Edit: Added #334 for it |
davinotdavid
left a comment
There was a problem hiding this comment.
Cool, thanks for the revisions! LGTM!
What changed?
Warning
This is a breaking change.
ToolTipso its default slot is now the trigger element it wraps, with tooltip content moved to a new namedcontentslot.position: relativewrapper consumers used to need.visibleprop (force show/hide) replacing the old CSS-class hackbeakprop to toggle the arrow, replacing the removedTooltipPosition.None.aria-describedby/role="tooltip"wiring via a scopedtooltipIdslot prop, replacing the removedaltprop.BaseButton.vueinternally to the new ToolTip (its own public props (tooltip,forceTooltip, etc.) are unchanged).Why?
ToolTiphad no concept of the element it annotates, so consumers had to manually wrap trigger and tooltip in aposition: relativecontainer and hand-offset the tooltip.Limitations and Notes
How to migrate
<tool-tip>now needs the trigger element as its default slot, with the tooltip text in<template #content>.altprop is removed. Bindaria-describedbyon your own trigger via the scoped slot proptooltipIdif you need an accessible description.visibleprop instead of a CSS class hack:true/falseforces shown/hidden, unset falls back to hover/focus control.TooltipPosition.Noneis removed. Use:beak="false"instead to hide the arrow.positionnow names the side the tooltip box appears on (e.g.pos-bottomplaces the tooltip below the trigger), not the arrow's direction as before.BaseButton'stooltip/forceTooltipprops are removed entirely. Buttons need to be explicitly wrapped in<tool-tip>from now on.Applicable Issues
Closes #283
QA Log
ToolTipstories (Standard, Position, NoBeak, Context) in Storybook: hover and Tab-focus both reveal tooltips, all four positions render on the correct side with matching beak direction, and:beak="false"hides the arrow.type-check, andlint.Screenshots
All stories now feature a primary button to trigger the tooltip. The default story:
The position story:

A new "no beak" story:

And renamed "Context" to "Always visible" sotry:
