J'ai scanné les réponses ci-dessus et l' approche proposée keydown/ keyupne fonctionne que dans des circonstances spéciales. Si l'utilisateur s'éloigne ou utilise un geste de touche pour ouvrir une nouvelle fenêtre ou un nouvel onglet de navigateur, alors un keydownsera enregistré, ce qui est bien, car à ce stade, il est impossible de dire si la clé est quelque chose que l'application Web surveille , ou est un navigateur standard ou un raccourci du système d'exploitation. En revenant à la page du navigateur, il pensera toujours que la clé est maintenue, bien qu'elle ait été publiée entre-temps. Ou une touche est simplement maintenue enfoncée, pendant que l'utilisateur passe à un autre onglet ou application avec la souris, puis relâchée en dehors de notre page.
Les touches de modification ( Shiftetc.) peuvent être surveillées via mousemoveetc. en supposant qu'au moins une interaction de la souris est attendue lors de la tabulation, ce qui est souvent le cas.
Pour la plupart toutes les autres touches ( à l' exception des modificateurs, Tab, Deletemais y compris Space, Enter), le suivi keypresstravaillerait pour la plupart des applications - une clé maintenue enfoncée continuera à feu. Il y a cependant une certaine latence dans la réinitialisation de la clé, en raison de la périodicité du keypressdéclenchement. Fondamentalement, si le keypresstir ne continue pas, il est possible d'exclure la plupart des clés. Ceci, combiné avec les modificateurs, est assez hermétique, même si je n'ai pas exploré quoi faire avec Tabet Backspace.
Je suis sûr qu'il existe une bibliothèque qui résume cette faiblesse du DOM, ou peut-être qu'une modification de la norme DOM l'a corrigée, car c'est une question plutôt ancienne.