[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

[nt1m]

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).

I think this is a security concern. This would be troublesome if it expands the window bounds:

<a title="Your computer has been compromised, click to install antivirus" href="https://malicious.site"></a>
<style>
html, body, a { display: block; width: 100%; height: 100%; }
::tooltip {
   padding: 10000px;
}
</style>
</body>

[LeaVerou]

@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.

We could change the syntax to style the tooltip shared across the whole document (e.g. something like @tooltip), and it would still cover a large chunk of use cases, but it's common to want to customize it differently per subtree and/or inherit from the element it’s on, and conceptually it makes far more sense.

I wonder if some of these mitigation strategies may make implementation more feasible:

• We can narrow it down to be generated only on [title], :has(>title) elements and do away with all the designs that allow tooltips to come from entirely arbitrary attributes.
• It could only be generated when content is not initial, and make sure to set content on :hover or whatever pseudo-class triggers it (this is also discussed in comment 0)
• UAs can still use the current OS-provided design for unstyled tooltips and share it across all elements, there’s a lot of precedent for this kind of thing (scrollbars, form controls etc)
• UAs could optimize bare ::tooltip selectors (and variatons) to style the tooltip shared across all elements, and only compute styles for elements whose tooltip is styled with more specific selectors.

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.

With the current proposal, positioning is still magic, so this shouldn't be a problem for L1.

---

@nt1m

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).

I think this is a security concern. This would be troublesome if it expands the window bounds:

<a title="Your computer has been compromised, click to install antivirus" href="https://malicious.site"></a>
<style>
html, body, a { display: block; width: 100%; height: 100%; }
::tooltip {
   padding: 10000px;
}
</style>
</body>

While clicking on the tooltip today is impossible due to the mechanics, conceptually I don’t think clicking on it is supposed to propagate to clicking on the element, so even if the tooltip tricks the end-user into clicking on it, nothing much would happen. Or is the risk that it will trick the end-user into clicking somewhere outside the browser window? In that case, would it make sense to make it trap clicks but not propagate them?

But even if — worst case — styled tooltips had to behave like JS-created ones and could not escape the window bounds, I think that is an acceptable tradeoff for authors (since that’s exactly the tradeoff they are making right now).

---

It would be very useful to hear from Blink implementors too (@chrishtr @bfgeek @dbaron @lilles @andruud ?)

[chrishtr]

@mfreed7

[jimmyfrasche]

There are also the error tooltips from html5 validation

[mfreed7]

Thanks for raising this issue! So as you mentioned, OpenUI is working on a popover=hint and Hover Triggering Proposal which is quite related. Having said that, there is a large class of use cases which likely don't need the full Popover API, and for those, something like ::tooltip or ::title would do the job nicely. So I'm generally supportive.

But it's important that the developer story is clear. To me, this seems to make the most sense:

1. The ::title/::tooltip pseudo class is for the "common", "simple" use case of just wanting to set the basic styles for tooltips that arise due to the title attribute. Without any data to back me up, I'd venture a guess that this will solve 80% of the tooltip use cases on the Web today.
2. The new Hint/Hover functionality being proposed is for all of the cases not handled by ::title/::tooltip.

If folks are roughly onboard with that split, then in my opinion, this issue (::title/::tooltip) should have the following goals and non-goals:

Goals:

• Allow setting basic styles for the tooltip that results from the title attribute.
• Support setting as many properties as possible, but perhaps not all properties. In particular, not positions.

Non-goals for ::title (these should be goals for popover=hint):

• Allow "generating" a tooltip from an element that does not bear the title attribute. That would be asking for a11y problems. It also has perf problems as discussed above.
• Allow the developer to control the position of the tooltip - that should continue to be managed by the UA.
• Allow the developer to add their own "pointer/arrow" from the tooltip to the element. This could still be auto-magically provided by the UA if desired.
• Allow the developer to control the triggering of the tooltip, for example setting hover time delays for showing/hiding. That is complex behavior and should continue to be managed by the UA.
• Allow the tooltip to extend beyond the bounds of the containing window. That is a security concern, as mentioned above, due to largely-arbitrary styling.

[tantek]

Regarding History:
> The earliest such proposal I could find was this one from 2009. (https://lists.w3.org/Archives/Public/www-style/2009Apr/0225.html)

This sounded familiar (as in I thought I had proposed something similar a while ago), and it turns out I had proposed exactly a "tooltip pseudo-element" nine years earlier 🙈😭

https://lists.w3.org/Archives/Public/www-style/2000Apr/0014.html

Note that the year 2000 was before the WG switched to the "::" prefix for pseudo-element selectors, so all pseudo-elements and pseudo-classes used the single ":" prefix.

(Originally published at: https://tantek.com/2023/195/t1/)

[LeaVerou]

@tantek Thanks for sharing this! I just updated the first post to include it.

[LeaVerou]

In preparation for the F2F, I think these are some questions we need to answer:

• We need to hear from implementors on the potential limitations for such a feature
• We should decide on scope for Level 1, Level 2+, and non-goals. I think we are in agreement that this should cater to simpler use cases, and more complex cases should be handled via the popover API, however I don't think we have consensus on the specifics. Some questions that were raised (see OP and @mfreed7’s comment) were:
  • Should this feature do simple tooltips that are not produced via the title attribute / <title> SVG element?
  • Should it deal with positioning?
  • Should it deal with customizing the user actions that trigger the tooltip?
  • Should it allow authors to customize the delay for showing the tooltip?
  • Should styled tooltips continue to be able to extend the window bounds? Also, is that window or viewport bounds (i.e. what happens with iframes)? This may require a tradeoff as it may limit the types of styling allowed, for security reasons, though in [css-ui] Standardize tooltip styling and expose as ::tooltip #8930 (comment) I do question whether a tradeoff is necessary (of course this may not even be possible for customized tooltips, we don't know until we hear from implementors).
  • Should this feature allow global styling of tooltips or work like a pseudo-element, customizing the tooltip per subtree?

IMO:

• I think the primary reasons authors go for custom tooltips are to customize the delay, animation, and basic styles (backgrounds, fonts, colors), so I think these should be a priority for L1. Basic styles alone are not enough.
• The idea of providing a way for the UA to automagically draw a tooltip pointer is interesting (and does solve the issue of how do we expose the position of the tooltip in a useful way so that authors can draw it), though it seems hard to spec such a feature that follows the arbitrary tooltip styling (shadows, borders, strokes etc), not sure how it would fit in to the box model, and not sure how we could give authors control over the size/proportions of the arrow. Note that transitions also often need to take the arrow into account (e.g. growing/shrinking transitions would use the pointer tip as a transform-origin).
• I think we can do away with arbitrary tooltips from arbitrary attributes and scope it down to specifically the title attribute and <title>.
• Regarding the position of the tooltip, I’m hoping we could perhaps define it in terms of Anchor Positioning, which may require changes to Anchor Positioning itself, to be able to describe the current behavior.
• My intuition is that most authors would trade extending window bounds for higher styling flexibility. I'd like us to really examine whether the tradeoff is necessary though, as I imagine it could be quite limiting for e.g. iframes.

[castastrophe]

Love this proposal; we could replace a lot of unnecessary web components by opening up certain access. Since much of the above is very detailed, I'd like to summarize a few properties that I see used in web components replicating this element:

• Background color / text color
• Border + border radius
• Including/styling a pointer arrow
• Positioning (top/bottom/left/right/auto)
• Typography

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Standardize tooltip styling and expose as `::tooltip` , and agreed to the following:

• RESOLVED: Standardize a ::tooltip pseudo, with a few properties, to style tooltips

The full IRC log of that discussion

<fremy> lea: proposal as of a few days ago
<fremy> lea: tooltip styling has been brought up multiple times
<fremy> lea: first was tantek, but there were many other ones
<fantasai> s/times/times by multiple people since 2000/
<fremy> lea: every single time, there was little pushback
<fremy> lea: yet it never went anywhere
<fremy> lea: many websites have custom code to style tooltips
<fremy> lea: and most of these stylings are not very fancy
<fremy> lea: mostly color, background, font-style, customizing the delays...
<fremy> lea: because browsers sometimes wait too much
<fremy> lea: but all of this requires chaning the markup, because the element must wrap the location
<fremy> lea: so this is pretty heavy-weight, and it's easy to forget some accessiblity requirements
<fremy> lea: so, I really think we should do something about it
<castastrophe_> +1 lea I argued so hard against our library building a tooltip web component at work
<fremy> lea: and the most common proposal is a pseudo-element acceting a few properties
<masonf> q?
<masonf> q+
<fremy> lea: since the tooltips can escape the window bounds, it could make huge tooltips and confuse the users if everything is customizable
<fremy> lea: but some properties sound fine
<una> q+
<fremy> lea: later on, we can add positioning, maybe using anchor positioning, but magic is fine for MVP
<gregwhitworth> q+
<fremy> lea: content itself can probably be magic too, because SVG and HTML do this differently
<fremy> lea: keyword vs totally magic, not that important
<fremy> lea: we can narrow this down later
<fremy> lea: later on, we can add html elements, attributes, focusable, etc...
<fremy> lea: but I see consensus on the basics
<fremy> lea: so, are there implementors that are concerned about this?
<gregwhitworth> note, I'm not an implementer anymore :P
<fremy> lea: (also, maybe javascript-created tooltips?)
<castastrophe_> A reference for anyone interested in Adobe's tooltip web component: https://opensource.adobe.com/spectrum-web-components/components/tooltip/#example
<fremy> lea: maybe in that case, bound to the frame
<castastrophe_> And an example from Shoelace: https://shoelace.style/components/tooltip
<masonf> q?
<fremy> lea: so, what are the constraints holding us back here?
<gregwhitworth> ack gregwhitworth
<emilio> q+
<astearns> ack masonf
<fremy> masonf: thank you for bringing this up
<masonf> Shameless plug for popover=hint and hover triggering: https://open-ui.org/components/popover-hint.research.explainer/
<fremy> masonf: I pasted our shim in the chat, a more complex version of this
<ntim> q+
<fremy> masonf: but for most use cases I have seen, a few styling would go a long way
<fremy> masonf: I would love it to have the tooltip in the window bounds, so that styled tooltips are consistent depending on how much they are styled
<fantasai> s/complex version of this/complex version of this using popover/
<fremy> masonf: I would prefer some things to remain magic, like delays, but ok
<fremy> masonf: html uses the title element, but also some aria attributes
<astearns> ack masonf
<astearns> ack una
<fremy> una: thank you for opening this issue
<myles> q+
<lea> q?
<fremy> una: the first thought that comes to mind, can this also style "form error messages"
<masonf> we should support the title attribute for HTML, or the <title> element with svg.
<fremy> una: does that also apply to "alt text" over images?
<fremy> una: maybe, this can be a "style bag" rather than a pseudo-element
<lea> q+
<emilio> q- later
<fremy> una: but, if you have a popover, that gives you multiple elements, and more flexibility
<fremy> una: so, the limitations of this proposal, are they acceptable enough, is my first question
<fremy> una: my second question, is that, how does this related to other features like alt text
<astearns> ack ntim
<SebastianZ> q+
<fremy> ntim: outside of the window bounds, we would want to filter down to a list of properties
<masonf> q+
<fremy> ntim: also, probably some constraints like size or box-shadow
<astearns> ack myles
<fremy> myles: further than that, tooltips ship with the OS, and the platform usually don't allow much styling
<fremy> myles: so, one limit, I would start with what the platform allows
<gregwhitworth> q+
<fremy> myles: also, tooltips outside the window, requires nsWindow etc...
<fremy> myles: this is costly if we want to do that
<fremy> myles: but I understand that from the issue, the benefits are also quite high
<fremy> myles: so, this is not "easy" at least
<fremy> astearns: the rest of the proposal doesn't get to that bar?
<astearns> ack lea
<fremy> myles: yes
<fremy> lea: I think errors for form controls are a different pseudo, because they have different constraints
<astearns> s/the rest/the hard part is displaying outside the window. The rest
<fremy> lea: there are commonalities, but also major differences
<fremy> lea: I'm not seeing the alt text connection, which I think is more of a ::part() I think
<una> q?
<fremy> lea: to reply to ntim, I would definitely favor an allow list
<fremy> lea: but, just an allow-list might not be the whole story
<fremy> lea: I think many authors want padding, rounded borders, etc...
<fremy> lea: to reply to myles, I think this would generate non-native tooltips
<myles> q+ to reply to that
<fremy> lea: because what authors do today is this
<gregwhitworth> ack gregwhitworth
<fremy> una: what do you think of popover=hint?
<fremy> lea: it can probably solve some, but it requires a lot of code, and doesn't play natively with title attribute etc
<fantasai> s/what do you think of popover=hint/do you think popover=hint solving these problems?
<fantasai> s/solving/solves/
<gregwhitworth> I agree with Lea on this
<fremy> lea: more complex use cases would like it
<astearns> ack myles
<Zakim> myles, you wanted to reply to that
<lea> q?
<fremy> myles: if this is not native tooltip, for us this is not a tooltip
<fremy> myles: I would not want to call this a tooltip at this point
<gregwhitworth> q+
<astearns> ack emilio
<fremy> emilio: indeed, we need to answer whether the content area is enough (even for iframes)
<fremy> emilio: if not, non-native tooltips are not ok
<lea> q+
<fremy> emilio: but we already discussed this for <selectmenu> elements
<TabAtkins> These are conditions that people already live with when they're using the custom JS-driven versions.
<fremy> emilio: so, if we are, this seems workable
<fremy> emilio: if we don't think this is sufficient, I would not think that this is doable (in a reasonable amount of effort)
<gregwhitworth> note, only when ::tooltip is present
<fremy> emilio: so, would browsers engines be fine with that?
<fremy> emilio: and I have the impression that myles isn't confortable with that, maybe?
<fremy> emilio: personally, I guess I'm fine, but needs some thoughts
<lea> q?
<fremy> astearns: TabAtkins replied on IRC that people today have those limitations, so those are probably ok with them
<gregwhitworth> not if you don't use ::tooltip
<fremy> emilio: but those aren't native, right?
<fremy> TabAtkins: yes, they override
<astearns> ack SebastianZ
<fremy> SebastianZ: I wanted to say more about the security issue
<fremy> SebastianZ: the native tooltips should still be able to actual document
<fremy> SebastianZ: right now, UAs can clip the text etc..., UAs can create new rules based on size etc...
<fremy> SebastianZ: do we have concensus that this is something that should be worked on, at least?
<masonf> I'll rejoin
<astearns> ack masonf
<fremy> masonf: <confusing echo>
<astearns> ack gregwhitworth
<fremy> gregwhitworth: personally, I never envisioned the non-native tooltips to escape the bounds
<fremy> gregwhitworth: and I think, as an author, that is reasonable
<fremy> gregwhitworth: but even then, we can start with simple properties anyway
<fremy> gregwhitworth: una pointed out alt text, and some sites use them as a tooltip in some cases
<fremy> gregwhitworth: also, agree with myles, maybe this shouldnt be called a tooltip
<fremy> gregwhitworth: but "the box that pops up when tooltips happen"
<gregwhitworth> +1 to masonf
<fremy> masonf: also, pointing out, many sites refuse to use these tooltips
<lea> +1 to masonf too
<fremy> masonf: and these sites accept the trade-off about off-bound positioning
<fremy> masonf: personally, I don't even see that native tooltips are that necessary
<fremy> masonf: I would not mind a single path, custom ones
<fremy> masonf: they would be simpler
<astearns> ack lea
<fremy> astearns: removing is difficult on the web platform, but that's an interesting idea
<fremy> lea: can we get some data about what tooltips can do on native platforms?
<fremy> lea: that would help shape the discussion
<fremy> lea: also, if it behaves like a tooltip, I feel it should be called a tooltip
<fremy> lea: scrollbars were in that list of strange things once, but we resolved that built-in customization is better than wild hacks
<masonf> astearns, the behavior of the title attribute (generating a "tooltip") is not standardized, so we're not really removing something. We're better defining it and making it more developer-friendly.
<emilio> q+
<fremy> lea: mutltiple codepaths are fine on the web platform, like for <button> so I don't buy that objection
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<fremy> lea: if we can get rid of the native ones, I don't mind personally
<fremy> lea: eventually, we can probably find constraints
<fremy> lea: most sites that have enough resources to make a choice
<fremy> lea: do not use the native ones
<astearns> ack dbaron
<Zakim> dbaron, you wanted to comment on alt text
<una> +1 will be much easier to build without expanding window bounds and that doesn't sound like a top requirement to support authors here
<fremy> lea: also, I would object about "title" as the name, because "title" was an odd name
<fremy> dbaron: some feedback we once got about alt text in tooltips
<TabAtkins> Basically, webcomics.
<fremy> dbaron: we stopped doing this by default
<astearns> ack emilio
<fremy> dbaron: because alt text was used as a hack, instead of a real description
<fremy> dbaron: so, this change was intentional
<fremy> emilio: multiple codepaths are fine, but also the difficulty of them is important
<lea> q?
<fremy> emilio: for me to become more serious about this, I would like to hear some consensus from implementors that the bound restriction
<lea> emilio: Of course the code path is different for buttons, my point was that from the author side there is precedent for rendering going through a different code path once CSS is applied.
<fremy> emilio: if we get consensus on that, I'm fine with this
<astearns> ack fantasai
<lea> We have "make simple things easy and complex cases possible" in our TAG principles :)
<fremy> fantasai: personally, I agree with lea, we need to bridge the gap between "you control nothing" and "you have to implement javascript, accessibility, etc..."
<lea> s/complex cases/complex things/
<fremy> fantasai: right now we don't have that middle ground
<fremy> fantasai: I also feel like if it looks like a tooltip and behaves like a tooltip, let's call it a tooltip
<fremy> fantasai: and for the content, I think we are ok with using the same text as it would do today
<fremy> fantasai: I think it's fine, ::tooltip should allow you to style it
<fremy> fantasai: given the facts a lot of authors seem fine to keep it in the window bounds, I think it's reasonable
<fremy> fantasai: in terms of positioning, we can punt this for now, and come back to this later
<masonf> +1 to everything fantasai just said.
<lea> also +1 to everything fantasai just said!
<fremy> fantasai: but, globally, I think it's a net benefit if (a) it's easy (b) <missed> (c) accessibility is preserved
<lea> q?
<lea> q+
<miriam> q+
<nicole> q+
<fremy> lea: I would not mind the bounds restrictions to depend on the used styles
<fremy> miriam: quick question
<fremy> miriam: I have seen many a11y recommendations to not use the title attribute
<fantasai> s/<missed>/UA handles positioning and appearance logic so it's not error-prone/
<fremy> miriam: is that an anti-pattern?
<fremy> chrishtr: I have heard the same, it's often much too loud for them
<fantasai> perhaps it should be less loud...
<fremy> astearns: I'm wondering, can we resolve on a ::tooltip pseudo, with a few properties allowed, and figure out the details later in little pieces
<lea> allowlist and window bounds are related, they should be part of the same issue
<masonf> +1
<lea> +1
<fremy> astearns: any direct response to that proposed resolution?
<gregwhitworth> +1
<fremy> astearns: any objection to this?
<bramus> +1
<castastrophe_> Very exciting!
<una> awesome :)
<gregwhitworth> only 23 years
<lea> 🎉
<fremy> RESOLVED: Standardize a ::tooltip pseudo, with a few properties, to style tooltips
<masonf> :-) nice!

[kizu]

There was one aspect that I want to re-iterate: a concern for the accessibility of the current native tooltips (the title attribute, etc.)

(The only comment in this issue where this was brought up — #8930 (comment) — by @Westbrook)

One of the concerns developers have when they implement custom tooltips is having to follow accessibility guidelines.

The issue is that the current title tooltip does not follow these guidelines either.

What I'm talking about is the WCAG “Content on Hover or Focus” — https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html, particularly the “Hoverable” criterion:

If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

There is an exception:

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

However, if we allowed styling the tooltip, I'd argue that at this point, this exception would stop being applied.

Tooltips not being hoverable (and their text not being selectable) is one of the reasons developers could continue using custom implementations.

However, interestingly, there is one aspect of the title tooltip that cannot in any way be currently implemented with just CSS without JS — the “Dismissible” criterion:

A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

Native tooltips can be dismissed by esc.

There are no ways in CSS to achieve this. Any custom implementation would require JS to make tooltips dismissible. Though this is a rather separate issue (I'm planning to eventually open up a separate issue), I think it is worth it to bring it up here, as if the new ::tooltip could be made to conform to the other criteria, it would be awesome.

---

That said, as an author, how would I want a ::tooltip to behave:

1. I'm 100% fine with it being visible only inside the page's viewport and never going outside of it.
2. I would say that if the ::tooltip is defined, ideally, we should remove the default UA behavior completely and add a new pseudo-element that would behave according to all the CSS rules without any additional UA behavior.
3. It should still have to be dismissible, and I would prefer this to be a mechanism available in CSS for anything else as well in some way (my draft idea that I wanted to create an issue about — make esc remove the :hover, :focus/:focus-visible/a new focus-… pseudo-class from the currently active element).
4. It should be selectable. A related issue that was also discussed recently — Allow user-select on ::marker pseudoelements #8892 — as this element would be a pseudo-element, browsers would have to support text selection of its content.
5. It should provide enough default affordance (either by default styles, and/or by delay before hiding), making it possible to hover over the tooltip while moving the cursor over it slowly.
6. It should be possible to trigger this tooltip from the keyboard, potentially when focusing the element with the title.
7. I probably forgot something else — probably a lot.

Until a ::tooltip would eventually check all these boxes (I'm totally ok with things being implemented iteratively), authors would continue relying on libraries and custom implementations.

[mikemai2awesome]

I believe the prerequisite for this cool thing would be making the title attribute accessible first. We should not encourage devs to jump on this and create more inaccessible UIs.

[patrickhlauke]

Agree, the styling side (making the native title tooltips more attractive to use) should really be accompanied by a parallel effort to make sure thy work for keyboard and assistive technology users. Making sure that browsers trigger them on focus when they're added to focusable elements (I seem to recall classic Edge did this at one point ... or was it IE11?), and providing clear guidance for authors reminding them that adding title to arbitrary non-focusable elements will make them inaccessible to non-pointer users.

[mayank99]

agree with @Westbrook and @mikemai2awesome. i think the work to make title attribute accessible should be done before any work on the styling side is even started.

as it stands, the title attribute is entirely useless not because of its inability to be styled, but because of its accessibility issues. i would hate to see ::tooltip finalized and shipped when the accessibility discussion is still in limbo, because it would still be entirely useless.

---

Two more tangential points i would like to point out. If the content property is the only way to change the tooltip text, then it would get in the way of both of these.

1. while dismissing tooltips on esc key does technically help satisfy SC 1.4.13 "Dismissible", it is not optimal. user research done by Sarah Higley has found that a ❌ button inside the tooltip works better.
2. there needs to be a way to indicate if the tooltip text is part of the element's accessible name (primary label) or its description (supplementary text).
   • while this could potentially be achieved by creating the tooltip using content: attr(aria-label)/content: attr(aria-description) (bypassing the title attribute entirely), it would be severely limiting because there are better, more widely-supported ways to add labels/descriptions. using content: attr(data-tooltip) is an option but it would cause duplication.

[aardrian]

Making sure that browsers trigger them on focus when they're added to focusable elements (I seem to recall classic Edge did this at one point ... or was it IE11?)

Internet Explorer, Legacy Edge (Ledge?), and now Chromium Edge (Chomiedge?) all show(ed) title attributes on focus (assuming the thing with title can take focus).

The current Edge implementation also does not disappear but can be dismissed by Esc. Moving the mouse into the trigger does dismiss it (and re-open it) so its 1.4.13 adherence is at least better than others.

I know this is not advancing the overall discussion, but it is worth noting one UA has tried to improve the accessibility and this proposal should not roll that back and should try to move all UAs further.

[Malvoz]

Making sure that browsers trigger them on focus [...]

Internet Explorer, Legacy Edge (Ledge?), and now Chromium Edge (Chomiedge?) all show(ed) title attributes on focus (assuming the thing with title can take focus).

Relevant bugs:

• https://bugs.chromium.org/p/chromium/issues/detail?id=829352
• https://bugzilla.mozilla.org/show_bug.cgi?id=97223
• https://bugs.webkit.org/show_bug.cgi?id=61732

An a11y best practice for authors should be to not (only) use :hover with this new ::tooltip pseudo-element (such as [title]:hover::tooltip used in the examples above), or at least also include :focus/:focus-visible.

[LeaVerou]

An a11y best practice for authors should be to not (only) use :hover with this new ::tooltip pseudo-element (such as [title]:hover::tooltip used in the examples above), or at least also include :focus/:focus-visible.

Instead of leaving it up to authors, what if this was automatically handled by the UA? What are the use cases where you don't want the tooltip to appear on focus?

[o-t-w]

I hope this also brings the ability to hide browser-default tooltips. I’m currently building a custom file input by setting opacity: 0 on the native HTML file input. It has a super-annoying tooltip saying “no file chosen” which is apparently impossible to get rid of.

https://stackoverflow.com/questions/12035400/how-can-i-remove-the-no-file-chosen-tooltip-from-a-file-input-in-chrome

Another example: Safari adds a tooltip to truncated text and it’s impossible to get rid of it (which has driven me crazy).

https://bugs.webkit.org/show_bug.cgi?id=114304

[LeaVerou]

The CSS Working Group just discussed [css-ui] Standardize tooltip styling and expose as `::tooltip`, and agreed to the following:

• RESOLVED: Standardize a ::tooltip pseudo, with a few properties, to style tooltips

The full IRC log of that discussion

So I filed #9447 for the allowlist. We decided not to allow customizing the content or trigger at the moment. Are there any other issues to file? Should we close this?

[yisibl]

Add a use case where in many pages, the range <input> will also have a tooltip to show the current value.

See: https://fonts.google.com/specimen/Open+Sans/tester?preview.size=131&stylecount=11

[LeaVerou]

Add a use case where in many pages, the range <input> will also have a tooltip to show the current value.

Unfortunately with the current design that won’t work (for native inputs), since the thumb is part of the control’s closed Shadow DOM, to which we have no access to, and it will be a while before we have control over positioning the tooltip :/