link - ¿Es una mala práctica insertar JavaScript en el cuerpo del HTML?
use js file in html (17)
No había visto esto antes. Parece funcionar en los pocos buscadores que he probado. Pero hasta donde sé, no es válido poner etiquetas de script en lugares como este.
Es válido, pero no es una buena (o recomendada) práctica.
¿Me equivoco? ¿Qué tan malo es que estamos poniendo etiquetas de script dentro de etiquetas div como esta? ¿Hay algún problema de compatibilidad del navegador que deba tener en cuenta?
No hay problema para colocar un <script> debajo de otros elementos (pero debe estar dentro de <head> o <body> ). Tampoco hay problema en términos de compatibilidad con el navegador, sin embargo, incrustar scripts JS en páginas web presenta serias desventajas (cómo / por qué se consideran malas) :
- Agrega el peso de la página
- Dificultad (o probablemente imposible) para la minificación
- No se puede migrar ni se puede usar para otras páginas
- No se puede almacenar en caché (debe descargarse cada vez que se carga la página)
- Sin separación de preocupaciones (más difícil de mantener)
Un equipo en el que estoy trabajando ha adquirido el hábito de usar etiquetas <script> en lugares aleatorios en el cuerpo de nuestras páginas HTML. Por ejemplo:
<html>
<head></head>
<body>
<div id="some-div">
<script type="text/javascript">//some javascript here</script>
</div>
</body>
</html>
No había visto esto antes. Parece funcionar en los pocos buscadores que he probado. Pero hasta donde sé, no es válido poner etiquetas de script en lugares como este.
¿Me equivoco? ¿Qué tan malo es que estamos poniendo etiquetas de script dentro de etiquetas div como esta? ¿Hay algún problema de compatibilidad del navegador que deba tener en cuenta?
¡Es válido!
Puedes usar:
<script type="text/javascript">
//<![CDATA[
// Some JavaScript code that perfectly validates in the W3C validator
//]]>
</script>
No creo que puedas decir si es una mala práctica en general. Tienes que decirlo en el caso. Pero seguro es que es bueno tener todo tu código JavaScript en el mismo lugar. Es un poco complicado si tiene pequeñas piezas de código JavaScript en todo su archivo HTML.
Ciertamente es legal; Lo he visto en algunas páginas aquí en Exforsys, por ejemplo.
Ahora este es un sitio de tutorial que muestra los conceptos básicos de HTML y JavaScript, por lo que en ese contexto es perfectamente comprensible. Sin embargo, no me gustaría verlo en el código de producción por algo más que una simple declaración o dos. Sin ver lo que ha reemplazado // Some JavaScript code here que no me gustaría comentar.
Sin embargo, no debería haber problemas con este navegador.
Como mencionaron varias personas, es válido, funciona y se usa ampliamente.
Las mejores prácticas en cuanto a la semántica recomiendan (o al menos se usan para recomendar) es colocar etiquetas de script dentro del encabezado.
Las mejores prácticas más modernas que tienen en cuenta el rendimiento recomiendan colocar etiquetas de script (externas y en línea) en la parte inferior derecha antes de la etiqueta corporal, para permitir que el marcado se visualice por completo antes de que se ejecute cualquier código JavaScript.
Para un código más fácil de entender y de mantener, se recomienda "JavaScript discreto", donde el código se encuentra en un archivo externo y vincula los eventos al DOM (JavaScript discreto de Google).
Un caso donde es útil tener JavaScript en línea es inicializar variables con valores que solo existen en el lado del servidor, que luego serán utilizados por el código JavaScript externo.
Consulte la interfaz de usuario de Yahoo para conocer las mejores prácticas: http://developer.yahoo.com/performance/rules.html (JavaScript en la parte inferior de la página)
En realidad, es bastante común. Por ejemplo , el código de seguimiento analítico de Google usa solo esta sintaxis:
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src=''" + gaJsHost + "google-analytics.com/ga.js'' type=''text/javascript''%3E%3C/script%3E"));
</script>
Si es lo suficientemente bueno para Google ...
Es perfectamente válido, aunque podría perjudicar la capacidad de mantenimiento. Ver también ¿Dónde debo poner las etiquetas <script> en el marcado HTML? y ¿Por qué la llamada a esta función jQuery falla en Firefox? .
Es perfectamente válido.
No querrá poner grandes bloques de código mezclados en el marcado allí (es mejor usar scripts externos), pero puede ser útil para:
agregar información de enlace adicional para la mejora progresiva (donde esos datos son difíciles de encajar en un nombre de clase u otro enfoque para ocultar información extendida en atributos); o
donde es necesario iniciar una mejora con guión lo más rápido posible (en lugar de esperar la carga de la ventana / listo para el documento). Un ejemplo de esto sería el autofoco, que puede irritar si se dispara demasiado tarde.
Puede estar pensando en elementos <style> , que no están permitidos en <body> (aunque la mayoría de los navegadores lo permiten).
Es una de muchas, muchas mejores prácticas que se trata tanto de mejorar el rendimiento como de mejorar su enfoque de programación.
¡En definitiva, en el desarrollo web, sacar el producto es lo más importante!
Es válido agregar <script> en el body , pero a Internet Explorer realmente no le gusta. Para estar del lado seguro, asegúrese de tener sus scripts dentro de la etiqueta <head>.
Eso realmente estaba creando estragos (especialmente para Internet Explorer) en el proyecto en el que estamos trabajando.
Es válido y, dependiendo de su marco de trabajo del servidor y la naturaleza del código, a veces es muy difícil de evitar.
La recomendación a menudo mencionada de que las secuencias de comandos deben mantenerse en el encabezado es para garantizar que la secuencia de comandos se carga antes de que se llame. Esto es solo un problema para ciertos manejadores de eventos. Para otros tipos de script, no importa, y para algunos tipos (como document.write), no tiene ningún sentido.
Prefiero poner referencias a scripts externos en la cabeza, y scripts que inician cosas e inicializan widgets y otras cosas en el cuerpo.
Un problema que es muy fácil de encontrar es que un elemento de script en el cuerpo no puede acceder a los elementos que vienen después. Además, un problema relacionado con la compatibilidad desagradable del navegador es el hecho de que IE no permite que los elementos del script modifiquen el elemento en el que se encuentran. Por lo tanto, si tiene esto:
<div id="foo">
<script type="text/javascript">
document.getElementById("foo")... // do something to it
</script>
</div>
IE no le va a gustar su página. Las versiones anteriores de IE solían dar mensajes de error muy crípticos para esto o incluso en blanco toda la página, pero IE8 parece dar un mensaje de error descriptivo.
Siempre y cuando se asegure de que sus scripts solo acceden a DOM que sea de acceso seguro, no creo que sea malo poner elementos de script en el cuerpo. De hecho, en mi humilde opinión, poner guiones que inicializan widgets después de los elementos relacionados puede ser más legible que poner todo en un solo lugar (y creo que esto también podría hacer que se ejecuten antes, lo que hace que las cosas salten menos a medida que la página se carga).
Si tiene un editor que pueda manejar la sintaxis HTML y JavaScript simultáneamente. Y si le gusta leer primero algunas líneas de HTML y luego cpde JavaScript ... seguro. Ve a por ello.
Sin embargo, también es bueno saber que el código JavaScript necesario para una sección de HTML va a estar ahí para eso. En lugar de tener que afirmar y crear alguna inclusión en la parte superior del archivo.
Entonces, en lugar de "si vas a usar este HTML, asegúrate de importar xyz.js", solo puedes incluir el HTML y terminarlo.
Entonces, no es necesariamente horrible mal. Tal vez no espectacularmente increíble, pero tampoco absolutamente terrible. Depende de la intención.
Supongo que su equipo está haciendo esto porque quieren insertar un script dinámicamente o porque están escribiendo un script que se activará al cargar la página.
No diría que hay nada de malo en hacer esto cuando sea ABSOLUTAMENTE NECESARIO (siempre que esté en un bloque CDATA), pero aparte de eso, recomendaría a su equipo que utilicen una biblioteca de scripts como Prototype o jQuery, y mantengan los scripts externos a la página. Esto es generalmente más limpio, y las bibliotecas a veces obligan a un poco de limpieza al código, que apostaría que no está sucediendo actualmente.
Tampoco me gustaría ejecutar funciones que consumen tiempo en las etiquetas de script en línea, ya que esto sucede en la carga de la página, y como Jason dijo anteriormente, podría ralentizar la carga de la página. Todas las bibliotecas de scripts tienen funciones ordenadas que le permiten hacer cosas al cargar la página, y le darán la opción de cuándo en la página cargar para dispararlas, como después de cargar el DOM.
Unas pocas cosas:
- Es completamente válido en cuanto a código.
- Es completamente no recomendado.
Hacer esto ralentiza considerablemente la carga de la página ya que el código JavaScript se debe ejecutar antes de que se pueda procesar el resto de la página. Si trabajas mucho en ese código JavaScript, tu navegador podría bloquearse. Debería intentar (siempre que sea posible) cargar su código JavaScript dinámicamente y al final de su página (preferiblemente antes de la etiqueta </body> ).
Compra y lee JavaScript de alto rendimiento . Cambiará la forma en que escribe el código JavaScript.