Voici quelques règles d’écriture que j’ai progressivement adoptées pour structurer correctement les formulaires en HTML tout en en simplifiant la mise en forme en CSS. J’obtiens ainsi des formulaires à la fois souples et robustes, qui s’adaptent à toutes les situations.
Structure générale des formulaires
- Chaque formulaire est englobé dans une div portant le sélecteur
générique «
formulaire» (qui permet d’homogénéiser d’un coup tous les formulaires du site) ;- Celui-ci est complété d’un sélecteur par type de formulaire (qui permet de cibler distinctement chaque type de formulaire), par exemple : «
formulaire_abonnement» ; - et d’un identifiant unique, par exemple «
formulaire_abonnement-523» ;
- Celui-ci est complété d’un sélecteur par type de formulaire (qui permet de cibler distinctement chaque type de formulaire), par exemple : «
- Chaque formulaire est subdivisé en blocs logiques grâce aux éléments HTML
<fieldset>et<legend>:- chaque fieldset est lui-même subdivisé en lignes ; c’est une simple liste
<ul><li>(éventuellement une liste ordonnée<ol><li>s’il s’agit d’étapes obligatoires successives) ;- chaque étape de saisie est isolée dans une ligne (
<li>) ; - chaque ligne porte un attribut class désignant l’étape qui lui
correspond : «
editer_surtitre», «date_de_naissance», etc. Ces class sont transversales : elles peuvent être ré-employées à l’identique d’un formulaire à l’autre ; - chaque ligne contient donc (au moins) un champ de saisie et son intitulé ;
- chaque étape de saisie est isolée dans une ligne (
- les boutons sont hors des
fieldset: ils leurs succèdent.
- chaque fieldset est lui-même subdivisé en lignes ; c’est une simple liste
Élément par élément
- Chaque champ de saisie (
textareaet/ouinputet/ouselect) est précédé d’un intitulé explicatif dans une balise<label>; - Chaque label porte un attribut
foridentique aunameet à l’iddu champ auquel il se rapporte ; - Les inputs portent systématiquement des class homonymes au
type:text,submit,checkbox, etc. (afin de palier à la déficience du navigateur Internet Explorer qui ne comprend pas le CSSinput[type=text]).
Exemple :
<label for="nom">Nom</label>
<input type="text" class="text" name="nom" id="nom" value="" />
Cas particuliers des champs obligatoires et des erreurs
- Les champs obligatoires sont explicitement signalés comme tels :
- par un message textuel (et non pas seulement visuel) placé dans le label, dans une balise
<em>; - une class «
obligatoire» est placée sur le<li>pour appliquer, si besoin, une mise en forme visuellement différente ;
- par un message textuel (et non pas seulement visuel) placé dans le label, dans une balise
- Les erreurs sont explicitement signalées :
- une class «
erreur» est alors placée sur le<li>pour signaler visuellement les étapes en erreur ; - chaque erreur bénéficie d’un message explicatif, portant la class «
erreur_message».
- une class «
Exemple :
<li class="saisir_courriel obligatoire">
<label for="courriel">Courriel<em> (Obligatoire)</em></label>
<input type="text" class="text" name="courriel" id="courriel" value="adresse@email.fr" />
</li>
- Structure HTML des formulaires
Exemple de formulaire ainsi structuré
Affichez le code source du fichier ci-joint.
Structure HTML des formulaires
Vos commentaires
# Le 9 mai 2008 à 10:25, par loic m.
Pourquoi encadrer ton formulaire dans un bloc
<div />? On a deja un bloc avec<form />non ?En revanche, l’utilisation des
<li />permet d’eviter l’utilisation de<br />a chaque fin de ligne mais egalement de bien structurer, via CSS, l’ensemble des champs.On voit bien par ton exemple l’interet d’utiliser les fieldset :)
Une bonne source d’inspiration au final. Merci pour ce billet.
# Le 9 mai 2008 à 11:52, par Romy Duhem-Verdière
Le bloc
divpermet d’englober proprement quelques bricoles parfois nécessaires autour d’un formulaire, comme par exemple une ancre, un titre et quelques paragraphes de mode d’emploi.Oui les
lipermettent de coder plus proprement, tout en se gardant suffisamment de liberté de mise en forme. D’expérience, cela me semble finalement plus adapté et plus maniable que despoudiv.# Le 13 mai 2008 à 10:20, par RastaPopoulos
J’adooooore.
Mais pourquoi diable créer des classes compliquées comme "formulaire" PLUS "formulaire_abonnement" PLUS "formulaire_abonnement_245". Car le grand intérêt des classes CSS c’est quand même d’être superposables. Donc pouvoir faire : div.formulaire.abonnement.id253 par exemple.
Ce qui allège considérablement la lisibilité et la maintenance.
Non ?
# Le 13 mai 2008 à 10:52, par Romy Duhem-Verdière
Oui, RastaPopoulos, des class comme les mots d’une phrase, c’est ce que je pratiquais auparavant. C’est très lisible... dans la page HTML.
Par contre, ça n’est plus du tout explicite, dans la feuille de style, parce qu’on n’y ré-écrit pas nécessairement le chemin. On gagne donc en lisibilité à avoir des noms de class qui restent explicites en solo.
# Le 16 mai 2008 à 15:45, par Stéphane Deschamps
De plus, de mémoire je crois qu’IE (6 ?) n’aime pas les noms de classes en cascade et ne prend en compte que la première.
Autrement dit
div.formulaire.abonnement.id253sera comprisdiv.formulaire.(attention, j’ai bien dit "de mémoire")
# Le 25 juin 2008 à 14:53, par marcimat
Effectivement, IE6 ne prend en compte que la dernière classe css, c’est à dire que dans l’exemple
div.formulaire.abonnement.id253, IE6 comprendradiv.id253.MM.
# Le 23 septembre 2008 à 11:20, par 20cent
Bonjour,
Je ne comprends pas trop pourquoi les li sont plus adaptés et maniables que des p ? Tu peux nous en dire plus ?
# Le 20 novembre 2008 à 21:58, par Romy Duhem-Verdière
En réalité, je ne saurais recommander précisément l’un plus que l’autre. Je préfère simplement réserver les
paux contenus textuels et leslime semblent mieux correspondre aux formulaires que j’aborde comme une liste de couples label+champs...Un message, un commentaire ?
Suivre les commentaires :
| 