Jsdom: Inline-Event-Handler noch nicht ganz richtig

Hoffe, das Durcheinander ist nicht so schlimm @domenic. Davon abgesehen...

In der Snuggsi-Webkomponentenbibliothek machen wir die folgende Konvention:

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

<script>

Element `foo-bar`

(class extends HTMLElement {

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

</script>

Wir durchlaufen im Grunde die untergeordneten Elemente des benutzerdefinierten Elements, suchen nach Attributen in GlobalEventHandlers und "registrieren" die Klassenmethode mit genau demselben Namen. Danach .bind ing Handler an das benutzerdefinierte Element _(oder explizit registrierte .childNode wie im obigen Beispiel)_. Der Versuch, bei der bewährten klassischen Eventregistrierung zu bleiben. _(Erstaunlich, dass keine Frameworks das wirklich geschafft haben. War eigentlich ein einfacher Algo )_

Wird uns das überhaupt beeinflussen? Oder ist dies für GlobalEventHandlers irrelevant. Wir verwenden jsdom zum Testen (natürlich). Deutet dies auch auf ein Auslaufen der HTML-Spezifikation hin?
Mir scheint, das wäre rauswerfen von 🍼 👶 mit 🛀 🚿 .

Vielen Dank im Voraus für die Köpfe!

/cc @brandondees

@snuggs Ich glaube nicht, dass es Sie betreffen würde, es ist nur so, dass die Ausführungsreihenfolge zwischen Listenern, die durch das Attribut angegeben sind, und Listenern, die über JS registriert sind, ziemlich nuanciert ist, und wir haben es nicht ganz richtig hinbekommen.

Kopieren Sie das @TimothyGu , danke für die schnelle Antwort! Ich liebe es immer, die Arbeit von euch zu verfolgen. 🙏