Quand un clic n'est-il pas un click ? Pour un développeur Web travaillant sur une interface utilisateur complexe, ce n'est pas une question philosophique abstraite. Si vous implémentez un comportement de saisie de la souris personnalisé, il est essentiel de garder à l'esprit l'intention de l'utilisateur. Par exemple, si un utilisateur clique sur un lien avec le bouton du milieu de la souris, il est raisonnable de supposer qu'il voulait ouvrir un nouvel onglet avec le contenu de ce lien. Si un utilisateur clique avec le bouton central sur un élément d'interface utilisateur aléatoire, vous pouvez supposer qu'il s'agit d'un clic accidentel et ignorer cette entrée, tandis qu'un clic sur un bouton principal devrait déclencher une réponse de l'UI.
Il est possible, bien que cela soit un peu lourd, 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 MouseEvent pour voir si elle a été définie sur 0, qui représente le bouton principal, ou sur toute autre valeur, 1 représentant généralement le bouton du milieu, etc. Cependant, peu de développeurs vont jusqu'à vérifier explicitement la propriété button, ce qui entraîne un 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 s'accompagne d'un changement de comportement correspondant de l'événement click: il ne se déclenche que lorsque le bouton principal de la souris est enfoncé. 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éressent, sans avoir à vérifier spécifiquement la propriété MouseEvent.button.
Réduit les faux positifs
Comme indiqué, la création de auxclick visait à éviter le déploiement de gestionnaires click personnalisés qui remplacent par erreur le comportement "clic du milieu de la souris ouvre un onglet". Par exemple, imaginez que vous avez écrit un gestionnaire d'événements click qui utilise l'API History pour réécrire la barre d'adresse et implémenter des navigations monopages personnalisées. Il peut se présenter comme suit:
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 de la souris, mais si ce code s'exécute lorsqu'un bouton central est cliqué, il s'agit d'un faux positif. Avant le nouveau comportement, vous empêchiez l'action par défaut d'ouvrir un nouvel onglet, ce qui allait à l'encontre des attentes de vos utilisateurs.
Bien que vous puissiez vérifier explicitement event.button === 0 au début de votre gestionnaire et n'exécuter le code que dans ce cas, il est facile de l'oublier ou de ne jamais réaliser qu'il est nécessaire de le faire.
Exécuter uniquement le code dont vous avez besoin
L'inconvénient de la réduction du nombre de faux positifs est que les rappels auxclick ne s'exécutent que lorsqu'un bouton de la souris autre que le principal est cliqué. Si vous avez un code qui 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 les frais généraux d'exécution lorsqu'un utilisateur clique sur le bouton principal de la souris.
Compatibilité et prise en charge 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 les bienvenus. Le meilleur moyen de partager ces commentaires avec les personnes qui travaillent sur le processus de normalisation est de signaler un problème sur GitHub.
En attendant, les développeurs n'ont pas besoin d'attendre que auxclick soit largement disponible pour suivre certaines bonnes pratiques de gestion des événements de souris. Si vous prenez le temps de vérifier la valeur de la propriété MouseEvent.button au début de votre gestionnaire d'événements click, vous pouvez vous assurer de prendre les mesures appropriées. Le modèle suivant gère les clics principaux et auxiliaires différemment, que auxclick soit compatible en mode natif ou non:
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);