La gestion des formulaires

Autre grosse tranche du HTML, la gestion des éléments formulaires. N’oublions quand même pas que la base de réflexion du HTML5 s’est appuyée sur Web Forms 2.0, ce qui démontre en partie les besoins de nos pages et des utilisateurs à interagir avec le contenu du web. Par contre, avant d’aller plus loin, il nous faut bien préciser à ce stade que les formulaires à eux seuls, ne gèrent pas l’intégralité du processus. Pour cela, rappelons brièvement le mode opératoire d’un formulaire :

1. Remplissage du formulaire par l’internaute,
2. Pré-validation des données avant l’envoi,
3. Envoi des données par protocole HTTP,
4. Récupération des données côté serveur,
5. Injection des données dans le système d’information.

Au cours de cette approche, nous nous focaliserons uniquement sur la première partie, c’est-à-dire l’aspect HTML qui consiste à mettre en place le formulaire et à le paramétrer. Donc, tout formulaire se situe au sein d’une balise <form> qui peut être découpée par des sous-balises <filedset> regroupant ainsi, de manière structurelle, divers aspects du formulaire. Il est alors possible d’employer des balises <legend> qui vont nommer ces espaces.

<form>
	<fieldset>
		<legend>Informations</legend>
		<!-- / Contenu / -->
	</fieldset>
	<fieldset>
		<legend>Inscription</legend>
		<!-- / Contenu / -->
	</fieldset>
</form>

Les champs de saisie

Quelque soit le type d’éléments de saisie proposé à l’internaute, nous devons employer une paire de balises HTML, une pour l’étiquette d’identification (<label>) et une autre pour le champ de saisie lui-même (parmi <input>, <textarea>, <select>). Il y a deux manières de les lier et en fonction de nos objectifs, l’une s’adaptera mieux que l’autre. Attention, si comme dans le deuxième cas, la relation entre l’attribut for (label) et l’attribut id (champs) n’est pas présente, la relation entre les deux éléments ne sera pas explicite, par exemple pour les lecteurs d’écran :

<label for="ch_nom">Nom : </label>
<input type="text" name="ch_nom" id="ch_nom">
<label>Nom : <input type="text" name="ch_nom"></label>

Il existe donc trois sortes de champs de saisie, <input>, <textarea> et <select>. A eux trois, les possibilités couvrent quasiment l’ensemble des besoins de nos applications web.

Depuis HTML5, le champ de type <input> s’est largement étoffé (voir la référence w3c). Ce type de champ propose un espace de saisie pour l’internaute, et au travers de l’ensemble des attributs disponibles, il est possible d’agir sur divers points, comme l’aspect requis du champ, la possibilité d’auto complète, le code lecture seule, la gestion de la désactivation… Il est possible de consulter toutes les possibilités qu’offrent ce type sur la page de PPK – HTML5 tests – inputs. Si par contre, vous avez besoin d’un espace multi-lignes, alors, il faut employer un champ <textarea> qui est prévu à cet effet.

Deux type de champs <input> ont la particularité de proposer des choix multiples <input type="checkbox" /> ou un choix unique <input type="radio" />. Leur regroupement s’obtient en employant la même valeur pour l’attribut name et en définissant les diverses possibilités de choix par des attributs value de différentes valeurs. Avec les checkbox plusieurs choix seront possibles, alors qu’avec radio chaque nouvelle sélection désélectionnera l’ancienne.

<fieldset>
	<input type="checkbox" name="groupeA" value="Choix 1">
	<input type="checkbox" name="groupeA" value="Choix 2"> 
</fieldset>
<fieldset>
	<input type="radio" name="groupeB" value="Choix 1">
	<input type="radio" name="groupeB" value="Choix 2"> 
</fieldset>

Il existe d’autres manières pour proposer des choix de sélection aux utilisateurs, et bien que toutes donnent l’impression d’être identiques, chacune y va de sa particularité, avantages, inconvénients, à vous de choisir :

• Utiliser une balise classique <select> couplée à une série d’<option> correspondant aux divers choix. L’internaute ne peux faire son choix que parmi cette liste,
• Employer le nouvel attribut list qui pointe vers l’id d’un élément datalist, uniquement valable en html5. Avec cette solution, l’internaute peut ajouter une valeur qui n’est pas présente dans la liste,
• Laisser le navigateur proposer des valeurs préalablement saisie par l’internaute, grâce au nouvel attribut autocomplete lié à HTML5.

<select>
	<option>Choix 1</legend>
	<option>Choix 2</legend>
	<option>Choix 3</legend>
</select>
<input type="text" list="reference" />
<datalist id="reference">
	<option>Choix 1</legend>
	<option>Choix 2</legend>
	<option>Choix 3</legend>
</datalist>
<input type="text" automplete="on" />

Paramétrage et envoi du formulaire

Bien que cette partie soit beaucoup plus liée avec la gestion du formulaire côté serveur, nous allons explorer côté client, les divers préparatifs que nous pouvons mettre en place. Tout va se passer au niveau des principaux attributs de la balise <form>.

• action, cet attribut exprime l’URL à laquelle le formulaire doit être envoyé, généralement cela pointe vers un fichier de type langage serveur (.php, .asp, .cfml, .cgi, .jsp…). Un protocole mailto: indiquant une adresse mail valide peut également être utilisé, mais le formulaire ne joindra pas les fichiers joints (si un champ <input type="file" /> a été employé), et l’ensemble des données name / value seront compilées les unes aux autres.
• method, cet attribut précise la méthode employée par le protocole HTTP pour transmettre les données. GET est employé si les données sont minimes et ne nécessitent pas de protection particulière, sinon on préférera POST qui va joindre les données dans un fichier parallèle,
• enctype, précise le type MIME de soumission des données, trois valeurs,
  • text/plain, dans de rares cas où aucun caractère spécial n’est employé dans le formulaire (espaces, caractères accentués, …),
  • application/x-www-form-urlencoded qui sera utilisée si le formulaire ne contient pas de données binaires (si un champ <input type="file" /> a été employé),
  • multipart/form-data, si des données binaires sont envoyées (présence d’un champ <input type="file" /> dans le formulaire),
• novalidate, si cet attribut est présent, cela spécifie que le formulaire ne doit pas être validé avant l’envoi (par les mécanismes mis en place avec HTML5),
• autocomplete, si cette valeur est placée sur off, les champs du formulaire n’useront pas des possibilités de mémoire de certains champs (nom, adresse, code postal, login…). Attention, si l’attribut est placé sur on, il faut encore que les préférences du navigateur utilisé permettent également ce genre de fonctionnalités.

Il est toujours important de valider les formulaires, et ce pour diverses raisons : d’une part pour s’assurer que les données attendues sont bien complétées, mais aussi pour ne pas devoir entrer de mauvaises données dans le système d’information, ou encore pour permettre à l’internaute de vérifier qu’il n’ait pas fait d’erreur (vérification de mail, …). De ce côté de la validation il existe diverses possibilités qui peuvent être cumulées ;

• Des vérifications avant envoi, en utilisant les nouvelles capacités du HTML5 : pour cela, il faut juste s’assurer que l’attribut novalidate soit absent de la balise <form> et que l’attribut required soit présent pour chaque champ devant être validé. Attention, d’une part le navigateur doit être compatible, et d’autre part, ce type de vérification ne permet pas la comparaison de champs (validation d’e-mail), ni la validation d’un whois (pertinence du mail)… Vous pouvez vérifier ce genre de fonctionnalité sur la page Web Forms 2.0 demo page ou sur ce JSFiddle.
• Toujours dans la série des vérifications avant envoi, il existe une multitude de librairies Javascript qui permettent ce genre de fonctionnalités, (Parsley.js, Validatious 2.0, jQuery Form Validator…). Il est également possible de développer sa propre solution et de contrôler l’envoi depuis la fonction submit().
• L’incontournable vérification côté serveur, avant d’injecter les données reçues dans le système d’information. Beaucoup de développeurs n’emploient pas les vérifications côté client, pour éviter trop de requêtes client / serveur en ce qui concerne la présence de contenu dans certains champs, ou l’homogénéité des données… mais s’assurent, une fois côté serveur, de la pertinence des données et évitent ainsi la corruption de la base de données, ou d’entrer des données non valides.

Le dernier point important en ce qui concerne la préparation HTML des formulaires, va être la présence et la mise en place des boutons de commande. Généralement, deux boutons par défaut peuvent faire affaire, envoi et réinitialisation du formulaire, mais un bouton standard peut piloter un javascript personnel pour gérer cet envoi… c’est au choix et en fonction des besoins :

<form action="fichier.php" method="post" enctype="application/x-www-form-urlencoded">
  <input type="submit" value="Envoyer">
  <input type="reset" value="RàZ">
</form>
<form action="fichier.php" method="post" enctype="application/x-www-form-urlencoded">
  <input type="button" value="Envoyer" onClick="this.form.submit()">
</form>