La version française de cette traduction est :
http://www.la-grange.net/w3c/html4.01/

Traducteur : J.J.Solari dans le cadre de l'effort de la liste de discussion w3c-translators.fr@w3.org
La version française peut contenir des erreurs. La version anglaise de cette note est l'unique version normative. Version originale : http://www.w3.org/TR/1999/REC-html401-19991224


18 Les scripts

Sommaire

  1. Introduction aux scripts
  2. La conception des documents pour les agents utilisateurs qui gèrent les scripts
    1. L'élément SCRIPT
    2. La spécification du langage de script
    3. Les événements intrinsèques
    4. La modification dynamique des documents
  3. La conception des documents pour les agents utilisateurs qui ne gèrent pas les scripts
    1. L'élément NOSCRIPT
    2. La dissimulation des données de script aux agents utilisateurs

18.1 Introduction aux scripts

Un script côté client est un programme pouvant accompagner le document HTML ou bien y être directement incorporé. Le programme s'exécute sur la machine cliente au chargement du document ou à tout autre moment comme l'activation d'un lien. La gestion des scripts de HTML est indépendante du langage de script.

Les scripts offrent aux auteurs le moyen d'accroître les documents HTML de manière à les rendre très réactifs et interactifs. Par exemple :

Il existe deux types de script que les auteurs peuvent attacher à un document HTML :

Remarque : Cette spécification comprend des précisions supplémentaires dans la section sur les macrocommandes de script.

18.2 La conception des documents pour les agents utilisateurs qui gèrent les scripts

Les sections suivantes abordent les questions concernant les agents utilisateurs qui gèrent les scripts.

18.2.1 L'élément SCRIPT

<!ELEMENT SCRIPT - - %Script;          -- déclartions du script -->
<!ATTLIST SCRIPT
  charset     %Charset;      #IMPLIED  -- encodage de caractères de la ressource reliée --
  type        %ContentType;  #REQUIRED -- type de contenu du langage de script --
  src         %URI;          #IMPLIED  -- URI d'un script externe --
  defer       (defer)        #IMPLIED  -- différer l'exécution du script --
  >

Balise ouvrante: obligatoire, balise fermante : obligatoire

Définition des attributs

src = uri [CT]
Cet attribut spécifie la localisation d'un script externe.
type = type-de-contenu [CI]
Cet attribut spécifie le langage de script du contenu de l'élément et prend le pas sur le langage de script par défaut. Le langage de script est spécifié comme type de contenu (par exemple, "text/javascript"). Les auteurs doivent fournir une valeur pour cet attribut. Celui-ci n'a pas de valeur par défaut
language = cdata [CI]
Déconseillé. Cet attribut spécifie le langage de script du contenu de cet élément. Sa valeur est un identifiant du langage, mais comme ces identifiants ne sont pas normalisés, l'attribut est déconseillé en faveur de l'attribut type.
defer [CI]
Quand il est présent, cet attribut booléen indique à l'agent utilisateur que le script ne va générer aucun contenu de document (par exemple, aucune instruction « document.write » en Javascript), l'agent utilisateur peut donc poursuivre l'analyse et la restitution.

Attributs définis ailleurs

L'élément SCRIPT installe un script dans le document. Cet élément peut apparaître un nombre quelconque de fois dans les éléments HEAD ou BODY d'un document HTML.

Le script peut être défini en contenu de l'élément SCRIPT ou dans un fichier externe. Si l'attribut src n'est pas spécifié, alors l'agent utilisateur doit interpréter le contenu de l'élément comme étant le script. Si l'attribut src a une valeur d'URI, alors l'agent utilisateur doit ignorer le le contenu de l'élément et ramener le script désigné par l'URI. Remarquez que l'attribut charset se réfère à l'encodage de caractères du script désigné par l'attribut src ; cela ne concerne pas le contenu de l'élément SCRIPT.

Les scripts sont évalués par les moteurs de script, qui doivent être connus de l'agent utilisateur.

La syntaxe des données du script dépend du langage de script.

18.2.2 La spécification du langage de script

Comme HTML ne dépend pas d'un langage de script particulier, les auteurs des documents doivent indiquer explicitement aux agents utilisateurs le langage de chaque script. Cela peut être fait soit au travers d'une déclaration par défaut, soit par une déclaration locale.

Le langage de script par défaut  

Les auteurs devraient spécifier le langage de script par défaut pour tous les scripts d'un document, en incluant la déclaration META suivante dans l'élément HEAD :

<META http-equiv="Content-Script-Type" content="un_certain_type">

dans laquelle la valeur "un_certain_type" représente le type de contenu nommant le langage de script. En exemple de telles valeurs : "text/tcl", "text/javascript", "text/vbscript".

En l'absence d'une déclaration META, le langage par défaut peut être fixé par un en-tête HTTP « Content-Script-Type ».

    Content-Script-Type: un_certain_type

dans lequel la valeur "un_certain_type" représente encore le type de contenu nommant le langage de script.

Les agents utilisateurs devraient déterminer le langage de script par défaut du document selon les étapes suivantes (de la priorité la plus grande à la plus faible) :

  1. Si d'éventuelles déclarations META spécifient une valeur "Content-Script-Type", c'est la dernière dans le flux de caractères qui détermine le langage de script par défaut ;
  2. Sinon, si d'éventuels en-têtes HTTP spécifie "Content-Script-Type", c'est le dernier dans le flux de caractères qui détermine le langage de script par défaut.

Les documents, qui ne spécifient pas de langage de script par défaut et qui contiennent des éléments spécifiant un script d'événement intrinsèque, sont erronés. Les agents utilisateurs peuvent toujours essayer d'interpréter les scripts spécifiés incorrectement mais ils ne sont pas obligés de le faire. Les outils d'édition devraient générer une indication de langage de script par défaut pour aider les auteurs à créer des documents corrects.

La déclaration locale du langage de script 

On doit spécifier l'attribut type pour chaque instance de l'élément SCRIPT dans le document. La valeur de l'attribut type d'un élément SCRIPT surclasse le langage de script par défaut de cet élément.

Dans cet exemple, nous déclarons le langage de script par défaut comme étant "text/tcl". Nous incluons dans l'en-tête du document un élément SCRIPT, dont le script en question est localisé dans un fichier externe, tel quel et écrit dans le langage de script "text/vbscript". Nous incluons également dans le corps du document un élément SCRIPT, lequel contient son propre script écrit dans le langage "text/javascript".

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
     "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Un document avec SCRIPT</TITLE>
<META http-equiv="Content-Script-Type" content="text/tcl">
<SCRIPT type="text/vbscript" src="http://quelquepart.com/progs/vbcalc">
</SCRIPT>
</HEAD>
<BODY>
<SCRIPT type="text/javascript">
...un code JavaScript...
</SCRIPT>
</BODY>
</HTML>

L'appel des éléments HTML à partir d'un script 

Chaque langage de script obéit à ses propres règles pour appeler des objets HTML à partir d'un script. Cette spécification ne définit pas de mécanisme standard pour appeler les objets HTML.

Néanmoins, les scripts devraient se référer à un élément en fonction du nom qui lui est assigné. Les moteurs de scripts devraient observer les règles de préséance suivantes dans l'identification d'un élément : l'attribut name est prioritaire sur l'attribut id, quand tous les deux sont spécifiés. Sinon, on peut utiliser l'un ou l'autre.

18.2.3 Les événements intrinsèques

Remarque : Les auteurs de documents HTML sont prévenus que des changements vont vraisemblablement intervenir dans le domaine des événements intrinsèques (par exemple, la manière dont les scripts sont rattachés aux événements. Les recherches dans ce domaine sont menées par les membres du groupe de travail sur le modèle objet de document du W3C (voir le site Web du W3C à http://www.w3.org/ pour plus de renseignements).

Définition des attributs

onload = script [CT]
L'événement onload se produit quand l'agent utilisateur finit de charger une fenêtre ou bien tous les cadres dans un jeu d'encadrement FRAMESET. Cet attribut peut s'utiliser avec les éléments BODY et FRAMESET.
onunload = script [CT]
L'événement onunload se produit quand l'agent utilisateur retire le document d'une fenêtre ou d'un cadre. Cet attribut peut s'utiliser avec les éléments BODY et FRAMESET.
onclick = script [CT]
L'événement onclick se produit quand le bouton du dispositif de pointage est cliqué au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
ondblclick = script [CT]
L'événement ondblclick se produit quand le bouton du dispositif de pointage est double-cliqué au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onmousedown = script [CT]
L'événement onmousedown se produit quand le bouton du dispositif de pointage est appuyé au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onmouseup = script [CT]
L'événement onmouseup se produit quand le bouton du dispositif de pointage est relâché au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onmouseover = script [CT]
L'événement onmouseover se produit quand le dispositif de pointage est déplacé sur un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onmousemove = script [CT]
L'événement onmousemove se produit quand le dispositif de pointage est déplacé alors qu'il est au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onmouseout = script [CT]
L'événement onmouseout se produit quand le dispositif de pointabe est déplacé en dehors d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onfocus = script [CT]
L'événement onfocus se produit quand un élément reçoit l'attention, soit par le biais du dispositif de pointage, soit au travers d'une navigation par tabulation. Cet attribut peut s'utiliser avec les éléments suivants : A, AREA, LABEL, INPUT, SELECT, TEXTAREA et BUTTON.
onblur = script [CT]
L'événement onblur se produit quand un élément perd l'attention, soit par le biais du dispositif de pointage, soit au travers d'une navigation par tabulation. On peut l'utiliser avec les mêmes éléments que l'événement onfocus.
onkeypress = script [CT]
L'événement onkeypress se produit quand une touche est pressée puis relâchée au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onkeydown = script [CT]
L'événement onkeydown se produit quand une touche est gardée appuyée au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onkeyup = script [CT]
L'événement onkeyup se produit quand une touche est relâchée au-dessus d'un élément. Cet attribut peut s'utiliser avec la plupart des éléments.
onsubmit = script [CT]
L'événement onsubmit se produit quand un formulaire est soumis. Il ne s'applique qu'à l'élément FORM.
onreset = script [CT]
L'événement onreset se produit quand un formulaire est réinitialisé. Il ne s'applique qu'à l'élément FORM.
onselect = script [CT]
L'événement onselect se produit quand l'utilisateur sélectionne un certain texte dans un champs textuel. Cet attribut peut s'utiliser avec les éléments INPUT et TEXTAREA.
onchange = script [CT]
L'événement onchange se produit quand une commande perd l'attention de saisie et quand sa valeur a été modifiée depuis l'instant où elle avait reçu l'attention. Cet attribut s'applique aux éléments suivants : INPUT, SELECT et TEXTAREA.

Il est possible d'associer une action à un certain nombre d'événements, qui se produisent quand l'utilisateur interagit avec l'agent utilisateur. Chacun des « événements intrinsèques » listés ci-dessus prend comme valeur un script. Le script s'exécute toutes les fois où l'événement se produit pour cet élément. La syntaxe des données de script dépend du langage de script.

Les éléments de commande, à savoir INPUT, SELECT, BUTTON, TEXTAREA et LABEL, répondent tous à certains événements intrinsèques. Quand ces éléments n'apparaissent pas dans un formulaire, on peut les employer pour augmenter l'interface utilisateur graphique du document.

Par exemple, l'auteur peut vouloir inclure des boutons poussoirs dans son document, ceux-ci ne soumettant pas de formulaire mais commnuniquant quand même avec un serveur quand ils sont activés.

Les exemples suivants montrent quelques commandes et comportements d'interface utilisateur possibles réalisés à partir d'événements intrinsèques.

Dans l'exemple suivant, la commande nommée "nomUtilisateur" est un champs obligatoire. Quand l'utilisateur quitte le champs, l'événement onblur appelle une fonction JavaScript qui confirme la validité de "nomUtilisateur".

<INPUT NAME="nomUtilisateur" onblur="verifNomUtilisateur(this.value)">

Voici un autre exemple en JavaScript :

<INPUT NAME="nombre"
    onchange="if (!verifNombre(this.value, 1, 10)) 
        {this.focus();this.select();} else {remercier()}"
    VALUE="0">

Voici l'exemple en VBScript d'un gestionnaire d'événement pour un champs textuel :

    <INPUT name="edit1" size="50">    
    <SCRIPT type="text/vbscript">
      Sub edit1_changed()
        If edit1.value = "abc" Then
          button1.enabled = True
        Else
          button1.enabled = False
        End If
      End Sub
    </SCRIPT>

Voici le même exemple utilisant cette fois Tcl :

    <INPUT name="edit1" size="50">
    <SCRIPT type="text/tcl">
      proc edit1_changed {} {
        if {[edit value] == abc} {
          button1 enable 1
        } else {
          button1 enable 0
        }
      }
      edit1 onChange edit1_changed
    </SCRIPT>

Voici un exemple en JavaScript d'une relation d'événement [ndt. event binding] à l'intérieur d'un script. Tout d'abord, voici un gestionnaire de clic simple :

    
<BUTTON type="button" name="mon_bouton" value="10">
<SCRIPT type="text/javascript">
      function mon_onclick() {
         . . .
      }
    document.form.mybutton.onclick = mon_onclick
 </SCRIPT>
 </BUTTON>

Voici un gestionnaire de fenêtre plus intéressant :

    
<SCRIPT type="text/javascript">
      function mon_onload() {
         . . .
      }

      var win = window.open("un/autre/URI")
      if (win) win.onload = mon_onload
</SCRIPT>

En Tcl, ça donnerait :

 <SCRIPT type="text/tcl">
     proc mon_onload {} {
       . . .
     }
     set win [window open "un/autre/URI"]
     if {$win != ""} {
         $win onload mon_onload
     }
 </SCRIPT>

Remarquez qu'une déclaration "document.write", ou une déclaration équivalente, dans les gestionnaires d'événement intrinsèque, crée et écrit vers un nouveau document plutôt que modifie le document courant.

18.2.4 La modification dynamique des documents

Les scripts qui s'exécutent quand le document est chargé sont capables de modifier dynamiquement le contenu du document. Ces capacités sont fonction du langage de script en question (par exemple, la déclaration "document.write" dans le modèle objet de HTML reconnue par certains éditeurs de logiciels).

On peut modéliser la modification dynamique d'un document comme suit :

  1. Tous les éléments SCRIPT sont évalués dans l'ordre au fur et à mesure du chargement du document ;
  2. Toutes les structures de script à l'intérieur d'un élément SCRIPT donné, qui génèrent des valeurs SGML de type CDATA, sont évaluées. Leur texte généré combiné est inséré dans le document à la place de l'élément SCRIPT ;
  3. Les données générées de type CDATA sont ré-évaluées.

Les documents HTML sont contraints de se conformer au DTD HTML avant comme après le traitement de chaque élément SCRIPT.

L'exemple suivant illustre la manière dont les scripts peuvent modifier un document dynamiquement. Soit le script suivant :

 <TITLE>Document de test</TITLE>
 <SCRIPT type="text/javascript">
     document.write("<p><b>Bonjour tout le monde !<\/b>")
 </SCRIPT>

celui-ci produit le même effet que ce balisage HTML :

 <TITLE>Document de test</TITLE>
 <P><B>Bonjour tout le monde !</B>

18.3 La conception des documents pour les agents utilisateurs qui ne gèrent pas les scripts

Les sections suivantes expliquent comment les auteurs peuvent créer des documents qui fonctionnent auprès des agents utilisateurs ne reconnaissant pas les scripts.

18.3.1 L'élément NOSCRIPT

<!ELEMENT NOSCRIPT - - (%block;)+
  -- contenu de remplacement pour une restitution sans les scripts -->
<!ATTLIST NOSCRIPT
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

Balise ouvrante: obligatoire, balise fermante : obligatoire

L'élément NOSCRIPT permet aux auteurs de fournir un contenu de remplacement quand un script n'est pas exécuté. Le contenu de l'élément NOSCRIPT ne devrait être restitué par un agent utilisateur reconnaissant les scripts que dans les cas suivants :

Les agents utilisateurs qui ne gèrent pas les scripts côté client doivent restituer le contenu de cet élément.

Dans l'exemple suivant, l'agent utilisateur qui interprète l'élément SCRIPT va inclure certaines données créées dynamiquement dans le document. Si l'agent utilisateur ne reconnaît pas les scripts, l'utilisateur peut toujours obtenir les données au travers d'un lien.

<SCRIPT type="text/tcl">
 ...un script Tcl qui insère des données...
</SCRIPT>
<NOSCRIPT>
 <P>Acc&eacute;der aux <A href="http://quelquepart.com/data">donn&eacute;es.</A>
</NOSCRIPT>

18.3.2 La dissimulation des données de script aux agents utilisateurs

Les agents utilisateurs qui ne reconnaissent pas l'élément SCRIPT vont vraisemblablement restituer le contenu de cet élément comme un texte. Certains moteurs de script, dont ceux des langages JavaScript, VBScript et Tcl, autorisent la délimitation des déclarations d'un script par un commentaire SGML. Les agents utilisateurs, qui ne reconnaissent pas l'élément SCRIPT, ignoreront donc le commentaire alors que les moteurs de script intelligents comprendront que le script dans le commentaire devrait être exécuté.

Une autre solution à ce problème, c'est de placer les scripts dans des documents externes et de les appeler avec l'attribut src.

Commenter les scripts en JavaScript
Le moteur JavaScript autorise l'apparition de la chaîne « <!-- » au début de l'élément SCRIPT et ignore les caractères suivants jusqu'à la fin de la ligne. JavaScript interprète la chaîne « // » comme le début d'un commentaire qui s'étend jusqu'à la fin de la ligne courante. Elle est nécessaire pour dissimuler la chaîne « --> » à l'analyseur JavaScript.

<SCRIPT type="text/javascript">
<!-- pour dissimuler le contenu du script aux navigateurs anciens
  function square(i) {
    document.write("L'appel a pass&eacute; ", i ," &agrave; la fonction.","<BR>")
    return i * i
  }
  document.write("La fonction a renvoy&é ",square(i),".")
// fin de la dissimulation du contenu aux navigateurs anciens -->
</SCRIPT>

Commenter les scripts en VBScript
En VBScript, le caractère guillemet simple fait que le reste de la ligne courante est traité comme un commentaire. On peut dont l'utiliser pour dissimuler la chaîne « --> » à VBScript, par exemple :

   <SCRIPT type="text/vbscript">
     <!--
       Sub foo()
        ...
       End Sub
     ' -->
    </SCRIPT>

Commenter les scripts en TCL
En Tcl, le caractère dièse « # » annonce le reste de la ligne comme un commentaire :

<SCRIPT type="text/tcl">
<!--  pour dissimuler le contenu du script aux navigateurs anciens
  proc square {i} {
    document write "L'appel a pass&eacute; $i &agrave; la fonction.<BR>"
    return [expr $i * $i]
  }
  document write "La fonction a renvoy&eacute; [square 5]."
# fin de la dissimulation du contenu aux navigateurs anciens -->
</SCRIPT>

Remarque : Certains navigateurs referment les commentaires au premier caractère « > » rencontré, ainsi, pour dissimuler le contenu du script à ces navigateurs, vous pouvez transposer les opérandes des opérateurs relationnels et de décalage [ndt. shift] (par exemple, écrire « y < x » au lieu de « x > y ») ou bien utiliser le mécanisme d'échappement du langage de script pour le caractère « > ».