Vous et vos utilisateurs souhaitez que les applications Web mobiles réagissent et défilent de manière fluide à l'écran. Leur développement devrait être simple, mais malheureusement, la façon dont les navigateurs Web mobiles réagissent aux événements tactiles lors du défilement est laissée comme détail d'implémentation dans la spécification TouchEvent. Par conséquent, les approches peuvent être réparties en quatre catégories. Cette situation met en évidence une tension fondamentale entre la fluidité du défilement et le contrôle du développeur.
Quatre modèles différents de traitement des événements tactiles ?
Les différences de comportement entre les navigateurs se répartissent en quatre modèles.
Traitement normal des événements synchrones
Les événements de mouvement tactile sont envoyés pendant le défilement, et chaque mise à jour de défilement est bloquée jusqu'à ce que la gestion du mouvement tactile soit terminée. Cette approche est intéressante, car elle est la plus simple à comprendre et la plus puissante, mais elle est mauvaise pour les performances de défilement, car elle signifie que chaque frame pendant le défilement doit bloquer sur le thread principal.
Navigateurs: navigateur Android (Android 4.0.4, 4.3), Safari mobile (lors du défilement de la div)
Traitement asynchrone de touchmove
Les événements touchmove sont envoyés pendant le défilement, mais le défilement peut se poursuivre de manière asynchrone (l'événement touchmove est ignoré une fois le défilement commencé). Cela peut entraîner une "double gestion" des événements, par exemple, le défilement continue après que le site Web a effectué une action avec le mouvement tactile et a appelé preventDefault sur l'événement, indiquant au navigateur de ne pas le gérer.
Navigateurs: Safari mobile (lors du défilement du document), Firefox
Déplacement tactile supprimé pendant le défilement
Les événements de mouvement tactile ne sont pas envoyés après le début du défilement et ne reprennent pas avant l'événement touchend. Dans ce modèle, il est difficile de faire la différence entre un appui immobile et un défilement.
Navigateurs: navigateur Samsung (événements de mouvement de souris envoyés)
Touchcancel au début du défilement
Vous ne pouvez pas avoir les deux : fluidité du défilement et contrôle du développeur. Ce modèle met en évidence le compromis entre le défilement fluide et la gestion des événements, semblable à la sémantique de la spécification Événements de pointeur. Certaines expériences qui peuvent nécessiter de suivre le doigt, comme le balayage pour actualiser, ne sont pas possibles.
Navigateurs: Chrome pour ordinateur M32 et versions ultérieures, Chrome pour Android
Pourquoi ce changement ?
Chrome pour Android utilise actuellement l'ancien modèle de Chrome : "touchcancel" au début du défilement, ce qui améliore les performances de défilement, mais crée de la confusion chez les développeurs. En particulier, certains développeurs ne connaissent pas l'événement touchcancel ni la façon de le gérer, ce qui a entraîné la défaillance de certains sites Web. Plus important encore, une classe entière d'effets et de comportements de défilement de l'interface utilisateur, tels que le refraîchissement par glissement, les barres masquées et les points d'ancrage, sont difficiles ou impossibles à implémenter correctement.
Plutôt que d'ajouter des fonctionnalités codées en dur spécifiques pour prendre en charge ces effets, Chrome vise à se concentrer sur l'ajout de primitives de plate-forme permettant aux développeurs d'implémenter ces effets directement. Pour une présentation générale de cette philosophie, consultez A Rational Web Platform.
Nouveau modèle de Chrome: le modèle de mouvement tactile asynchrone limité
Chrome introduit un nouveau comportement conçu pour améliorer la compatibilité avec le code écrit pour d'autres navigateurs lors du défilement, et pour activer d'autres scénarios qui dépendent de la réception d'événements de mouvement tactile lors du défilement. Cette fonctionnalité est activée par défaut. Vous pouvez la désactiver à l'aide de l'indicateur suivant, chrome://flags\#touch-scrolling-mode.
Le nouveau comportement est le suivant:
- Le premier mouvement de doigt est envoyé de manière synchrone pour permettre de annuler le défilement.
- Pendant le défilement actif
- Les événements touchmove sont envoyés de manière asynchrone.
- limité à un événement par 200 ms ou si une région de glissement CSS de 15 px est dépassée
- Event.cancelable est false
- Sinon, les événements touchmove se déclenchent de manière synchrone comme d'habitude lorsque le défilement actif se termine ou n'est pas possible, car la limite de défilement a été atteinte.
- Un événement touchend se produit toujours lorsque l'utilisateur lève son doigt.
Vous pouvez essayer cette démo dans Chrome pour Android et activer/désactiver l'indicateur chrome://flags\#touch-scrolling-mode pour voir la différence.
Donnez-nous votre avis
Le modèle Async Touchmove peut améliorer la compatibilité entre les navigateurs et permettre une nouvelle classe d'effets de gestes tactiles. Nous aimerions connaître l'avis des développeurs et voir les choses créatives que vous pouvez faire avec.