Jsdom: Los controladores de eventos en línea todavía no están del todo bien

Creado en 20 ago. 2017 · 3Comentarios · Fuente: jsdom/jsdom

Dos síntomas:

[ ] inline-event-handler-ordering.html no pasa (incluso después de una tirada de WPT para corregir un error que solía estar presente en él)
[x] EventTarget-impl.js todavía tiene cosas de controlador de eventos en línea, pero eso ya no debería ser necesario (corregido en https://github.com/tmpvar/jsdom/pull/1950)

Para investigar después de desenredarme de mi lío actual.

Fuente

domenic

Comentario más útil

@snuggs No creo que los afecte, es solo que el orden de ejecución entre los oyentes especificados a través del atributo y los oyentes registrados a través de JS tiene bastantes matices, y no lo hemos entendido del todo correctamente.

TimothyGu en 24 ago. 2017

❤1 🎉1 👍1

Todos 3 comentarios

Espero que el desorden no sea tan malo @domenic. Habiendo dicho eso...

En la biblioteca de componentes web de snuggsi hacemos la siguiente convención:

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

<script>

Element `foo-bar`

(class extends HTMLElement {

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

</script>

Básicamente, recorremos los elementos secundarios del elemento personalizado en busca de atributos dentro GlobalEventHandlers y "registramos" el método de clase con el mismo nombre exacto. Luego, .bind ing handler al elemento personalizado _(o registrado explícitamente .childNode como en el ejemplo anterior)_. Intentando seguir con el registro de eventos clásico probado y verdadero. _(Sorprendido, ningún marco realmente ha dado en el clavo. En realidad, era un algoritmo simple )_

¿Esto nos afectará en algo? ¿O esto es irrelevante para GlobalEventHandlers . Usamos jsdom para probar (por supuesto). ¿Esto también sugiere una eliminación gradual en la especificación html?
Me parece que sería tirar 👶 🍼 con 🚿 🛀 .

¡Gracias de antemano por el aviso!

/cc @brandondees