Es posible unir muchas páginas HTML pequeñas con navegación para lograr interacción

• El enfoque de (L)ots of (L)ittle ht(M)l page(s) reemplaza la interacción dentro de la página basada en JavaScript por desplazamientos entre varias páginas HTML pequeñas
• La interacción se compone como navegación entre páginas HTML, se mejora en entornos modernos con transiciones de vista CSS (view transitions) y solo se agrega un poco de JavaScript cuando hace falta
• El Menu del blog no es una UI que se despliega con JavaScript, sino que funciona moviéndose a una página dedicada al menú siguiendo el enlace <a href="/menu/">
• Para cerrar el menú, por defecto también se usa un enlace hacia /, pero si existe document.referrer, JavaScript ejecuta history.back() para evitar que abrir y cerrar el menú vaya acumulando entradas en el historial
• Al apoyarse en la función básica del navegador, seguir enlaces, esto funciona incluso en dispositivos antiguos, navegadores viejos y entornos con JavaScript desactivado, y mientras más pequeño se mantenga el tamaño de las páginas, más rápida y robusta será la interacción

---

Forma de implementar el menú y resultados de diseño

• Abrir y cerrar, ambos resueltos con enlaces

  • En una página normal hay un enlace a la página del menú, y en la página del menú ese enlace cambia a una “X” que cumple la función de cerrar el menú
  • La acción de cerrar también usa por defecto un enlace a /, pero si existe document.referrer, JavaScript ejecuta history.back() para que no se agreguen entradas de apertura y cierre del menú al historial del navegador
  • Una implementación simplificada es la siguiente

    <!-- 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>
    

• Distinguir entre visita directa y navegación interna

  • Con document.referrer se distingue si se llegó a la página del menú mediante navegación interna del blog o por una visita directa, como escribir la URL
  • Si fue una navegación interna, se puede ejecutar un history.back() con sentido; si fue una visita directa, se navega a /

• El enfoque termina moldeando el diseño

  • Aunque parece una solución simple, también obliga a pensar en la esencia de la navegación, en la interacción que cruza varias páginas y en cómo mantener pequeño el tamaño de las páginas
  • Hay que mantener las páginas pequeñas para que la interacción siga siendo rápida, robusta e intuitiva
  • Si se ve el navegador no como un runtime que ejecuta código arbitrario, lo descarga, lo compila y lo muestra, sino como una herramienta para explorar documentos, se pueden crear sitios web mucho más simples de lo que las herramientas suelen inducir

[GN⁺]

Comentarios de Lobste.rs

• Por lo general me gusta el enfoque de responder siempre con HTML, pero en el caso de los menús no estoy tan seguro.
  Me gustaría conocer la opinión de especialistas en accesibilidad sobre qué es mejor entre elementos conmutables y una transición de página completa para abrir un menú.
  Aquí, la Popover API se siente como una mejor solución, porque permite ofrecer un menú sin JavaScript y sin una ida y vuelta completa.
  En casi todo lo demás, coincido en que no hay que tenerle miedo a las transiciones de página. Hoy en día, incluso una navegación tipo SPA casi siempre puede lograrse con accesibilidad en sitios SSR o estáticos sin demasiada dificultad.

  • No soy especialista en accesibilidad, pero como alguien que tiene NVDA instalado para desarrollo web, no noto una gran diferencia en la experiencia de usuario.
    La navegación entre páginas reinicia la ubicación actual, pero si la intención era abrir el menú y efectivamente llegas al menú, ambos se sienten bastante parecidos.
    Aun así, igual que para alguien que no usa lector de pantalla, abrir un menú y que te lleve a una página nueva se siente bastante raro.
  • La palabra clave es can, no should. Si las páginas HTML son adecuadas para una interacción, úsalas; si otro enfoque es más adecuado, usa ese.
    Por ejemplo, si preguntas si el estado expandido/colapsado de un componente debería representarse como dos páginas HTML distintas o si deberías usar la etiqueta <details>, obviamente lo segundo.
    Del mismo modo, usar la Popover API está totalmente bien. La idea es evitar necesitar JavaScript para la interacción dentro de la página, no insistir en una navegación HTML multipágina.

• El enfoque presentado carga el menú dinámicamente con JavaScript y onclick, así que introduce latencia y añade otro punto de datos al recorrido del usuario.
  En su lugar, el menú podría incluirse en cada página y mostrarse u ocultarse con el elemento <details> o el selector CSS :focus-within.
  https://nlnet.nl funciona de esta manera.

• El enfoque descrito en realidad no funciona correctamente. Si desactivas JavaScript, abres una entrada del blog y luego abres y cierras el menú, terminas en la página principal (/) en vez de volver al artículo original.
  Para poner el enlace correcto en el botón de cerrar, este enfoque solo funciona si el menú se renderiza dinámicamente desde el backend.
  Personalmente, si es posible prefiero la Popover API. Así se puede renderizar todo estáticamente sin depender del backend.

  • El enlace del ícono X del menú apunta a https://blog.jim-nielsen.com/, pero con JavaScript activado parece que el controlador onclick intercepta la navegación.

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

    Te envía a una página distinta de la que figura en el href, lo cual es una mala experiencia de usuario. Suelo pasar el cursor sobre los enlaces para verificar el destino, y no me gusta sentir que eso engaña.

• Por un lado, realmente me encanta. Solo con HTML se puede hacer mucho más de forma más fluida y simple que con JavaScript.
  Por otro lado, este enfoque parece encajar sobre todo en móvil. En una página de escritorio esperaría que el menú estuviera siempre visible o que se desplegara, no que exigiera cambiar de página.
  Entonces me pregunto si ahora harán falta dos versiones de páginas según el navegador.

  • En cambio, si en móvil la conexión es inestable, hay que ir una vez al menú y luego otra vez al destino.
    La fricción se duplica.
  • Supongo que soy relativamente joven. Hace 20 o 30 años todos los sitios web funcionaban así, y HTML en cierta medida estaba pensado para usarse de esa manera.
    JavaScript fue más bien un accidente.
    Me sorprende que esto se sienta más difícil o complejo que cualquier solución con JavaScript. Claramente es la forma más simple y fácil de hacer un sitio web.

• No me convence mucho la forma de navegación, pero sí me gustó el efecto de transición, y no sabía que esto era posible.
  Lo apliqué también a mi sitio, que usa un generador estático y una biblioteca de plantillas hechos por mí en C++: https://vittorioromeo.com/
  Creo que funciona especialmente bien para el interruptor entre tema oscuro y claro.

• En escritorio, hacer clic en “menu” y que te lleve a otra página no se siente bien. Hay una recarga completa de la página y resulta bastante molesto porque no es lo que uno espera.
  Personalmente me corta el flujo de lectura y de pensamiento. Cuando hago clic en un enlace hacia otro sitio, siento que estoy saliendo de una habitación y dejando atrás la anterior; pero si eso pasa con un menú, se siente como si hubiera ido hacia la puerta y de pronto apareciera en una habitación completamente distinta, lo cual es incómodo.
  La idea en sí, sinceramente, es buena, pero usarla no se siente bien.
  Y tampoco sé a qué efecto de transición se refieren. En mi entorno, al pulsar el botón Menu simplemente se carga la página Menu como siempre.

  • Las transiciones de vista entre documentos todavía no funcionan en Firefox.
    Puede que tampoco funcionen en otros navegadores, pero mi navegador principal es Librewolf, un fork de Firefox.
    En Chromium sí se ve el efecto de transición.

• Es una idea interesante, pero me pregunto cómo funcionaría en escritorio.
  Un menú como página completa me parece un poco excesivo, así que cambiar toda la página da la impresión de encajar menos.

• No se menciona preload para reducir la latencia al cargar la página del menú.
  Me pregunto qué tan bien funcionaría si se usara.

  • También haría falta incluir los encabezados de caché correctos. Aquí probablemente bastaría incluso con un encabezado simple de expiración.
    Entonces ni siquiera haría falta volver al servidor para validar antes de mostrarlo, y se sentiría muy rápido.

• Hace unos años vi un juego de texto hecho por @misty que usaba enlaces simples como interacción para dar una ilusión de elección.
  El HTML simple y la fuerza de la narrativa me llegaron mucho.