Validation native des formulaires HTML : required, pattern, type et la Constraint Validation API

Ce que c'est

HTML vérifie les contrôles de formulaire avant la soumission d'un formulaire, sans aucun script. required, minlength et maxlength, min, max et step, pattern, et les types d'entrée email, url, number et date déclarent chacun une contrainte. Lorsqu'un contrôle en viole une, le navigateur refuse de soumettre et affiche son propre message au niveau du premier contrôle invalide. Le guide MDN décrit le côté CSS : un contrôle invalide correspond à :invalid, et, une fois que l'utilisateur a interagi avec lui, également à :user-invalid. La Constraint Validation API (checkValidity(), reportValidity(), setCustomValidity(), l'objet validity) expose le même état aux scripts ; novalidate sur le formulaire désactive les bulles du navigateur mais laisse l'API fonctionner.

Pourquoi c'est important

La validation native fonctionne avant même que le JavaScript soit arrivé, se soit exécuté ou ait échoué ; ses messages apparaissent dans la langue propre du navigateur sans aucun travail de traduction ; et les contraintes existent en un seul endroit, dans le balisage, où scripts, tests et robots d'indexation peuvent les lire. Ce n'est pas une mesure de sécurité : le guide MDN précise explicitement que le serveur doit malgré tout valider chaque soumission.

Comment l'appliquer

• Choisir d'abord le type : email, url et number apportent leur propre contrainte et leur propre clavier. Utiliser inputmode pour du texte libre qui n'a besoin que d'un clavier numérique.
• Ajouter required, minlength, min/max et pattern pour les règles de format. Le motif est compilé comme une expression régulière JavaScript et doit correspondre à la valeur entière. Décrire le format attendu dans un texte visible et dans un attribut title ; la page citée note que les navigateurs peuvent utiliser le title dans le message de validation.
• Styliser :user-invalid plutôt que :invalid, afin que les champs requis vides ne soient pas marqués en rouge avant que l'utilisateur les ait touchés.
• Utiliser setCustomValidity() pour les règles inter-champs telles que la confirmation de mot de passe, et la réinitialiser avec une chaîne vide, sinon le contrôle reste invalide.
• Si un rendu propre de la liste d'erreurs est fait sous novalidate, appeler malgré tout reportValidity() afin que les utilisateurs au clavier ou avec un lecteur d'écran soient amenés à la première erreur.
• Tester le chemin serveur en soumettant avec novalidate ou avec curl ; les vérifications du navigateur sont une facilité, pas un contrat.

Pièges

Les bulles d'erreur natives ne peuvent pas être stylisées, disparaissent quand le focus change, et n'affichent qu'une erreur à la fois. Un pattern sur type="email" se combine avec la vérification intégrée, donc les deux doivent réussir. Les contrôles désactivés ne sont jamais validés. Un contrôle requis masqué avec display: none bloque quand même la soumission, mais le navigateur n'a nulle part où afficher le message, ce qui est souvent signalé comme un bug où « le formulaire ne fait rien ». Les entrées de type date et nombre affichent des widgets dépendants de la locale, difficiles à restyliser.