[css-ui] Standardize tooltip styling and expose as `::tooltip`

[LeaVerou]

Now that popover and anchor positioning are moving forwards, I wonder if it’s time to re-examine standardizing tooltip styling and adding a ::tooltip pseudo-element so that authors can customize it.

History

• The earliest such proposal appears to be Tantek’s from April 2000. It received one neutral response and that was it.
• It was brought up again 2009. It got no opposition, some support, but very little discussion and no resolution.
• I brought it up again in 2012, which generated some more discussion, but the discussion went on tangents and eventually died.
• It was brought up again in 2017, which also didn't generate much discussion (just one message saying it doesn’t cover all use cases).

Since 6 years have passed since then, it seems like a good time to discuss it again. Maybe this time it will bear fruit. 😁

ETA: Apparently there was also a recent Open UI discussion on this with some good discussion.

Problem statement

Default UA tooltips are generally seen as inflexible, slow, and not aesthetically pleasing. Their styling is entirely disconnected from the element they describe (e.g. observe that the font size of the span does not affect the font size of the tooltip at all), and their color scheme is set by the OS, not the page (observe how in dark mode, the tooltip is dark, even when the page is actually not).

MacOS	Windows	MacOS dark mode

For these reasons, nearly all popular websites employ some kind of scripting for custom tooltips. NPM packages for tooltips are in the millions of downloads per week. However, the styling employed by the vast majority of cases is actually pretty simple.

A few examples:

Google	Facebook	Twitter	GitHub	Google Docs	Reddit

Literally all component libraries include a component for tooltips (OpenUI research), however due to the limitations of components, they have to create an element for something that is conceptually not an element, but a behavior of another element. This results in unpredictable markup and complex selectors (e.g. consider <sl-tooltip>; selectors now need to account for sl-tooltip possibly being anywhere in the tree, consider how a selector like ul > li > ul > li would need to be rewritten).

Older scripts depend on processing all [title] elements on the page, renaming the attribute to data-title or something, and adding event listeners (usually through event delegation). The downside of these scripts is that they don't work in shadow trees, and are often inaccessible.

And of course, there are always the authors that will roll their own, usually also resulting in poor accessibility.

Goals

• Custom tooltip styling (fonts, backgrounds, colors, shadows etc), including pointers
• Customization of show/hide animations (one of the major issues with the UA tooltips is how long they take to appear)

Non-goals

• Tooltips with arbitrary HTML content (these can be done with the popover API)

Proposal

We define a ::tooltip pseudo-element and standardize the default styling through a UA rule, which could look like this:

::tooltip {
	content: attr(title);
	color: InfoText;
	background: InfoBackground;
	font-size: .8rem;
	box-shadow: .1rem .1rem .2rem rgb(0 0 0 / .2);
	transition: 0s 3s visibility;	

	@starting-style {
		visibility: hidden;
	}
}

Notes:

• To allow for pointers, this needs to allow sub-pseudo-elements.
• Do we need to restrict the properties that apply to this pseudo-element?
• Right now tooltip contents are set via the content property, which can be overridden to something else. Is this useful? I can see it being set to totally unrelated attributes, harming accessibility.

Issues

Positioning

As it currently stands, how the tooltip is positioned is still magic. This does make it easier to implement, but makes certain common styles very difficult: how to add a pointer when you don't know how the tooltip and originating element positions relate? We definitely don't want authors to have to deal with positioning tooltips manually, as that is insanely complicated. Perhaps we should expose some info to them about the relative positions of the tooltip and element that they can use in their styling? Maybe via env()? Or, even better, it could be defined in terms of anchor positioning.

I think it's ok if we ship an MVP where pointers are not yet possible (which still covers a large number of use cases), but the design does need to allow for this to become possible in the future. Perhaps by restricting the properties allowed in ::tooltip

Customizing display triggers

As it currently stands, what makes the tooltip to be displayed is still magic. While this is fine, especially for an MVP, it would open up a ton of really nice use cases if this was grounded in specific user action pseudo-classes that generate the tooltip or not. Authors could then generate tooltips on :focus, :focus-within, via interactions on other elements (e.g. :focus + .foo::tooltip), or even through entirely custom interactions (by toggling classes via JS).

Perhaps, if we agree that setting the content property is what generates the box (like ::before and ::after), the default UA styles could look like this:

::tooltip {
	color: TooltipText;
	background: TooltipBackground;
	font-size: .8rem;
	box-shadow: .1rem .1rem .2rem rgb(0 0 0 / .2);
	transition: 0s 3s visibility;	

	@starting-style {
		visibility: hidden;
	}
}

[title]:hover::tooltip {
	content: attr(title);
}

The downside is that this couples the display trigger with the content. If someone wants to override the content, they also need to be up to date with the display triggers used and vice versa.

We could do something like this:

::tooltip {
	content: attr(title);
	color: TooltipText;
	background: TooltipBackground;
	font-size: .8rem;
	box-shadow: .1rem .1rem .2rem rgb(0 0 0 / .2);
	transition: 0s 3s visibility;	
	visibility: hidden;
}

[title]:hover::tooltip {
	visibility: visible;
}

But this implies the box is pre-generated and simply shown, which I don't imagine is desirable for implementations.

::tooltip in SVG

Instead of using a title attribute, SVG supports a <title> element, so when used in SVG, ::tooltip should cover these tooltips as well. However, there is no way to specify something analogous to content: attr(title) that works with that markup pattern, which may be another reason to axe that and have the content be magic (prefixes and suffixes can always be added via ::before and ::after). Or alternatively, we can define a new keyword or function for content that returns the tooltip content, regardless of where it comes from.

Not exactly within the purview of the CSS WG, but it would be nice if in the future we could backport this element into HTML, to cater to the use cases that require more rich tooltip content without having to deal with all the plumbing and positioning manually. I do wonder what web compat would be like — I suspect there must be some clumsy author code out there that assumes there is only a single <title> element on the page, and it contains the document title. Though inline SVG would break those already.

[Westbrook]

This looks very cool! I love the idea of moving more things into a known space. 👏🏼 👏🏼 👏🏼

If this was the way forward, would we need to do some work on the accessibility side around title before it would be a good idea to leverage it more actively? This article isn't exactly new, but much of the ideas in it haven't gotten much attention in the interim.

[scottaohara]

We had been (briefly) discussing this in open ui as well. Here's the issue that I had posted to open ui (which pales in comparison to the detailed issue @LeaVerou opened here), after having discussed this with @mfreed7 and @aleventhal.

@gregwhitworth had suggested we open an issue over here... does this need to be talked about more in open ui? or can the csswg move forward with this, and bring specific questions/asks to open ui to move those potential tasks forward?

[bleper]

The problem mentioned in the “Customizing display triggers” section is easily solved by putting content: attr(title) in the user agent layer and content: initial in the presentation hint layer.

Then it will be possible to display a tooltip on content: revert and hide it on content: revert-layer.

---

The content can be overridden in this way:

@container style(content) and (not style(content: none)) {
   content: 'Hello World!'}

[bleper]

There is also an option to add auto for content and set that as the initial value. This will either return normal or a string in the applicable contexts set by the host language (in this case the tooltip text).

But this is speculative, as the mechanics of this would need to be explicitly specified in user agents, and this rules out noncommon languages.

---

And this, in turn, will allow us to move away from the keywords dependent on the cascade and reduce the previous block of code to:

@container not style(content) {…}

[frivoal]

Bit of a side track, but you kind of provided a prompt:

Non-goals
Tooltips with arbitrary HTML content (these can be done with the popover API)

Instead of using a title attribute, SVG supports a <title> element […] it would be nice if in the future we could backport this element into HTML

I don't inherently have much appetite for tool tips with fully arbitrary content. At the same time, full on i18n does require more than plain text. And general text semantics do too. Drawing the line is tricky though:

0. plain text
1. plain text with a lang and dir attribute
2. ability to nest <span>, <bdi>, and <bdo>with different lang and dir attributes on different parts of the text
3. <wbr> and <br>?
4. also <sub> and <super>?
5. what about <ruby>?
6. what about <em>, <strong>, <b>, <u>, <i>, <s>, <q>, <var>, <code>, <small>, <ins>, <del>…?
7. <math>, <img>, <svg>…?
8. <a>? <button>?

Most of that doesn't seems wrong in a tooltip, but we're quickly getting close to arbitrary content. (The last two are starting to feel like a stretch, but just looking on this github page and hovering a username gets you tooltips with <img>, <svg>, <a>, and <button>.… Maybe they're popovers more than tooltips, but I find the limit blurry.)

Anyway, I think solving this here is probably out of scope for this issue, but it would be good to make sure that the solution we pick for this issue can scale to that too, because as @LeaVerou said, it would be good to be able to deal with:

the use cases that require more rich tooltip content without having to deal with all the plumbing and positioning manually

[bleper]

By the way, looking at #7845, the tooltip pseudo-element is somewhat similar to ::backdrop: they seem to be present on all elements, but only displayed under certain conditions.

So it's more logical to create an auto magic value for the display property, apply it to those two, and to be able to hide them, put box-generation back in the spec (#343, [CSS-DISPLAY-3] says this is deferred).

[gregwhitworth]

I love this and think that this is a quick win for web UI authors.

Not exactly within the purview of the CSS WG, but it would be nice if in the future we could backport this element into HTML, to cater to the use cases that require more rich tooltip content without having to deal with all the plumbing and positioning manually. I do wonder what web compat would be like — I suspect there must be some clumsy author code out there that assumes there is only a single <title> element on the page, and it contains the document title. Though inline SVG would break those already.

I think this piece should move to Open UI as we've discussed numerous times as popup landed that we'd need to introduce various popup type elements that people will reach for the popup API with manual or hint and probably get some of the a11y wrong (tooltip being the most commonly referenced).

As it currently stands, how the tooltip is positioned is still magic. This does make it easier to implement, but makes certain common styles very difficult: how to add a pointer when you don't know how the tooltip and originating element positions relate?

I'm personally in favor of V1 leaving this as magic as you noted for MVP.

Maybe via env()?

I think it's ok if we ship an MVP where pointers are not yet possible (which still covers a large number of use cases), but the design does need to allow for this to become possible in the future. Perhaps by restricting the properties allowed in ::tooltip

@tabatkins can anchor positioning help here?

Yeah, that is my thought as well. The UA stylesheet should have a recommendation of leveraging anchor-positioning, or at least not inhibiting the support for it (eg: for all I know historical implementation details make it so anchor positioning will have little to no effect). For example, Chromium allows titles to escape the window bounds so this will need some level of discussion not only of implementation but also security (maybe not since tooltip is ephemeral due to only occuring on :hover and doesn't contain interactive content).

That doesn't mean that ::tooltip shouldn't happen but it does introduce the need for a conditional of some form in that the UA will probably need to revert to a behavior that supports more complex styling capabilities but I'll allow the implementors to weigh in on that (eg: how hard is it to add a drop shadow to that if it's a completely different window, how do animations work, etc)?

The name
And one final thing that I would like some alignment on between Open UI and the CSSWG is the naming. Tooltip has been in HTML forever so the name here makes sense, but I'm curious as look towards additional elements to add to the authors toolbox that have the semantic and a11y bindings built in leveraging the popover primitive will we use the same name given its wide adoption across the web or utilize a different name. This is lower pri, but wanted to surface this.

Thank you again @LeaVerou so much for raising this and with the Open UI community, we greatly appreciate it! Also, thanks @scottaohara for at-mentioning me so that this popped up in my inbox :)

[bleper]

Summing up and slightly rethinking my previous message thread, I suggest:

• calculate the normal value of the content property on ::tooltip as none;

• add a from-markup keyword, setting the text depending on the content of the <title> in the SVG;

• additionally add the element-text(#id) function, which allows to take the text from the element (and this makes up for the parity of SVG with other languages);

• the problem of showing the tooltip and redefining its content is solved by changing the content value to the required via @container style(content) and the following styles in the presentational hints and user agent layers (so the author can use the revert to override the hiding mechanism):

/*/ ua /*/
[title] {content: attr(title)}
title {content: from-markup}
/*/ host languages /*/
:is(title,[title]):not(:focus-visible,:hover) {content: initial}

[emilio]

Re system colors, InfoText and InfoBackground already exist and they were for this purpose iirc.

As proposed in comment 0 this would be an extra unconditional per-each-element pseudo, which I don't think it's desirable. In practice, at least in Gecko, the tooltip is shared between all elements.

Adding an unconditional pseudo-element is unfortunate performance wise, because it forces the style engine to compute the styles for it all the time. Doing it conditionally might be better, but then we need to figure out what the condition is.

Other tricky thing apart from the "tooltips might want to escape the viewport if they are too long", is that positioning is tricky. If you use a bigger mouse size you might want to shift the tooltip more. This is hard to do without exposing the cursor size to the website, which we might not want to do.

[SebastianZ]

Other tricky thing apart from the "tooltips might want to escape the viewport if they are too long", is that positioning is tricky. If you use a bigger mouse size you might want to shift the tooltip more. This is hard to do without exposing the cursor size to the website, which we might not want to do.

This is discussed in #8639 and in #8315.

Sebastian