Attributs de validation HTML natifs que les développeurs manquent souvent

Vous écrivez du JavaScript personnalisé pour valider des formulaires que HTML pourrait gérer nativement. La plupart des développeurs frontend connaissent required et pattern, mais la plateforme offre bien plus — des attributs qui réduisent le code, améliorent l’accessibilité et créent une meilleure UX sans dépendances de frameworks.

Cet article couvre les attributs de validation HTML que vous négligez probablement, ainsi que les fonctionnalités CSS et JavaScript qui rendent la validation de formulaires native véritablement utile.

L’attribut form : contrôles en dehors des formulaires

Besoin d’un bouton de soumission dans l’en-tête de votre page alors que le formulaire se trouve dans le contenu principal ? L’attribut form permet à n’importe quel contrôle de s’associer à un formulaire par ID, quelle que soit sa position dans le DOM.

<form id="checkout">
  <input type="email" name="email" required>
</form>

<button type="submit" form="checkout">Complete Purchase</button>

Cela élimine les acrobaties d’encapsulation et fonctionne avec les inputs, boutons, selects et textareas.

Surcharges par bouton que vous devriez connaître

Un seul formulaire peut se comporter différemment selon le bouton qui le soumet. Ces attributs surchargent les paramètres du formulaire parent :

• formaction — Soumettre vers une URL différente
• formmethod — Utiliser GET au lieu de POST (ou vice versa)
• formenctype — Changer l’encodage pour les téléchargements de fichiers
• formtarget — Ouvrir la réponse dans un nouvel onglet
• formnovalidate — Ignorer complètement la validation

L’attribut formnovalidate mérite une attention particulière. Il est essentiel pour les boutons « Enregistrer le brouillon » où des données incomplètes sont acceptables.

Validation par motif avec messages d’erreur utiles

L’attribut pattern accepte les regex, mais les navigateurs affichent des erreurs génériques par défaut. Associez-le avec title pour fournir du contexte :

<input type="text" 
       pattern="[A-Z]{2}[0-9]{6}" 
       title="Format: Two letters followed by six digits (e.g., AB123456)">

Note : lorsque multiple est défini sur des inputs comme type="email", le pattern est appliqué à chaque valeur individuelle, et non à la chaîne complète séparée par des virgules.

Tokens modernes d’autocomplete

Au-delà de on et off, autocomplete accepte des tokens sémantiques qui améliorent la précision du remplissage automatique :

• autocomplete="new-password" — Déclenche les générateurs de mots de passe
• autocomplete="one-time-code" — Optimise pour la vérification par SMS
• autocomplete="webauthn" — Signale les champs d’identifiants passkey

Ces tokens réduisent les frictions et signalent l’intention aux navigateurs et gestionnaires de mots de passe (voir la liste complète des tokens dans la spécification HTML et la documentation autocomplete de MDN).

L’attribut dirname pour l’internationalisation

Lors de la prise en charge des langues de droite à gauche, dirname soumet automatiquement la direction du texte avec la valeur :

<input type="text" name="comment" dirname="comment.dir">

Le formulaire soumet à la fois comment (la valeur) et comment.dir (ltr ou rtl). Essentiel pour un rendu approprié du contenu généré par les utilisateurs.

La nuance de readonly

Une idée reçue courante : les champs readonly participent à la soumission du formulaire mais se comportent différemment avec la validation. Ils soumettent des valeurs et peuvent recevoir le focus.

Cependant, les contrôles readonly sont exclus de la validation par contraintes dans le HTML moderne. Cela signifie que les attributs comme required, pattern, min ou max sont ignorés à des fins de validation sur les inputs readonly dans tous les navigateurs modernes actuels.

Si vous devez afficher une valeur sans autoriser les modifications et sans la soumettre, disabled est souvent le meilleur choix — bien que les champs désactivés ne soumettent pas leurs valeurs.

CSS :user-invalid pour une UX de formulaire moderne

La pseudo-classe classique :invalid se déclenche immédiatement, affichant des erreurs avant que les utilisateurs n’interagissent. La plus récente :user-invalid ne correspond qu’après l’interaction de l’utilisateur — résolvant le problème des « bordures rouges au chargement de la page ».

input:user-invalid {
  border-color: #dc3545;
}

input:user-valid {
  border-color: #28a745;
}

Cela crée une meilleure UX sans logique de timing JavaScript. La prise en charge par les navigateurs est maintenant solide sur tous les navigateurs modernes (voir :user-invalid sur MDN).

L’API Constraint Validation

Lorsque la validation native nécessite une augmentation, l’API Constraint Validation offre un contrôle programmatique :

• checkValidity() — Renvoie un booléen, déclenche l’événement invalid en cas d’échec
• reportValidity() — Renvoie un booléen et affiche l’interface d’erreur native
• setCustomValidity() — Définit des messages d’erreur personnalisés

const password = document.querySelector('#password');
const confirm = document.querySelector('#confirm');

confirm.addEventListener('input', () => {
  confirm.setCustomValidity(
    password.value !== confirm.value ? 'Passwords must match' : ''
  );
});

Appelez setCustomValidity('') pour effacer les erreurs — passer une chaîne non vide marque le champ comme invalide.

Quand la validation native atteint ses limites

La validation native gère la plupart des cas, mais a des limites :

• La validation inter-champs (confirmation de mot de passe) nécessite du JavaScript
• Le style des messages d’erreur est contrôlé par le navigateur
• La validation asynchrone complexe (disponibilité du nom d’utilisateur) nécessite du code personnalisé

La stratégie : utilisez les attributs de validation HTML comme base de référence, stylisez avec CSS :user-invalid, et ajoutez l’API Constraint Validation uniquement là où c’est nécessaire.

Conclusion

La validation de formulaires native a considérablement mûri. Les attributs couverts ici — form, surcharges par bouton, dirname, tokens modernes d’autocomplete — éliminent un JavaScript personnalisé substantiel tout en améliorant l’accessibilité par défaut.

Auditez vos formulaires existants. Vous trouverez probablement une logique de validation que HTML gère nativement, et des problèmes d’UX que CSS :user-invalid résout sans un seul écouteur d’événements.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.