Dans quels cas un clic n'est-il pas une click ? Pour un développeur Web travaillant sur une interface utilisateur
complexe, il ne s'agit pas d'une question philosophique abstraite. Si vous implémentez un comportement d'entrée personnalisé à la souris, il est essentiel de garder à l'esprit l'intention de l'utilisateur. Par exemple, si un utilisateur clique sur un lien avec le bouton central de sa souris, il est raisonnable de supposer qu'il souhaite ouvrir un nouvel onglet avec le contenu de ce lien. Si un utilisateur clique au milieu sur un élément d'interface utilisateur aléatoire, vous pouvez supposer qu'il s'agit d'une erreur et ignorer cette entrée, tandis qu'un clic principal sur le bouton devrait déclencher une réponse de l'interface utilisateur.
Il est possible, bien que fastidieux, de modéliser ces interactions nuancées via un seul écouteur d'événements click. Vous devez vérifier explicitement la propriété button de l'élément MouseEvent pour voir s'il a été défini sur 0, qui représente le bouton principal, en comparaison avec tout autre élément (1 représente généralement le bouton du milieu, etc.). Toutefois, peu de développeurs vont jusqu'à vérifier explicitement la propriété button, ce qui conduit à du code qui gère tous les click de manière identique, quel que soit le bouton enfoncé.
À partir de Chrome 55, un nouveau type de MouseEvent, appelé auxclick, est déclenché en réponse à tous les clics effectués avec un bouton non principal. Ce nouvel événement est accompagné d'un changement de comportement de l'événement click: il ne se déclenche que lorsque l'utilisateur appuie sur le bouton principal de la souris. Nous espérons que ces modifications permettront aux développeurs Web d'écrire plus facilement des gestionnaires d'événements qui ne répondent qu'au type de clics qui les intéresse, sans avoir à vérifier spécifiquement la propriété MouseEvent.button.
Réduit les faux positifs
Comme indiqué précédemment, la création de auxclick était motivée par le fait d'éviter le déploiement de gestionnaires click personnalisés qui ignorent à tort le comportement "middle-click-opens-a-tab". Par exemple, imaginez que vous avez écrit un gestionnaire d'événements click qui utilise l'API History pour réécrire la barre d'emplacement et que vous avez implémenté des navigations personnalisées sur une seule page. Cela peut ressembler à ceci:
document.querySelector('#my-link').addEventListener('click', event => {
event.preventDefault();
// ...call history.pushState(), use client-side rendering, etc....
});
Votre logique personnalisée peut fonctionner comme prévu lorsqu'elle est déclenchée par le bouton principal d'une souris, mais si ce code s'exécute lorsqu'un utilisateur clique sur le bouton du milieu, il s'agit d'un faux positif. Avant le nouveau comportement, vous finissiez par empêcher l'action par défaut consistant à ouvrir un nouvel onglet, ce qui va à l'encontre des attentes de vos utilisateurs.
Bien que vous puissiez vérifier explicitement la présence de event.button === 0 au début de votre gestionnaire et n'exécuter le code que si c'est le cas, il est facile de l'oublier ou de ne jamais vous rendre compte que c'est nécessaire.
Exécutez uniquement le code dont vous avez besoin
L'inconvénient de la diminution du nombre de faux positifs est que les rappels auxclick ne s'exécutent que lorsqu'un utilisateur clique sur un bouton de souris non principal. Si votre code doit, par exemple, calculer une URL de destination appropriée avant d'ouvrir un nouvel onglet, vous pouvez écouter auxclick et inclure cette logique dans votre rappel. Il n'entraîne pas de surcharge d'exécution lorsque l'utilisateur clique sur le bouton principal de la souris.
Prise en charge et compatibilité des navigateurs
Ce nouveau comportement n'est actuellement implémenté que dans Chrome 55. Comme indiqué dans la proposition initiale, les commentaires (positifs et négatifs) de la communauté des développeurs Web sont appréciés. Signaler un problème GitHub est le meilleur moyen de partager vos commentaires avec les personnes qui travaillent sur le processus de standardisation.
En attendant, les développeurs n'ont pas besoin d'attendre que auxclick soit largement disponible pour suivre certaines bonnes pratiques concernant la gestion des événements de souris. Si vous prenez le temps de vérifier la valeur de la propriété MouseEvent.button au démarrage de votre gestionnaire d'événements click, assurez-vous de prendre les mesures appropriées. Le modèle suivant gère les clics principaux et auxiliaires différemment, qu'il existe ou non une compatibilité native avec auxclick:
function handlePrimaryClick(event) {
// ...code to handle the primary button click...
}
function handleAuxClick(event) {
// ...code to handle the auxiliary button click….
}
document.querySelector('#my-link').addEventListener('click', event => {
if (event.button === 0) {
return handlePrimaryClick(event);
}
// This provides fallback behavior in browsers without auxclick.
return handleAuxClick(event);
});
// Explicitly listen for auxclick in browsers that support it.
document.querySelector('#my-link').addEventListener('auxclick', handleAuxClick);