Resumen

  • Un borrador HTML 5 del W3C de abril de 2009 describió pushState() para añadir una entrada de estado y popstate al activar una entrada guardada. Atrás podía recorrer vistas de un mismo documento.
  • La Recomendación HTML5 de 2014 puso replaceState() junto a pushState() y mostró un juego que reconstruía la pantalla con event.state después de volver. El navegador guardaba la entrada; la página montaba el escenario.

El botón Atrás había hecho su trabajo. Llegó a la entrada anterior del historial. La página, mientras tanto, seguía vestida para la escena siguiente y miraba al público como si nada. Los lectores acusaban al botón. El navegador conservaba la entrada correcta; la aplicación había perdido el decorado.

El desajuste se volvió visible cuando los sitios empezaron a cambiar partes de una página sin pedir un documento nuevo a cada paso. Una galería pasaba a otra foto, una búsqueda cambiaba sus resultados, un mapa se movía a otro barrio. La pantalla avanzaba y la dirección podía quedarse quieta. Después el lector pulsaba Atrás para recuperar la foto, los resultados o el mapa anterior. Si la web no había dado al navegador una entrada para esa vista, Atrás saltaba a otro sitio. Había que juntar dos memorias: la del navegador para los pasos y la de la aplicación para las imágenes.

El borrador HTML 5 del W3C fechado el 23 de abril de 2009 describía ese encuentro. Su interfaz History incluía los controles conocidos back, forward y go. pushState(data, title, url) añadía al historial de sesión una entrada con estado, mientras que popstate aparecía al volver a activar una entrada de ese tipo. Una vista dentro de la misma página podía llevar una dirección y unos datos propios. Así el navegador tenía por dónde volver aunque el documento no se hubiera sustituido.

El borrador recurría a un ejemplo de juego cuya posición podía quedar en una dirección guardable. El jugador avanzaba, la página dibujaba la nueva posición y la entrada del historial podía avanzar con ella. Al retroceder, el navegador recuperaba el estado de una parada anterior. El juego debía dibujar la posición correspondiente. Guardar una entrada no equivale a que el navegador pinte el tablero con sus propias manos. El técnico de escena seguía trabajando para la página.

La diferencia entre añadir y sustituir una entrada cambió el modo de pensar el recorrido. La Recomendación HTML5 del W3C de 28 de octubre de 2014 describía pushState() para añadir una parada y replaceState() para actualizar la parada actual. Una vista a la que el lector querrá regresar puede merecer un paso. Una corrección de la misma vista puede quedarse en el paso presente. Si cada tecla suma una parada, un solo toque de Atrás se convierte en una excursión; si ninguna vista la suma, el botón salta por encima del trabajo del lector.

El texto de 2014 incluía un pequeño juego sobre una línea. Cuando cambiaba su posición, llamaba a history.pushState(...). Su manejador onpopstate pasaba event.state a setupPage() para preparar la pantalla al recorrer el historial. En pocas líneas aparecía todo el contrato: el navegador elegía la entrada y la aplicación devolvía la escena. Una barra de direcciones correcta encima de un contenido equivocado se parece a la cartelera de una obra pegada en la sala de otra.

La dirección tampoco era un disfraz ilimitado. La Recomendación de 2014 comprobaba que la URL escrita con el estado perteneciese al ámbito permitido del documento. El capítulo de historial del estándar HTML vivo de WHATWG sigue fijando esa frontera. En una página HTTP o HTTPS pueden variar ruta, consulta y fragmento dentro de las condiciones establecidas; una llamada no permite presentarse como otro sitio con un nombre distinto. La dirección puede seguir el movimiento de la página sin volverse una placa falsa.

Los datos de estado son un pequeño contrato entre el navegador y el sitio. El primero los conserva junto a la entrada; el segundo decide qué significan: una pestaña elegida, un punto del mapa, el identificador de una tarjeta. Cuando el lector regresa, popstate lleva esa pista a la aplicación. Si esta la ignora, la dirección y la pantalla cuentan historias distintas. El registro del navegador funciona; el tramoyista no ha oído la señal.

La API tampoco entregaba a la web los mandos de navegación del lector. El lector pulsaba Atrás y Adelante, y el navegador recorría la sesión. El sitio decidía cuándo uno de sus cambios merecía una entrada, qué dato guardar y cómo dibujar la vista al volver. Esta cooperación permitió que una página cambiante siguiera ofreciendo un trayecto reconocible. El navegador conocía las paradas; la web conocía el aspecto de cada una.

El borrador de 2009 y la Recomendación de 2014 dejan ver dos momentos del mismo reparto. El primero ya describía cómo añadir estados al historial. La segunda presentaba juntas las operaciones de añadir y sustituir y daba un ejemplo explícito de reconstruir la vista tras un evento. El estándar vivo de WHATWG mantiene esos métodos dentro de un modelo de navegación más amplio. La historia no depende de una animación vistosa: depende de que el sitio y el navegador se pasen una nota legible.

Para el lector, la expectativa es antigua y razonable: Atrás debería llevarme adonde estaba. La API History dio a las páginas dinámicas una manera de cumplirla sin cargar otro documento en cada giro. Cuando el botón encontraba la entrada correcta y la página seguía en la escena equivocada, el único actor que sabía su papel era el botón.