- 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