Jsdom: Inline event handlers still not quite right

Created on 20 Aug 2017 · 3Comments · Source: jsdom/jsdom

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.

Source

domenic

Most helpful comment

@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.

TimothyGu on 24 Aug 2017

❤1 🎉1 👍1

All 3 comments

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