You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #8930 we resolved to standardize a ::tooltip pseudo-element to style UA generated tooltips, with some of the specifics TBD.
Possibly the main such decision that needs to be made is which properties are allowed in ::tooltip?.
This is intrinsically linked to another issue: should styled tooltips be able to escape window bounds?
As a reminder, native OS tooltips can escape window bounds:
If tooltips can escape window bounds, then security concerns may force us to adopt a smaller allowlist. Overall in the telcon it seemed there was consensus that we're ok to constrain the tooltip to always be within window bounds (or a margin around the window) so that we could get more styling capabilities, since that's what authors do today anyway with the custom JS libraries they use.
In terms of styling, as I mentioned in the original proposal, the actual styling usually applied is pretty basic, but control over the delay and animation is essential. Without it, most authors would not use this and still opt for a library.
Control over appearance effect
I suggest we do this via transitions, that authors can combine with @starting-style to customize the appearance effect. Doing it with animations would require weirdness like some reserved animation name, and animations are not really required here, since most appearance effects are pretty basic. UA stylesheets would have:
clip-path for custom shapes, and certain appearance effects
Filters and backdrop-filter
animation
mix-blend-mode
border-image
outline
text-decoration
fill and stroke
Other things
Note that positioning is absent: we resolved to leave it up to the UA for now while anchor positioning is fleshed out, then define it in terms of that.
Can users interact with the tooltip? Can they click on it or select text on it? Right now with OS-generated tooltips they cannot. If they can, then pointer-events and user-select would also be needed to disable that.
In #8930 we resolved to standardize a
::tooltip
pseudo-element to style UA generated tooltips, with some of the specifics TBD.Possibly the main such decision that needs to be made is which properties are allowed in
::tooltip
?.This is intrinsically linked to another issue: should styled tooltips be able to escape window bounds?
As a reminder, native OS tooltips can escape window bounds:
If tooltips can escape window bounds, then security concerns may force us to adopt a smaller allowlist. Overall in the telcon it seemed there was consensus that we're ok to constrain the tooltip to always be within window bounds (or a margin around the window) so that we could get more styling capabilities, since that's what authors do today anyway with the custom JS libraries they use.
In terms of styling, as I mentioned in the original proposal, the actual styling usually applied is pretty basic, but control over the delay and animation is essential. Without it, most authors would not use this and still opt for a library.
Control over appearance effect
I suggest we do this via transitions, that authors can combine with
@starting-style
to customize the appearance effect. Doing it with animations would require weirdness like some reserved animation name, and animations are not really required here, since most appearance effects are pretty basic. UA stylesheets would have:For example, the code to customize tooltips to fade-in and have no delay would be:
Allowlist proposal
So, here's what I would propose for a v0, i.e. the absolutely necessary ones:
text-transform
,letter-spacing
,word-spacing
, and the i18n text propertiesbackground
,color
,box-shadow
,text-shadow
,border-radius
,border
,padding
,opacity
(including their longhands)transform
,transform-origin
,rotate
,scale
,translate
Additionally, nice to haves would be:
clip-path
for custom shapes, and certain appearance effectsbackdrop-filter
animation
mix-blend-mode
border-image
outline
text-decoration
fill
andstroke
Other things
pointer-events
anduser-select
would also be needed to disable that.Editorial/Meta
(Moved to its own issue, see #9453)
The text was updated successfully, but these errors were encountered: