- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 07 Aug 2025 16:02:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``How to handle addEventListener on `CSSPseudoElement`?``.
<details><summary>The full IRC log of that discussion</summary>
<sakhapov> sakhapov<br>
<zcorpan> sakhapov: We discussed in CSSWG. On board with event listeners for pseudo-elements. Went to whatwg to propose<br>
<zcorpan> sakhapov: Feedback that pseudo-elements shouldn't have such powers<br>
<zcorpan> sakhapov: Asking here with folks from both groups<br>
<sakhapov> https://github.com/w3c/csswg-drafts/issues/12575<br>
<zcorpan> sakhapov: New approach that Noam suggested<br>
<sakhapov> 12575<br>
<zcorpan> sakhapov: Reuse slot to represent the pseudo-element<br>
<emilio> I have to drop (conflict), but I commented on Noam's proposal and it seems potentially nice / less complex?<br>
<keithamus> q+<br>
<zcorpan> sakhapov: Want to address concern from annevk and lea, about events<br>
<zcorpan> astearns: Not a new ask to support this<br>
<astearns> ack keithamus<br>
<zcorpan> keithamus: From what I heard, it's a bit confusing. Adds a lot of API surface. How would events propagate?<br>
<zcorpan> keithamus: Will not achieve the desired effect, i.e. understand when an event fired from a pseudo<br>
<zcorpan> keithamus: Would be a closed shadow tree. The event path would be retargeted, would only see where the click originated from<br>
<zcorpan> keithamus: other than the host<br>
<zcorpan> keithamus: Don't understand how the two proposals can complement each other, or how the second proposal solves what teh first is claiming<br>
<zcorpan> keithamus: Personally objecting to the notion to have events fired on pseudos<br>
<zcorpan> sakhapov: We fire the second contained event, only for the pseudo object<br>
<zcorpan> sakhapov: Add a property to event, e.g. pseudoTarget<br>
<zcorpan> keithamus: Why not add that to the first event?<br>
<zcorpan> sakhapov: For mouseover event, should not fire the second event when you move from pseudo to the real element<br>
<zcorpan> sakhapov: For only one event, problem with target change<br>
<lea> Thinking out loud, it seems that the right primitive that is needed is a way for the web platform to do regular elements (with regular DOM objects, targeted by selectors etc) where some things are off-limits and cannot be accessed, set or matched (what things those are depends on the case, e.g. descendants, element type, attributes etc). That would also fix all the issues with `::slotted()` and `::part()` as well, and (depending on how it's<br>
<lea> defined) has the potential to fix a ton of shadow DOM pain points too. But obviously, that's much larger scope.<br>
<lea> Pseudo-elements were originally envisioned as a way for CSS to target parts of an element or not real elements, and using them to do encapsulation with regular elements it usually creates a host of issues.<br>
<zcorpan> keithamus: practical ramifications? Why can't we do that? I've heard the theoretical issue, but is it an issue in practice?<br>
<zcorpan> sakhapov: mouseover?<br>
<flackr> q+<br>
<zcorpan> sakhapov: Existing websites. Hovering, firing two events for teh same element can confuse or break things<br>
<zcorpan> smaug: need mouseout. Don't get the right combination of events<br>
<zcorpan> keithamus: aha, I see<br>
<astearns> ack flackr<br>
<zcorpan> flackr: Can we treat the pseuido as a real element?<br>
<zcorpan> flackr: Already a problem if you have multiple real elements in an ancestor<br>
<zcorpan> sakhapov: Fire an event only on the pseudo, which doesn't bubble. Second event is fired on the element as today<br>
<zcorpan> flackr: If we restrict (MISSED)<br>
<zcorpan> sakhapov: Don't want to change the old behavior<br>
<zcorpan> sakhapov: only want to know info that a specific pseudo got some events<br>
<astearns> s/(MISSED)/contained events to boundary events (I think)/<br>
<zcorpan> flackr: Usually done with event delegation<br>
<masonf> q+<br>
<zcorpan> flackr: Would want to know at the root<br>
<zcorpan> flackr: Don't think they don't want it, if we can solve it as bubbles<br>
<zcorpan> annevk: One solution is to use real elements instead of pseudo-elements<br>
<zcorpan> lea: agree with annevk. Psueod-elements are not real elements<br>
<masonf> q-<br>
<zcorpan> keithamus: ::part() and ::slot() are (MISSED)<br>
<astearns> s/Psueod-elements/Some pseudo-elements/<br>
<zcorpan> flackr: can exclude ::first-line<br>
<zcorpan> lea: architecture becomes unclear<br>
<keithamus> s/(MISSED)/element backed<br>
<zcorpan> lea: Not consistent, more complicated story to tell<br>
<zcorpan> lea: slotted and part are huge pain points today<br>
<zcorpan> lea: Trying to make pseudo-elements do things they were not intended to do<br>
<zcorpan> lea: Not sure the solution is to add more stuff to them<br>
<zcorpan> lea: If you see the problem space as exposing elements while not exposing as elements, (MISSED)<br>
<zcorpan> annevk: Also worried that it's a slippery slope<br>
<lea> +1 annevk<br>
<zcorpan> annevk: Easier if carousel use real elements, like all other widgets we have<br>
<zcorpan> sakhapov: View transitions ...<br>
<fantasai> +1 annevk<br>
<zcorpan> flackr: We already distinguish element-backed pseudos. This is just an extension<br>
<zcorpan> flackr: They are hit-testable<br>
<lea> q?<br>
<zcorpan> astearns: For clarification, are you suggesting we should stop adding new pseudos?<br>
<zcorpan> annevk: If you have a use case that warrants an element, then use an element<br>
<lea> q+<br>
<zcorpan> annevk: If you want just styling, pseudo is OK<br>
<zcorpan> keithamus: precedent for `details`. Implicit summary, but a real element can be added<br>
<astearns> ack lea<br>
<zcorpan> lea: I think element-backed pseudos were a mistake<br>
<zcorpan> lea: Easier to introduce pseudos than a general solution<br>
<jarhar> q+<br>
<zcorpan> lea: We should have solved it differently imo<br>
<zcorpan> lea: So many issues with the pseudo-element solution for slotted<br>
<zcorpan> lea: Understand that it's bigger scope<br>
<ntim> element-backed pseudos do not expose the underlying elements themselves fyi<br>
<astearns> ack jarhar<br>
<zcorpan> jarhar: For customizable select the picker was an author-provided element<br>
<masonf> q+<br>
<zcorpan> jarhar: Later, changed to shadowroot that the author doesn't provide since it always needs to exist<br>
<zcorpan> jarhar: not up to date on carousel<br>
<lea> q+<br>
<zcorpan> jarhar: forcing the author to write every element, seems better to generate<br>
<astearns> ack masonf<br>
<lea> qq+<br>
<zcorpan> masonf: too late to debate whether we should have pseudos<br>
<zcorpan> masonf: developer-wise, pseudos are nice<br>
<zcorpan> masonf: Nicely handled by the browser, e.g. ::after<br>
<flackr> +1<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to react to masonf<br>
<zcorpan> lea: I think misunderstanding. I think pseudos are great. Discussed element-backed pseudos<br>
<zcorpan> lea: Didn't suggest authors should be writing them<br>
<zcorpan> lea: expose regular elements<br>
<zcorpan> lea: can be generated by teh browser<br>
<zcorpan> masonf: In the shadow tree (can't expose) or in the real tree (also funny)<br>
<zcorpan> lea: that's with what we currently have... Could change what we expose<br>
<zcorpan> masonf: That's the shape of this proposal though?<br>
<flackr> +1<br>
<zcorpan> lea: Proposal to introduce DOM object to represent pseudo-elements<br>
<zcorpan> annevk: I think what you're saying is also not "a real element". <summary>-like is more what I had in mind<br>
<zcorpan> sakhapov: My proposal is you have a pseudo ...<br>
<zcorpan> annevk: We take issue with adding events to pseudo-elements, hence discussing these other things<br>
<zcorpan> masonf: My understanding was if you want events or so, add a normal element<br>
<ntim> I'm not aware of view transitions use cases<br>
<lea> q?<br>
<zcorpan> masonf: Let the browser do the nice thing by default, but allow<br>
<zcorpan> annevk: I would like some more explanation on the view transitions use case<br>
<flackr> q+<br>
<zcorpan> annevk: hard to imagine why we want to listen for events there<br>
<zcorpan> annevk: for scroll, seems more tricky<br>
<keithamus> q+<br>
<astearns> ack lea<br>
<astearns> q+<br>
<zcorpan> lea: If it boils down to making authors do more work, I would vote for using pseudo-elements due to the priority of constituencies<br>
<astearns> ack flackr<br>
<zcorpan> flackr: One alternative is, rather than pseudos being a full part of the event path, just add pseudo to the normal event<br>
<lea> Oh that's a very interesting compromise<br>
<zcorpan> astearns: No additional events<br>
<zcorpan> astearns: If you have a listener only for a pseudo<br>
<zcorpan> lea: part of adding the listener<br>
<zcorpan> flackr: That was part of the proposal<br>
<zcorpan> annevk: I thought exposing pseudo on the event was dismissed, but didn't understand why<br>
<zcorpan> keithamus: can't observe changes<br>
<zcorpan> keithamus: e.g. transition from ::before to the host element<br>
<lea> e.g. `element.addEventListener("click", { pseudoElement: "foobar" })`<br>
<zcorpan> masonf: can you add something to the options bag? opt-in when adding the event listener<br>
<zcorpan> flackr: Sure<br>
<zcorpan> lea: Do both?<br>
<zcorpan> flackr: Yes<br>
<smaug> rather ugly to use addEventListener as a way to change how events are dispatched<br>
<astearns> ack keithamus<br>
<zcorpan> keithamus: Earlier discussion about difficulty of authoring scroll markers<br>
<zcorpan> keithamus: generate a carousel of however many images<br>
<zcorpan> keithamus: N number of LIs and buttons<br>
<lea> Slotting in these seems independently useful. E.g. you want a custom icon on a scroll marker, you shouldn't have to generate it in CSS (which currently involves a ton of hoops depending on the way you do icons…)<br>
<zcorpan> flackr: Can create a scroll marker for pages, not possible without a lot of script<br>
<zcorpan> astearns: propagation... If we added an event listener to the pseudo-object, never propagate<br>
<zcorpan> astearns: Authors would need to send it manually to propagate<br>
<zcorpan> lea: I don't follow<br>
<flackr> keithamus: an example is https://codepen.io/flackr/pen/yLmyPEV or https://chrome.dev/carousel/horizontal/pages/<br>
<zcorpan> astearns: Let's keep discussing in the issue<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12163#issuecomment-3164836504 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 August 2025 16:02:16 UTC