Est-ce une mauvaise pratique d'intégrer JavaScript dans le corps du HTML?

Question 1

Une équipe sur laquelle je travaille a pris l'habitude d'utiliser des <script>balises à des endroits aléatoires dans le corps de nos pages HTML. Par exemple:

<html>
    <head></head>
    <body>
        <div id="some-div">
            <script type="text/javascript">//some javascript here</script>
        </div>
    </body>
</html>

Je n'avais jamais vu ça auparavant. Cela semble fonctionner dans les quelques navigateurs que j'ai testés. Mais pour autant que je sache, il n'est pas valide de mettre des balises de script dans des endroits comme celui-ci.

Ai-je tort? À quel point est-ce que nous mettons des balises de script dans des balises div comme celle-ci? Y a-t-il des problèmes de compatibilité du navigateur dont je devrais être conscient?

Question 2

C'est parfaitement valable.

Vous ne voudriez pas y mettre de gros blocs de code mélangés dans le balisage (mieux vaut utiliser des scripts externes), mais cela peut être utile pour:

ajouter des informations de liaison supplémentaires pour l'amélioration progressive (lorsque ces données sont difficiles à intégrer dans un nom de classe ou dans une autre approche pour masquer des informations étendues dans les attributs); ou
où il est nécessaire de lancer une amélioration scriptée le plus rapidement possible (plutôt que d'attendre le chargement de la fenêtre / prêt pour le document). Un exemple de ceci serait la mise au point automatique, qui peut irriter si elle est tirée trop tard.

Vous pensez peut-être à des <style>éléments qui ne sont pas autorisés <body>(bien que la plupart des navigateurs le permettent néanmoins).

Question 3

En fait, c'est assez courant. Par exemple , le code de suivi analytique de Google utilise uniquement cette syntaxe:

<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 c'est assez bon pour Google ...

Question 4

Il est valide et, selon votre framework côté serveur et la nature du code, parfois très difficile à éviter.

Question 5

Comme plusieurs personnes l'ont mentionné, c'est valable, cela fonctionne et c'est largement utilisé.

Les meilleures pratiques dans la mesure où la sémantique le recommande (ou du moins utilisée pour le recommander) consiste à placer des balises de script à l'intérieur de l'en-tête.

Les meilleures pratiques plus modernes qui prennent en compte les performances recommandent de placer des balises de script (externes et en ligne) en bas à droite avant la balise body, pour permettre au balisage de s'afficher complètement avant l'exécution de tout code JavaScript.

Pour un code plus facile à comprendre et à maintenir, «JavaScript discret» est recommandé, où le code est dans un fichier externe et lie les événements au DOM (JavaScript discret de Google).

Un cas où il est utile d'avoir JavaScript en ligne est d'initialiser des variables avec des valeurs qui n'existent que côté serveur, qui seront ensuite utilisées par le code JavaScript externe.

Question 6

Je préfère mettre des références à des scripts externes dans la tête, et des scripts qui démarrent et initialisent des widgets et autres dans le corps.

Un problème très facile à rencontrer est qu'un élément de script dans le corps ne peut pas accéder aux éléments qui le suivent. De plus, un problème de compatibilité avec les navigateurs est le fait qu'IE ne permet pas aux éléments de script de modifier l'élément dans lequel ils se trouvent. Donc, si vous avez ceci:

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

IE ne va pas aimer votre page. Les anciennes versions d'IE avaient l'habitude de donner des messages d'erreur très cryptiques pour cela ou même de vider toute la page, mais IE8 semble donner un message d'erreur descriptif.

Tant que vous vous assurez que vos scripts n'accèdent qu'au DOM auquel l'accès est sûr, je ne pense pas que ce soit mal de mettre des éléments de script dans le corps. En fait, à mon humble avis, mettre des scripts qui initialisent les widgets après les éléments associés peut être plus lisible que de tout mettre au même endroit (et je pense que cela pourrait également les faire fonctionner plus tôt, ce qui fait que les choses sautent moins à mesure que la page se charge).

Question 7

C'est valable!

Vous pouvez utiliser:

<script type="text/javascript">
    //<![CDATA[

    // Some JavaScript code that perfectly validates in the W3C validator

    //]]>
</script>

Je ne pense pas que vous puissiez dire si c'est une mauvaise pratique en général. Vous devez dire dans l'affaire. Mais c'est sûr qu'il est bon d'avoir tout votre code JavaScript au même endroit. C'est un peu compliqué si vous avez de petits morceaux de code JavaScript partout dans votre fichier HTML.

Question 8

Je n'avais jamais vu ça auparavant. Cela semble fonctionner dans les quelques navigateurs que j'ai testés. Mais pour autant que je sache, il n'est pas valide de mettre des balises de script dans des endroits comme celui-ci.

C'est une pratique valide, mais pas une bonne (ou recommandée).

Ai-je tort? À quel point est-ce que nous mettons des balises de script dans des balises div comme ça? Y a-t-il des problèmes de compatibilité du navigateur dont je devrais être conscient?

Il n'y a aucun problème à placer un <script>sous d'autres éléments (mais il devrait être à l'intérieur <head>ou <body>). Il n'y a pas non plus de problème en termes de compatibilité du navigateur, cependant, l'intégration de scripts JS sur des pages Web présente de sérieux inconvénients (comment / pourquoi ils sont considérés comme mauvais) :

Ajoute du poids à la page
Difficulté (ou probablement impossible) pour la minification
Ne peut pas être migré ou utilisé pour d'autres pages
Ne peut pas être mis en cache (doit être téléchargé à chaque fois que la page est chargée)
Pas de séparation des préoccupations (plus difficile à maintenir)

Question 9

Cependant, il est également bon que vous sachiez que le code JavaScript nécessaire à une section HTML sera là pour cela. Plutôt que d'avoir à affirmer et à construire une inclusion en haut du fichier.

Donc, plutôt que "si vous allez utiliser ce HTML, assurez-vous d'importer xyz.js", vous pouvez simplement inclure le HTML et en finir avec lui.

Donc, ce n'est pas nécessairement un mal horrible. Peut-être pas spectaculairement génial, mais pas vraiment terrible non plus. Cela dépend en quelque sorte de l'intention.

Question 10

Consultez l'interface utilisateur de Yahoo pour les meilleures pratiques: http://developer.yahoo.com/performance/rules.html (JavaScript au bas de la page)

Question 11

C'est certainement légal; Je l'ai vu sur quelques pages ici sur Exforsys par exemple.

Maintenant, c'est un site de tutoriel montrant les bases de HTML et JavaScript donc dans ce contexte c'est parfaitement compréhensible. Cependant, je n'aimerais pas le voir dans le code de production pour autre chose qu'une simple déclaration ou deux. Sans voir ce que vous avez remplacé, // Some JavaScript code hereje ne voudrais pas commenter.

Il ne devrait pas y avoir de problèmes de navigateur avec cela.

Question 12

Il est valide d'ajouter <script> body, mais Internet Explorer ne l'aime vraiment pas. Donc, pour être plus sûr, assurez-vous d'avoir vos scripts dans la balise <head>.

Cela a vraiment fait des ravages (en particulier pour Internet Explorer) dans le projet sur lequel nous travaillons.

Question 13

Je suppose que votre équipe fait cela soit parce qu'elle souhaite insérer un script de manière dynamique, soit parce qu'elle écrit un script qui se déclenchera au chargement de la page.

Je ne dirais pas qu'il y a quelque chose de mal à faire cela quand ABSOLUMENT NÉCESSAIRE (tant que c'est dans un bloc CDATA), mais en dehors de cela, je recommanderais à votre équipe d'utiliser une bibliothèque de scripts comme Prototype ou jQuery, et de garder les scripts externes à la page. C'est généralement plus propre, et les bibliothèques forceront parfois un peu de propreté au code, ce qui, je parie, ne se produit pas actuellement.

Je n'exécuterais pas non plus de fonctions chronophages dans les balises de script en ligne, car elles se produisent lors du chargement de la page et, comme Jason l'a déclaré ci-dessus, pourraient ralentir le chargement de la page. Toutes les bibliothèques de scripts ont des fonctions intéressantes qui vous permettent de faire des choses au chargement de la page, et vous donneront la possibilité de les lancer dans la page, par exemple après le chargement du DOM.

Question 14

C'est l'une des nombreuses meilleures pratiques qui visent autant à améliorer les performances qu'à améliorer votre approche de la programmation.

En fin de compte, dans le développement Web, c'est la sortie du produit qui compte le plus!

Question 15

C'est parfaitement valable, même si cela pourrait nuire à la maintenabilité. Voir aussi Où dois-je mettre les balises <script> dans le balisage HTML? et Pourquoi l'appel à cette fonction jQuery échoue-t-il dans Firefox? .

Question 16

La recommandation souvent formulée selon laquelle les scripts doivent être conservés dans l'en-tête est de s'assurer que le script est chargé avant d'être appelé. Ce problème concerne uniquement certains gestionnaires d'événements. Pour d'autres types de script, cela n'a pas d'importance, et pour certains types (comme document.write), cela n'a aucun sens.

Question 17

Si vous disposez d'un éditeur capable de gérer simultanément la syntaxe HTML et JavaScript. Et si vous aimez d'abord lire quelques lignes de HTML puis JavaScript cpde ... bien sûr. Fonce.

Question 18

Quelques choses:

C'est complètement valide au niveau du code.
C'est complètement déconseillé.

Cela ralentit considérablement le chargement de votre page car le code JavaScript doit s'exécuter avant que le reste de la page puisse être rendu. Si vous travaillez beaucoup avec ce code JavaScript, votre navigateur pourrait se bloquer. Vous devriez essayer de charger (dans la mesure du possible) votre code JavaScript dynamiquement et à la fin de votre page (de préférence avant la </body>balise).

Achetez et lisez du JavaScript haute performance . Cela changera la façon dont vous écrivez le code JavaScript.