- From: Noam Rosenthal via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 06:09:39 +0000
- To: public-css-archive@w3.org
> I think we might want to have both approaches, the observer one for tracking async creation/removal of pseudos (to e.g. add event listeners), but I feel like we might still need the sync version as well, for example for:
> - An author might need to know the state of pseudo right now, for example, say you have a copy button and in its event listener you only want to do something if there is a selection, that would be as easy as:
> ```
> btn.onclick = () => {
> if (el.pseudo('::selection').exists) {
> copyToClipboard();
> }
> }
> ```
They should use the selection API
> - There might be some library/polyfill on a website that needs to be initialized. It might need to check if a pseudo is e.g. being rendered to fallback to poly filling it instead.
CSS.supports()
> - Theoretically, but still... If an author is just looping through the tree/list of elements to e.g. generate some report or export some data, sync check might be useful there.
They can do that in the resize observer loop
> - I wonder if the observer with its creation/removal pattern makes sense for non-tree-abiding pseudos, which are more like states.
Not sure...
> - An author might want to have a way to check the existence of a pseudo element in some unit testing. To e.g. check that the ::scroll-marker is really rendered.
The test runner can provide a sync check
--
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12158#issuecomment-3531020308 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 06:09:40 UTC