Summary

  • W3C가 2011년 6월 2일 공개한 Page Visibility 작업 초안은 문서가 보이는지 읽을 수 있는 상태와 상태가 바뀔 때의 visibilitychange를 설명했다.
  • 초안의 예시는 웹메일이었다. 화면에 보일 때는 몇 초마다 새 메일을 확인하고, 뒤로 숨으면 몇 분마다 확인하도록 바꿀 수 있었다. 간격은 앱이 정했다.

메일 탭은 지도와 기사와 장바구니 뒤에 묻혀 있다. 주인은 다른 일을 한다. 그런데도 메일 페이지는 또 서버에 새 편지가 있는지 묻는다. 잠시 뒤 다시 묻는다. 빈 사무실의 우편함을 몇 초마다 열어 보는 성실한 직원 같다. 이런 탭이 여럿이면 그 성실함의 대가는 처리 시간과 배터리 몫이 된다.

W3C가 2011년 6월 2일 낸 Page Visibility 초안은 정보의 엇갈림을 다뤘다. 브라우저는 어느 탭이 앞에 있는지, 창이 최소화됐는지, 문서가 화면에 보이는지 안다. 페이지는 document.hidden과 가시성 상태를 읽고, 상태 변화가 생기면 visibilitychange를 받을 수 있게 됐다. 브라우저가 자신이 관리하는 창의 사정을 알려 주고, 페이지가 일정을 고르는 방식이다.

초안의 메일 예시는 아주 평범해서 좋다. 독자가 받은편지함을 바라본다면 몇 초마다 새 편지를 확인할 수 있다. 다른 탭으로 가면 몇 분 간격으로 늦출 수도 있다. 어느 알림이 얼마나 급한지는 메일 서비스가 안다. 지금 화면 앞에 독자가 있는지는 브라우저가 안다. 두 쪽의 정보가 만나는 순간, 보이지 않는 페이지도 앞에 있는 척 서둘러 일할 이유가 줄어든다.

2011년 1월 W3C 공개 메일링리스트의 제안에는 다른 장면도 있었다. 퍼즐 탭을 가리면 게임 시계를 멈추고, 정기적인 조회를 쉬며, 실제로 누군가 탭을 볼 때까지 영상을 시작하지 않는 것이다. 같은 “보이지 않는다”는 신호를 받아도 앱마다 결론이 다르다. 게임은 플레이어의 시간을 지키고, 메일은 문의 횟수를 아끼고, 영상은 관객을 기다린다.

그렇다면 숨었다는 말은 어떤 상태일까. 초안은 뒤쪽 탭, 최소화한 브라우저, 잠금 화면을 예로 들었다. 문서의 일부라도 어느 화면에 보이면 가시 상태로 취급했다. 화면을 크게 가리는 접근성 도구를 쓰더라도 그 도구를 통해 페이지를 볼 수 있는 경우를 고려했다. 페이지가 포커스의 출입만으로 짐작하는 것보다 브라우저가 실제 표시 상태를 전하는 편이 정확했다.

상태는 하루에 여러 번 바뀐다. 처음 열 때 document.hidden을 한 번 읽는 것으로는 메일을 보다가 지도로 갔다 다시 돌아오는 사람을 따라갈 수 없다. visibilitychange는 그 전환을 알려 준다. 2011년 7월의 최종 의견 수렴 초안도 생활 속 예시를 남기며 인터페이스를 다듬었다. 바뀌는 순간마다 앱은 자신의 근무표를 다시 정할 수 있었다.

2013년 5월 14일 W3C 권고안은 hidden, visibilityState, visibilitychange를 정리했고 화면 밖 사전 렌더링이나 문서가 떠나는 상황의 추가 상태도 조건에 따라 기술했다. 같은 해 10월의 제2판 권고안은 꽤 인간적인 수정을 남겼다. 4.3절의 visibilitychange 이벤트 이름에 난 오타 하나를 고친 것이 유일한 변경이었다. 페이지를 누가 보고 있는지 정의하는 데 몇 해를 쓰고, 마지막에는 알림 이름을 다시 맞춤법 검사했다.

이 문제는 Web Workers가 해결한 것과 다르다. Worker는 긴 계산을 클릭에 반응해야 할 자리에서 다른 실행 공간으로 옮긴다. Page Visibility는 지금 그 계산이나 조회를 얼마나 자주 할지 판단할 단서를 준다. 메일 앱은 둘 다 쓸 수 있다. 계산은 따로 돌리고, 숨은 동안 새 편지를 덜 자주 확인한다. 일할 장소와 일할 시간은 별도의 결정이다.

2011년 초안은 CPU와 전력 효율을 목표로 내세웠다. 원리는 사무실에서 쉽게 이해된다. 아무도 없는 방의 우편함을 몇 초마다 뒤질 필요는 없다. 브라우저는 방이 비었다는 걸 알고 있었다. 마침내 그 소식이 탭 안의 성실한 직원에게 전달됐다.