api.Element.animationend_event - Element does not include event handlers, but HTML/MathML/SVGElement does

[saschanaz]

What type of issue is this?

Other

What information was incorrect, unhelpful, or incomplete?

16531 demixed animation events from GlobalEventHandlers to Element, but Element does not directly include GlobalEventHandlers.

https://html.spec.whatwg.org/multipage/dom.html#htmlelement

HTMLElement includes GlobalEventHandlers;

https://w3c.github.io/mathml-core/#dom-and-javascript

MathMLElement includes GlobalEventHandlers;

https://svgwg.org/svg2-draft/types.html#InterfaceSVGElement

SVGElement includes GlobalEventHandlers;

What browsers does this problem apply to, if applicable?

Chromium (Chrome, Edge 79+, Opera, Samsung Internet), Firefox, Safari

What did you expect to see?

Technically it does not exist on Element, so I'd say it should exist on each element?

That said, every sub-interface of Element include GlobalEventHandlers, but there's still a way to create an instance of Element, see below.

Did you test this? If so, how?

document.createElementNS("abc", "foo").onanimationcancel

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

No response

Do you have anything more you want to share?

I see the urge to ignore such edge case, since otherwise quite a lot of data should be duplicated to three interfaces. Perhaps this is a chance to change the spec?

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Element/animationend_event

MDN metadata

MDN page report details

* Query: `api.Element.animationend_event` * Report started: 2022-07-26T01:45:17.273Z

[queengooborg]

We had placed the events on Element vs. HTMLElement due to the target for the event rather than the event handler. @foolip wrote the following on the PR:

Like with most bubbling events we have too many entries. I've read https://drafts.csswg.org/css-animations/#events and Chromium's implementation, and it looks like the event target is always an Element for these events.

It might be helpful to add a note indicating that the event handler is only available on each individual element type's interface?

[saschanaz]

Like with most bubbling events we have too many entries. I've read https://drafts.csswg.org/css-animations/#events and Chromium's implementation

Not sure what Chromium's implementation exactly looks like, but if it does not check each Element's type then we should probably change the spec than keeping a weird edge case 🤔

[saschanaz]

While I specifically pointed to animation events, more events are affected by this kind of issue in 5.1.4+.

• all mouse/touch/pointer/key events
• selectstart (This being in Node is even more confusing)

[foolip]

The animate() method is on Element: https://drafts.csswg.org/web-animations-1/#extensions-to-the-element-interface

Presumably that does cause events to fire. I tested this in the case of at least some other events like "click".

It is weird that the events can fire but there are no event handler properties, but I'm not sure it's actually worth mentioning in docs. I don't have a strong opinion though.

[foolip]

To put things in another way, the presence of event handler properties on the web platform doesn't align very well with where events actually fire, with lots of discrepancies. We've tried to match where events actually fire, since starting from the properties would lead to much more weird situations.

I think a bunch of cases could be debated though, in particular selectstart could go on Element and Text instead of Node. I don't have a proposed rule for when to merge or split in situations like this.

[foolip]

Like with most bubbling events we have too many entries. I've read https://drafts.csswg.org/css-animations/#events and Chromium's implementation

Not sure what Chromium's implementation exactly looks like, but if it does not check each Element's type then we should probably change the spec than keeping a weird edge case 🤔

What might need changing? The spec doesn't mention SVG at all and only HTML with some references that aren't type tests. Granted, I still haven't tested that animation events can actually fire on pure Element instances, but per spec they can, right?

[saschanaz]

What might need changing?

I mean stop doing each include and do Element includes GlobalEventHandlers.

[foolip]

I agree that might be a sensible spec change. For various reasons spec editors have been reluctant to put things on Element that might not make sense for all XML languages, and I think there are no event handler properties on Element right now. It's worth proposing, I think.

[saschanaz]

To log my context: https://github.com/microsoft/TypeScript-DOM-lib-generator/ cannot automatically infer that GlobalEventHandlers members are now in Element, since the interface does not include the mixin. That specific situation can be workarounded (although not ideal) but it can be more problematic if this continues to happen to other things.