Quelques techniques HTML et CSS pour réduire l’utilisation de JavaScript

Conserver un élément à l’écran quand il est important

On peut vouloir conserver toujours visible des en-têtes, un panier ou une barre d’outils. Je rencontre souvent ce genre de comportement mais plus rarement sa correcte implémentation.

Version JavaScript

Historiquement, pour faire cela, il fallait écouter les événements de défilement très souvent envoyés. Tellement souvent que la plupart des solutions ignorent la plupart des événements avec des solutions de throttling ou debounce qui filtrent alors leur nombre. De nos jours, on peut utiliser IntersectionObserver pour ne recevoir des événements que lorsque l’élément entre ou sort de l’écran. C’est déjà bien plus économe.

Une fois que l’on a détecté l’entrée ou la sortie de l’élément dans la fenêtre, il faut passer d’une position: relative à une position: fixed. Cela demande au navigateur de recalculer les tailles et positions des éléments (qu’on appelle « faire un layout » ou « reflow ») ce qui est coûteux. Et justement, il faut s’assurer que les éléments autour ne se déplacent pas pour ne pas provoquer un saut du contenu. « Le Monde » souffre par exemple de cette implémentation imparfaite.

Si jamais le rendu est bloqué lorsque l’élément entre ou sort de la fenêtre (ce qui est fort probable avec la tendance actuelle consistant à avoir des animations coordonnées avec le défilement), la bascule ne s’effectuera que bien plus tard.

Version native

CSS dispose maintenant d’une position: sticky pour obtenir ce comportement. Aucun problème de performance, de réactivité ou de saut de contenu : tant que le navigateur peut défiler, il gardera l’élément positionné exactement où vous l’avez déclaré. Pour choisir son positionnement, on utilise top, bottom, left ou right.

Voir la démonstration de la liste de noms
sticky sur CodePen</a >

Tous les navigateurs sauf Internet Explorer et de vieilles versions de Chrome ou Firefox supportent la position: sticky. Pour ces anciens navigateurs, les éléments sont en position: static, ce qui est la valeur par défaut et ne prendront pas en compte les valeurs de top, bottom, left et right. À garder en tête si vous avez besoin de supporter ces navigateurs. D’anciennes versions de Safari nécessitent d’utiliser le préfixe -webkit-sticky.

Il existe cependant une limitation : il est impossible de modifier l’apparence d’un élément selon qu’il adhère à l’écran ou non par exemple avec une pseudo-class :stuck. C’est une limitation générale de CSS. Dans ces cas là, je recommande de combiner les bénéfices de la position: sticky pour changer l’adhérence d’un élément avec IntersectionObserverpour en modifier l’apparence (tout en veillant à ne pas en changer les dimensions, afin de ne pas provoquer de sauts de contenu).

Défilement avec points d’accroche

Cela permet de créer des diaporamas, des listes horizontales avec des points d’accroche ou des sections prenant la taille de l’écran.

Version JavaScript

Pour réaliser un diaporama, on écoute généralement :

• les événements de contact (mousedown, mouseup, touchstart, touchend, pointerdown ou pointerup) ;
• les événements de déplacement du pointeur (mousemove, touchmove ou pointermove).

Bien gérer cela pour tous les types de pointeurs (souris ou doigt) et lorsque le pointeur sort de la zone est très délicat. Une fois que l’on a bien géré ces événements, on déplace les éléments en fonction du mouvement. Chaque déplacement déclenche un rendu, coûteux, ce qui peut créer des saccades brisant l’illusion pour l’internaute.

Pour les sections prenant la taille de l’écran ou les listes horizontales, il faut écouter les événements de défilement, les annuler pour les remplacer par le défilement que l’on souhaite. Obtenir un comportement agréable est très difficile : je pense que tout le monde a déjà enragé devant son écran en rencontrant un site qui détourne le défilement natif. C’est tellement fréquent qu’on parle alors de scroll jacking (vol du défilement).

Pour ces deux usages, il vous faudra décider quand passer à l’élément suivant selon la distance et la vitesse du déplacement initial. Si vos choix ne correspondent pas au comportement du système utilisé, vous frustrez vos utilisateurs ou utilisatrices.

Version native

CSS dispose de scroll snap pour gérer cela. Sur le conteneur du défilement, on définit scroll-snap-type pour indiquer la direction dans laquelle on souhaite des accroches et si l’accroche est obligatoire ou seulement lorsqu’on est à proximité d’un point d’accroche. Puis sur les enfants de ce conteneur, on définira scroll-snap-align pour indiquer les points d’accroche.

La démo suivante fonctionne entièrement sans JavaScript. Elle utilise aussi scroll-behavior pour suggérer à l’utilisateur ou l’utilisatrice la possibilité d’utiliser le défilement habituel.

En cochant la case, on active un tout petit peu de IntersectionObserver pour mettre en avant la miniature de l’image actuellement affichée.

Voir la démonstration d’un diaporama avec
scroll-snap sur CodePen</a >

Tous les navigateurs récents supportent ce comportement. Il existait une syntaxe alternative mais je ne recommande pas de l’utiliser. Cela augmente le nombre de cas que vous devrez tester et l’on peut se reposer sur la dégradation progressive. Dans ces navigateurs sans support, cela sera un défilement classique.

Comme cette fonctionnalité utilise le défilement normal, on obtient une fluidité sans égale avec les solutions JavaScript, quel que soit le type de pointeur utilisé.