La navigation ne se fige plus en haut de l'écran lors du scroll

Vous l'avez peut-être constaté par vous-même, le menu de navigation de ce site[1] ne se fige plus en haut de l'écran quand vous descendez dans la page. Ce fonctionnement que j'avais trouvé très sexy s'avère poser plusieurs problèmes, donc j'ai préféré le supprimer.

Le premier problème — le plus important — est ergonomique.

Comme le met en évidence Stéphane dans son billet «Le problème de position:fixed» illustré par le cas concret du site de Jérémie, fixer des éléments en haut ou bas de page conduit à masquer une partie du contenu lorsque l'on scroll par à coups, avec les touches page suivante / page précédente du clavier.

Pour éviter cela, il faudrait redécaler le scroll dans le sens inverse de celui provoqué par l'utilisateur, avec un effet visuel sans doute déplaisant[2].

Le second problème — qui pourrait être très important mais sur lequel il est plus facile de corriger le tir — concerne la performance.

Dans le code que j'avais mis en ligne initialement, basé sur le tutoriel «Fixed Floating Elements» de jQuery for Designers, le traitement était provoqué par l'événement window.onscroll. Chaque mouvement, même infime, de l'ascenseur provoquait donc l'appel de mon code. L'effet dans les vieux navigateurs au moteur JavaScript pas du tout optimisé était désastreux.

Heureusement, un billet de John Resig sur un problème similaire trouvé chez Twitter m'avait permis de bien améliorer le système, en passant à un contrôle de la position de scroll toutes les 100 millisecondes plutôt qu'à chaque mouvement.

Un problème d'eXpérience Utilisateur

Permalink to heading Un problème d'eXpérience Utilisateur

Malheureusement, cette nouvelle version du code, si elle était bien plus performante et impactait beaucoup moins les navigateurs obsolètes, faisait qu'il y avait un effet désagréable de saut du menu quand l'utilisateur descendait dans la page.

Le passage au point névralgique devant faire passer en position: fixed; ne se faisait effectivement que rarement au moment précis d'une itération de contrôle, donc le menu commençait à disparaître en haut, avant de revenir soudainement en place, de manière que j'ai jugée trop désagréable à l’œil pour pouvoir la conserver.


  1. L'ancien site en fait, sur http://gasteroprod.com/ ↩︎

  2. Je n'ai même pas osé essayer… ↩︎


  1. screenshot of Why We're Breaking Up with CSS-in-JS

    Sam Magura

    Why We're Breaking Up with CSS-in-JS

    Thanks for reading this deep dive into runtime CSS-in-JS. Like any technology, it has its pros and cons. Ultimately, it's up to you as a developer to evaluate these pros and cons and then make an informed decision about whether the technology is right for your use case. For us at Spot, the runtime performance cost of Emotion far outweighed the DX benefits, especially when you consider that the alternative of Sass Modules + utility classes still has a good DX while providing vastly superior performance.

  2. screenshot of Speeding Up Async Snippets

    Harry Roberts avatar Harry Roberts

    Speeding Up Async Snippets

    For all the resulting script is asynchronous, the <script> block that creates it is fully synchronous, which means that the discovery of the script is governed by any and all synchronous work that happens before it, whether that’s other synchronous JS, HTML, or even CSS. Effectively, we’ve hidden the file from the browser until the very last moment, which means we’re completely failing to take advantage of one of the browser’s most elegant internals… the Preload Scanner.

  3. screenshot of Hydration is Pure Overhead

    Miško Hevery avatar Miško Hevery

    Hydration is Pure Overhead

    The re-execution of code on the client that the server already executed as part of SSR/SSG is what makes hydration pure overhead: that is, a duplication of work by the client that the server already did. The framework could have avoided the cost by transferring information from the server to the client, but instead, it threw the information away.