Google va finalement faire des Pointer Events le type principal d'évènement de Chrome, rejoignant ainsi les rangs de Microsoft et Firefox, et laissant de côté Apple.
Rick Byers, responsable de l'équipement fonctionnalités pour Chrome et Blink, a annoncé l'année dernière que Blink/Chrome n'allait pas implémenter les Pointer Events (PE) malgré l'implication de Google dans le groupe de travail ces dernières années. Byers a mentionné plusieurs raisons à ce choix, dont l'opposition ferme d'Apple qui pourrait nuire à l'adoption, un problème de performance d'environ 2% des frames standard de 16ms, et l'impossibilité de gérer les évènements durant le scroll. Google a même soutenu le polyfill PE qu'ils avaient à la Fondation jQuery.
Mais après avoir reçu de "nombreux retours réguliers de développeurs web, d'auteurs de frameworks et d'autres navigateurs qui voient les Pointer Events comme un ajout important pour la plate-forme”, Byers a récemment annoncé qu'ils allaient remettre les Pointer Events dans Chrome, en commençant par les implémenter derrière une propriété activable. Un bug Chromium a été ouvert et le Dashboard Chromium montre que le travail a commencé sur les PE. Byers a également discuté avec l'équipe PE de Microsoft afin de supporter des changements dans l'API pour résoudre le problème de performance.
Nous avons interviewé Byers pour en savoir plus sur ce choix.
InfoQ : Comment envisagez-vous de faire fonctionner sur un même terminal les deux spécifications d'évènements ? Envisagez-vous de convertir tous les TE en PE comme ce document suggère?
Rick : Si nous soumettons le support des PE, alors les Pointer Events deviendront le type d'évènement principal. Si un pointer event n'est pas intercepté et consommé, alors, on peut envisager de le convertir en touch ou mouse event. Heureusement, nous en avons déjà appris beaucoup grâce aux efforts d'IE pour être davantage compatible avec le web mobile actuel (en supportant les touch events). Je pense que les ingénieurs d'IE ont fait de bons choix de design dans ce cas et nous voulons globablement s'inspirer de leur design dans une spécification pour Chrome (que nous adapterons ensuite lorsque nous plongerons dans les détails de celle-ci).
InfoQ : Jacob Rossi de Microsoft a exprimé son enthousiasme à travailler pour résoudre les bugs relatifs aux PE, mais la spécification PE a atteint le statut de Recommandation finale au W3C, et à ce que j'ai compris, seulement des modifications mineures peuvent maintenant être apportées. Comment comptez-vous gérer cela ?
Rick : Le travail a déjà commencé pour proposer une nouvelle version de la spécification pour intégrer les excellents retours que nous avons reçus. Cela ne fait qu'ajouter un élément (malgré tout important) à la liste des choses à faire pour la prochaine version des Pointer Events. Le plus gros challenge sera de s'assurer que ces changements seront suffisamment compatibles avec le code existant sur le web, mais je suis sûr que nous trouverons un compromis raisonnable entre compatibilité et intégration des demandes intéressantes.
InfoQ : Pouvez-vous expliquer pourquoi le "modèle non capturé par défaut pour les évènements touch pose un problème de performance" ?
Rick : La différence se situe dans quels noeuds du DOM recoivent les évènements "move". En tactile, la cible d'un touch-move est toujours l'élément qui a reçu le touch-start (on parle de "capture implicite"). Avec une souris et (par défaut) pour les pointer events, la cible est toujours l'élément qui est en dessous du curseur. Cela signifie qu'à chaque mouvement, le navigateur doit effectuer un test pour déterminer ce qui se trouve effectivement sous le curseur. Du fait de la complexité des design CSS, ce genre de test est un processus complexe dont les performances sont plus que difficiles à prédire. Lorsqu'il répond à des mouvements tactiles, le navigateur et l'application ont 16ms par évènement pour assurer une expérience fluide à 60fps, et réduire le travail dans cette fenêtre est un de nos travaux principaux en tant que moteur de navigateur. Ce genre de test, même dans des cas simples où l'on ne consomme que 2% de cette fenêtre, est un coût non négligeable, et nous pensons que la plate-forme ne devrait pas faire ce choix à moins que le développeur ne choisisse explicitement de passer en mode "uncaptured".
Une grosse partie du web recherche maintenant un design tactile en priorité car les développeurs ont réalisé combien une bonne expérience tactile est importante pour l'engagement des utilisateurs. Je pense que toute nouvelle API devrait tenir compte de cette nouvelle réalité et être conçue pour prioriser un fonctionnement moderne avec une manipulation directe (captured) des interactions utilisateur.
Google compte implémenter les PE dans Chrome sur toutes les plate-formes supportées, dont Android et les WebView. Les PE sont aussi implémentés dans Spartan/IE 10, Firefox derrière une propriété, jQuery et Dojo. Apple est maintenant le seul navigateur à ne pas avoir choisi cette voie.