Кратко

  • Проект HTML 5 W3C от апреля 2009 года описывал pushState() для добавления записи с состоянием и popstate при возвращении к сохранённой записи. Разные виды одного документа могли стать остановками истории.
  • Рекомендация HTML5 2014 года описала также replaceState() и показала игру, которая после «Назад» заново рисовала экран из event.state. Браузер хранил билет, страница ставила декорацию.

Кнопка «Назад» всё сделала как надо. Она пришла к предыдущей записи истории. Страница осталась на сцене в костюме следующего акта и удивлённо смотрела в зал. Зрители объявили кнопку сломанной. У браузера был верный билет; приложение потеряло нужный задник.

Разногласие стало заметным, когда сайты начали менять части страницы без новой загрузки документа. Галерея показывала другой снимок, поиск обновлял результаты, карта переходила в другой район. Экран двигался вперёд, а адрес мог стоять на месте. Читатель нажимал «Назад» ради прежней фотографии, выдачи или карты. Если сайт не оставил браузеру запись о внутреннем переходе, тот уходил куда-то дальше в прошлое. Память браузера о шагах нужно было связать с памятью приложения о содержимом.

Рабочий проект HTML 5 W3C от 23 апреля 2009 года описал такую связь. Интерфейс History включал знакомые back, forward и go. Метод pushState(data, title, url) добавлял в историю сеанса запись с состоянием; при повторной активации сохранённой записи возникало событие popstate. Внутренний вид одного документа мог получить собственный адрес и данные. У браузера появлялась тропинка через изменения, которые прежде знал только сайт.

В проекте был пример игры, где положение можно сохранять как адрес. Игрок передвинулся; страница показала новую точку; адрес и запись истории переместились вместе с ним. После «Назад» браузер нашёл старую запись и её состояние. Игра должна была нарисовать игрока на прежнем месте. Хранение билета не превращает браузер в художника игрового поля. Художник всё ещё работает в приложении.

Добавление записи и замена текущей создают разные обратные пути. Рекомендация HTML5 W3C от 28 октября 2014 года описывает pushState() как добавление шага, а replaceState() — как обновление нынешнего. Новый вид, к которому читатель может захотеть вернуться, заслуживает своей остановки. Исправление текущего экрана может остаться на той же. Если каждой букве выделить запись, одно нажатие «Назад» превратится в поход; если не записывать значимые виды, кнопка перескочит через работу читателя.

В тексте 2014 года есть простая игра с движением по линии. Когда позиция меняется, код вызывает history.pushState(...). При обходе истории обработчик onpopstate передаёт event.state функции setupPage(), и она перестраивает экран. Пример короткий, но распределение работы видно целиком. Браузер выбирает запись; приложение восстанавливает вид. Верный адрес над неверным экраном похож на афишу нужного спектакля, повешенную над чужой сценой.

У адреса были границы. Рекомендация 2014 года проверяла, что новый URL совместим с текущим документом. Нынешняя глава живого стандарта HTML WHATWG о навигации и истории по-прежнему задаёт условия изменения адреса. Для страниц HTTP и HTTPS путь, строка запроса и фрагмент могут меняться в допустимых пределах; метод не позволяет странице объявить себя другим сайтом. Адрес помогает читателю, пока остаётся честным адресом приложения.

Данные состояния — короткая записка между двумя работниками. Браузер хранит значение рядом с записью. Приложение решает, что оно означает: выбранную вкладку, координаты карты или номер карточки. При возвращении popstate передаёт записку странице. Если страница её игнорирует, адресная строка и видимый экран рассказывают разные истории. Архив браузера в порядке; сценический рабочий пропустил свой выход.

API не передавал сайту кнопку читателя. «Назад» и «Вперёд» выбирает человек, а браузер проходит по истории сеанса. Сайт решает, когда внутреннее изменение заслуживает записи, какие данные в неё положить и как нарисовать вид при повторной активации. Это небольшое сотрудничество оставило знакомый обратный путь внутри документа, который постоянно меняется.

Проект 2009 года и Рекомендация 2014 года показывают две стадии договора. Первый уже описывал добавление записей с состоянием. Второй поставил рядом добавление и замену и показал восстановление экрана после события истории. Живой текст WHATWG продолжает определять эти методы в более широкой системе навигации. Главное здесь не форма стрелки: браузер помнит порядок сцен, а страница должна помнить внешний вид каждой.

Для читателя обещание старое и понятное: «Назад» должно вернуть меня туда, где я был. History API дал меняющейся странице способ сдержать его без новой загрузки документа на каждом повороте. Когда кнопка находила верную запись, а страница оставалась не в том акте, только кнопка знала свою роль.