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


17 Les formulaires

Sommaire

  1. Introduction aux formulaires
  2. Les commandes
    1. Les types de commande
  3. L'élément FORM
  4. L'élément INPUT
    1. Les types de commande créés par l'élément INPUT
    2. Exemples de formulaires contenant des commandes INPUT
  5. L'élément BUTTON
  6. Les éléments SELECT, OPTGROUP et OPTION
    1. Les options présélectionnées
  7. L'élément TEXTAREA
  8. L'élément ISINDEX
  9. Les labels
    1. L'élément LABEL
  10. Le rajout d'une structure aux formulaires : les éléments FIELDSET et LEGEND
  11. Donner l'attention à un élément
    1. La navigation par tabulation
    2. Les clés d'accès
  12. Les commandes inactives et en lecture seule
    1. Les commandes inactives
    2. Les commandes en lecture seule
  13. La soumission du formulaire
    1. La méthode de soumission du formulaire
    2. Les commandes réussies
    3. Le traitement des données du formulaire
    4. Les types de contenu du formulaire

17.1 Introduction aux formulaire

Un formulaire HTML est une partie du document constituée d'un contenu normal, d'un balisage, d'éléments spéciaux appelés commandes (cases à cocher, boutons radio, menus, etc.) et de labels sur ces commandes. L'utilisateur « remplit » généralement le formulaire en modifiant ses commandes (en saisissant un texte, en sélectionnant les articles d'un menu, etc.), avant de soumettre le formulaire à un agent pour son traitement (par exemple, à un serveur Web, à un serveur de courrier, etc.).

Voici un formulaire simple qui comprend des labels, des boutons radio et des boutons poussoirs (pour réinitialiser le formulaire ou le soumettre) :

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    <LABEL for="prenom">Prénom : </LABEL>
              <INPUT type="text" id="prenom"><BR>
    <LABEL for="nom">Nom : </LABEL>
              <INPUT type="text" id="nom"><BR>
    <LABEL for="email">e-mail : </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
    </P>
 </FORM>

Remarque : Cette spécification comprend des informations plus détaillées concernant les formulaires dans la sous-section traitant des problèmes d'affichage des formulaires.

17.2 Les commandes

Les utilisateurs interagissent avec les formulaires au moyen de commandes nommées.

Le « nom de commande » d'une commande est donné par son attribut name. La portée de l'attribut name d'une commande au sein d'un élément FORM est cet élément FORM.

Chaque command possède à la fois une valeur initiale et une valeur courante, les deux sont des chaînes de caractères. Veuillez consulter la définition de chaque commande pour des précisions sur la valeur initiale et les éventuelles contraintes sur les valeurs imposées par la commande. En général, la « valeur initiale » d'une commande peut être spécifiée avec l'attribut value de l'élément de commande. Cependant, la valeur initiale d'un élément TEXTAREA est donnée par son contenu et la valeur initiale d'un élément OBJECT dans un formulaire est déterminée par l'implémentation de l'objet (i.e., elle n'est pas précisée par cette spécification).

La « valeur courante » d'une commande est d'abord égale à la valeur initiale. Par la suite, la valeur courante de la commande peut être modifiée par les actions de l'utilisateur et par les scripts.

La valeur initiale d'une commande ne change pas. Ainsi, quand un formulaire est réinitialisé, chacune des valeurs courantes des commandes reprend sa valeur initiale. Si la commande n'a pas de valeur initiale, alors l'effet de la réinitialisation du formulaire sur cette commande n'est pas défini.

Lors de la soumission du formulaire pour son traitement, le nom et la valeur courante de certaines commandes sont accouplés et ces couples sont soumis avec le formulaire. On appelle ces commandes, pour lesquelles des couples nom/valeur sont soumis, des commandes réussies [ndt. successful controls].

17.2.1 Les types de commande

HTML défini les types de commande suivants :

Les boutons
Les auteurs peuvent créer trois types de boutons :

Les auteurs créent des boutons avec les éléments BUTTON ou INPUT. Veuillez consulter leurs définitions respectives pour des précisions sur la spécification des divers types de bouton.

Remarque : Les auteurs devraient remarquer que l'élément BUTTON offre des possibilités de restitution plus étendues que celles de l'élément INPUT.

Les cases à cocher
Les cases à cocher (et les boutons « radio ») sont des interrupteurs marche/arrêt qui peuvent être actionnés par l'utilisateur. L'interrupteur est sur « marche » quand l'attribut checked de l'élément de commande est spécifié. Lors de la soumission du formulaire, seules les commandes de cases à cocher sur « marche » peuvent devenir des commandes réussies.

Dans un formulaire, plusieurs cases à cocher peuvent partager le même nom de commande. Ainsi, par exemple, les cases à cocher permettent aux utilisateurs de sélectionner plusieurs valeurs pour la même propriété. On utilise l'élément INPUT pour créer une commande de case à cocher.

Les boutons « radio »
Les boutons « radio » sont analogues aux cases à cocher, à la différence que, quand plusieurs boutons partage le même nom de commande, alors ils s'excluent mutuellement : quand l'un est mis sur « marche », tous les autres avec le même nom se mettent sur « arrêt ». On utilise l'élément INPUT pour créer une commande de bouton radio.
Si aucun des boutons radio, dans un jeu partageant le même nom de commande, n'est en position « marche », alors le comportement de l'agent utilisateur, pour le choix de la commande qui est initialement sur « marche », n'est pas défini. Remarque : Comme les implémentations existantes gèrent diversement ce cas, la spécification courante se démarque du document RFC1866 ([RFC1866] section 8.1.2.4), qui déclare :
À tout instant, un seul bouton radio exactement parmi ceux dans un jeu est pressé. Si aucun des éléments dans un jeu de boutons radio ne spécifie un attribut "CHECKED", alors l'agent utilisateur doit activer initialement le premier des boutons radio du jeu en question.

En raison des différences d'interprétation entre les agents utilisateurs, les auteurs devraient s'assurer qu'un des boutons radio dans un jeu soit mis initialement sur « marche ».

Les menus
Les menus proposent des options aux utilisateurs parmi lesquelles faire un choix. L'élément SELECT crée un menu, en conjonction avec les éléments OPTGROUP et OPTION.
La saisie de texte
Les auteurs peuvent créer deux types de commande qui permettent aux utilisateurs la saisie d'un texte. L'élément INPUT crée une commande pour une saisie sur une seule ligne et l'élément TEXTAREA crée une commande pour une saisie sur plusieurs lignes. Dans les deux cas, le texte saisi devient la valeur courante de la commande.
La sélection d'un fichier
Ce type de commande permet à l'utilisateur de sélectionner un fichier de sorte que son contenu puisse être soumis avec le formulaire. On utilise l'élément INPUT pour créer une commande de sélection de fichier.
Les commandes cachées
Les auteurs peuvent créer des commandes qui ne sont pas restituées mais dont les valeurs sont soumises avec le formulaire. Les auteurs utilisent en général ce type de commande pour enregistrer les informations entre les échanges client/serveur, qui seraient perdues sinon du fait de la nature apatride du protocole HTTP (voir le document [RFC2616]). On utilise l'élément INPUT pour créer une commande cachée.
Les commandes d'objets
Les auteurs peuvent insérer des objets génériques dans les formulaires de telle sorte que les valeurs qui leur sont associées soient soumises en même temps que les autres commandes. On utilise l'élément OBJECT pour créer une commande d'objet.

Les éléments utilisés pour créer les commandes apparaissent généralement dans un élément FORM, mais ils peuvent aussi apparaître en dehors de la déclaration de l'élément FORM quand on les utilise pour construire des interfaces utilisateurs. Ceci est abordé dans la section sur les événements intrinsèques. Remarquez que les commandes en dehors d'un formulaire ne peuvent pas être des commandes réussies.

17.3 L'élément FORM

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
<!ATTLIST FORM
  %attrs;                              -- %coreattrs, %i18n, %events --
  action      %URI;          #REQUIRED -- gestionnaire de formulaire côté serveur --
  method      (GET|POST)     GET       -- méthode HTTP utilisée
                                          pour soumettre le formulaire --
  enctype     %ContentType;  "application/x-www-form-urlencoded"
  accept      %ContentTypes; #IMPLIED  -- liste de types MIME pour le
                                          chargement des fichiers --
  name        CDATA          #IMPLIED  -- nom du formulaire pour les scripts --
  onsubmit    %Script;       #IMPLIED  -- le formulaire a été soumis --
  onreset     %Script;       #IMPLIED  -- le formulaire a été réinitialisé --
  accept-charset %Charsets;  #IMPLIED  -- liste des jeux de caractères reconnus --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs

action = uri [CT]
Cet attribut spécifie l'agent pour le traitement du formulaire. Le comportement de l'agent utilisateur pour une valeur autre qu'un URI HTTP est indéfini.
method = get|post [CI]
Cet attribut spécifie la méthode HTTP qui sera employée pour soumettre le jeu des données de formulaire. Les valeurs possibles (insensibles à la casse) sont "get" (la valeur par défaut) et "post". Voir la section sur la soumission du formulaire pour des informations sur leur utilisation.
enctype = type-de-contenu [CI]
Cet attribut spécifie le type de contenu défini pour soumettre le formulaire au serveur (quand la valeur de la méthode est "post"). La valeur par défaut de cet attribut est "application/x-www-form-urlencoded". La valeur "multipart/form-data" devrait être utilisée en conjonction avec l'élément INPUT, quand celui-ci est défini tel que type="file".
accept-charset = charset list [CI]
Cet attribut spécifie la liste des encodages de caractères des données saisies qui sont acceptés par le serveur traitant ce formulaire. La valeur est une liste de valeurs de jeu de caractère, séparées par des espaces et/ou des virgules. Le client doit interpréter cette liste comme une liste de type « OU exclusif », i.e., le serveur est capable d'accepter un quelconque encodage de caractères seul par entité reçue.

La valeur par défaut de cet attribut est la chaîne réservée "UNKNOWN". Les agents utilisateurs peuvent interpréter cette valeur comme représentant l'encodage de caractères employé pour transmettre le document contenant l'élément FORM en question.

accept = liste-de-types-de-contenu [CI]
Cet attribut spécifie la liste de types de contenu, séparés par des virgules, que le serveur traitant ce formulaire va prendre en charge correctement. L'agent utilisateur peut utiliser ces informations pour éliminer les fichiers non conformes quand il demande à l'utilisateur de sélectionner un fichier à envoyer au serveur (voir l'élément INPUT quand l'attribut type="file").
name = cdata [CI]
Cet attribut nomme l'élément de sorte qu'il puisse être appelé par une feuille de style ou un script. Remarque : Cet attribut est conservé pour la rétro-compatibilité. Les applications devraient utiliser l'attribut id pour identifier les éléments.

Attributs définis ailleurs

L'élément FORM agit comme conteneur pour les commandes. Il spécifie :

Un formulaire peut contenir un texte et un balisage (paragraphes, listes, etc.) en plus des commandes de formulaire.

L'exemple suivant montre un formulaire qui va être traité par le programme « ajoutermembre » une fois soumis. Le formulaire sera envoyé au programme à l'aide de la méthode HTTP "post".

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
 ...contenu du formulaire...
 </FORM>

Veuillez consulter la section traitant de la soumission du formulaire pour des renseignements sur la manière dont les agents utilisateurs doivent préparer les données de formulaire pour les serveurs et sur la manière dont les agents utilisateurs devraient interpréter les réponses prévisibles.

Remarque : Les explications complètes concernant le comportement des serveurs lorsqu'ils reçoivent des données de formulaire sont hors de l'objet de cette spécification.

17.4 L'élément INPUT

<!ENTITY % InputType
  "(TEXT | PASSWORD | CHECKBOX |
    RADIO | SUBMIT | RESET |
    FILE | HIDDEN | IMAGE | BUTTON)"
   >


<!ELEMENT INPUT - O EMPTY              -- commande de formulaire -->
<!ATTLIST INPUT
  %attrs;                              -- %coreattrs, %i18n, %events --
  type        %InputType;    TEXT      -- le type de la commande --
  name        CDATA          #IMPLIED  -- soumis en tant que partie du formulaire --
  value       CDATA          #IMPLIED  -- pour les boutons radio et les cases à cocher --
  checked     (checked)      #IMPLIED  -- pour les boutons radio et les cases à cocher --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  readonly    (readonly)     #IMPLIED  -- pour les types text et passwd --
  size        CDATA          #IMPLIED  -- propre à chaque type de champs --
  maxlength   NUMBER         #IMPLIED  -- caractères maxi pour les champs textuels --
  src         %URI;          #IMPLIED  -- pour les champs et les images --
  alt         CDATA          #IMPLIED  -- brève description --
  usemap      %URI;          #IMPLIED  -- utiliser une image cliquable côté client --
  ismap       (ismap)        #IMPLIED  -- utiliser une image cliquable côté serveur --
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  accesskey   %Character;    #IMPLIED  -- touche de caractère pour accessibilité --
  onfocus     %Script;       #IMPLIED  -- l'élément a l'attention --
  onblur      %Script;       #IMPLIED  -- l'élément perd l'attention --
  onselect    %Script;       #IMPLIED  -- un texte est sélectionné --
  onchange    %Script;       #IMPLIED  -- la valeur de l'élément a changé --
  accept      %ContentTypes; #IMPLIED  -- liste des types MIME pour l'envoi d'un fichier --
  >

Balise ouvrante : obligatoire, balise fermante : interdite

Définition des attributs

type = text|password|checkbox|radio|submit|reset|file|hidden|image|button [CI]
Cet attribut spécifie le type de commande à créer. La valeur par défaut de cet attribut est "text".
name = cdata [CI]
Cet attribut assigne le nom de la commande.
value = cdata [CA]
Cet attribut spécifie la valeur initiale de la commande. Celui-ci est optionnel, sauf quand l'attribut type a la valeur "radio" ou bien "checkbox".
size = cdata [CN]
Cet attribut indique à l'agent utilisateur la largeur initiale de la commande. La largeur est donnée en pixels, sauf quand l'attribut type a la valeur "text" ou bien "password". Auxquels cas, sa valeur correspond au nombre (entier) de caractères.
maxlength = nombre [CN]
Quand l'attribut type a la valeur "text" ou bien "password", cet attribut spécifie le nombre maximum de caractères que l'utilisateur peut saisir. Ce nombre peut excéder la valeur spécifiée pour l'attribut size, auquel cas l'agent utilisateur devrait proposer un mécanisme de défilement. La valeur par défaut de cet attribut est un nombre illimité.
checked [CI]
Quand l'attribut type a la valeur "radio" ou bien "checkbox", cet attribut booléen spécifie que le bouton est sur « marche ». Les agents utilisateurs doivent ignorer cet attribut pour les autres types de commande.
src = uri [CT]
Quand l'attribut type a la valeur "image", cet attribut spécifie la localisation de l'image à utiliser pour décorer le bouton de soumission graphique.

Attributs définis ailleurs

17.4.1 Les types de commande créés par l'élément INPUT

Le type de commande défini par l'élément INPUT est fonction de la valeur de l'attribut type :

text
Crée une commande de saisie de texte sur une seule ligne.
password
Comme pour la valeur "text", mais le texte saisi est restitué de manière à dissimuler les caractères (par exemple, une succession de caractères astérisques « * »). Ce type de commande est souvent employé pour les entrées sensibles comme les mots de passe. Remarquez que la valeur courante est le texte saisi par l'utilisateur, non le texte restitué par l'agent utilisateur.

Remarque : Les développeurs d'applications devraient remarquer que ce mécanisme n'offre qu'une protection légère. Bien qu'il soit masqué par l'agent utilisateur aux yeux d'un éventuel observateur, le mot de passe est transmis au serveur en texte clair et peut être lu par quiconque ayant un accès granulaire au réseau.

checkbox
Crée une case à cocher.
radio
Crée un bouton « radio ».
submit
Crée un bouton de soumission.
image
Crée un bouton de soumission graphique. La valeur de l'attribut src spécifie l'URI de l'image qui va décorer le bouton. Pour des questions d'accessibilité, les auteurs devraient fournir un texte de remplacement pour l'image au moyen de l'attribut alt.

Quand un dispositif de pointage est employé pour cliquer sur l'image, le formulaire est soumis et les coordonnées du clic sont passées au serveur. La coordonnée « x » se mesure en pixels à partir de la gauche de l'image et la coordonnée « y » en pixels à partir du haut de l'image. Les données soumises comprennent les valeurs nom.x=valeur-de-x et nom.y=valeur-de-y, dans lesquelles le « nom » est la valeur de l'attribut name, et « valeur-de-x » et « valeur-de-y » sont les valeurs des coordonnées « x » et « y » respectivement.

Si le serveur entreprend diverses actions en fonction de l'endroit cliqué, l'utilisateur d'un navigateur non-graphique sera désavantagé. Pour cette raison, les auteurs devraient considérer ces approches alternatives :

reset
Crée un bouton de réinitialisation.
button
Crée un bouton poussoir. Les agents utilisateurs devraient utiliser la valeur de l'attribut value comme intitulé du bouton.
hidden
Crée une commande cachée.
file
Crée une commande de sélection de fichier. Les agents utilisateurs peuvent utiliser la valeur de l'attribut value comme nom de fichier initial.

17.4.2 Exemples de formulaires contenant des commandes INPUT

L'exemple de fragment HTML suivant définit un formulaire simple qui permet à l'utilisateur de saisir ses prénom, nom, adresse e-mail et genre. Quand on actionnera le bouton de soumission, le formulaire sera transmis au programme spécifié par l'attribut action.

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    Prénom : <INPUT type="text" name="prenom"><BR>
    Nom : <INPUT type="text" name="nom"><BR>
    E-mail: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
    </P>
 </FORM>

Ce formulaire pourrait être restitué comme suit :

Un exemple de restitution d'un formulaire.

Dans la section traitant de l'élément LABEL, nous aborderons le balisage des intitulés tel que « Prénom » ici.

Dans l'exemple suivant, la fonction JavaScript « verifier » est déclenchée quand l'événement "onclick" se produit :

<HEAD>
<META http-equiv="Content-Script-Type" content="text/javascript">
</HEAD>
<BODY>
 <FORM action="..." method="post">
    <P>
    <INPUT type="button" value="Cliquez moi" onclick="verifier()">
 </FORM>
</BODY>

Veuillez consulter la section sur les événements intrinsèques pour plus d'informations à propos des scripts et des événements.

L'exemple suivant montre la manière dont le contenu d'un fichier spécifié par l'utilisateur peut être soumis avec le formulaire. L'utilisateur est invité à donner son nom et la liste des noms de fichier dont le contenu devrait être soumis avec le formulaire. En spécifiant la valeur "multipart/form-data" pour l'attribut enctype, chaque contenu de fichier sera conditionné pour soumission dans une section distincte d'un document en plusieurs parties.

<FORM action="http://server.dom/cgi/gestion"
    enctype="multipart/form-data"
    method="post">
 <P>
 Quel est votre nom ? <INPUT type="text" name="nom_expediteur">
 Quels sont les fichiers à envoyer ? <INPUT type="file" name="nom_des_fichiers">
 </P>
</FORM>

17.5 L'élément BUTTON

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- bouton poussoir -->
<!ATTLIST BUTTON
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  value       CDATA          #IMPLIED  -- envoyé au serveur à la soumission --
  type        (button|submit|reset) submit -- à utiliser comme bouton de formulaire --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  accesskey   %Character;    #IMPLIED  -- touche de caractère pour l'accessibilité --
  onfocus     %Script;       #IMPLIED  -- l'élément a l'attention --
  onblur      %Script;       #IMPLIED  -- l'élément perd l'attention --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs

name = cdata [CI]
Cet attribut assigne le nom de la commande.
value = cdata [CS]
Cet attribute assigne la valeur initiale au bouton.
type = submit|button|reset [CI]
Cet attribut déclare le type du bouton. Les valeurs possibles sont :

Attributs définis ailleurs

Les boutons créés par l'élément BUTTON fonctionnent exactement comme ceux créés avec l'élément INPUT, mais ils offrent des possibilités de restitution plus variées : l'élément BUTTON peut avoir un contenu. Par exemple, un élément BUTTON qui contient une image fonctionne de la même façon et peut avoir le même aspect qu'un élément INPUT dont l'attribut type a la valeur "image", sauf que le type d'élément BUTTON admet un contenu.

Les agents utilisateurs visuels peuvent restituer les boutons BUTTON en relief et avec un mouvement de haut en bas quand on les clique, tandis qu'ils peuvent restituer les boutons INPUT comme des images « plates ».

L'exemple suivant reprend et prolonge un exemple précédent en créant des boutons de soumission et de réinitialisation avec l'élément BUTTON au lieu de INPUT. Les boutons contiennent des images par l'intermédiaire d'éléments IMG.

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    Prénom : <INPUT type="text" name="prenom"><BR>
    Nom : <INPUT type="text" name="nom"><BR>
    E-mail: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <BUTTON name="submit" value="envoyer" type="submit">
    Envoyer<IMG src="/icons/c-bon.gif" alt=""></BUTTON>
    <BUTTON name="reset" type="reset">
    Effacer<IMG src="/icons/c-pas-bon.gif" alt=""></BUTTON>
    </P>
 </FORM>

Les auteurs doivent se rappeler de fournir un texte de remplacement pour l'élément IMG.

Il est illégal d'associer une image cliquable à un élément IMG apparaissant en contenu d'un élément BUTTON.

EXEMPLE ILLÉGAL :
Ce qui suit n'est pas légal pour HTML.

<BUTTON>
<IMG src="foo.gif" usemap="...">
</BUTTON>

17.6 Les éléments SELECT, OPTGROUP et OPTION

<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- sélecteur d'option -->
<!ATTLIST SELECT
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED  -- nom du champs --
  size        NUMBER         #IMPLIED  -- rangées visibles --
  multiple    (multiple)     #IMPLIED  -- une seule sélection par défaut --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  onfocus     %Script;       #IMPLIED  -- l'élément a l'attention --
  onblur      %Script;       #IMPLIED  -- l'élément perd l'attention --
  onchange    %Script;       #IMPLIED  -- la valeur de l'élément a changé --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs pour SELECT

name = cdata [CI]
Cet attribut assigne le nom de la commande.
size = nombre [CN]
Quand l'élément SELECT se présente comme une zone de liste défilante [ndt. scrolled list box], cet attribut spécifie le nombre de rangées de cette liste qui devraient être visibles en même temps. Les agents utilisateurs ne sont pas tenus de présenter l'élément SELECT sous forme d'une zone de liste ; ils peuvent faire appel à un autre mécanisme, tel qu'un menu déroulant [ndt. drop-down menu].
multiple [CI]
Quand il est présent, cet attribut booléen permet une sélection multiple. En son absence, l'élément SELECT n'autorise que la sélection simple.

Attributs définis ailleurs

L'élément SELECT crée un menu. Chaque option offerte par le menu est représentée par un élément OPTION. L'élément SELECT doit contenir au moins un élément OPTION.

L'élément OPTGROUP permet aux auteurs le regroupement logique des options. Cela est particulièrement utile quand l'utilisateur doit effectuer un choix à partir d'une longue liste d'options ; les groupes d'options apparentées sont plus facile à comprendre et à se remémorer qu'une seule longue liste d'options. Dans HTML 4 tous les éléments OPTGROUP doivent être spécifiés directement dans un élément SELECT (i.e., les groupes ne peuvent pas être imbriqués).

17.6.1 Les options présélectionnées

Zéro ou plusieurs options peuvent être présélectionnées pour l'utilisateur. Les agents utilisateurs devraient déterminer les options qui sont préselectionnées comme suit :

<!ELEMENT OPTGROUP - - (OPTION)+ -- regroupement d'option -->
<!ATTLIST OPTGROUP
  %attrs;                              -- %coreattrs, %i18n, %events --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  label       %Text;         #REQUIRED -- à utiliser dans les menus hiérarchiques --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs pour OPTGROUP

label = texte [CS]
Cet attribut spécifie l'intitulé du groupe d'options.

Attributs définis ailleurs

Remarque : Les développeurs sont prévenus de ce que les futures versions de HTML pourraient prolonger le mécanisme de regroupement pour autoriser les groupes imbriqués (i.e., les éléments OPTGROUP pourraient s'imbriquer). Cela permettrait aux auteurs de représenter une hiérarchie d'options plus complète.

<!ELEMENT OPTION - O (#PCDATA)         -- option sélectionnable -->
<!ATTLIST OPTION
  %attrs;                              -- %coreattrs, %i18n, %events --
  selected    (selected)     #IMPLIED
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  label       %Text;         #IMPLIED  -- à utiliser dans les menus hiérarchiques --
  value       CDATA          #IMPLIED  -- le contenu de l'élément par défaut --
  >

Balise ouvrante : obligatoire, balise fermante : optionnelle

Définition des attributs pour OPTION

selected [CI]
Quand il est présent, cet attribut booléen spécifie que l'option est présélectionnée.
value = cdata [CS]
Cet attribut spécifie la valeur initiale de la commande. Si cet attribut n'est pas spécifié, la valeur initiale est alors le contenu de l'élément OPTION.
label = texte [CS]
Cet attribut permet aux auteurs de spécifier un intitulé pour l'option qui est plus court que le contenu de l'élément OPTION. Quand il est spécifié, les agents utlisateurs devraient utiliser la valeur de cet attribut plutôt que le contenu de l'élément OPTION comme intitulé pour l'option.

Attributs définis ailleurs

Lors de la restitution de l'option d'un menu, l'agent utilisateur devrait utiliser la valeur de l'attribut label de l'élément OPTION comme intitulé pour l'option. Si cet attribut n'est pas spécifié, l'agent utilisateur devrait utiliser le contenu de l'élément OPTION.

L'attribut label de l'élément OPTGROUP spécifie l'intitulé d'un groupe d'options.

Dans cet exemple, nous créons un menu qui permet à l'utilisateur de sélectionner lequel parmi sept composants logiciels choisir. Le premier et le deuxième composants sont présélectionnés mais ils peuvent être désélectionnés par l'utilisateur. Les composants restants ne sont pas présélectionnés. L'attribut size déclare que le menu ne devrait avoir que quatre rangées, même si l'utilisateur peut effectuer un choix parmi sept options. La mise à disposition des autres options devrait se faire au moyen d'un mécanisme de défilement.

L'élément SELECT est suivi par un bouton de soumission et un de réinitialisation.

<FORM action="http://unsite.com/prog/choisir_composant" method="post">
   <P>
   <SELECT multiple size="4" name="selection_composant">
      <OPTION selected value="composant_1_a">Composant_1</OPTION>
      <OPTION selected value="composant_1_b">Composant_2</OPTION>
      <OPTION>Composant_3</OPTION>
      <OPTION>Composant_4</OPTION>
      <OPTION>Composant_5</OPTION>
      <OPTION>Composant_6</OPTION>
      <OPTION>Composant_7</OPTION>
   </SELECT>
   <INPUT type="submit" value="Envoyer"><INPUT type="reset">
   </P>
</FORM>

Seules les options sélectionnées réussiront (en utilisant le nom de commande "selection_composant"). Si aucune option n'est sélectionnée, la commande n'est pas réussie et ni le nom ni la valeur ne sont envoyés au serveur à la soumission du formulaire. Remarquez que l'attribut value est spécifié, il détermine donc la valeur initiale de la commande, sinon ce serait le contenu de l'élément.

Dans ce exemple, nous employons l'élément OPTGROUP pour regrouper les options. Soit le balisage suivant :

<FORM action="http://unsite.com/prog/unprogramme" method="post">
 <P>
 <SELECT name="ComOS">
     <OPTION selected label="aucun" value="aucun">Aucun</OPTION>
     <OPTGROUP label="PortMaster 3">
       <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 avec ComOS 3.7.1</OPTION>
       <OPTION label="3.7" value="pm3_3.7">PortMaster 3 avec ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm3_3.5">PortMaster 3 avec ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="PortMaster 2">
       <OPTION label="3.7" value="pm2_3.7">PortMaster 2 avec ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm2_3.5">PortMaster 2 avec ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="IRX">
       <OPTION label="3.7R" value="IRX_3.7R">IRX avec ComOS 3.7R</OPTION>
       <OPTION label="3.5R" value="IRX_3.5R">IRX avec ComOS 3.5R</OPTION>
     </OPTGROUP>
 </SELECT>
</FORM>

celui-ci représenterait le regroupement suivant :

  Aucun
  PortMaster 3
      3.7.1
      3.7
      3.5
  PortMaster 2
      3.7
      3.5
  IRX
      3.7R
      3.5R

Les agents utilisateurs visuels peuvent autoriser les utilisateurs à effectuer une sélection à partir des groupes d'options au moyen d'un menu hiérarchique ou d'un autre mécanisme qui reflète la structure des options.

Un agent utilisateur graphique pourrait restituer ceci par :

Une restitution possible pour OPTGROUP

Cette image montre un élément SELECT qui est restitué par un menu en cascade. L'intitulé supérieur du menu affiche la valeur sélectionnée la nouvelle valeur (PortMaster 2, 3.7). Remarquez que chaque sous-menu affiche l'intitulé d'un élément OPTGROUP, ou d'un élément OPTION.

17.7 L'élément TEXTAREA

<!ELEMENT TEXTAREA - - (#PCDATA)       -- multi-line text field -->
<!ATTLIST TEXTAREA
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  rows        NUMBER         #REQUIRED
  cols        NUMBER         #REQUIRED
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  readonly    (readonly)     #IMPLIED
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  accesskey   %Character;    #IMPLIED  -- touche de caractère pour l'accessibilité --
  onfocus     %Script;       #IMPLIED  -- l'élément a l'attention --
  onblur      %Script;       #IMPLIED  -- l'élément perd l'attention --
  onselect    %Script;       #IMPLIED  -- some text was selected --
  onchange    %Script;       #IMPLIED  -- la valeur de l'élément a changé --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs

name = cdata [CI]
Cet attribut assigne le nom de la commande.
rows = nombre [CN]
Cet attribut spécifie le nombre de lignes de texte visibles. Les utilisateurs devraient pouvoir saisir plus de lignes que ce nombre, les agents utilisateurs devraient donc fournir un moyen de faire défiler le contenu de la commande quand celui-ci s'étend au-delà de la zone visible.
cols = nombre [CN]
Cet attribut spécifie la largeur visible en fonction de la chasse moyenne des caractères. Les utilisateurs devraient pouvoir saisir des lignes plus longues que cette largeur. Les agents utilisateurs peuvent couper les textes de ligne visibles afin de garder les longues lignes visibles sans devoir les faire défiler.

Attributs définis ailleurs

L'élément TEXTAREA crée une commande de saisie de texte multilignes. Les agents utilisateurs devraient utiliser le contenu de cet élément comme valeur initiale et restituer initialement ce texte.

Cet exemple crée une commande TEXTAREA qui fait vingt rangées par quatre-vingt colonnes et qui contient initialement deux lignes de texte. La commande TEXTAREA est suivie par un bouton de soumission et un de réinitialisation.

<FORM action="http://unsite.com/prog/lecture-texte" method="post">
   <P>
   <TEXTAREA name="le_texte" rows="20" cols="80">
   Première ligne de texte initial.
   Seconde ligne de texte initial.
   </TEXTAREA>
   <INPUT type="submit" value="Envoyer"><INPUT type="reset">
   </P>
</FORM>

La spécification de l'attribut readonly permet à l'auteur d'afficher un texte non modifiable dans la commande TEXTAREA. Ce n'est pas la même chose que d'utiliser un texte balisé standard dans un document, parce que la valeur de l'élément TEXTAREA est soumise avec le formulaire.

17.8 L'élément ISINDEX

L'élément ISINDEX est déconseillé. Cet élément crée une commande de saisie d'un texte sur une seule ligne. Les auteurs devraient utiliser l'élément INPUT pour créer des commandes de saisie de texte.

Voir le DTD transitoire pour sa définition formelle.

Définition des attributs

prompt = texte [CS]
Déconseillé. Cet attribut spécifie une chaîne d'invite [ndt. prompt string] pour le champs de saisie.

Attributs définis ailleurs

L'élément ISINDEX crée une commande de saisie de texte sur une seule ligne, qui admet un nombre quelconque de caractères. Les agents utilisateurs peuvent utiliser la valeur de l'attribut prompt comme titre pour l'invite.

EXEMPLE DÉCONSEILLÉ :
Soit la déclaration ISINDEX suivante :

<ISINDEX prompt="Saisissez le mot à rechercher : ">

celle-ci pourrait se récrire avec l'élément INPUT, comme suit :

<FORM action="..." method="post">
<P>Saisissez le mot à rechercher : <INPUT type="text"></P>
</FORM>

La sémantique de l'élément ISINDEX. Actuellement, la sémantique de l'élément ISINDEX n'est bien définie que quand l'URI de base du document englobant est un URI HTTP. En pratique, la chaîne saisie se limite au jeu de caractères Latin-1 car l'URI ne dispose d'aucun moyen pour spécifier un jeu de caractères différent.

17.9 Les labels

Quelques commandes de formulaire ont des labels qui leur sont automatiquement associés (les boutons poussoirs) tandis que la plupart d'entre elles en sont dépourvues (les champs de texte, les cases à cocher et les boutons radio ainsi que les menus).

Pour celles des commandes qui ont un label implicite, les agents utilisateurs devraient utiliser la valeur de l'attribut value comme chaîne pour le label.

On utilise l'élément LABEL pour spécifier les labels des commandes qui n'ont pas de labels implicites.

17.9.1 L'élément LABEL

<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- texte du label d'un champs de texte -->
<!ATTLIST LABEL
  %attrs;                              -- %coreattrs, %i18n, %events --
  for         IDREF          #IMPLIED  -- correspond à la valeur ID du champs --
  accesskey   %Character;    #IMPLIED  -- touche de caractère pour l'accessibilité --
  onfocus     %Script;       #IMPLIED  -- l'élément a l'attention --
  onblur      %Script;       #IMPLIED  -- l'élément perd l'attention --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs

for = idref [CS]
Cet attribut associe explicitement le label qui est défini à une autre commande. Quand il est présent, la valeur de cet attribut doit être la même que la valeur de l'attribut id d'une certaine commande dans le même document. Quand il est absent, le label qui est défini est associé au contenu de l'élément.

Attributs définis ailleurs

L'élément LABEL peut s'utiliser pour attacher des informations aux commandes. Chaque élément LABEL est associé à exactement une commande de formulaire.

L'attribut for associe explicitement un label à une autre commande : la valeur de l'attribut for doit être la même que celle de l'attribut id de l'élément de commande associé. On peut associer plusieurs éléments LABEL à la même commande en créant plusieurs références via l'attribut for.

Cet exemple crée une table qui est utilisée pour aligner deux commandes de saisie de texte et les labels qui leur sont associés. Chaque label est associé explicitement à une commande de saisie de texte :

<FORM action="..." method="post">
<TABLE>
  <TR>
    <TD><LABEL for="label_prenom">Prénom</LABEL>
    <TD><INPUT type="text" name="prenom" id="label_prenom">
  <TR>
    <TD><LABEL for="label_nom">Nom</LABEL>
    <TD><INPUT type="text" name="nom" id="label_nom">
</TABLE>
</FORM>

Cet exemple reprend un exemple de formulaire précédent et y inclut des éléments LABEL.

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    <LABEL for="label_prenom">Prénom : </LABEL>
              <INPUT type="text" id="label_prenom"><BR>
    <LABEL for="label_nom">Nom : </LABEL>
              <INPUT type="text" id="label_nom"><BR>
    <LABEL for="label_email">E-mail : </LABEL>
              <INPUT type="text" id="label_email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
    </P>
 </FORM>

Pour associer implicitement un label à une autre commmande, l'élément de commande doit se trouver à l'intérieur de l'élément LABEL. Auquel cas, cet élément LABEL ne peut contenir qu'un seul élément de commande. Le label en question peut se placer avant ou après la commande associée.

Dans cet exemple, nous associons implicitement deux labels à deux commandes de saisie de texte :

<FORM action="..." method="post">
<P>
<LABEL>
   Prénom
   <INPUT type="text" name="prenom">
</LABEL>
<LABEL>
   <INPUT type="text" name="nom">
   Nom
</LABEL>
</P>
</FORM>

Remarquez qu'on ne peut pas employer cette technique quand la disposition est assurée par une table, le label étant dans une cellule et la commande associée dans une autre cellule.

Quand un élément LABEL reçoit l'attention, celui-ci communique cette attention à la commande qui lui est associée. Voir la section ci-dessous sur les clés d'accès pour des exemples.

Les agents utilisateurs peuvent restituer les labels de nombreuses façons (par exemple, visuellement, lus par des synthétiseurs de parole, etc.).

17.10 Le rajout d'une structure aux formulaires : les éléments FIELDSET et LEGEND


<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- form control group -->
<!ATTLIST FIELDSET
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

<!ELEMENT LEGEND - - (%inline;)*       -- fieldset legend -->

<!ATTLIST LEGEND
  %attrs;                              -- %coreattrs, %i18n, %events --
  accesskey   %Character;    #IMPLIED  -- touche de caractère pour l'accessibilité --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Définition des attributs pour LEGEND

align = top|bottom|left|right [CI]
Déconseillé. Cet attribut spécifie la position de la légende par rapport au jeu de champs [ndt. fieldset]. Les valeurs possibles sont :
  • top : la légende est en haut du jeu de champs. C'est la valeur par défaut ;
  • bottom : la légende est en bas du jeu de champs ;
  • left : la légende est à gauche du jeu de champs ;
  • right : la légende est à droite du jeu de champs.

Attributs définis ailleurs

L'élément FIELDSET perment aux auteurs de regrouper thématiquement les commandes et les labels apparentés. Le regroupement des commandes rend leur compréhension plus aisée aux utilisateurs, tout en facilitant la navigation par tabulation pour les agents utilisateurs visuels et la navigation vocale pour les agents utilisateurs vocaux. La bonne utilisation de cet élément rend les documents plus accessibles.

L'élément LEGEND permet aux auteurs d'assigner une légende à un élément FIELDSET. La légende renforce l'accessibilité quand l'élément FIELDSET est restituée de manière non-visuelle.

Dans cet exemple, nous créons un formulaire, du genre de ceux que l'on pourrait remplir dans un cabinet médical. Il se divise en trois parties : les informations personnelles, l'historique médical et le traitement courant. Chaque partie contient les commandes pour la saisie des informations concernées.

<FORM action="..." method="post">
 <P>
 <FIELDSET>
  <LEGEND>Informations personnelles</LEGEND>
  Nom : <INPUT name="personnel_nom" type="text" tabindex="1">
  Prénom : <INPUT name="personnel_prenom" type="text" tabindex="2">
  Adresse : <INPUT name="personnel_adresse" type="text" tabindex="3">
  <em>...autres informations personnelles...</em>
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Historique médical</LEGEND>
  <INPUT name="historique_maladie" 
         type="checkbox" 
         value="variole" tabindex="20"> Variole
  <INPUT name="historique_maladie" 
         type="checkbox" 
         value="oreillons" tabindex="21"> Oreillons
  <INPUT name="historique_maladie" 
         type="checkbox" 
         value="vertiges" tabindex="22"> Vertiges
  <INPUT name="historique_maladie" 
         type="checkbox" 
         value="eternuements" tabindex="23"> Éternuements
  <em>...autres épisodes médicaux...</em>
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Traitement courant</LEGEND>
  Suivez-vous actuellement un traitement ? 
  <INPUT name="traitement_actuel" 
         type="radio" 
         value="oui" tabindex="35">Oui
  <INPUT name="traitement_actuel" 
         type="radio" 
         value="non" tabindex="35">Non

  Si vous prenez des médicaments, veuillez les
  inscrire dans l'espace ci-dessous :
  <TEXTAREA name="medication_courante" 
            rows="20" cols="50"
            tabindex="40">
  </TEXTAREA>
 </FIELDSET>
</FORM>

Remarquez, dans cet exemple, que nous pourrions améliorer la présentation visuelle du formulaire en alignant les éléments à l'intérieur de chaque élément FIELDSET (avec les feuilles de style), en ajoutant de la couleur et des indications de police (avec les feuilles de styles), en ajoutant des scripts (disons, pour n'ouvrir la zone de texte "medication_courante" que si l'utilisateur indique prendre des médicaments), etc.

17.11 Donner l'attention à un élément

Dans un document HTML, un élément doit recevoir l'attention [ndt. focus] par le biais de l'utilisateur afin de devenir actif et de remplir sa fonction. Par exemple, les utilisateurs doivent activer le lien spécifié par l'élément A pour suivre le lien en question. De la même manière, les utilisateurs doivent donner l'attention à l'élément TEXTAREA pour y saisir un texte.

Il y a plusieurs façons de donner l'attention à un élément :

17.11.1 La navigation par tabulation

Définition des attributs

tabindex = nombre [CN]
Cet attribut spécifie la position de l'élément en question dans l'ordre de tabulation du document courant. Cette valeur doit être un nombre entre 0 et 32767. Les agents utilisateurs devraient ignorer les zéros de tête.

L'ordre de tabulation définit l'ordre dans lequel les éléments vont recevoir l'attention lorsque l'utilisateur navigue au clavier. L'ordre de tabulation peut comprendre les éléments imbriqués dans d'autres éléments.

Les éléments qui reçoivent l'attention devraient être parcourus par les agents utilisateurs en fonction des règles suivantes :

  1. Ceux des éléments qui reconnaissent l'attribut tabindex et lui assignent une valeur positive sont parcourus en premier. La navigation procède à partir de l'élément avec la plus petite valeur pour l'attribut tabindex vers l'élément avec la valeur la plus élevée. Les valeurs ne se suivent pas forcément ni doivent commencer à une valeur particulière. Les éléments dont les valeurs de l'attribut tabindex sont identiques devraient être parcourus dans l'ordre de leur apparition dans le flux de caractère ;
  2. Ceux des éléments qui ne reconnaissent pas l'attribut tabindex, ou bien le reconnaissent et lui assigne une valeur de "0", sont parcourus ensuite. Ces éléments sont parcourus dans l'ordre de leur apparition dans le flux de caractères ;
  3. Les éléments qui sont inactifs ne participent pas dans l'ordre de tabulation.

Les éléments suivants reconnaissent l'attribut tabindex : A, AREA, BUTTON, INPUT, OBJECT, SELECT, et TEXTAREA.

Dans cet exemple, l'ordre de tabulation sera le suivant : l'élément BUTTON, les éléments INPUT en ordre (remarquez que celui nommé "champs1" partage la même valeur d'attribut tabindex que le bouton, mais "champs1" apparaît plus tard dans le flux de caractères) et finalemnt le lien créé par l'élément A.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Un document avec FORM</TITLE>
</HEAD>
<BODY>
...un texte...
<P>Aller sur le 
<A tabindex="10" href="http://www.w3.org/">site Web du W3C.</A>
...suite du texte...
<BUTTON type="button" name="base_de_donnees"
           tabindex="1" onclick="base_de_donnees()">
Obtenir la base de données courante.
</BUTTON>
...suite du texte...
<FORM action="..." method="post">
<P>
<INPUT tabindex="1" type="text" name="champs1">
<INPUT tabindex="2" type="text" name="champs2">
<INPUT tabindex="3" type="submit" name="submit">
</P>
</FORM>
</BODY>
</HTML>

Les clés de tabulation : La combinaison de clés réelle qui produit la navigation par tabulation est fonction de la configuration de l'agent utilisateur (par exemple, la touche « tabulation » est pour la navigation et la touche « entrée » pour l'activation de l'élément sélectionné).

Les agents utilisateurs peuvent également définir des combinaisons de clés pour parcourir l'ordre de tabulation à rebours. Quand la fin (ou le début) de l'ordre de tabulation est atteinte, l'agent utilisateur peut revenir en arrière au début (ou à la fin).

17.11.2 Les clés d'accès

Définition des attributs

accesskey = caractère [CN]
Cet attribut assigne une clé d'accès à un élément. Une clé d'accès est un caractère seul provenant du jeu de caractères du document. Remarque : Les auteurs devraient prendre en considération la méthode de saisie du lecteur supposé lors de la spécification d'une clé d'accès.

La pression de la clé d'accès assignée à un élément lui donne l'attention. L'action qui survient quand l'élément reçoit l'attention est fonction de l'élément. Par exemple, quand l'utilisateur active un lien défini par l'élément A, l'agent utilisateur suit en général le lien. Quand l'utilisateur active un bouton radio, l'agent utilisateur change la valeur du bouton radio. Quand l'utilisateur active un champs de texte, la saisie devient possible, etc.

Les éléments suivants reconnaissent l'attribut accesskey : A, AREA, BUTTON, INPUT, LABEL et LEGEND, ainsi que TEXTAREA.

Cet exemple assigne la clé d'accès « U » au label associé à une commande INPUT. Le fait d'appuyer sur la clé d'accès donne l'attention au label, qui à son tour la transmet à la commande associée. L'utilisateur peut alors saisir un texte dans la zone INPUT.

<FORM action="..." method="post">
<P>
<LABEL for="label_utilisateur" accesskey="U">
User Name
</LABEL>
<INPUT type="text" name="utilisateur" id="label_utilisateur">
</P>
</FORM>

Dans cet exemple, nous assignons une clé d'accès à un lien défini par l'élément A. La frappe de cette clé d'accès conduit l'utilisateur vers un autre document, ici une table des matières.

<P><A accesskey="T" 
      rel="contents"
      href="http://quelquepart.com/specification/table_des_matieres.html">
    Table des matières</A>

L'invocation des clés d'accès est fonction du système sous-jacent. Par exemple, sur les machines faisant tourner le système MS Windows, on devra en général presser la touche « alt » en plus de la clé d'accès. Sur les systèmes Apple, ce sera la touche « cmd » qu'il faudra appuyer en plus de la clé d'accès.

La restitution des clés d'accès est fonction de l'agent utilisateur. Nous recommandons aux auteurs d'inclure la clé d'accès dans le texte du label ou partout où la clé d'accès doit s'appliquer. Les agents utilisateurs devraient restituer la valeur d'une clé d'accès de sorte à mettre en évidence son rôle et à la distinguer des autres caractères (par exemple, en la soulignant).

17.12 Les commandes inactives et en lecture seule

Dans les situations pour lesquelles les entrées de l'utilisateur sont soit indésirables, soit hors de propos, il importe de pouvoir rendre une commande inactive ou de la restituer en lecture seule. Par exemple, on peut vouloir que le bouton de soumission d'un formulaire reste inactif tant que l'utilisateur n'a pas entré certaines données obligatoires. De la même manière, l'auteur peut vouloir inclure un bout de texte en lecture seule, qui doit être soumis comme valeur en même temps que le formulaire. Les sections suivantes décrivent les commandes inactives et celles en lecture seule.

17.12.1 Les commandes inactives

Définition des attributs

disabled [CI]
Quand il est placé sur une commande de formulaire, cet attribut booléen inactive la commande vis-à-vis d'une entrée de l'utilisateur.

Quand il est présent, l'attribut disabled produit l'effet suivant sur un élément :

Les éléments suivants reconnaissent l'attribut disabled : BUTTON, INPUT, OPTGROUP, OPTION, SELECT, et TEXTAREA.

Cet attribut est hérité mais les déclarations locales surclassent la valeur héritée.

La manière dont les éléments inactifs sont restitutés est fonction de l'agent utilisateur. Par exemple, certains agents utilisateurs restituent en « grisé » les articles de menu, les labels de bouton, etc. qui sont inactifs.

Dans cet exemple, l'élément INPUT est inactif. C'est pourquoi il ne peut pas recevoir l'entrée de l'utilisateur et sa valeur ne peut pas être soumise avec le formulaire.

<INPUT disabled name="fred" value="stone">

Remarque : Seul un script peut modifier dynamiquement la valeur de l'attribut disabled.

17.12.2 Les commandes en lecture seule

Définition des attributs

readonly [CI]
Quand il est placé sur une commande de formulaire, cet attribut booléen interdit les changements sur la commande.

L'attribut readonly spécifie si la commande peut être modifiée ou non par l'utilisateur.

Quand il est présent, l'attribut readonly produit les effets suivants sur l'élément :

Les éléments suivants reconnaissent l'attribut readonly : INPUT et TEXTAREA.

La manière dont les éléments en lecture seule sont restitués est fonction de l'agent utilisateur.

Remarque : Seul un script peut modifier dynamiquement la valeur de l'attribut readonly.

17.13 La soumission du formulaire

Les sections suivantes expliquent la manière dont les agents utilisateurs soumettent les données de formulaire aux agents de traitement des formulaires.

17.13.1 La méthode de soumission du formulaire

L'attribut method de l'élément FORM spécifie la méthode HTTP employée pour envoyer le formulaire à l'agent de traitement. Cet attribut admet deux valeurs :

On devrait employer la méthode "get" quand le formulaire est idempotent (i.e., ne produit aucun effet secondaires). Nombre de recherches dans les bases de données n'ont pas d'effets secondaires visibles et font des applications idéales pour la méthode "get".

Si le service associé au traitement d'un formulaire entraîne des effets secondaires (par exemple, si le formulaire modifie une base de données ou l'abonnement à un service), on devrait alors employer la méthode "post".

Remarque : La méthode "get" restreint les valeurs du jeu des données du formulaire [ndt. form data set] aux caractères ASCII. Seule la méthode "post" (avec l'attribut enctype="multipart/form-data") est spécifiée comme recouvrant le jeu de caractères [ISO10646] entier.

17.13.2 Les commandes réussies

Une commande réussie est « valable » pour une soumission. Toute les commandes réussies ont leur nom de commande accouplé à leur valeur courante et font partie du jeu des données du formulaire qui est soumis. Une commande réussie doit être définie dans un élément FORM et doit avoir un nom de commande.

Cependant :

Si une commande n'a pas de valeur courante au moment de la soumission du formulaire, les agents utilisateurs ne sont pas obligés de la traiter comme une commande réussie.

De surcroît, les agents utilisateurs ne devraient pas considérer les commandes suivantes comme étant réussies :

Les commandes cachées et les commandes qui ne sont pas restituées en raison de l'effet d'une feuille de style peuvent quand même réussir. Par exemple :

<FORM action="..." method="post">
<P>
<INPUT type="password" style="display:none"  
          name="mot_de_passe_invisible"
          value="mon_mot_de_passe">
</FORM>

cela entraînera malgré tout l'accouplement de la valeur au nom "mot_de_passe_invisible" et leur soumission avec le formulaire.

17.13.3 Le traitement des données du formulaire

Quand l'utilisateur soumet le formulaire (par exemple, en activant un bouton de soumission), l'agent utilisateur le traite de la manière suivante.

Première étape : identifier les commandes réussies 

Deuxième étape : construire le jeu des données du formulaire 

Le jeu des données du formulaire est la séquence des couples nom de commande/valeur courante construite à partir des commandes réussies.

Troisième étape : coder le jeu des données du formulaire 

Le jeu des données du formulaire est alors codé en fonction du type de contenu spécifié par l'attribut enctype de l'élément FORM.

Quatrième étape : soumettre le jeu des données du formulaire codé 

Enfin, les données codées sont envoyées à l'agent de traitement désigné par l'attribut action, en utilisant le protocole spécifié par l'attribut method.

Cette spécification ne définit pas toutes les méthodes de soumissions valides ni les types de contenu qui peuvent être utilisés avec les formulaires. Cependant, les agents utilisateur HTML 4 doivent obéir aux conventions établies dans les cas suivants s:

Pour toute autre valeur de l'attribut action ou method, le comportement n'est pas spécifié.

Les agents utilisateurs devraient restituer les réponses des transactions HTTP "get" et "post".

17.13.4 Les types de contenu du formulaire

L'attribut enctype de l'élément FORM spécifie le type de contenu utilisé pour coder le jeu des données du formulaire en vue de sa soumission au serveur. Les agents utilisateurs doivent reconnaître les types de contenu listés ci-dessous. Le comportement pour d'autres types de contenu n'est pas spécifié.

Veuillez consulter également la section sur l'échappement [ndt. escaping] des esperluettes dans les valeurs d'attribut des URI.

"application/x-www-form-urlencoded"  

C'est le type de contenu par défaut. Les formulaires soumis avec ce type de contenu doivent être codés commes suit :

  1. Les noms de commandes et les valeurs sont échappées. Les caractères « espace » sont remplacés par des caractères plus « + » puis les caractères réservés sont échappés comme décrit dans le document [RFC1738], section 2.2 : Les caractères non-alphanumériques sont remplacés par une séquence de la forme « %HH », un caractère pourcentage et deux chiffres hexadécimaux qui représentent le code ASCII du caractère en question. Les sauts de ligne sont représentés par des couples de caractères "CR LF" (i.e., "%0D%0A") ;
  2. Les couples nom/valeur des commandes sont listés selon leur ordre d'apparition dans le document. Le nom est séparé de la valeur par un caractère égal « = », et les couples nom/valeur sont séparés les uns des autres par des caractères esperluettes « & ».

"multipart/form-data"  

Remarque : Veuillez consulter le document [RFC2388] pour des informations supplémentaires sur le chargement des fichiers, y compris les problèmes de rétro-compatibilité, la relation entre "multipart/form-data" et les autres types de contenu, les questions d'efficacité, etc.

Veuillez consulter l'appendice pour des informations concernant les problèmes de sécurité des formulaires.

Le type de contenu "application/x-www-form-urlencoded" est inefficace pour l'envoi de grandes quantités de données binaires ou de texte contenant des caractères non-ASCII. C'est le type de contenu "multipart/form-data" qui devrait être utilisé pour la soumission de formulaires contenant des fichiers, des données non-ASCII et des données binaires.

Le contenu "multipart/form-data" observe les règles de tous les flux de données MIME en plusieurs parties, comme indiqué dans le document [RFC2045]. La définition du type "multipart/form-data" est disponible dans les registres de l'[IANA].

Un message "multipart/form-data" contient une succession de parties, chacune d'elles représentant une commande réussie. Les parties sont envoyées à l'agent de traitement dans le même ordre selon lequel les commandes correspondantes apparaissent dans le flux du document. Les bornes de ces parties ne devraient pas survenir au milieu des données  cette spécification ne définit pas la façon dont cela est fait.

Comme pour tous les types MIME en plusieurs parties, chaque partie possède en option un en-tête « Content-Type » dont la valeur par défaut est "text/plain". Les agents utilisateurs devraient produire l'en-tête « Content-Type », accompagné d'un paramètre "charset".

Chaque partie est censée contenir :

  1. un en-tête « Content-Disposition » dont la valeur est "form-data" ;
  2. un attribut name spécifiant le nom de commande de la commande correspondante. Les noms de commande, qui sont codés originellement dans des jeux de caractères non-ASCII, peuvent être codé à l'aide de la méthode indiquée dans le document [RFC2045].

Ainsi, par exemple, pour une commande nommée "macommande", la partie correspondante serait spécifiée par :

Content-Disposition: form-data; name="macommande"

Comme pour toutes les transmissions MIME, on utilise les caractères "CR LF" (i.e., "%0D%0A") pour séparer les lignes de données.

Chaque partie peut être codée et l'en-tête « Content-Transfer-Encoding » peut être fourni, si la valeur de cette partie n'est pas conforme à l'encodage par défaut (7BIT) (voir le document [RFC2045], section 6)

Si le contenu d'un fichier est soumis avec un formulaire, l'entrée du fichier devrait être identifiée par le type de contenu adéquat (par exemple, "application/octet-stream"). Si plusieurs fichiers doivent être retournés en résultat d'une seule entrée de formulaire, ils devraient être retournés comme type "multipart/mixed" imbriqué dans le "multipart/form-data".

L'agent utilisateur devrait essayer de fournir un nom de fichier pour chaque fichier soumis. Le nom du fichier peut être spécifié avec le paramètre "filename" dans un en-tête 'Content-Disposition: form-data' ou, au cas où il y aurait plusieurs fichiers, dans un en-tête 'Content-Disposition: file' de la sous-partie. Si le nom de fichier du système d'exploitation du client n'est pas en US-ASCII, le nom de fichier pourrait être approximé ou codé en utilisant la méthode décrite dans le document [RFC2045]. Cela est commode pour les cas où, par exemple, les fichiers téléchargés vers le serveur pourraient contenir des références les uns vers les autres (par exemple, un fichier TeX et sa description de style auxilliaire ".sty").

L'exemple suivant illustre le codage "multipart/form-data". Supposons le formulaire suivant :

 <FORM action="http://server.com/cgi/gestion"
       enctype="multipart/form-data"
       method="post">
   <P>
   Quel est votre nom ? <INPUT type="text" name="nom_soumis"><BR>
   Quels sont les fichiers à envoyer ? <INPUT type="file" name="fichiers"><BR>
   <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
 </FORM>

Si l'utilisateur saisit "Martin" dans la commande de texte et sélectionne le fichier textuel "fichier1.txt", l'agent utilisateur pourrait envoyer en retour les données suivantes :

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="nom_soumis"

   Martin
   --AaB03x
   Content-Disposition: form-data; name="fichiers"; filename="fichier1.txt"
   Content-Type: text/plain

   ... contenu de fichier1.txt ...
   --AaB03x--

Si l'utilisateur avait sélectionné un second fichier (image) "fichier2.gif", l'agent utilisateur pourrait assembler les parties comme suit :

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="nom_soumis"

   Martin
   --AaB03x
   Content-Disposition: form-data; name="fichiers"
   Content-Type: multipart/mixed; boundary=BbC04y

   --BbC04y
   Content-Disposition: file; filename="fichier1.txt"
   Content-Type: text/plain

   ... contenu de fichier1.txt ...

   --BbC04y
   Content-Disposition: file; filename="fichier2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contenu de fichier2.gif...

                        errata-10
   --BbC04y--
   --AaB03x--