S'il y a une chose que les utilisateurs attendent vraiment du défilement, c'est qu'il soit fluide. Historiquement, Chrome a proposé un défilement fluide dans certains cas, par exemple lorsque les utilisateurs font défiler la page avec leur pavé tactile ou effectuent un balayage sur un appareil mobile. Toutefois, si l'utilisateur a branché une souris, le comportement de défilement "par étapes" est plus saccablé, ce qui est beaucoup moins esthétique. Cela va changer dans Chrome 49.
Pour de nombreux développeurs, la solution au comportement de défilement natif par étapes, basé sur les entrées, a été d'utiliser des bibliothèques, dont l'objectif est de le remapper pour obtenir un comportement plus fluide et plus agréable à l'œil. Les utilisateurs peuvent également le faire via des extensions. Toutefois, les bibliothèques et les extensions qui modifient le défilement présentent des inconvénients:
- Un sentiment de vallée de l'étrange. Cela se manifeste de deux manières: d'une part, un site peut avoir un comportement de défilement fluide, mais un autre non. L'utilisateur peut donc se sentir désorienté par cette incohérence. Deuxièmement, les principes physiques de fluidité de la bibliothèque ne correspondent pas nécessairement à ceux de la plate-forme. Par conséquent, même si le mouvement est fluide, il peut sembler incorrect ou étrange.
- Augmentation de la propension aux conflits de thread principal et aux à-coups. Comme pour tout code JavaScript ajouté à la page, la charge du processeur sera augmentée. Ce n'est pas nécessairement un désastre, selon les autres actions effectuées par la page. Toutefois, si une tâche de longue durée est effectuée sur le thread principal et que le défilement a été associé au thread principal, le résultat peut être un défilement saccadé et des à-coups.
- Plus de maintenance pour les développeurs, plus de code à télécharger pour les utilisateurs. Une bibliothèque permettant un défilement fluide doit être mise à jour et entretenue, et elle augmentera le poids global de la page du site.
Ces inconvénients sont souvent également valables pour de nombreuses bibliothèques qui gèrent les comportements de défilement, qu'il s'agisse d'effets de parallaxe ou d'autres animations couplées au défilement. Ils déclenchent trop souvent des à-coups, entravent l'accessibilité et nuisent généralement à l'expérience utilisateur. Le défilement est une interaction fondamentale du Web. Il convient donc de le modifier avec des bibliothèques avec beaucoup de prudence.
Dans Chrome 49, le comportement de défilement par défaut changera sous Windows, Linux et ChromeOS. L'ancien comportement de défilement par étapes disparaîtra, et le défilement sera fluide par défaut. Aucune modification de votre code n'est nécessaire, sauf peut-être la suppression de bibliothèques de défilement fluide si vous les avez utilisées.
Autres fonctionnalités de défilement
D'autres fonctionnalités liées au défilement sont en cours de développement et méritent également d'être mentionnées. Beaucoup d'entre nous souhaitent des effets couplés au défilement, comme la parallaxe, le défilement fluide vers un fragment de document (par exemple, example.com/#somesection). Comme je l'ai indiqué précédemment, les approches utilisées aujourd'hui peuvent souvent être préjudiciables aux développeurs et aux utilisateurs. Deux normes de plate-forme en cours de développement pourraient vous aider: les worklets de composition et la propriété CSS scroll-behavior.
Houdini
Les worklets de composition font partie de Houdini et n'ont pas encore été entièrement spécifiés ni implémentés. Toutefois, à mesure que les correctifs seront déployés, vous pourrez écrire du code JavaScript exécuté dans le pipeline du moteur de rendu, ce qui signifie généralement que les effets couplés au défilement, comme la parallaxe, seront parfaitement synchronisés avec la position de défilement actuelle. Compte tenu de la façon dont le défilement est géré aujourd'hui, où les événements de défilement ne sont envoyés au thread principal que périodiquement (et peuvent être bloqués par d'autres tâches du thread principal), cela représenterait un énorme progrès. Si vous êtes intéressé par les worklets de composition ou par l'une des autres nouvelles fonctionnalités intéressantes de Houdini, consultez l'article de présentation de Houdini par Surma, les spécifications de Houdini et partagez vos commentaires sur la liste de diffusion Houdini.
scroll-behavior
En ce qui concerne le défilement basé sur des fragments, la propriété CSS scroll-behavior peut également vous aider. Si vous souhaitez l'essayer, sachez qu'il est déjà disponible dans Firefox. Vous pouvez également l'activer dans Chrome Canary à l'aide de l'option Enable experimental Web Platform features (Activer les fonctionnalités expérimentales de la plate-forme Web). Si vous définissez, par exemple, l'élément <body> sur scroll-behavior: smooth, tous les défilements déclenchés par des modifications de fragment ou par window.scrollTo seront animés de manière fluide. C'est bien mieux que d'avoir à utiliser et à gérer le code d'une bibliothèque qui tente de faire la même chose. Avec un élément aussi fondamental que le défilement, il est vraiment important d'éviter de décevoir les attentes des utilisateurs. Par conséquent, même si ces fonctionnalités sont en pleine évolution, il est toujours utile d'adopter une approche d'amélioration progressive et de supprimer toutes les bibliothèques qui tentent de polyfiller ces comportements.
Faites défiler la page.
À partir de Chrome 49, le défilement est plus fluide. Mais ce n'est pas tout: d'autres améliorations potentielles peuvent être apportées via Houdini et des propriétés CSS telles que smooth-scroll. Essayez Chrome 49, dites-nous ce que vous en pensez et, surtout, laissez le navigateur faire le défilement lorsque vous le pouvez !