Chrome 47 dispose d'une nouvelle fonctionnalité qui vous permet de comprendre plus facilement la façon dont les utilisateurs interagissent avec votre site : InputDeviceCapabilities. Prenons un peu de recul et voyons pourquoi c'est important.
Les événements d'entrée DOM sont une abstraction au-dessus des événements d'entrée de bas niveau, faiblement liés à l'entrée des appareils physiques (par exemple, Les événements click peuvent être déclenchés par une souris, un écran tactile ou un clavier. Toutefois, un problème est survenu: il n'existe pas de méthode simple pour obtenir des informations sur l'appareil physique responsable d'un événement.
En outre, certains types d'entrées peuvent générer d'autres "faux" événements d'entrée DOM pour des raisons de compatibilité. Un tel événement factice de DOM se produit lorsqu'un utilisateur appuie sur un écran tactile (comme sur un téléphone mobile). Il déclenche non seulement des événements tactiles, mais également, pour des raisons de compatibilité, des événements de souris.
Cela cause des problèmes pour les développeurs lorsqu'ils acceptent à la fois la saisie à la souris et la saisie tactile. Il est difficile de savoir si un événement mousedown représente réellement une nouvelle entrée provenant d'une souris ou s'il s'agit simplement d'un événement de compatibilité pour un événement "touchstart" traité précédemment.
La nouvelle API InputDeviceCapabilities fournit des détails sur les sources sous-jacentes des événements d'entrée via un objet sourceCapabilities sur UIEvent.
L'objet possède une propriété firesTouchEvents définie sur true ou false selon la façon dont l'événement a été généré par l'action de l'utilisateur.
La question est donc la suivante: où ces données doivent-elles être utilisées ?
En dehors des événements de pointeur, de nombreux développeurs gèrent aujourd'hui la logique d'interaction au niveau de la couche tactile, ce qui empêche la création par défaut d'éviter de créer de "faux" événements de souris.Cette conception fonctionne bien dans de nombreux scénarios et n'a pas besoin d'être modifiée pour exploiter les InputDeviceCapabilities.
Toutefois, dans certains cas, vous ne voulez pas vraiment empêcher l'événement tactile par défaut ; par exemple, vous souhaitez quand même que les gestes envoient des événements de type "clic" et modifient la mise au point. Dans ce cas, les informations contenues dans la propriété MouseEvent.sourceCapabilities.firesTouchEvents vous permettent de commencer à consolider la logique des événements tactiles et de la souris dans un modèle semblable à la manière dont vous géreriez la logique avec des événements de pointeur. Autrement dit, vous pouvez disposer d'un seul ensemble de code qui gère la logique d'interaction et permet aux développeurs de partager plus facilement la logique entre les navigateurs qui acceptent ou non les événements de pointeur.
function addMouseEventListener(target, type, handler, capture) {
target.addEventListener(type, function(e) {
if (e.sourceCapabilities.firesTouchEvents)
return false;
return handler(e);
}, capture);
}
La bonne nouvelle, c'est qu'elle a été Polyfilled par Rick Byers pour que vous puissiez l'utiliser sur la plupart des plates-formes.
Aujourd'hui, cette API est minimaliste, axée sur la résolution d'un problème spécifique lié à l'identification des événements de souris dérivés des événements tactiles.
Il est même possible d'instancier une instance de InputDeviceCapabilities. Toutefois, elle ne contient que firesTouchEvents. À l'avenir, il est prévu de se développer pour vous permettre d'en savoir plus sur tous les périphériques d'entrée du système d'un utilisateur. N'hésitez pas à nous faire part de vos commentaires sur les cas d'utilisation.