Resumo

  • Um rascunho HTML 5 do W3C de abril de 2009 descreveu pushState() acrescentando uma entrada com estado e popstate quando uma entrada guardada voltava a ser ativa. Vistas dentro de um documento podiam ganhar passos no histórico.
  • A Recomendação HTML5 de 2014 descreveu também replaceState() e mostrou um jogo que redesenhava a tela a partir de event.state depois de Voltar. O navegador guardava o bilhete; a página trocava o cenário.

O botão Voltar havia feito exatamente seu serviço. Chegara à entrada anterior do histórico. A página, porém, permanecia com a roupa da próxima cena e encarava a plateia. O público chamava o botão de quebrado. O navegador tinha o bilhete certo; o site perdera o cenário correspondente.

O desencontro ficou mais comum quando os sites começaram a mudar partes da página sem pedir um documento novo a cada movimento. A galeria avançava uma foto, a busca trocava resultados, o mapa passava a outro bairro. A tela mudava; o endereço podia ficar imóvel. Então o leitor apertava Voltar para rever a foto, os resultados ou a localização anterior. Sem uma entrada de histórico para a mudança interna, o navegador pulava para outro lugar. Era preciso aproximar a memória do navegador, que conhece as etapas, e a da aplicação, que conhece seus painéis.

O rascunho HTML 5 do W3C de 23 de abril de 2009 descreveu o encaixe. Sua interface History incluía back, forward e go. pushState(data, title, url) adicionava uma entrada com estado ao histórico da sessão; popstate era associado à ativação de uma entrada desse tipo. Uma vista da mesma página podia ter seu próprio endereço e um dado guardado, sem trocar o documento inteiro. O navegador passava a ter por onde voltar dentro da aplicação.

Um exemplo do rascunho pensava num jogo cuja posição podia virar uma URL para guardar. O jogador avançava; a página desenhava a nova posição; endereço e histórico podiam avançar junto. Ao usar Voltar, o navegador encontrava o estado de uma etapa anterior. O jogo precisava desenhar a posição antiga. Guardar o bilhete não significa que o navegador saiba pintar a tela do jogo sozinho. A equipe de palco ainda trabalhava para a aplicação.

Adicionar e substituir uma entrada são escolhas diferentes. Na Recomendação HTML5 do W3C de 28 de outubro de 2014, pushState() acrescentava uma etapa, enquanto replaceState() atualizava a atual. Uma mudança de vista que o leitor talvez queira desfazer pode merecer um passo novo. Corrigir algo na vista presente pode manter o mesmo passo. Cada tecla transformada em entrada faria de Voltar uma caminhada interminável; não registrar nenhuma mudança importante faria o botão saltar por cima do caminho percorrido.

O texto de 2014 trazia um jogo simples sobre uma linha. Quando a posição mudava, ele chamava history.pushState(...). Seu tratamento de popstate passava event.state para setupPage(), reconstruindo a tela durante a travessia do histórico. O exemplo cabia em poucas linhas e mostrava a divisão inteira. O navegador selecionava a entrada; a aplicação montava a cena. Uma URL correta sobre um conteúdo errado é a placa da peça certa pregada no palco vizinho.

A URL também tinha limites. A Recomendação de 2014 verificava se o novo endereço permanecia compatível com o documento atual. O capítulo de navegação e histórico do padrão HTML vivo da WHATWG continua a definir esse perímetro. Para páginas HTTP ou HTTPS, caminho, consulta e fragmento podem mudar dentro das condições permitidas; a página não pode anunciar que se tornou outro site com uma simples chamada. O endereço ajuda o leitor quando aponta honestamente para a aplicação.

O dado de estado é um recado passado entre dois profissionais. O navegador guarda o valor com a entrada. A aplicação decide o que ele quer dizer: aba selecionada, posição do mapa, identificador de um cartão. Quando o leitor retorna, popstate entrega o recado. Se a página o ignora, a barra de endereço e a tela passam a contar histórias diferentes. O arquivo do navegador está em ordem; o cenógrafo perdeu a deixa.

A API não entregou ao site os controles do leitor. Voltar e Avançar continuam sendo acionados pela pessoa, e o navegador percorre o histórico. O site decide quando uma vista interna merece uma entrada, que estado acompanhará essa entrada e como a vista será redesenhada quando ela voltar. Essa pequena cooperação permitiu que uma página mutável mantivesse um trajeto reconhecível.

O rascunho de 2009 e a Recomendação de 2014 mostram momentos desse acordo. O primeiro já descrevia a inclusão de entradas com estado; a segunda tratava inclusão e substituição lado a lado e exemplificava o redesenho após um evento. O texto vivo da WHATWG mantém esses métodos dentro de um modelo mais amplo de navegação. O navegador lembra a ordem dos atos; a página precisa lembrar a aparência de cada um.

Para o leitor, a regra é antiga: Voltar deve me levar ao lugar onde eu estava. A API History deu à página dinâmica um modo de cumprir a promessa sem carregar outro documento a cada mudança. Quando o botão encontrava a entrada certa e a página continuava na cena errada, o único ator que sabia suas falas era o botão.