뒤로 가기 버튼은 약속을 지켰다. 페이지가 앞 장면을 잊었다.

요약

• W3C가 2009년 4월 공개한 HTML 5 작업 초안은 pushState()로 상태를 담은 기록을 추가하고 저장된 기록이 다시 활성화될 때 popstate를 보내는 방식을 설명했다. 한 문서 안의 화면도 뒤로 갈 길의 정거장이 될 수 있었다.
• 2014년 HTML5 권고안은 replaceState()를 함께 설명하고, 작은 게임이 뒤로 가기 후 event.state를 받아 화면을 다시 그리는 예를 실었다. 브라우저는 표를 보관하고 페이지는 무대를 바꿨다.

뒤로 가기 버튼은 약속대로 움직였다. 이전 기록으로 돌아갔다. 하지만 페이지는 다음 장면의 옷을 입은 채 무대에 서서 관객을 멀뚱히 바라봤다. 독자는 버튼이 고장 났다고 했다. 브라우저 손에는 올바른 표가 있었고, 웹 애플리케이션은 옛 배경을 잃어버렸다.

사이트가 문서를 새로 읽어 오지 않고 페이지 조각을 바꾸기 시작하면서 이런 엇박자가 드러났다. 사진 모음에서 다음 사진을 보고, 검색 결과를 바꾸고, 지도를 다른 동네로 옮긴다. 화면은 변했는데 주소는 그대로일 수 있다. 독자가 뒤로 가기를 눌러 앞 사진이나 결과나 장소를 다시 보려 해도, 페이지가 그 변화를 기록으로 남기지 않았다면 브라우저는 더 먼 곳으로 넘어간다. 브라우저는 걸어온 단계를 알고, 페이지는 자기 화면의 변화를 안다. 두 기록을 이어야 했다.

2009년 4월 23일 W3C의 HTML 5 작업 초안은 연결 방법을 적었다. History에는 익숙한 back, forward, go가 있었다. pushState(data, title, url)는 세션 기록에 상태를 담은 항목을 더했다. 저장된 상태 항목이 다시 활성화될 때는 popstate가 전달됐다. 같은 문서의 한 화면에도 주소와 상태를 붙일 수 있게 됐다. 브라우저는 페이지 안의 변화 사이를 되짚을 발판을 얻었다.

초안의 예에는 위치를 북마크할 수 있는 게임이 나온다. 게임 속 위치가 바뀌면 페이지가 새 위치를 그리고 주소와 기록도 함께 움직인다. 사용자가 뒤로 가면 브라우저가 옛 단계의 상태를 찾는다. 게임은 그 값을 읽어 캐릭터를 원래 자리에 그려야 한다. 표를 보관했다고 브라우저가 게임판까지 다시 칠해 주는 것은 아니다. 무대 담당자는 여전히 페이지 안에 있다.

새 단계를 더할지 지금 단계를 바꿀지도 중요하다. 2014년 10월 28일 W3C HTML5 권고안은 pushState()가 항목을 추가하고 replaceState()가 현재 항목을 고친다고 설명한다. 독자가 다시 찾을 만한 화면에는 새 정거장이 어울린다. 같은 화면을 조금 수정했다면 지금 정거장에 남아도 된다. 키 한 번 칠 때마다 기록을 늘리면 뒤로 가기가 긴 행군이 된다. 중요한 화면 변화를 기록하지 않으면 버튼은 독자가 막 지나온 곳을 건너뛴다.

2014년 문서의 선 위를 움직이는 작은 게임은 분담을 또렷하게 보여 준다. 위치가 달라지면 history.pushState(...)를 부른다. 브라우저 기록을 따라 이동하다 popstate가 오면 onpopstate가 event.state를 setupPage()에 넘겨 화면을 다시 마련한다. 몇 줄짜리 코드 안에서 브라우저가 기록을 고르고 페이지가 장면을 복원한다. 주소는 맞는데 화면이 틀리다면, 옳은 공연의 포스터가 엉뚱한 무대에 걸린 셈이다.

페이지가 주소를 마음대로 위장할 수는 없었다. 2014년 권고안은 새 URL이 현재 문서와 호환되는지 검사했다. WHATWG 현행 HTML 표준의 탐색과 기록 장도 주소를 고칠 수 있는 범위를 정한다. HTTP나 HTTPS 페이지에서 경로, 검색 부분, 조각은 허용된 조건 안에서 바꿀 수 있다. 메서드 한 번으로 다른 사이트의 간판을 가져다 붙일 수는 없다. 바뀐 주소는 화면을 가리키는 정직한 표지여야 한다.

상태 값은 두 작업자 사이의 짧은 쪽지다. 브라우저가 그 값을 기록 항목과 함께 보관한다. 페이지는 뜻을 정한다. 선택된 탭, 지도 위치, 카드 번호일 수 있다. 독자가 돌아오면 popstate가 쪽지를 건넨다. 페이지가 이를 무시하면 주소창과 화면은 서로 다른 이야기를 한다. 브라우저의 서랍은 정돈돼 있는데 무대 담당자가 호출을 못 들은 것이다.

History API가 독자의 뒤로 가기 버튼을 사이트에 넘긴 것은 아니다. 누르는 사람은 독자이고, 세션 기록을 이동하는 것은 브라우저다. 사이트는 자기 화면의 변화 중 무엇을 기록으로 만들지, 어떤 상태를 붙일지, 옛 단계가 활성화되면 무엇을 그릴지 결정한다. 이 작은 협업으로 한 문서 안에서 계속 변하는 페이지에도 익숙한 돌아갈 길이 생겼다.

2009년 초안과 2014년 권고안은 그 약속의 두 장면이다. 앞선 문서는 상태 항목을 추가하는 방법을 이미 설명했다. 뒤의 문서는 추가와 교체를 함께 다루고 기록 사건 뒤 화면을 복원하는 예를 실었다. WHATWG의 살아 있는 문서도 더 넓은 탐색 체계에서 이 고전적인 메서드를 규정한다. 버튼의 모양보다 중요한 것은 기억의 분담이다. 브라우저는 장면의 순서를 기억하고 페이지는 각 장면의 모습을 기억한다.

독자의 바람은 오래됐고 단순하다. 뒤로 가기를 누르면 아까 있던 곳이 나와야 한다. History API는 움직이는 페이지가 매번 문서를 새로 불러오지 않고도 그 약속을 지킬 방법을 줬다. 브라우저가 올바른 기록을 찾았는데 페이지가 다른 장면에 남아 있다면, 대사를 외운 배우는 뒤로 가기 버튼 하나뿐이다.