[css-pseudo] Who is currently using CSSPseudoElement and what events can target them?

[sanketj]

As far as I understand, the main motivation for making CSSPseudoElement an EventTarget was the web animations API. However, the web animations spec has since dropped its dependency on CSSPseudoElement (#4437 ). So I was wondering if there are any other specs that currently depend on CSSPseudoElement, and whether there are any spec'ed events that have a CSSPseudoElement target?

[Loirooriol]

It's not clear if web animations can get rid of CSSPseudoElement in the nested case, see #4487

[frivoal]

As far as I can tell, this is more of a question than an issue, and we're trying to get people's attention to answer it. Since Github alone hasn't worked so far, Agenda+ to draw attention to it.

[hober]

cc @graouts @megangardner

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Who is currently using CSSPseudoElement and what events can target them?, and agreed to the following:

• RESOLVED: Add a warning to the section and close this issue but continue work

The full IRC log of that discussion

<dael> Topic: [css-pseudo] Who is currently using CSSPseudoElement and what events can target them?
<dael> github: https://github.com//issues/4619
<dael> florian: This is more of a request for information. CSS Pseudol Element class exists and is an event target, but it's not clear what API uses and what events it recieves. When the issue was raised I think intent was figure out who should we talk to when we refine events on Pseudos
<emilio> q+
<dael> florian: This has been sitting in GH for a while without feedback. This is a louder call to figure out who is the crowd interested
<dael> emilio: I think main consumer is web animations. like css animations that target css pseudo elements. Not aware of other consumers.
<dael> florian: I'm a little fuzzy on this b/c decision to stop using pseudo elements as a class on animation, but pointed out there still is. But that would be the group
<dael> astearns: One of the reasons we pushed to have css pseduo element historically is we thought regions could be made out of pseudo elements but that's moot at this point
<dael> florian: I see reasons why it's useful, but before drafting new things it would be good to know what's done
<dael> gregwhitworth: Are yous aying you can't animation pseudo elements?
<dael> florian: No, but I believe API shape of animations has changed and it's no longer done through pseudol element class set up in pseudos 4. I could be wrong. A bit out of my area
<dael> astearns: Anyone else with a known dependency or use case for css pseudo element as an event target?
<dael> astearns: So it may be down to whatever use case web animations might have?
<dael> florian: Plus what sanketj and I want to add
<dael> sanketj: Does anyone use pseudo element not as an event target? Web animation sis only thing I could tell which has since been dropped. I didn't find any users of pseudo element at all
<dael> florian: I have use cases, but not existing usage
<dael> iank_: I think this has been one of the things that's an obvious gap on api side. Nice to get target if it's exposed but not high priority so hasn't been impl
<dael> sanketj: Should we try to remove css pseudo element and come at it again in a different way? Not sure the process
<dael> astearns: If there are no consumers and little impl interest it's plausable to remove it and retain intent of fixing the hole in the API. Need motivating use cases to spur impl interest
<dael> florian: I don't know. If we suspect API shape is wrong maybe remove. but I believe there are use cases that we're slowly getting ot. Having a place where we accumulate our way to useful thing it would be good. If we start by deleting it doesn't speed up getting there
<dael> astearns: Fair point
<dael> astearns: sanketj do you have an argument for deletion?
<dael> sanketj: Not specifically. originally looked around highlight api and there are not highlight events. pseudo element being an event target prompted us to look. I don't think I have a way to have it useful in highlight, but I don't have a strong reason to delete or keep
<dael> florian: I have other use cases to look into in the near future. I'd like to keep working. For now it's hear so no rush to delete
<dael> iank_: One thing to keep in mind is only before and after pseudo elements make sense with this API. Perhaps merging in that this might change is a path
<dael> sanketj: Yes, only tree abiding was designed originally I think. I don't believe it works for range based
<dael> iank_: Yeah, for example doesn't make sense for ::first-line
<dael> fantasai: Would work for any, but only defined for tree abiding. Every pseudo element has originating element. If you highlight it will cross multiple pseudo elements as you cross multiple elements
<dael> iank_: In related to geometry apis and event propegation the tree abiding ones are much siplier
<dael> florian: I'd suggest slap a warning across this area of the spec saying don't rush to impl but if you have use cases or problems bring forward
<iank_> sorry sanketj :)
<sanketj> thanks for covering it :)
<dael> astearns: As a way forward put a warning on this part of the spec that this is early and needs fleshing out. Do we close this issue with a reoslution to have a warning or do we need to dive into web animations usage more
<dael> florian: Since we're not resolving to delete it I don't think we need the explaination urgently
<dael> astearns: Prop: Add a warning to the section and close this issue
<dael> astearns: Objecitons?
<dael> RESOLVED: Add a warning to the section and close this issue but continue work

[graouts]

Web Animations was using CSSPseudoElement for a while but that dependency was removed to be able to move towards finalization of Web Animations 1.0.