Types d’input HTML

Que sont les types d’input HTML ?

L’attribut type d’un élément input choisit le genre de contrôle que dessine le navigateur, de la simple zone de texte au sélecteur de date, en passant par une pastille de couleur ou un sélecteur de fichiers. La spécification HTML définit 22 mots-clés, et chacun nomme un état : type=email est l’état Email, type=datetime-local l’état Local Date and Time, et ainsi de suite.

C’est un attribut énuméré, ce qui oblige la spécification à dire ce qui se passe quand la valeur n’est pas reconnue. Elle le dit : la valeur par défaut en cas d’absence et la valeur par défaut en cas d’invalidité de l’attribut sont toutes deux l’état Text. Cette seule phrase est la raison d’être de cette page.

Lisez-la posément et elle couvre deux situations à la fois. Un navigateur qui n’a pas implémenté un type retombe sur un champ texte — et un mot-clé que vous avez simplement mal orthographié aussi. Les deux produisent une zone de texte ordinaire, sans erreur, sans avertissement dans la console et sans rien à l’écran pour les distinguer.

Comment s’en servir

1. Saisissez un mot-clé dans la case pour le vérifier. Elle démarre sur une faute de frappe, car c’est le cas qu’il vaut mieux voir en premier. L’outil indique si la spécification définit le mot-clé et, dans le cas contraire, en quoi il va silencieusement se transformer.
2. Lisez le tableau. Les 22 mots-clés avec le nom d’état que la spécification donne à chacun, regroupés par genre de contrôle. La liste est complète, ce n’est pas une sélection.
3. Regardez la dernière colonne. Elle est mesurée dans le navigateur avec lequel vous lisez, pas recopiée d’un tableau de compatibilité. Elle demande chaque type à un élément input et relit ce qu’il déclare être.

Pourquoi un tableau de compatibilité est la mauvaise forme pour cette question

La plupart des pages qui répondent à quels navigateurs prennent en charge type=date vous servent une grille de versions. Cette grille est périmée le jour de sa publication, elle ne peut pas savoir quel navigateur vous utilisez, et encore moins celui de vos visiteurs. Elle répond à une question sur le monde alors que vous vouliez une réponse sur votre machine.

La règle de repli rend possible une meilleure réponse. Puisqu’un type non pris en charge se résout en état Text, on peut interroger directement un élément : affectez la propriété, relisez-la, et si elle revient en text, le navigateur ne l’a pas acceptée. Trois lignes, sans bibliothèque, sans reniflage de version, et la réponse décrit le navigateur qui exécute réellement le code.

C’est ce que fait ici la dernière colonne, et c’est pourquoi elle affiche vérification de votre navigateur tant que la page n’est pas chargée plutôt que de dessiner une supposition côté serveur. Le serveur n’a aucune idée de ce que vous utilisez ; prétendre le contraire serait exactement l’erreur de la grille.

Une ligne échappe à la vérification, et le tableau le dit au lieu de le cacher. Demander text renvoie text, que le reste soit pris en charge ou non : cette ligne est donc marquée par définition. Toutes les autres sont de vraies mesures.

La faute de frappe que vous ne verrez jamais

Des deux cas que couvre la règle de repli, la faute de frappe est celle qui fait le plus mal, car elle est entièrement de votre fait et ressemble exactement à une réussite. Écrivez type=dat au lieu de type=date et vous obtenez un champ texte. Écrivez type=nubmer et vous obtenez un champ texte. Écrivez type=datetime, qui fut un vrai mot-clé avant d’être retiré du standard, et vous obtenez un champ texte.

Rien ne proteste. La page s’affiche, le formulaire s’envoie, le champ accepte la saisie. Ce que vous perdez, c’est tout ce que le bon mot-clé aurait apporté : le sélecteur de date, le clavier numérique sur téléphone, la validation intégrée, la contrainte qui empêcherait l’envoi d’une valeur absurde. Sur un navigateur de bureau et en plein développement, un champ texte à la place d’un sélecteur de date passe inaperçu des semaines durant.

C’est à cela que sert la case en haut de page. Collez-y ce que vous avez réellement écrit, et elle vous dit si la spécification en a jamais entendu parler. C’est une petite vérification, et c’est la seule disponible, car par conception le navigateur ne vous dira rien.

Limites assumées

La prise en charge n’est pas une seule question. Un navigateur peut accepter un type, en dessiner un contrôle et se comporter malgré tout différemment d’un autre qui l’accepte aussi : l’allure du sélecteur de date, le respect ou non d’un attribut step, la façon dont une valeur est présentée à l’utilisateur. Cette page ne répond qu’à la première question, celle de savoir si le navigateur a accepté le type. C’est celle que la règle de repli rend vérifiable, et ce n’est pas toute l’histoire.

Le tableau ne peut rien vous dire non plus d’un navigateur autre que le vôtre. S’il vous faut savoir ce que reçoivent vos visiteurs, la mesure doit se faire dans leurs navigateurs, ce qui est un autre travail que celui d’une page comme celle-ci.

Deux colonnes du tableau de la spécification manquent ici, volontairement. Elle donne aussi un type de donnée et un type de contrôle pour chaque mot-clé, et leur extraction a décalé les colonnes sur au moins une ligne : l’entrée file est ressortie en décrivant un type MIME là où va le type de contrôle. Publier un tableau qui a l’air juste sans l’être vaut moins qu’en publier un plus court qui l’est ; seuls le mot-clé et le nom d’état figurent donc ici.

Enfin, la spécification évolue. Des mots-clés ont été ajoutés au fil des ans et au moins un a été retiré : une liste est donc un instantané du standard tel qu’il est. La règle de repli, elle, n’a pas bougé, et c’est elle qu’il faut retenir.

Pourquoi est-ce gratuit ?

La liste est statique et la vérification s’exécute dans votre navigateur. Aucun serveur n’intervient : rien à facturer, aucun compte à créer.

Rien n’est envoyé et rien n’est conservé. Rechargez la page et elle aura oublié ce que vous avez saisi.