Quando incluo um link para uma seção em uma página — esse link, ao ser clicado, não modifica o histórico do navegador. Ao navegar para trás, ele prossegue para sair da página, em vez de retornar à posição da página onde o link está definido.
Edição: Bem, neste Discourse, não consigo criar um elemento com um ID, então não posso demonstrar isso aqui. O código abaixo é o que eu gostaria de fazer — mas isso é apenas para ilustrar e não impacta a essência do meu problema:
<div id="link-target"></div>
*Esta seção é linkada a partir de cima. Nada para ver aqui.*
Isso é meio que esperado. Se você clicar em um link para outro post no mesmo tópico, ele também não é adicionado ao histórico, e como é um link completo sem fragmentos, nunca adicionamos navegação dentro do tópico ao histórico.
Considero esse comportamento extremamente inesperado
Aqui está uma página de exemplo sem JavaScript. No Chromium, clicar nesse link leva você ao final da página. Ao clicar em voltar, você retorna ao local de onde clicou. Esse é o comportamento esperado que você verá em qualquer outro site que não consuma esse histórico.
Suponho que o Discourse esteja lidando com fragmentos de URL por meio de JavaScript, rolando até o local e, portanto, o histórico precisaria ser empurrado explicitamente.
@codinghorror expressa uma opinião forte e definitiva sobre isso aqui. É surpreendente ver uma opinião tão forte sobre uma mudança no comportamento padrão dos navegadores web. Para ser justo, ainda não usei o Discourse para navegação pesada por tópicos e, portanto, não consigo apreciar a obviedade do argumento dele.
Estou usando o Discourse em parte para documentação e esse comportamento é extremamente disruptivo, a ponto de eu ter medo de clicar em um link e perder minha posição na página.
Se você se sentir tentado a clicar em qualquer um dos links do sumário e depois retornar ao ponto de partida usando o histórico do navegador, não conseguirá.
Por que fornecer um sumário desde o início?
Para aqueles sites que desejam suportar a navegação padrão do navegador, alguma sugestão?
Estou investigando a modificação do comportamento de rolagem para o elemento, que suspeito estar por trás disso, mas estou começando literalmente sem nenhum conhecimento do código-fonte Chegar lá eventualmente, mas se alguém tiver algumas dicas, agradeço a ajuda!
Dependendo do contexto em que você usará suas âncoras, talvez este plugin tabela de conteúdo seja útil (e, na minha opinião, ele se encaixaria bem na página de Termos de Serviço e FAQ)?
Exemplo aqui.
Eu nunca percebi que isso me incomodava até você apontar. Muitas vezes, tento voltar para onde cliquei em um link no Discourse e, em vez disso, acabo em uma página anterior. Muito irritante. Eu sempre atribuí isso a uma combinação do aplicativo iOS, já que o uso para quase tudo no Discourse, e a erro do usuário.
Este componente de TOC foi muito bem feito e estamos usando em todas as páginas da documentação — estamos muito gratos pelo trabalho dedicado a ele!
No entanto, o problema de navegação permanece. Clicar em um link no TOC não modifica o histórico do navegador e, portanto, ao voltar, você sai da página.
Isso certamente é verdade. Seria ótimo corrigir isso, @Johani, mas tenho a sensação de que é muito complicado. Talvez possamos apenas usar pushState ao clicar em um link do Sumário.
Implementei uma solução alternativa (que, sob a perspectiva do Discourse sobre navegação por links, pode ser considerada uma abordagem adequada para personalizar um site) por meio de um componente de tema. Isso segue o padrão usado pelo DiscoTOC, onde um marcador é adicionado a uma postagem para acionar o comportamento. O código aplicável está aqui.
Acho que modificar o DiscoTOC para usar fragmentos de URL e o histórico do navegador é uma boa ideia. Isso exige mudar a abordagem do componente em relação à navegação, o que não é uma alteração trivial. O DiscoTOC usa atributos de dados para passar os alvos, em vez de usar os hrefs dos links. Não há nenhuma tentativa de refletir a nova localização da página na URL do navegador (window.location).
Acredito que o padrão que estou usando acima poderia funcionar para o DiscoTOC, mas isso teria implicações mais amplas para esse componente, dada sua abordagem atual.
