::tooltip pseudo element explainer

[alisonmaher]

This change creates an explainer for a new ::tooltip pseudo element that is closely based on a pre-existing CSSWG proposal w3c/csswg-drafts#8930.

[KurtCattiSchmidt]

Interesting, so the legacy behavior will still exist for most sites, unless they use a ::tooltip selector?

[alisonmaher]

Yeah the idea is that we allow UAs to keep whatever styles they want outside of this case.

This would likely be preferable for Safari, since they will likely want to continue to match the OS in this case.

This could also allow us to update our default styling on Windows to better match Windows, which is an ask from one of our customers (CC @aluhrs13 who likely remembers who that is)

[KurtCattiSchmidt]

Is this really a breaking change if all OS's and browsers are currently different?

[alisonmaher]

It might not be completely breaking (but potentially for no longer allowing tooltips to escape window bounds).

We will likely look into unifying things in Chromium, but this would be something that would be done after this work, and shouldn't be a requirement for UAs.

Updated the wording slightly to say it may be a breaking change on some browsers, since it is unclear if it will or won't

[alisonmaher]

@microsoft-github-policy-service agree company="Microsoft"

[dandclark]

This is a great explainer. Just some nitpicks/typos.

[dandclark]

Not part of this explainer, but are we planning on driving this for Chromium?

[alisonmaher]

Yeah that is the idea, although engineering work here will be delayed due to reshuffling of work from this week. But this would be something that should be done as part of this feature work

[kbabbitt]

It's a little odd that visibility is included among the UA default styles when it's not listed among the properties that can be applied to ::tooltip in the next section. One might read these default styles as suggesting that an author could trigger a tooltip to be shown by doing something like:

.myelement::tooltip {
  visibility: visible;
}

To be clear, I think we should disallow author control of visibility in this manner and leave it entirely up to the UA. If we enabled visibility control like in the example above, we would need to calculate styles for the ::tooltip pseudo on every element just to check for visibility, which would be a big perf hit.

edit: Reading further I see there's a use case for adjusting the timing of showing/hiding the tooltip, but I'll leave this comment open for consideration of the point about style calc performance.

[alisonmaher]

Yeah agreed we don't want an author to play with it, but they might want to adjust the timing as you mentioned. Would we need to include visibility in the list of adjustable styles for an author to be able to adjust the transition tied to visibility?

Either way, I think appearance: base being the thing that triggers the base tooltip styles, as opposed to visibility on its own would remain in tact, which I think would avoid the performance concern?

There is also an open question on the right property to include in the transition (i.e. should it be position-visibility instead, which may require an additional value to position-visibility, but perhaps there is another option)?

We could also leave this as a future idea to let authors adjust this timing, which would leave the transition bit up to the UA as opposed to part of the UA stylesheet

[kbabbitt]

Either way, I think appearance: base being the thing that triggers the base tooltip styles, as opposed to visibility on its own would remain in tact, which I think would avoid the performance concern?

Well, the issue there is that you still need to calculate styles to determine that appearance: base was set :) Allowing the author to set transition seems like a reasonable solution, but perhaps it's worth a note to explain why the author can set a transition on visibility but not visibility itself.

[alisonmaher]

Added a note to Scenario 3 for this. Lmk if you have any edits to the added text.

Well, the issue there is that you still need to calculate styles to determine that appearance: base was set :)

I suppose that's true, but I think that would only be required if the author touches ::tooltip in some way for a given element(s), right? In other words, is there some way to avoid that?

[alisonmaher]

Although, I guess is that problem that an author could change the value of appearance via script, which means that we would need to store the ::tooltip styles in some way to ensure that works as expected?

[alisonmaher]

Chatted offline and got clarity on what was meant here. I've updated the note under Scenario 3 to better clarify why visibility isn't allowed to be adjusted by authors. Lmk if I missed anything.

[sfortiner]

Should there be something written about tooltip dimensions? For example, can the web developer control the dimensions? Can the dimensions be modified via script, animation etc. after creation? Are there constraints other than 'limited to the browser window size'?

[alisonmaher]

This is a good callout. I had considered adding something about this at one point and completely forgot to add a section on it, so appreciate you bringing it up.

For now, I've decided on using default sizing constraints, which means that the tooltip will be sized based on its text content (and padding properties, etc). I also played with the demo in https://codepen.io/alisonmaher/pen/MYYxpJZ and with longer tooltips, the size is constrained by the viewport in the inline direction, but might overflow in the block direction.

I've included this info in a new section (called ::tooltip sizing), and leave an open question for if this should be adjustable by the author (I don't see a strong use case for this since the only content can be text, but I also wouldn't object to adding such properties if we discover a good reason from developers).

I was going to add an open question on if we should set a non-default sizing constraint on the tooltip, but figured that is covered by the open question on "what are the right default UA styles?". Feel free to let me know if you think it is worth calling that out explicitly as a separate open question, as well.