[Article] Comprendre la balise script
S'il est bien une balise qui est souvent mal utilisée en HTML, c'est la balise <script>.
Nous allons essayer dans ce billet de faire le point sur cette balise en comprenant pourquoi.
La syntaxe de base est relativement simple et ne pose pas de problème :
Il est toutefois important de noter que même si elle ne possède pas forcément de contenu, elle reste susceptible d'en avoir (le script en lui-même) ce qui fait que contrairement à une balise <link /> mais à l'instar d'une balise <style>, elle n'est pas autofermante et doit posséder une balise fermante.
L'attribut src ne pose habituellement pas de gros soucis.
Cet attribut correspond à l'URL à laquelle se trouve le fichier correspondant. Attention toutefois, dans le cas d'une URL relative, de bien comprendre où se trouve le script en fonction de l'URL effective (celle affichée par le navigateur) qui appellera le script. Attention donc par exemple aux include en PHP.
En revanche, deux attributs sont assez souvent confondus, il s'agit des attributs language et type.
Il faut déjà savoir que le premier est deprecated depuis HTML 4 alors qu'au contraire, le second est required. Cela signifie qu'il faut bannir language.
La syntaxe correcte devient donc
Code:
<script type="text/javascript"></script>
Mais alors, si l'attribut language est à bannir, pourquoi le retrouve-t-on si souvent ?
Parce que, malheureusement, plusieurs facteurs empêchent de l'éradiquer.
Déjà, de nombreux scripts usuels sont bien référencés et recopiés tels quels bien que très anciens. Du coup, l'attribut se propage facilement.
D'autre part, peut-être surtout, parce que beaucoup ignorent la signification de cet attribut.
A la base, il servait à indiquer le langage et la version du langage de script utilisé. Cependant, aucune norme n'a été trouvée pour savoir ce qu'il pouvait bien contenir, ce qui a donc amené à ce qu'il soit déprécié. De toute façon, le seul langage de script universellement reconnu par les navigateurs est JavaScript (quelle que soit sa déclinaison : ECMAScript, JScript, ...) donc l'information n'a que peu d'intérêt. De même, préciser une version à utiliser n'a pas vraiment de sens : JavaScript, pour des raisons de rétro-compatibilté ne perd pas de fonctionnalités, il ne fait qu'en accepter de nouvelles !
Note : en HTML5, l'attribut type n'est plus requis et dans cette version, la syntaxe
Code:
<script[ src="..."]></script>
est désormais suffisante.
Pendant longtemps (et on retrouve encore couramment la syntaxe), les scripts étaient entourés soit de commentaires HTML soit d'entités CDATA :
Code:
1
2
3
4
5
6
| <script type="text/javascript"><!--
// Code JavaScript
--></script>
<script type="text/javascript"><![CDATA[
// Code JavaScript
]]></script> |
Là encore, la pratique remonte à un temps que les moins de 20 ans (voire plus !) n'ont pas connue !
Ces syntaxes, héritées du XML, servaient à l'origine à éviter que les navigateurs ne possédant pas d'interpréteur JavaScript (on ne parle pas de ceux qui ont JavaScript désactivé, bien de ceux pour lesquels JavaScript n'existe tout simplement pas !) n'essayent d'interpréter le contenu du script comme du HTML. De mémoire, on parle là de IE3 et de NS3. Il me semble que la part de marché de ces navigateurs atteint depuis longtemps un seuil qui rend cette technique quelque peu obsolète !
Plusieurs écoles s'affrontent à ce niveau.
Une chose est sure : il est demandé de séparer les différentes couches du document : le HTML pour le contenu, le CSS pour la mise en forme et le JavaScript pour l'ergonomie (ou le le comportement). Ainsi, insérer ses scripts en plein milieu du document est assez maladroit.
Pendant un temps, les bonnes pratiques recommandaient de placer les scripts entre les balises <head> et de les initialiser via l'événement onload de l'objet window.
Cette façon de procéder est plutôt satisfaisante mais l'événement onload implique que l'ensemble du contenu de la page soit chargé avant de lancer les scripts (donc y compris les éléments dits remplacés : images, iframes, object, etc.) et comme les pages Web deviennent de plus en plus gourmandes en ressources externes, cela fini par nuire à l'expérience utilisateur.
Différentes techniques existent pour pallier cela, entre autre, l'utilisation de l'événement DOMContentLoaded, mais qui n'est pas (encore) suffisamment universel pour être totalement satisfaisant.
La problématique est que pour pouvoir utiliser un script, il faut que les éléments du DOM qu'il va utiliser existent au moment où il est appelé. Une solution efficace est alors de placer les scripts juste avant la fermeture du document (avant la balise </body>), ce qui permet d'être sûr que les éléments du DOM ont été créés et de conserver la notion de séparation des couches.
Gardez toutefois à l'esprit que quelle que soit la solution choisie, elle aura une importance majeure lors de l'écriture de codes destinés à être réutilisés.
Billet original publié sur les blogs de developpez.com...
