change - convención de nombre de evento javascript/DOM
title css (3)
Hola cuando comencé a hacer desarrollo web, me di cuenta de que los nombres de eventos de JavaScript estaban en minúsculas sin separadores, es decir, "mousedown" , "mouseup" , etc. Y cuando trabajaba con la biblioteca jQuery UI, noté que también usan la misma convención ; es decir, "dropdeactivate" como en el siguiente ejemplo
javascript $( ".selector" ).on( "dropdeactivate", function( event, ui ) {} )
Si bien esto funciona bien para nombres que son solo de 2 o 3 palabras, es realmente horrible para los nombres con más palabras.
A pesar de esto, seguí esa convención también cuando tuve que disparar eventos personalizados (sintéticos) que creé, hasta hace poco cuando decidí que era mejor comenzar a usar algún tipo de separador. Ahora uso algo como "drop: deactivate" o "app: ready" .
en iOS Apple recientemente agregó este evento para la API de HTML 5 Airplay, y estoy de acuerdo con el autor de esta publicación http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review cuando dice:
Creo que "webkitcurrentplaybacktargetiswirelesschanged" ha ganado el récord: el nombre de evento de JavaScript más largo que haya existido .
¿Cuál es la razón detrás de esta extraña convención? ¿por qué no utilizar cualquier forma de separador o convención camelCase para nombrar los eventos de una manera más legible?
Creo que hay una razón para eso, muchas personas inteligentes trabajaron en esto ... Pero después de un tiempo todavía me pregunto por qué?
Desafortunadamente, no es tan simple cuando manejas convenciones heredadas. Y los eventos DOM tienen mucha historia detrás de ellos.
A continuación se detalla cómo se define el atributo de tipo de Event en la especificación de eventos DOM2:
Evento de interfaz (introducido en DOM nivel 2)
tipo (de tipo DOMString, solo lectura)El nombre del evento (sin distinción de mayúsculas y minúsculas). El nombre debe ser un nombre XML.
El razonamiento detrás de esto, supongo, se explica por este párrafo en el mismo documento:
En HTML 4.0, los detectores de eventos se especificaron como atributos de un elemento. [...] Para lograr la compatibilidad con HTML 4.0, los implementadores pueden ver la configuración de los atributos que representan los manejadores de eventos como la creación y el registro de un EventListener en EventTarget .
Ahora, aunque la postura ha cambiado en DOM3 (donde los nombres de los eventos son case-sensitive ), el enfoque original es, supongo, la opción más segura, así que uno no tendrá que depender de la corrección de los agentes del usuario (consultar esta discusión y este divertido problema como ejemplos).
Tenga en cuenta que el propio W3C ha registrado una gran cantidad de eventos CamelCased en DOM2 (todos los MutationEvents, DOMActivate , DOMFocusIn y DOMFocusOut ).
Por lo que puedo decir, no hay una práctica oficial con respecto a ese tema. Me parece que, dado que camelCase es el estándar generalmente aceptado para los nombres en js, se aplicaría lo mismo con el nombramiento de eventos. Sin embargo, como ha observado, js y muchas bibliotecas lo hacen de otra manera. He visto ambas convenciones utilizadas por grandes programadores, así que creo que es simplemente irrelevante. En el caso de "el nombre de evento de JavaScript más largo que haya existido", ese es un gran ejemplo de un evento que debería haber usado camelCase, en mi opinión ... o tal vez podrían haberlo acortado :)
Si quiere apegarse a lo que ha visto con más frecuencia, use minúsculas. Si crees que es difícil para los ojos (yo lo hago), utiliza camelCase. Probablemente no use nada más si estás tratando de cumplir con un estándar.
cuando se trata de convenciones, es de una forma u otra, un hábito, los marcos de JavaScript parecen seguir la convención de la API de eventos DOM de JavaScript, no sé si hay una razón o al menos un razonamiento claro por qué, pero simplemente es. para las convenciones generales, crockford es una de las mejores referencias que hay, pero no se mencionan los nombres de los eventos, pero al mismo tiempo here los eventos parecen ser un poco diferentes, lo que me hizo pensar en ello como una cuestión de elección, ni mas ni menos