Skip to content

fix(tooltip): cap the content width at the space Radix measures - #130

Merged
tmccoy14 merged 1 commit into
mainfrom
fix/tooltip-default-max-width
Sep 10, 2026
Merged

fix(tooltip): cap the content width at the space Radix measures#130
tmccoy14 merged 1 commit into
mainfrom
fix/tooltip-default-max-width

Conversation

@tmccoy14

Copy link
Copy Markdown
Contributor

Why

TooltipContent sets no max-width at all, so every consumer has to cap it themselves or let long content run the tooltip off screen. Guardian's studio app was doing exactly that at eight call sites behind a token of its own — this pulls the default into the design system so it doesn't have to.

Found while reviewing a tooltip sweep in guardian, where the app-level version of this token was silently broken (see below).

The @theme inline part matters

The value has to live in the @theme inline block. With a plain @theme, Tailwind declares the token on :root and emits max-width: var(--container-tooltip). A var() inside a custom property is substituted where that property is declared — on :root, where --radix-tooltip-content-available-width doesn't exist — so it collapses to the 100vw fallback before it ever reaches a tooltip, and the Radix measurement is a bystander.

Compiled both ways to confirm:

@theme         →  .tooltip-content { max-width: var(--container-tooltip) }   /* var resolved on :root */
@theme inline  →  .tooltip-content { max-width: min(32rem, var(--radix-tooltip-content-available-width, 100vw)) }

Inlined, the declaration lands on the content element — the same element Radix sets the variable on — and the measurement survives, collision padding included. Verified in the built dist/tooltip.module.module.css.module.css.

This is the same pattern the component already uses for @apply origin-(--radix-tooltip-content-transform-origin).

Overriding

.tooltip-content compiles unlayered, so it beats @layer utilities regardless of order — a plain max-w-* utility won't win, and an override needs max-w-md!. That's already the convention consumers hit with this component (guardian writes text-xs! on these very tooltips), but it wasn't written down, so the docs now cover both that and the --container-tooltip token for a global change.

Note for consumers

This is a behavior change: any app relying on unbounded tooltip width now gets a 32rem cap. Guardian is unaffected — it already caps at exactly this value in all eight places, and those come out once this publishes.

Docs updated with a new Width section on the Tooltip page.

TooltipContent set no max-width at all, so every consumer had to cap it
themselves or let long content run the tooltip off screen. Studio was doing
exactly that at eight call sites behind a token of its own.

Give the component the default. The value has to live in the @theme inline
block: a plain @theme declares the token on :root, where
--radix-tooltip-content-available-width does not exist, so the var() collapses
to its 100vw fallback before it ever reaches the tooltip. Inlined, the
declaration lands on the content element -- the same element Radix sets the
variable on -- and the measurement survives, collision padding included.

.tooltip-content is unlayered and so beats a plain utility, which the docs now
say, along with the token to retheme.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@tmccoy14
tmccoy14 merged commit 7ed35c1 into main Sep 10, 2026
1 check passed
@tmccoy14
tmccoy14 deleted the fix/tooltip-default-max-width branch September 10, 2026 11:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant