Re: [csswg-drafts] [css-ui] Standardize tooltip styling and expose as `::tooltip` (#8930)

@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 ?)

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1589742042 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 13 June 2023 17:31:53 UTC