¿Es una mala práctica incrustar JavaScript en el cuerpo de HTML?

84

Un equipo en el que estoy trabajando se ha acostumbrado a utilizar <script>etiquetas en lugares aleatorios del 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 navegadores que he probado. Pero hasta donde yo sé, no es válido poner etiquetas de script en lugares como este.

¿Me equivoco? ¿Qué tan malo es que coloquemos etiquetas de script dentro de etiquetas div como esta? ¿Hay algún problema de compatibilidad del navegador que deba tener en cuenta?

javascript html Andrés
fuente
1
¿Está funcionando document.writesallí o no hay ninguna razón particular para que esté donde está?
Martin Smith
8
Es legal que los guiones aparezcan en cualquier parte del cuerpo. No hay nada de malo en eso. Tiene sus implicaciones (tiempo, mantenibilidad, mezcla de código y diseño, preferencia personal), pero por lo demás está bien.
Tomalak
@earlz: vea mi respuesta sobre por qué es malo. tratando de salvar una vida aquí. y estoy en lo correcto.
Jason

Respuestas:

88

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 vinculación 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 sea necesario iniciar una mejora con guión lo más rápido posible (en lugar de esperar a que se cargue la ventana / esté listo para el documento). Un ejemplo de esto sería el enfoque automático, que puede irritar si se dispara demasiado tarde.

Es posible que esté pensando en <style>elementos que no están permitidos <body>(aunque la mayoría de los navegadores lo permiten).

bobince
fuente
12
+1 para el enfoque automático; a veces tengo una conexión lenta y no es divertido estar ya en otro lugar (en el peor de los casos: escribiendo una contraseña) cuando me devuelven al primer campo.
Marcel Korpel
1
Sin embargo, incrustar JS puede ser útil cuando solo hay una página y para reducir las búsquedas en el servidor. La misma historia que CSS incrustado. Pero normalmente es mejor separar el código javascript y css en archivos separados para reducir los tiempos de carga de la página (con el uso de un encabezado de caché válido) cuando se usa una plantilla con los mismos requisitos de javascript y css.
Codebeat
17

De hecho, es bastante común. Por ejemplo , el código de seguimiento de análisis 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 ...

Keltex
fuente
37
-1 - El hecho de que Google lo esté haciendo no significa que sea una buena práctica. ¡Común! = Bueno.
Jason
3
De todos modos, Google Analytics es demasiado complicado y su uso de JavaScript para el seguimiento es en realidad un buen ejemplo de sobreingeniería.
Esko
Además, recomiendan que coloques el guión al final de la página, no en el medio, que es donde se deben colocar los guiones si tienes que colocarlos. NO en el encabezado donde la gente suele ponerlos
Jason
2
Fuera del tema a un lado: siempre me irrita el uso innecesario y extraño de Google unescape, dado que escape/ unescapeIs Evil (y esa \x3Chabría sido una forma mucho más simple de hacerlo).
Bobince
3
@Keltex: El código no es válido, sin embargo, afirmar que es una buena práctica solo porque algunas personas lo usan no es un argumento válido.
Matti Virkkunen
4

Es válido y, según el marco del lado del servidor y la naturaleza del código, a veces es muy difícil de evitar.

Puntiagudo
fuente
4

Como mencionaron varias personas, es válido, funciona y se usa ampliamente.

Las mejores prácticas por lo que la semántica recomienda (o al menos se usa 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 e integradas) en la parte inferior derecha antes de la etiqueta del cuerpo, para permitir que el marcado se represente por completo antes de que se ejecute cualquier código JavaScript.

Para facilitar la comprensión y el mantenimiento del código, se recomienda "JavaScript no intrusivo", donde el código está en un archivo externo y vincula eventos al DOM (JavaScript no intrusivo de Google).

Un caso en el que es útil tener JavaScript en línea es inicializar variables con valores que solo existen en el servidor, que luego serán utilizados por el código JavaScript externo.

Galón
fuente
3

Prefiero poner referencias a scripts externos en el encabezado y scripts que inician las cosas e inicializan los widgets y todo eso 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 le siguen. Además, un desagradable problema relacionado con la compatibilidad del navegador es el hecho de que IE no permite que los elementos de la secuencia de comandos modifiquen el elemento en el que se encuentran. Entonces, si tiene esto:

<div id="foo">
  <script type="text/javascript">
    document.getElementById("foo")... // do something to it
  </script>
</div>

A IE no le va a gustar tu página. Las versiones antiguas 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 que se asegure de que sus scripts solo accedan al DOM al que sea seguro acceder, no creo que sea malo poner elementos de script en el cuerpo. De hecho, en mi humilde opinión, poner scripts 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 se carga la página).

Matti Virkkunen
fuente
3

¡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 contarlo en el caso. Pero seguro que es bueno tener todo tu código JavaScript en el mismo lugar. Es un poco complicado si tiene pequeños fragmentos de código JavaScript en todo su archivo HTML.

meo
fuente
2
es una mala práctica en general.
Jason
ok, solo lee tu publicación, es bueno saberlo. De todos modos nunca lo hago, pero nunca pensé que podría hacer que tu navegador se cuelgue ... ... ¿cómo viene?
meo
1
Cualquier JavaScript puede bloquear su navegador (a veces todavía obtengo esos cuadros de alerta en Firefox con una opción de 'Abortar script' y 'Continuar script').
Marcel Korpel
esto es cierto, cualquier JS puede bloquear su navegador. sin embargo, si va a colgarlo (obviamente nunca se recomienda), es mejor hacerlo una vez que la página se haya renderizado completamente con el contenido y el usuario pueda comenzar a leer / interactuar con la página. La razón por la que JS cuelga su navegador es porque se ejecuta sincrónicamente, lo que significa que el navegador debe esperar hasta que JS se ejecute por completo antes de continuar renderizando, ya que no sabe qué va a hacer JS. Mientras espera, no se renderiza, lo que hace que parezca que está colgando.
Jason
No uses esa cosa de CDATA, es una tontería. Solo los analizadores que validan XML entienden las secciones CDATA, por lo que si sus páginas se sirven como HTML, no hay diferencia funcional. Sin embargo, si sus páginas se sirven como XML, se mostrará el "//" antes de la etiqueta de apertura.
brothercake
2

No había visto esto antes. Parece funcionar en los pocos navegadores que he probado. Pero hasta donde yo sé, no es válido poner etiquetas de script en lugares como este.

Es una práctica válida, pero no una buena (o recomendada).

¿Me equivoco? ¿Qué tan malo es que coloquemos 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 debería estar dentro <head>o <body>). Tampoco hay ningún problema en términos de compatibilidad del navegador, sin embargo, incrustar scripts JS en páginas web presenta serias desventajas (cómo / por qué se consideran malos) :

  1. Agrega peso a la página
  2. Dificultad (o probablemente imposible) para la minificación
  3. No se puede migrar ni utilizar para otras páginas
  4. No se puede almacenar en caché (debe descargarse cada vez que se carga la página)
  5. Sin separación de preocupaciones (más difícil de mantener)

fuente
2

Sin embargo, también es bueno saber que el código JavaScript necesario para una sección de HTML estará ahí. En lugar de tener que afirmar y crear alguna inclusión en la parte superior del archivo.

Entonces, en lugar de "si va a utilizar este HTML, asegúrese de importar xyz.js", puede incluir el HTML y terminar con él.

Entonces, no es necesariamente una maldad horrible. Quizás no espectacularmente impresionante, pero tampoco del todo terrible. Depende de la intención.

Will Hartung
fuente
2

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)

Jonathan Lebrun
fuente
gran +1! Tantas respuestas, pero ninguna de ellas menciona que los scripts en HEAD pueden bloquear otros elementos (¡como imágenes! Que pueden estropear el diseño en una conexión lenta)
David J
1

Ciertamente es legal; Lo he visto en algunas páginas aquí en Exforsys, por ejemplo.

Ahora bien, 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 para nada más que una simple declaración o dos. Sin ver lo que ha reemplazado // Some JavaScript code here, no me gustaría comentar.

Sin embargo, no debería haber ningún problema con el navegador.

ChrisF
fuente
1

Es válido agregar <script> en body , pero a Internet Explorer realmente no le gusta. Entonces, para estar más 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.

arrozal
fuente
1

Supongo que su equipo está haciendo esto porque quieren insertar un script de forma dinámica 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 es ABSOLUTAMENTE NECESARIO (siempre que esté en un bloque CDATA), pero fuera de eso, recomendaría a su equipo que usen una biblioteca de scripts como Prototype o jQuery, y mantengan los scripts externos a la página. Esto suele ser más limpio, y las bibliotecas a veces obligan a limpiar un poco el código, lo que apuesto a que no está sucediendo actualmente.

Tampoco ejecutaría funciones que consuman mucho tiempo en las etiquetas de script en línea, ya que ocurren en la carga de la página y, como dijo Jason anteriormente, podrían 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 se cargan en la página para activarlas, como después de que se cargue el DOM.

Jesse
fuente
1

Es una de las muchas, muchas mejores prácticas que se trata tanto de mejorar el rendimiento como de mejorar su enfoque de la programación.

En última instancia, en el desarrollo web, ¡sacar el producto es lo más importante!

Heydenberk
fuente
0

La recomendación frecuente de que los scripts se mantengan en el encabezado es garantizar que el script se cargue antes de llamarlo. Este es solo un problema para ciertos controladores de eventos. Para otros tipos de secuencias de comandos, no importa, y para algunos tipos (como document.write), no tiene ningún sentido.

Tor Haugen
fuente
0

Si tiene un editor que puede manejar la sintaxis HTML y JavaScript simultáneamente. Y si primero le gusta leer algunas líneas de HTML y luego JavaScript cpde ... seguro. Ve a por ello.

Alegre
fuente
Suena como Visual Studio y vistas de afeitar que pueden manejar ambos. Esto puede ser bastante conveniente en algunos casos (todo el código que necesita editar en un solo lugar). Por supuesto, demasiado javascript en la vista puede dificultar la lectura y la comprensión del código y también existe el problema de inflar el html de salida.
jahu
0

Unas pocas cosas:

  1. Es un código completamente válido.
  2. Es completamente desaconsejado.

Hacer esto ralentiza considerablemente la carga de la página, ya que el código JavaScript debe ejecutarse antes de que se pueda procesar el resto de la página. Si está trabajando mucho en ese código JavaScript, su 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 del</body> etiqueta).

Compre y lea JavaScript de alto rendimiento . Cambiará la forma en que escribe el código JavaScript.

Jason
fuente
3
No mis votos negativos, pero cuando pienso en Yahoo, creo que YAHOO.util.Event.addListenerno es un javascript eficiente / conciso. No leería un libro y lo trataría como un evangelio, a veces debes tener javascript en la página misma, por ejemplo, una variable renderizada dinámicamente, algo que no puedes hacer en un externo .js.
Nick Craver
2
¿Has leído el libro? si lo hubiera hecho, sabría que enseña técnicas de optimización. cosas como YAHOO.xx.xx.xxse almacenan en caché localmente. en ocasiones, sí, está bien representar una variable en la página, pero de todos modos eso se puede hacer externamente si solo establece un valor de entrada oculto desde el servidor. pero dije que no es recomendable, no está mal . además, nicholas zakas, el autor, sabe lo que hace, independientemente de quién sea su empleador.
Jason
2
"Cargar dinámicamente" y "cargar al final de la página" son cosas diferentes, y es muy improbable que haya alguna mejora en el rendimiento al usar ambos. "¿Has leído el libro?" y "estoy en lo cierto" tampoco son la mejor manera de iniciar una conversación constructiva. Además, la pregunta original se puede responder con "porque eventualmente se ahoga en IE", ya que algunas operaciones solo son compatibles si el script es un hijo directo de body.
Nacho Coloma