On peut relier de nombreuses petites pages HTML par la navigation pour créer de l’interaction

• L’approche (L)ots of (L)ittle ht(M)l page(s) remplace les interactions internes à la page basées sur JavaScript par des déplacements entre plusieurs petites pages HTML
• L’interaction est construite comme une navigation entre pages HTML, améliorée dans les environnements modernes avec les transitions de vue CSS (view transitions), avec seulement un peu de JavaScript quand c’est nécessaire
• Le Menu du blog n’est pas une UI dépliée en JavaScript, mais fonctionne en suivant le lien <a href="/menu/"> vers une page dédiée au menu
• La fermeture du menu est, par défaut, un lien vers /, mais si document.referrer est présent, JavaScript exécute history.back() pour éviter d’empiler dans l’historique des entrées d’ouverture et de fermeture du menu
• En s’appuyant sur la fonctionnalité native du navigateur, à savoir la navigation par liens, cela fonctionne aussi sur les anciens appareils, les anciens navigateurs et dans les environnements où JavaScript est désactivé, et plus la taille des pages reste réduite, plus l’interaction devient rapide et robuste

---

Méthode d’implémentation du menu et conséquences de conception

• Ouvrir et fermer, tout passe par des liens

  • Sur une page normale, il y a un lien vers la page du menu, et sur la page du menu, ce lien est remplacé par un « X » qui sert à fermer le menu
  • L’action de fermeture est aussi, par défaut, un lien vers /, mais si document.referrer est présent, JavaScript exécute history.back() pour éviter d’ajouter à l’historique du navigateur des entrées d’ouverture et de fermeture du menu
  • Une implémentation simplifiée ressemble à ceci

    <!-- Normal page -->
    <nav>
      <a href="/menu/">
        <svg>...</svg>
      </a>
    </nav>
    
    <!-- Menu page -->
    <nav>
      <a href="/" onclick="document.referrer ? history.back() : window.location.href = '/'; return false;">
        <svg>...</svg>
      </a>
    </nav>
    

• Distinguer une visite directe d’une navigation interne

  • document.referrer permet de distinguer si l’on est arrivé sur la page du menu via une navigation interne au blog ou par un accès direct, comme la saisie de l’URL
  • En cas de navigation interne, history.back() a un sens ; en cas d’accès direct, on redirige vers /

• L’approche façonne le design

  • La solution peut sembler simple, mais elle oblige à réfléchir ensemble à la nature de la navigation, aux interactions qui traversent plusieurs pages et à la manière de garder des pages légères
  • Il faut conserver des pages de petite taille pour que l’interaction reste rapide, robuste et intuitive
  • Si l’on considère le navigateur non comme un runtime qui exécute, télécharge, compile puis affiche du code arbitraire, mais comme un outil de consultation de documents, on peut créer des sites web bien plus simples que ne le suggèrent les outils

[GN⁺]

Commentaires sur Lobste.rs

• En général, j’aime l’approche qui consiste à toujours répondre en HTML, mais pour quelque chose comme un menu, je ne suis pas certain
  J’aimerais connaître l’avis de spécialistes de l’accessibilité sur ce qui est préférable entre un élément repliable et une transition de page complète pour ouvrir un menu
  Ici, la Popover API me semble être une meilleure solution. Elle permet de proposer un menu sans JavaScript, sans aller-retour complet
  Pour le reste, je suis d’accord sur le fait qu’il ne faut pas avoir peur des changements de page. Aujourd’hui, même une navigation de type SPA n’est presque jamais difficile à rendre accessible sur des sites SSR ou statiques

  • Je ne suis pas spécialiste de l’accessibilité, mais en tant que personne qui a installé NVDA pour le développement web, je ne ressens pas de grande différence côté expérience utilisateur
    Un changement de page réinitialise la position actuelle, mais si l’intention était d’ouvrir le menu et qu’on arrive bien sur le menu, les deux expériences sont assez proches
    Cela dit, même indépendamment de l’usage d’un lecteur d’écran, ouvrir un menu en allant vers une nouvelle page paraît assez étrange
  • Le mot-clé, c’est can, pas should. Si des pages HTML conviennent à l’interaction, on peut les utiliser ; si une autre approche est plus adaptée, il faut prendre celle-là
    Par exemple, si l’on demande s’il vaut mieux faire deux pages HTML différentes pour l’état ouvert/fermé d’un composant, ou utiliser la balise <details>, alors c’est évidemment la seconde option
    De même, utiliser la Popover API est tout à fait acceptable. L’idée est d’éviter d’avoir besoin de JavaScript pour les interactions dans la page, pas de s’obstiner à imposer une navigation HTML multipage

• L’approche proposée charge le menu dynamiquement avec JavaScript et onclick, ce qui introduit de la latence et ajoute un point de donnée de plus dans le parcours utilisateur
  À la place, on pourrait intégrer le menu dans chaque page et l’afficher ou le masquer avec l’élément <details> ou le sélecteur CSS :focus-within
  https://nlnet.nl fonctionne de cette manière

• L’approche décrite ne fonctionne pas correctement en pratique. Si l’on désactive JavaScript, qu’on ouvre un billet de blog, puis qu’on ouvre et referme le menu, on est redirigé vers l’accueil (/) au lieu de revenir au billet d’origine
  Pour mettre le bon lien sur le bouton de fermeture, il faudrait forcément rendre le menu dynamiquement côté backend pour que cette approche tienne la route
  Personnellement, je préfère la Popover API quand c’est possible. Cela permet de tout rendre de manière statique, sans backend

  • Le lien de l’icône X du menu pointe vers https://blog.jim-nielsen.com/, mais avec JavaScript activé, le gestionnaire onclick semble intercepter la navigation

    document.referrer  
      ? history.back()  
      : window.location.href = '/';  
    return false;  
    

    Comme cela envoie vers une page différente de celle indiquée dans le href, c’est une mauvaise expérience utilisateur. Je vérifie souvent la destination en survolant les liens, donc je n’aime pas avoir l’impression d’être trompé de cette façon

• D’un côté, j’aime beaucoup. On peut faire énormément de choses avec seulement du HTML, de manière plus fluide et plus simple qu’avec JavaScript
  D’un autre côté, cette approche semble surtout bien convenir au mobile. Sur desktop, on s’attend plutôt à ce que le menu soit toujours visible ou surgisse en panneau, pas à devoir changer de page
  Alors je me demande si cela veut dire qu’il faut désormais deux versions des pages selon les navigateurs

  • À l’inverse, sur mobile, si la connexion est instable, il faut aller une fois au menu puis repartir vers la destination
    Cela double la friction
  • J’ai sans doute un point de vue relativement jeune. Il y a 20 ou 30 ans, tous les sites web fonctionnaient ainsi, et HTML était en partie conçu pour être utilisé de cette manière
    JavaScript était presque un accident
    Je trouve étrange de considérer cette approche comme plus difficile ou plus complexe que n’importe quelle solution JavaScript. C’est clairement la façon la plus simple et la plus facile de créer un site web

• Je n’aime pas trop la méthode de navigation, mais j’ai aimé les effets de transition, et je ne savais pas que c’était possible
  Je l’ai appliqué aussi à mon site, qui utilise un générateur statique C++ maison et une bibliothèque de templates : https://vittorioromeo.com/
  Je trouve que cela convient particulièrement bien au basculeur de thème sombre/clair

• Sur desktop, cliquer sur “menu” et être envoyé vers une autre page n’est pas agréable. Cela déclenche un rechargement complet de la page, ce qui est étonnamment gênant par rapport à ce qu’on attend
  Personnellement, cela casse mon flux de lecture et mon fil de pensée. Quand je clique sur un lien vers un autre site, j’ai l’impression de quitter une pièce pour en rejoindre une autre, donc j’abandonne naturellement la précédente ; mais quand cela arrive avec un menu, c’est comme aller jusqu’à une porte et se retrouver dans une pièce complètement différente, ce qui est déroutant
  Honnêtement, l’idée en elle-même est bonne, mais à l’usage la sensation n’est pas bonne
  Et je ne vois même pas de quels effets de transition il s’agit. Dans mon environnement, quand j’appuie sur le bouton Menu, cela charge simplement la page Menu comme d’habitude

  • Les transitions de vue entre documents ne fonctionnent pas encore dans Firefox
    Il est possible que cela ne marche pas non plus dans d’autres navigateurs, mais j’utilise principalement Librewolf, un fork de Firefox
    Dans Chromium, les effets de transition apparaissent bien

• L’idée est intéressante, mais je me demande comment cela fonctionne sur desktop
  Un menu en page complète me paraît un peu excessif, donc cette façon de remplacer toute la page semble moins adaptée

• Il n’est pas question du preload pour réduire le délai de chargement de la page de menu
  Je me demande dans quelle mesure cela fonctionnerait bien

  • Il faut aussi mettre les bons en-têtes de cache. Ici, un simple en-tête expires suffirait probablement
    Cela éviterait même d’avoir à revalider auprès du serveur avant l’affichage, donc la navigation semblerait très rapide

• Il y a quelques années, j’ai vu un jeu en texte créé par @misty qui utilisait de simples liens comme interaction pour donner une illusion de choix
  La simplicité du HTML et la force du récit m’avaient profondément marqué