Jsdom: Les gestionnaires d'événements en ligne ne sont toujours pas tout à fait corrects

Créé le 20 août 2017 · 3Commentaires · Source: jsdom/jsdom

Deux symptômes :

[ ] inline-event-handler-ordering.html ne passe pas (même après un roll WPT pour corriger un bug qui y était présent)
[x] EventTarget-impl.js a toujours des éléments de gestionnaire d'événements en ligne, mais cela ne devrait plus être nécessaire (corrigé dans https://github.com/tmpvar/jsdom/pull/1950)

A enquêter après m'être débarrassé de mon désordre actuel.

Source

domenic

Commentaire le plus utile

@snuggs Je ne pense pas que cela vous affecterait, c'est juste que l'ordre d'exécution entre les auditeurs spécifiés via l'attribut et les auditeurs enregistrés via JS est assez nuancé, et nous ne l'avons pas tout à fait correct.

TimothyGu le 24 août 2017

❤1 🎉1 👍1

Tous les 3 commentaires

J'espère que ce gâchis n'est pas trop grave @domenic. Cela étant dit...

Dans la bibliothèque de composants Web snuggsi, nous faisons la convention suivante :

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

<script>

Element `foo-bar`

(class extends HTMLElement {

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

</script>

Nous parcourons essentiellement les enfants de l'élément personnalisé à la recherche d'attributs dans GlobalEventHandlers et "enregistrons" la méthode de classe portant exactement le même nom. Ensuite, .bind ing handler vers l'élément personnalisé _(ou explicitement enregistré .childNode comme dans l'exemple ci-dessus)_. Essayer de s'en tenir à l'enregistrement d'événements classique éprouvé. _(Étonné qu'aucun framework n'ait vraiment réussi. C'était un simple algo en fait )_

Cela nous affectera-t-il du tout? Ou est-ce sans rapport avec GlobalEventHandlers . Nous utilisons jsdom pour les tests (bien sûr). Cela implique-t-il également une suppression progressive de la spécification html?
Il me semble que ce serait jeter 🍼 👶 avec 🛀 🚿 .

Merci d'avance pour l'avertissement !

/cc @brandondees