Jsdom: Inline event handlers still not quite right

[domenic]

Two symptoms:

• [ ] inline-event-handler-ordering.html doesn't pass (even after a WPT roll to fix a bug that used to be present in it)
• [x] EventTarget-impl.js still has inline event handler stuff, but that really shouldn't be necessary anymore (fixed in https://github.com/tmpvar/jsdom/pull/1950)

To investigate after I disentangle myself from my current mess.

[snuggs]

Hope that mess isn't too bad @domenic. That being said...

In the snuggsi web components library we do the following convention:

<foo-bar onclick=onbaz></foo-bar>

<script>

Element `foo-bar`

(class extends HTMLElement {

  onbaz (event)
    { console.log (this, 'is the `<foo-bar>` element') }
})

</script>

We basically traverse the custom element's children looking for attributes within GlobalEventHandlers and "register" the class method of the exact same name. Afterwards then .binding handler to the custom element _(or explicitly registered .childNode as in the example above)_. Attempting to stick with tried and true classic event registration. _(Amazed no frameworks have really nailed this. Was a simple algo actually)_

Will this effect us at all? Or is this irrelevant to GlobalEventHandlers. We use jsdom for testing (of course). Also does this hint a phasing out in the html spec?
Seems to me that would be throwing out 🍼 👶 with 🛀 🚿 .

Thanks in advance for the heads up!

/cc @brandondees

[TimothyGu]

@snuggs I don't think it would affect you folks, it's just that the order of execution between listeners specified through the attribute and listeners registered through JS is fairly nuanced, and we haven't quite gotten it fully correct.

[snuggs]

Copy that @TimothyGu thanks for the swift response! Always love following you guys' work. 🙏