Résumé

  • Le premier projet public du W3C, en décembre 2012, proposait une famille d’événements indépendante du matériel pour la souris, le stylet et le toucher, tout en ménageant les pages écrites pour la souris.
  • La recommandation de février 2015 précisait les événements de pointeur, pointerType, touch-action pour les gestes gérés par le navigateur et la capture du pointeur pendant les glissements.

Imaginez un club où le portier ne reconnaît que les souris. Une main arrive et touche la sonnette. Le portier lui colle une fausse moustache de souris pour la laisser entrer. Puis vient un stylet, et tout le monde doit écrire encore une règle. Sur les pages anciennes, ce déguisement avait un équivalent réel : des événements de souris pouvaient être produits pour des gestes qui venaient d’un autre dispositif.

Le premier projet de travail public Pointer Events du W3C, du 11 décembre 2012, partait de cette difficulté. Les sites avaient beaucoup de code bâti autour de la souris. Ajouter le toucher et le stylet par des familles d’événements séparées multipliait les gestionnaires et les cas particuliers. Le projet proposait un « pointeur » pour les contacts qui désignent une position sur l’écran, quelle que soit la main ou l’outil qui les produit.

Cette abstraction n’effaçait pas les différences. Un événement PointerEvent peut préciser pointerType, la pression, la géométrie du contact ou l’inclinaison. Pour ouvrir un menu, connaître la pression d’un stylet n’apporte guère. Pour dessiner, elle peut changer le trait. La même famille d’événements permet de traiter le geste commun et de demander ensuite le détail dont une tâche a vraiment besoin.

La recommandation du W3C du 24 février 2015 fixe notamment pointerdown, pointermove, pointerup et pointercancel. On trouve aussi les événements d’entrée et de sortie d’une zone. Les noms rappellent les événements de souris familiers aux auteurs. L’identifiant du pointeur aide à suivre la bonne suite de mouvements lorsque plusieurs contacts existent. Le club a conservé son plan, mais il a cessé de réserver la porte à un seul invité.

Les anciennes pages n’ont pas été jetées sur le trottoir. La recommandation décrit la production d’événements de souris compatibles à partir d’autres pointeurs. C’est utile pour les contenus qui n’écoutent encore que la souris. Cela entretient aussi une ambiguïté : un événement appelé « souris » peut être l’écho d’un doigt. L’événement de pointeur et son pointerType donnent à une nouvelle page une manière plus nette de savoir ce qu’elle traite.

Sur un écran tactile, le vrai conflit arrive quand le doigt bouge. Faut-il déplacer une carte dessinée par le site, ou faire défiler la page ? Si le navigateur doit attendre que chaque mouvement soit annulé par un script avant de choisir, le défilement peut devenir lourd. La propriété touch-action, décrite dans la recommandation, annonce les gestes tactiles par défaut permis dans une région. Le navigateur peut faire son travail de défilement sans demander la permission au script à chaque centimètre.

La capture du pointeur règle une autre scène familière. On saisit une poignée pour la faire glisser; le doigt sort un instant du rectangle de la poignée. L’élément peut conserver les événements de ce pointeur malgré la sortie de sa zone. Le texte de 2015 décrit la prise, la libération et les événements gotpointercapture et lostpointercapture. Le glissement garde son fil même quand la main dessine une trajectoire moins sage que prévu.

Les capacités particulières restent visibles. Le contact du doigt possède une surface; le stylet peut donner inclinaison et pression; la souris apporte boutons et curseur. Le pointeur commun est une langue partagée, pas un uniforme imposé à tous les mouvements. Un site peut bâtir son bouton sur le geste général et réserver la finesse du stylet à une toile de dessin.

L’historique de publication du W3C pour Pointer Events 1 situe le premier projet public en décembre 2012 et la recommandation en février 2015. Les documents montrent comment le web a accommodé les pages héritées de la souris et les appareils qui n’en avaient pas. La difficulté était pratique : écrire une interface qui marche quand la main change d’outil, sans dupliquer toute l’application.

Le lecteur, lui, ne vient pas au club pour admirer les badges. Il veut toucher une commande, tracer au stylet, faire défiler la page et terminer son geste même si son doigt glisse un peu trop loin. Quand tout cela fonctionne, la souris peut garder sa table. Elle a simplement de nouveaux voisins.