Permettre au web de « simplement fonctionner » via tout type de saisie : souris, interactions tactiles et événements de pointeur

Nous avons récemment annoncé la prise en charge de l'API d'interaction tactile dans Internet Explorer, pour une mise à jour Windows Phone 8.1, dans le cadre de notre engagement à permettre au web de « simplement fonctionner » pour nos utilisateurs. Cela signifie qu'Internet Explorer prend en charge trois API principales de saisie par pointage : les événements de souris, tactiles et de pointeur. Certes, l'expérience de l'utilisateur en matière de navigation mobile est optimisée. Cependant, les développeurs finissent par se demander quelle API utiliser.

Pour les aider à savoir quelle API appliquer et quand, nous avons décidé de proposer quelques nouveaux conseils et suggestions éclairées concernant l'évolution des plateformes web, si l'on considère que les événements de pointeur seront bientôt pris en charge dans Firefox, Google ayant pour sa part choisi de ne pas implémenter cette spécification.

Modèles : comparaison et différences

Nous voulons que les développeurs utilisent la technologie de saisie qui leur correspond. Ainsi, nous proposons des événements tactiles interopérables pour un public aussi étendu que possible, sur la plupart des navigateurs actuels, ainsi que des événements de pointeur dernier cri pour les modèles de codage plus simples, des fonctions supplémentaires, une meilleure prise en charge des périphériques, une conception plus simple et plus réactive et une meilleure accélération matérielle. Voici un descriptif des avantages et fonctions de chaque modèle.

1 Sur certains navigateurs Android, des événements tactiles peuvent se produire en cas de saisie à la souris. Cependant, cette saisie ne peut pas être distinguée d'une interaction tactile lors du recours à des événements tactiles.

2 Tous les navigateurs déclenchent certains événements de souris en cas de saisie tactile unique, afin de conserver la compatibilité avec les pages Web prévues pour la souris. Toutefois, il n'est pas possible, actuellement, de faire la distinction entre une saisie tactile et une saisie de souris lors de l'utilisation d'événements tactiles. De même, la saisie d'un geste via la fonction Kinect pour Xbox, sur Internet Explorer, déclenche également certains événements de souris, afin que la compatibilité de base soit maintenue.

3 Les événements de pointeur sont actuellement candidats à la recommandation et feront bientôt l'objet d'une recommandation. Les événements tactiles font d'ores et déjà l'objet d'une recommandation. En 2012, le groupe de travail Web Events Working Group a décidé de mettre un terme à la rédaction de la version 2 de sa spécification sur les événements tactiles et de fermer ce groupe de travail, afin de consacrer ses efforts à la normalisation des événements de pointeur.

4 La prise en charge complète des événements de pointeur est proposée dans Internet Explorer. Elle sera bientôt possible dans Mozilla Firefox. Actuellement, les navigateurs Google Chrome, Mozilla Firefox et Opera les prennent partiellement en charge (API touch-action). Une prise en charge partielle est également envisagée par WebKit pour Safari. Grâce à des « polyfills » comme les événements de pointeur Google Polymer et Hand.JS, le modèle d'événement de pointeur peut être utilisé sur différents navigateurs.

Consultez cet article de HTML5 Rocks, qui fournit des informations plus détaillées sur ces différences et ces problèmes.

Performances

En matière de saisie, tout particulièrement de saisie tactile, les performances jouent un rôle critique. En réalité, vous ne faites que passer vos doigts sur une plaque de verre, mais nous voulons que vous ayez l'impression de déplacer une page web. C'est pour cette raison que nous avons investi 3 années d'efforts afin de reconcevoir le pipeline d'interactions tactiles, de façon qu'il inclue quatre threads et soit accéléré par la carte graphique (pour Internet Explorer 10, puis Internet Explorer 11, avec des améliorations). Par ailleurs, nous avons conçu les événements de pointeur de façon à tirer parti des architectures ayant fait leur apparition dans d'autres architectures récentes.

Les fonctions de zoom et de panoramique font partie des interactions tactiles les plus importantes, car elles représentent plus de 60 % de l'ensemble des mouvements tactiles sur Internet Explorer et Chrome pour Windows. En effet, presque tous les sites et applications natives ou web utilisent ces fonctions. Ce type de mouvement est très révélateur quand on se penche sur les performances de saisie. La fonction de panoramique peut s'avérer lente (ne suivant le tracé de vos doigts qu'après un moment) ou hachée (certains cadres étant ignorés). Dans ce cas-là, vous vous rappelez qu'il ne s'agit que d'une plaque de verre.

Les événements tactiles nécessitent l'exécution d'une commande JavaScript synchrone avant le début d'une action de panoramique ou de zoom, ce qui peut engendrer un ralentissement important des performances, de l'ordre de plusieurs centaines de millisecondes, voire plus. Pour cette raison, le choix des événements de pointeur peut permettre d'améliorer nettement l'expérience tactile de l'utilisateur :

Démo illustrant l'impact des performances d'une action de zoom ou de panoramique suite à un événement tactile (sur un téléphone Android LG Nexus 5 et sur un Windows Phone HTC 8x)
Les événements de pointeur permettent d'obtenir des actions tactiles asynchrones et à accélération matérielle, ce qui se traduit souvent par une optimisation des performances.

Dans cet exemple de page de test de base (configurée pour un retard de 1 000 ms), qui a été développée par Rick Byers au sein de l'équipe Chrome, nous pouvons voir que, lors d'un événement tactile dans Internet Explorer, le rendu du premier cadre du panoramique n'est effectué que lorsque le contact tactile est déplacé pendant 1 020 millisecondes et parcourt une distance de 4,8 cm, ce que l'utilisateur ne peut manquer de constater. Le simple fait de remplacer les gestionnaires d'événements tactiles par des gestionnaires d'événements de pointeur permet de limiter ce temps de latence à 31 ms, pour une distance de 0,3 cm. En somme, cela correspond à des performances plus de 32 fois supérieures.

Même si le retard décrit dans cette page de test a été créé de toutes pièces, il a permis de mettre à jour un problème de performances essentiel, souvent rencontré sur Internet. Dans la pratique, nous avons pu consulter des pages présentant un retard supérieur ou inférieur à 1 000 ms. Cette dépendance sans limite autant que variable par rapport au thread principal d'un navigateur entraîne une expérience utilisateur imprévisible et limite les efforts d'amélioration visant à proposer un temps de réponse optimal d'1 ms. Les chercheurs du service des sciences avancées de Microsoft Research ont fait la démonstration de l'impact incroyable de ce type de réduction du temps de latence pour les utilisateurs. Nous axons toujours nos efforts sur un temps de réponse d'1 ms lors d'une action de panoramique ou de zoom. À nos yeux, les événements de pointeur sont une étape cruciale dans ce contexte.

Les événements de pointeur incluent également une fonction supplémentaire par rapport aux événements tactiles : les événements de transition over/out/enter/leave réclamés par les développeurs. Or, les fonctionnalités supplémentaires s'accompagnent de coûts additionnels. Cependant, nous nous efforçons de réduire ces coûts. La fonction de test de résultats, requise pour ces fonctionnalités, que nous avons ajoutée indique généralement un coût se montant à quelque 0,15 ms, mais nous avons quelques pistes pour améliorer ce résultat, si nous constatons un impact sur la capacité des développeurs à atteindre des performances de 60 i/s.

Compatibilité

Dans notre message annonçant la prise en charge des événements tactiles, nous avons abordé différents problèmes touchant la technologie web de bureau, qui nous ont empêchés de proposer cette API à ces périphériques, en assurant la compatibilité. Ainsi, si les événements tactiles sont activés sur l'ordinateur de bureau, l'exemple de code courant ci-après met un terme à la prise en charge de la souris :

Dans cet exemple (incorrect), la gestion d'événements de souris essentiels n'est pas effectuée sur tout navigateur prenant en charge les événements tactiles, que l'écran du périphérique soit ou non tactile. Cela entraîne des problèmes de fonctionnalité très importants concernant les menus, listes déroulantes et icônes de partage, entre autres, qui ne fonctionnent plus correctement sur des sites gérant la souris comme Web MD, Macys, Onet, Pages Jaunes, Globo, Samsung, Taobao, Huffington Post, etc.

Pour faciliter le travail des développeurs et améliorer l'expérience tactile des utilisateurs, nous voulons effectuer les opérations suivantes :

• Ajouter la prise en charge des événements tactiles sur Internet Explorer, sur Windows Phone (terminé)
• Collaborer avec les développeurs de site pour la correction des problèmes indiqués ci-dessus, dans le but de pouvoir, un jour, activer les API de manière responsable (en cours : surveillance des e-mails ou Tweets provenant de notre équipe de sensibilisation et de webcompat.com)
• Proposer des événements tactiles à l'ensemble de nos plateformes, afin que la matrice de support soit plus claire pour les développeurs (en cours)
• Participer à l'implémentation des événements de pointeur sur d'autres plateformes (en cours sur Mozilla Firefox et Google Chrome)
• Collaborer activement avec les développeurs de site et d'infrastructure, afin de rassembler leurs commentaires et leurs suggestions en matière d'orientation des plateformes web
• Partager nos documents de conception internes, diagrammes architecturaux, méthodologies de test et code pour d'autres navigateurs (en cours)

De nombreux développeurs considèrent qu'il est plus simple d'utiliser des événements de pointeurs avec des « polyfills » pour d'autres navigateurs, comme les événements de pointeur Google Polymer ou Hand.JS. Si vous décidez d'utiliser des événements tactiles, assurez-vous d'apporter la prise en charge de souris adéquate et ne supposez pas que l'existence d'API d'interaction tactile signale un périphérique disposant d'un écran tactile.

Pour aller plus loin...

Les événements de saisie constituent toujours l'un des points faibles les plus importants en matière d'interopérabilité sur les différents navigateurs et périphériques. Comme la plupart des problèmes d'interopérabilité, cela entraîne inévitablement des difficultés pour les développeurs et les utilisateurs, qu'il s'agisse d'une grande complexité des modèles de code ou de préoccupations liées à la compatibilité. Nous nous sommes engagés à améliorer cette situation en nous penchant sur l'interopérabilité lors de nos efforts de normalisation et d'optimisation des navigateurs, chez W3C.

Nous voulons créer une plateforme qui fonctionne correctement, tant pour les développeurs web que pour les utilisateurs. Donnez-nous votre avis : qu'est-ce qui vous semble le plus efficace ou le moins utile ? Que voulez-vous que nous proposions ensuite ? Exprimez-vous sur @iedevchat et sur les pages de suivi des problèmes relatifs à Google Chrome et Mozilla Firefox.

Jacob Rossi
Chef de projet