Testeur de code touche JavaScript

Qu’est-ce qu’un testeur de code touche ?

Quand vous appuyez sur une touche, le navigateur déclenche un événement keydown qui porte plusieurs propriétés décrivant la même frappe de façons différentes. Un testeur vous montre ce que ces propriétés contiennent réellement, ce qui est le moyen le plus rapide de savoir quoi vérifier dans votre code — et le seul d’en être sûr, car la réponse dépend du navigateur, du système d’exploitation et de la disposition de clavier posée devant vous.

Les trois qui comptent sont key, code et keyCode. Le code nomme la touche physique par sa place sur un clavier américain théorique : la touche voisine du Maj gauche est KeyZ, que la lettre imprimée dessus soit Z, Y ou W. Le key est ce que cette frappe a produit : le caractère lui-même, ou un nom comme ArrowLeft ou Escape quand il n’y a pas de caractère. Et keyCode est un nombre hérité d’une conception bien plus ancienne que les navigateurs continuent d’envoyer.

La démonstration est au-dessus et tient dans une main. Appuyez sur la touche 1 : key vaut « 1 », code vaut Digit1, keyCode vaut 49. Maintenez maintenant Maj et recommencez : code vaut toujours Digit1, keyCode vaut toujours 49, et key est devenu « ! ». Deux caractères différents, une seule touche physique, et un nombre incapable de les séparer.

Comment s’en servir

1. Cliquez dans la zone, puis appuyez sur une touche. La zone n’écoute que lorsqu’elle a le focus : rien n’est capté à votre insu. Tous les champs de l’événement apparaissent aussitôt, et les huit dernières frappes restent en dessous pour comparer deux touches côte à côte.
2. Essayez une paire qui ne diffère que par un modificateur. 1 et Maj+1, ou la touche point-virgule avec et sans Maj. Regardez key changer pendant que code et keyCode ne bougent pas : c’est toute la distinction, visible sur un seul clavier.
3. Cherchez un code dans les tables du dessous. Les deux tables sont celles de la norme. Cherchez par nom ou par numéro ; les codes que la norme range sous deux caractères différents sont signalés, car ce sont précisément ceux que keyCode ne peut pas trancher.

keyCode n’a jamais été une norme, et la norme le dit

On dit couramment que keyCode est déprécié. Ce n’est pas tout à fait ce qui s’est passé, et ce qui s’est passé est plus intéressant. La section 7 de la spécification UI Events, où ces propriétés sont décrites, est marquée non normative et dit d’elles qu’elles « n’ont jamais été formellement spécifiées et que les implémentations actuelles des navigateurs varient de façon significative ». La spécification « ne définit pas normativement » l’une d’entre elles. Elles ne sont écrites que pour que ce que font déjà les navigateurs soit consigné quelque part.

La raison avancée est qu’il est trop tard pour corriger. Formaliser les attributs hérités « risquerait de casser autant de contenu que cela en réparerait ou en permettrait », tant il existe de code qui détecte le navigateur et agit en conséquence. La spécification ajoute que ces attributs « ne conviennent pas à un usage international et ne répondent pas aux préoccupations d’accessibilité », et qu’il faut employer key à la place.

Puis elle fait une chose inhabituelle : elle publie deux tables décrivant ce sur quoi les navigateurs s’accordent, et les sépare selon ce qu’elle accepte d’affirmer. L’une énumère les codes qui « ne changent pas habituellement selon la disposition du clavier sur les systèmes de bureau » — notez « habituellement », qui est le mot de la norme elle-même. L’autre énumère la ponctuation qui « PEUT changer de code selon la disposition », où les navigateurs renvoient le nombre du clavier américain parce que le code ancien l’attend.

La seconde table contient la preuve la plus nette de cette page, et elle ne demande aucune frappe. Onze de ses codes y figurent deux fois : une fois pour le caractère sans Maj, une fois pour le caractère avec Maj. 186 est à la fois le point-virgule et les deux-points. 187 est à la fois le signe égal et le plus. 222 est à la fois l’apostrophe et le guillemet. L’ambiguïté n’est ni un bogue de navigateur ni un cas limite : elle est imprimée dans la norme.

Limites assumées

Cette page ne peut vous dire que ce que votre navigateur, sur votre système, avec votre disposition de clavier actuelle, envoie à cet instant. C’est réellement utile — c’est la machine sur laquelle vous déboguez — mais ce n’est pas une réponse générale. Si vous devez savoir ce qu’un clavier AZERTY français envoie pour une touche physique donnée, aucun testeur tournant sur votre machine ne peut le dire : la valeur de code est justement définie contre une disposition américaine théorique pour ne pas varier, et tout le reste varie.

La zone n’écoute que lorsqu’elle a le focus, et c’est délibéré plutôt qu’une limite. Une page qui capte toutes les frappes quoi qu’il arrive est désagréable et casse les raccourcis du navigateur lui-même. Pour la même raison, la tabulation n’est pas captée sauf demande explicite : appuyer sur Tab est la façon de quitter la zone au clavier, et la piéger en silence laisserait quelqu’un coincé.

Certaines touches ne peuvent pas être captées par une page web, quoi qu’elle fasse. Le navigateur et le système passent en premier : une combinaison affectée à la fermeture d’une fenêtre, au changement d’application ou à l’ouverture d’un menu système n’atteint jamais la page. Aucun testeur ne peut contourner cela, et toute page qui prétend le contraire teste autre chose.

Les touches mortes méritent d’être connues si vous écrivez une langue accentuée. Sur beaucoup de dispositions, une touche d’accent ne produit aucun caractère à elle seule — elle modifie le suivant — et le navigateur rapporte key comme « Dead ». Le testeur les étiquette au lieu d’afficher une valeur vide, car un champ key vide ressemble à un bogue alors que c’est la bonne réponse.

Enfin, les tables présentées ici sont celles de la norme, pas un recensement de tout ce qu’un navigateur peut envoyer. La plupart des codes ne figurent dans aucune des deux, et la page le dit plutôt que d’inventer un statut : la norme ne décrit que les valeurs sur lesquelles elle a constaté un accord.

Pourquoi est-ce gratuit ?

Parce que cela ne coûte rien à faire tourner. Tout se passe dans votre navigateur : les frappes sont lues et affichées localement, rien n’est envoyé nulle part, et il n’y a pas de compte.

Les tables sont extraites de la spécification par un script conservé dans le dépôt, et les tests les ré-extraient puis comparent : un écart entre ce que cette page affiche et ce que la norme imprime casse la compilation au lieu de vous parvenir. La coquille que la norme elle-même comporte dans un nom de touche est conservée exprès, comme preuve que la table a été lue et non recopiée de mémoire.