[css-pseudo-4] Semantics of CSSPseudoElement : EventTarget

[george-steel]

The CSSPseudoElement IDL specifies an inheritance from EventTarget, and this leaves a not a questions as to how enent handling on pseudo-elements should behave (which has no section on the spec). Is this interface only for animation events (transition events already target the parent but include a pseudoElement field to specify the pseudo-type)?

Currently system events (including click) which hit a pseudo-element are retargeted to the parent element before propagation. Should pseudo-elements be able to listen for these events, and if so, should event.target be the the pseudo-element (a breaking change) or the parent element.

Also, while the current system of event bubbling is well-defined for for the tree hierarchy for elements, some pseudo-elements (first-line, selection) feature multiple inheritance. How would pseudo-element events handle this. In normal event handling, a bubbled event always bubbles to it's parent element. However, when dealing with pseudo-elements, we have (following CSS cascade rules) we have the chain
parent -> parent::first-line -> child -> child::first-line
How would we handle bubbling in this case? Do we break normal order and follow the CSS inheritance hierarchy? Do we propagate through all the pseudo-elements first?

[Loirooriol]

I think this can only make sense for tree-abiding pseudo-elements: ::marker, ::before and ::after. Not for things like ::first-line.

[bfgeek]

@flackr

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] Semantics of CSSPseudoElement : EventTarget.

The full IRC log of that discussion

<dael> Topic: [css-pseudo-4] Semantics of CSSPseudoElement : EventTarget
<dael> github: https://github.com//issues/4398
<florian> s/Sep issue for number/Sep issue for type of number/
<dael> fantasai: I don't know what to do with it. I'm asking for help from WG
<dael> astearns: Anyone want to jump it?
<dael> astearns: Might be better to tag particular people
<dael> fantasai: Don't know who
<dael> florian: Punt while we figure out event handling for highlight APIs? Might influence here
<dael> florian: Until that's resolved we leave this hanging. Unless someone has better idea
<dael> sanketj: I think we discussed similar on a different call. I don't think there's impl interest in this area
<dael> dbaron: My reaction to the issue is probably worth going slow. One suggestion is this is only for animation events and that might be reasonable way to start
<dael> dbaron: Not a good idea to make intent to change event handling in non-backwards compat ways. Difference in how click events are handled is prob not what we want
<dael> florian: Even handling on pseudos we haven't attacked precisely, but want to handle it generally. I agree
<dael> astearns: Let's leave it here. We have highlight issue linked. This will go into issue
<dael> astearns: As dbaron says we can go slowly on this.