- From: Bramus via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2025 12:54:08 +0000
- To: public-css-archive@w3.org
> I don't think they can completely become first-class citizens in the DOM. Because in events, the [`target`](https://dom.spec.whatwg.org/#dom-event-target) isn't a pseudo-element, and allowing it to be a `CSSPseudoElement` seems most likely not web compatible.
But [[`CSSPseudoElement`]](https://drafts.csswg.org/css-pseudo-4/#CSSPseudoElement-interface) is specced to extend `EventTarget`, which would make it work?
> > Get info about their position+size
>
> In some cases you can use `getComputedStyle` to get the height and width.
The `getComputedStyle` is not enough to, for example, get a `::view-transition-group()`’s position mid-flight.
> I don't think `getBoundingClientRect()` makes much sense for non-tree-abiding pseudo-elements like `::selection`.
Good call. My assumption is that it would return `null` or throw when called on a non-tree-abiding pseudo-element.
> > Animate them: Only if they already have animation attached to them that you can hijack
>
> You don't need to hijack, you can animate directly, this works on browsers:
🤦♂️ Duh, of course … and to say I even created a demo that uses it the very same day I posted this. Sorry, my bad!
> > Theoretically using Element.getAnimations() but that is not specced yet
>
> It's specced (but seems unimplemented): https://drafts.csswg.org/web-animations-1/#dictdef-getanimationsoptions
>
> element.getAnimations({pseudoElement: "::before"})
My proposal is to allow `getAnimations` to work directly on `CSSPseudoElement` instead needing to call `getAnimations` on its ultimate originating element.
--
GitHub Notification of comment by bramus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11559#issuecomment-2609737739 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 January 2025 12:54:09 UTC