[csswg-drafts] [css-ui] Which properties should be available to `::tooltip`? (#9447)

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-ui] Which properties should be available to `::tooltip`? ==
In #8930 we [resolved](https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1644333441) 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: 
![](https://user-images.githubusercontent.com/865244/244259060-6b3c4b56-3d58-476c-82eb-8ef25e287ffc.png)
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 clip to 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](https://github.com/w3c/csswg-drafts/issues/8930#issue-1746705324), 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`](https://drafts.csswg.org/css-transitions-2/#defining-before-change-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:

```css
::tooltip {
 transition: 0s 2s;

 @starting-style {
  visibility: hidden;
 }
}
``` 

For example, the code to customize tooltips to fade-in and have no delay would be:

```css
::tooltip {
 transition: 300ms;

 @starting-style {
  opacity: 0;
 }
}
``` 

## Allowlist proposal

So, here's what I would propose for a v0, i.e. the absolutely necessary ones:


- All font properties, `text-transform`, `letter-spacing`, `word-spacing`, and the [i18n text properties](https://drafts.csswg.org/css-writing-modes-3/)
- Styling: `background`, `color`, `box-shadow`, `text-shadow`, `border-radius`, `border`, `padding`, `opacity` (including their longhands)
- Transitions (see above)
- Transforms (mainly useful for appearance transitions): `transform`, `transform-origin`, `rotate`, `scale`, `translate` 
- Custom properties

Additionally, nice to haves would be:
- `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.

## Editorial/Meta

We are starting to have a fair number of pseudo-classes and pseudo-elements that accept restricted sets of properties:
1. `:visited`
2. `::selection`
3. `::marker`
4. `::placeholder`
5. `::grammar-error`
6. `::spelling-error`
7. `::highlight()`

It may be useful to create "sets" of properties that we can refer to, so we don't have to update several locations when we add a new property, which is error-prone. We've already started doing that for the [highlight pseudo-elements](https://drafts.csswg.org/css-pseudo/#highlight-pseudo-element). It would also be easier for authors if there are specific sets, rather than each pseudo having its own ad hoc allowlist.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9447 using your GitHub account


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

Received on Saturday, 7 October 2023 19:51:37 UTC