[csswg-drafts] [selectors-4] Introduce `:popover` pseudo class (#8637)

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

== [selectors-4] Introduce `:popover` pseudo class ==
We [recently resolved](https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1276473056) to add general-purpose `:open` and `:closed` pseudo classes, which apply to "things that can open and close". While not defined in CSSWG, the stated [intention](https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1242377579) was to include things like `<details>`, `<select>`, `<dialog>`, and Popover.

@jakearchibald recently [raised](https://github.com/whatwg/html/issues/9055) the issue that in some cases, this is ambiguous, because there are multiple "ways" that something can be open or closed, and both might apply at the same time. Take, as an example, `<details popover>`, which can be "open" as a popover, but "closed" as a details, or vice versa. There's no way for these to be disambiguated on the basis of `:open` or `:closed` alone.

It is a bit unclear whether fullscreen elements should be included as "something that can open and close", but it's possible. That allows the possibility of a fullscreen `<details>` element which can be both open and closed. But fullscreen elements have a dedicated pseudo, `:fullscreen`, which allows one to disambiguate that state of openness vs. others.

It would seem that we need another such pseudo for popovers, because any element can also be a popover, and can therefore run into this dual-states problem. We discussed this in OpenUI, and [proposed `:popover`](https://github.com/whatwg/html/issues/9055#issuecomment-1481493678) as a pseudo class that applies only to popovers that are open (as a popover). That would allow developers to do:

```css
details[popover]:closed:popover {
  /* styles for a non-expanded details that is open as a popover */
}
```



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


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

Received on Thursday, 23 March 2023 17:14:37 UTC