Chrome 47 propose une nouvelle fonctionnalité qui permet de mieux comprendre comment les utilisateurs interagissent avec votre site : InputDeviceCapabilities. Reprenons un peu en arrière 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, liés de manière lâche à l'entrée de l'appareil physique (par exemple, Les événements click peuvent être déclenchés par une souris, un écran tactile ou un clavier. Cependant, il existe un problème: il n'existe pas de méthode simple pour obtenir les détails de l'appareil physique responsable d'un événement.
De plus, certains types d'entrées peuvent générer d'autres événements d'entrée DOM "factices" pour des raisons de compatibilité. Un tel événement DOM factice se produit lorsqu'un utilisateur appuie sur un écran tactile (par exemple, sur un téléphone mobile). Il ne déclenche pas seulement des événements tactiles, mais également des événements de souris pour des raisons de compatibilité.
Cela pose problème aux développeurs lorsqu'ils prennent en charge à la fois la saisie au clavier 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 ne s'agit que d'un événement de compatibilité pour un événement touchstart précédemment traité.
La nouvelle API InputDeviceCapabilities fournit des informations sur les sources sous-jacentes des événements d'entrée via un objet sourceCapabilities sur l'UIEvent.
L'objet possède une propriété firesTouchEvents définie sur true ou false en fonction de la façon dont l'événement a été généré par l'action de l'utilisateur.
La question est: où utiliser cette fonctionnalité ?
En dehors des événements de pointeur, de nombreux développeurs gèrent aujourd'hui la logique d'interaction dans la couche tactile, ce qui empêche Default de créer des événements de souris "factices" en premier lieu.Cette conception fonctionne bien dans de nombreux scénarios et n'a pas besoin d'être modifiée pour tirer parti de InputDeviceCapabilities.
Toutefois, dans certains cas, vous ne souhaitez pas vraiment empêcher l'événement tactile. Par exemple, vous souhaitez toujours que les pressions envoient des événements de "clic" et changent le focus. Dans ces cas, les informations contenues dans la propriété MouseEvent.sourceCapabilities.firesTouchEvents vous permettent de commencer à consolider la logique des événements tactiles et basés sur la souris dans un modèle similaire à celui que vous utiliseriez pour gérer la logique avec les événements de pointeur. Autrement dit, vous pouvez avoir un seul ensemble de code qui gère la logique d'interaction et offre aux développeurs un moyen plus simple de partager la logique entre les navigateurs compatibles et non compatibles avec 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 est que Rick Byers a comblé cette fonctionnalité afin que vous puissiez l'utiliser sur la plupart des plates-formes.
Aujourd'hui, cette API est minimale et vise à résoudre 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, cette fonctionnalité devrait s'étendre 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.