É possível encadear muitas páginas HTML pequenas com navegação para criar interação

• A abordagem (L)ots of (L)ittle ht(M)l page(s) substitui interações internas de página baseadas em JavaScript por navegação entre várias páginas HTML pequenas
• A interação é composta por navegação entre páginas HTML, aprimorada em ambientes modernos com transições de visualização CSS (view transitions) e com um pouco de JavaScript só quando necessário
• O Menu do blog não é uma UI expandida com JavaScript; em vez disso, funciona navegando por um link <a href="/menu/"> até uma página dedicada ao menu
• O fechamento do menu também é, por padrão, um link para /, mas se houver document.referrer, o JavaScript executa history.back() para evitar que itens de abrir/fechar menu se acumulem no histórico de navegação
• Ao depender do recurso nativo do navegador, a navegação por links, isso funciona mesmo em dispositivos antigos, navegadores antigos e ambientes com JavaScript desativado, e quanto menor o tamanho das páginas, mais rápida e robusta a interação se torna

---

Como o menu é implementado e os resultados desse design

• Abrir e fechar são ambos tratados com links

  • Em páginas normais, há um link para a página do menu, e na página do menu esse link muda para “X”, passando a servir para fechar o menu
  • A ação de fechar também é, por padrão, um link para /, mas se houver document.referrer, o JavaScript executa history.back() para que itens de abrir/fechar menu não sejam adicionados ao histórico do navegador
  • Uma implementação simplificada é a seguinte

    <!-- 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 visita direta de navegação interna

  • Com document.referrer, distingue-se se a página do menu foi acessada por navegação interna do blog ou por visita direta, como digitar a URL
  • Se for navegação interna, é possível executar um history.back() com significado; se for visita direta, navega para /

• A abordagem molda o design

  • Parece uma solução simples, mas é preciso considerar em conjunto a essência da navegação, a interação que atravessa várias páginas e como manter o tamanho das páginas pequeno
  • É preciso manter as páginas pequenas para que a interação continue rápida, robusta e intuitiva
  • Se você enxergar o navegador não como um runtime que executa, busca e compila código arbitrário para exibir algo, mas como uma ferramenta para navegar por documentos, é possível criar sites muito mais simples do que as ferramentas costumam induzir

[GN⁺]

Comentários do Lobste.rs

• Em geral, gosto da abordagem de sempre responder com HTML, mas no caso de menus não tenho tanta certeza
  Fico curioso sobre a opinião de especialistas em acessibilidade quanto ao que é melhor: elementos alternáveis ou uma transição de página inteira para abrir um menu
  Aqui, a Popover API parece uma solução melhor, porque permite oferecer um menu sem JavaScript e sem uma ida e volta completa da página
  No restante, concordo que não é preciso ter medo de transições de página. Hoje em dia, até navegações no estilo SPA quase sempre não são difíceis de tornar acessíveis em SSR e sites estáticos

  • Não sou especialista em acessibilidade, mas como alguém que instalou o NVDA para desenvolvimento web, não sinto uma grande diferença na experiência do usuário
    A navegação entre páginas redefine a posição atual, mas se a intenção era abrir o menu e a pessoa de fato chega ao menu, os dois casos são bem parecidos
    Ainda assim, como acontece mesmo para quem não usa leitor de tela, abrir um menu e ir para uma nova página parece bastante estranho
  • A palavra-chave é can, não should. Se páginas HTML forem adequadas para a interação, use-as; se outra abordagem for mais apropriada, use essa
    Por exemplo, se a pergunta for se você deve fazer dois estados diferentes de uma página HTML para expandir/recolher um componente, ou usar a tag <details>, então obviamente é a segunda opção
    Da mesma forma, usar a Popover API é totalmente válido. A ideia é evitar precisar de JavaScript para interações dentro da página, não insistir em navegação HTML multipágina

• A abordagem apresentada carrega o menu dinamicamente com JavaScript e onclick, então há latência e mais um ponto de dados adicionado à jornada do usuário
  Em vez disso, você pode colocar o menu em cada página e mostrá-lo ou escondê-lo com o elemento <details> ou o seletor CSS :focus-within
  https://nlnet.nl funciona dessa forma

• A abordagem descrita, na prática, não funciona direito. Se você desativar o JavaScript, abrir um post do blog e depois abrir e fechar o menu, vai para a home (/), não de volta ao post original
  Para colocar o link correto no botão de fechar, esse método só se sustenta se o backend renderizar o menu dinamicamente
  Pessoalmente, prefiro a Popover API quando possível. Assim dá para renderizar tudo estaticamente sem backend

  • O link do ícone X no menu aponta para https://blog.jim-nielsen.com/, mas com JavaScript ativado parece que o manipulador onclick intercepta a navegação

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

    Como envia a pessoa para uma página diferente da indicada no href, isso é uma experiência ruim para o usuário. Eu costumo passar o mouse sobre links para conferir o destino, e não gosto dessa sensação de ter sido enganado

• Por um lado, gostei bastante. Dá para fazer muita coisa só com HTML de forma mais fluida e simples do que com JavaScript
  Por outro, esse jeito parece funcionar principalmente no mobile. Numa página desktop, eu esperaria que o menu estivesse sempre visível ou aparecesse em pop-out, não que exigisse mudar de página
  Aí fico pensando se agora vamos precisar de dois conjuntos de páginas para navegadores diferentes

  • Por outro lado, no mobile, se a conexão estiver instável, você precisa navegar uma vez para o menu e depois de novo para o destino
    O atrito dobra
  • Acho que sou relativamente jovem. Há 20 ou 30 anos, todos os sites funcionavam mais ou menos assim, e o HTML até certo ponto foi pensado para ser usado dessa maneira
    O JavaScript foi quase um acidente
    Acho estranho sentir que isso é mais difícil ou mais complexo do que qualquer solução em JavaScript. É claramente a forma mais simples e mais fácil de criar um site

• Não gostei muito da navegação, mas gostei do efeito de transição e não sabia que isso era possível
  Até apliquei no meu site, que usa um gerador estático em C++ e uma biblioteca de templates feitos por mim: https://vittorioromeo.com/
  Acho que combina especialmente bem com alternância entre tema escuro/claro

• No desktop, clicar em “menu” e ir para outra página não é uma sensação boa. Como acontece um recarregamento completo da página, isso acaba sendo bem incômodo e diferente do esperado
  Para mim, isso interrompe o fluxo de leitura e de pensamento. Quando clico num link para outro site, parece que estou saindo de um cômodo e deixando o anterior para trás; mas quando isso acontece num menu, parece que fui até a porta e acabei numa sala totalmente diferente, o que é desconfortável
  Sinceramente, a ideia em si é boa, mas a sensação de usar não é boa
  E também não sei de que efeito de transição estão falando. No meu ambiente, quando aperto o botão Menu, simplesmente carrega a página Menu como de costume

  • Transições de visualização entre documentos ainda não funcionam no Firefox
    Talvez também não funcionem em outros navegadores, mas meu navegador principal é o Librewolf, um fork do Firefox
    No Chromium, o efeito de transição aparece

• Ideia interessante, mas fico curioso sobre como isso funcionaria no desktop
  Um menu em página inteira parece um pouco exagerado, então trocar a página inteira parece menos adequado

• Não mencionam preload para reduzir a latência ao carregar a página do menu
  Fico curioso para saber o quão bem isso funcionaria

  • Também seria preciso incluir os headers de cache corretos. Aqui, é bem possível que um simples header de expiração já baste
    Aí nem seria necessário voltar ao servidor para revalidar antes de exibir, então a sensação de velocidade seria muito boa

• Há alguns anos vi um jogo de texto feito por @misty que usava links simples como interação e criava a ilusão de escolha
  O HTML simples e a narrativa forte me marcaram bastante