Les formulaires

Tout ceux qui ont eu l’occasion de développer des HIM sur des application dites lourdes seront d’accord sur le fait que les formulaires HTML sont plus que simplistes. Étant donné que c’est une partie fondamentale pour les interactions avec l’utilisateur, il fallait que cela évolue. En fait, le brouillons de HTML 5 ne parle pas encore des formulaires. Tout ce qui est indiqué, c’est que cette partie sera une re-transcription du brouillon sur les « Web Forms 2.0 ». Celui-ci apporte un lot de nouveautés assez intéressantes. Nous allons en voir quelques unes (il faudrait un dossier entier rien que pour présenter les nouveautés des Web Forms).

Typage du champ input

Actuellement, il n’est pas possible de contrôler nativement le contenu d’un champ input du coté client. En effet, nous ne pouvons pas spécifier ce que l’on demande à l’utilisateur de rentrer comme données. Les Web Forms 2.0 permettent de régler ce problème en modifiant un peu le champ type de l’élément input. Celui-ci pourra prendre les valeurs suivantes: datetime, datetime-local, date, month, week, time, number, range, email et url.

Pour les input de type numérique (et date / heure), des champs min et max pourront être ajoutés pour borner les valeurs acceptables. Il sera aussi possible de faire des input incrémentaux (toujours pour les numériques et dates). Il suffira de préciser le pas avec le champ step. Typiquement, l’incrémentation et la décrémentation pourront se faire via deux flèches sur le coté du contrôle, un concept bien connu dans les application lourdes.

Pour finir, il sera possible de créer ses propres types pour mieux coller aux besoins. L’expression du typage sera basée sur des expressions régulières (défini dans ECMA-262: « ECMAScript Language Specification »). Cela se passe via l’attribut pattern. Par exemple, on demande à l’utilisateur de rentrer son INE (Identifiant National Étudiant). Celui-ci est composé de 9 chiffres et d’une lettre à la fin. Voilà comment contrôle cela avec pattern:

<input type="text" pattern="[0-9]{9}[a-Z]" name="ine" />

Suggestion de valeurs: les datalists

L’élément input se voit ajouter un nouvel attribut: list. Celui-ci permet de spécifier une liste d’éléments prédéfinis pour faire des suggestions à l’utilisateur. Pour comprendre un peu quelle forme cela peut prendre, faites une recherche sur Google. Quand vous entrez vos mots clefs dans le champ texte, vous navigateur vous propose un historique de vos recherches passée. Et bien là, ce serait pareil, sauf que c’est l’auteur du document qui indiquera les valeurs à suggérer.

Les données proposées en elle-mêmes ne se trouvent pas dans l’attribut list. En effet, celui-ci ne contient que le nom d’un datalist. C’est cet élément qui contiendra les données en elles-même. Concrètement, voilà ce que cela pourrait donner:

<input type="text" name="monnaie" list="monnaies">
<datalist id="monnaies">
	<option label="Dollar US" value="USD">
	<option label="Dollar Canadien" value="CASD">
	<option label="Euro" value="EUR">
	<option label="Franc CFA" value="FCFA">
</datalist>

Uploads multiples

L’upload de fichiers par le biais de formulaires devient vite fastidieux quand on a un grand nombre de fichiers à uploader. Souvent les auteurs de documents HTML mettent plusieurs champs input de type file pour faire gagner un peu de temps à l’utilisateur. On peut aussi créer dynamiquement des champs en fonction des besoins de l’utilisateur. Mais tout ceci est loin d’être idéal …

Avec HTML 5, il est possible d’uploader plusieurs fichiers par le même contrôle input ! Les attributs min et max permettent de spécifier les bornes entres lesquelles le nombre de fichiers uploadés par le contrôle doit se trouver. Par défaut, chaque champ a un min à 0 et un max à 1. Exemple d’utilisation (ici on accepte entre 5 et 15 images):

<input type="file" accept="image/*" min="5" max="10" />

L’élément output

L’élément output est un contrôle qui n’est pas modifiable par l’utilisateur. Le but est d’afficher des données qui proviennent du formulaire courant sans avoir à le soumettre au serveur. On pourrait s’en servir, par exemple, sur un formulaire de commande. On a la liste des produits, leurs prix et l’utilisateur peut modifier les quantités. L’élément output servirait à afficher dynamiquement le prix global de la commande.

Nouvelles méthodes de soumission

HTML 5 apporte une flexibilité plus qu’agréable dans la soumission des formulaires au serveur. Actuellement, on ne connaît qu’un seul type de soumission: on envoyait toutes les données sous la forme ?var1=value&var2=value au serveur (en POST ou en GET). Ensuite, on chargeait la page que le serveur nous renvoyait. C’est en total décalage avec la tendance actuelle qui est à l’AJAX …

La première chose qui change, c’est les façons dont les données peuvent être présentées au formulaire. Cela dépend de la valeur de l’attribut enctype du form en question. On distingue 4 valeurs possibles:

• application/x-www-form-urlencoded: c’est la méthode traditionnelle (utilisée en HTML4).

• multipart/form-data: la méthode actuellement utilisée quand on a des fichiers joints au formulaire (entre autre).

• text/plain: les données sont envoyées en texte brut sous la forme suivante:

  var1=value
  var2=value
  var3=value

• application/x-www-form+xml: là, les données sont envoyées sous la forme d’un document XML:

  ^?View Code XML

  <formdata xmlns="http://n.whatwg.org/formdata"> <field name="var1" index="0">value</field> <field name="var2" index="0">value</field> <field name="var3" index="1">value</field> </formdata>

Autre nouveauté intéressante, c’est la possibilité de spécifier ce que l’on fera des données renvoyées par le serveur en réponse à la soumission du formulaire. Il existe deux modes de fonctionnement. On choisit l’un ou l’autre par la valeur de l’attribut replace de l’élément form. Voici ceux deux valeurs:

• document: C’est la valeur par défaut. Elle correspond au comportement que l’on connaît actuellement. Quand on reçoit la réponse du serveur, on recharge totalement la page.

• values: Ce fonctionnement ne recharge que la valeur des éléments du formulaire (en fonction de ce que le serveur renvoie). On ne perd plus de temps à recharger toute la page.

Nouveautés CSS et DOM

Bien évidement, l’apparition de nouveaux éléments et le perfectionnement des éléments existant engendre des nouveautés du coté de CSS et DOM. Pour CSS, il s’agit de nouvelles pseudos-classes. Elles permettent de gérer le style d’un élément en fonction de son état (activé, par défaut, valide, invalide, …). Voici la liste des nouveaux sélecteurs: :checked, :default, :disabled, :enabled, :indeterminate, :valid, :invalid, :in-range, ut-of-range, :required, ptional, :read-only et :read-write.

Du coté de chez DOM, il s’agit principalement de nouveaux événements [1. Si vous n'arrivez pas à replacer le contexte d'événement DOM, voici un exemple: quand l'événement submit d'un formulaire se déclenche, il va exécuter le code qui se trouve dans l'attribut onsubmit ...]. Ceux-ci permettent, quand il se déclenchent, de lancer un code javascript. Voici les nouveautés:

• input est un événement qui fait penser à l’actuel change. Seulement il est déclenché à chaque nouvelle touche pressée. On est donc plus précis.

• formchange et forminput sont identiques à change et input. La différence, c’est qu’ils se déclenchent dans tout le formulaire quand un champ de ce dernier est modifié.

• invalid est déclenché dès que la valeur d’un champ est invalide (c’est à dire qu’il ne respecte pas son type ou son pattern).

• received permet de détecter que l’envoi des données du formulaire au serveur est bien terminé. A ne pas confondre avec submit qui indique que le formulaire vient de commencer d'être envoyé !