이 문서는 Page Visibility (Second Edition) (W3C Recommendation 29 October 2013)의 한국어 번역본입니다.
이 문서에 오역 및 오타를 포함할 수 있습니다. 가능하면 원문도 확인하시길 바랍니다.
스펙 문서의 규범적인 정의에 수정이 있을 가능성이 있기 때문에 errata도 참조하시길 바랍니다.
번역본도 있습니다.이 번역본은 한국어 번역본 입니다
Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
이 스펙 문서는 사이트 개발자가 전력 및 CPU 측면에서 효율적인 웹 어플리케이션을 개발할 수 있도록, 현재 페이지의 가시성 상태를 프로그램에서 판별하는 방법을 정의합니다.
이 섹션은 이 문서를 공개했을 때 상태에 대해 설명합니다. 다른 문서가 이 문서를 덮어쓸 가능성이 있으니 주의하시길 바랍니다. 이 문서 및 W3C에서 공개한 다른 문서의 최신 버전은 W3C technical reports index at http://www.w3.org/TR/에서 확인 가능합니다.
이 문서는 "페이지 가시성 (두번째 에디션)"의 W3C 권고안 문서입니다. 2013년 후보 권고안 단계에서 작성한 페이지 가시성 test suite를 기반으로 하는 구현 레포트도 제공합니다.
첫번째 에디션과 두번째 에디션 간 변경점은 섹션 4.3에서 visibilitychange event의 이름 변경입니다.
public-web-perf@w3.org (archived)으로 제목에 [PageVisibility]를 붙여서 코멘트를 남길 수 있습니다.
페이지 가시성 스펙 문서에서 이용하고 있는 열거 타입을 지원하는 idlharness.js 업데이트와 함께, 디렉터는 WEB IDL 부분의 안정성 증거에 의해 만족하고 있다고 하였습니다. 디렉터는 이 스펙이 DOM4에서 Document 정의로 제공하고 있던 것의 확장형태인 HTML5 스펙 문서에서 제공하는 Doucment 정의 부분 인터페이스 규정에 따른 확장에 의존하여 참조하고 있습니다. 이 인터페이스는 DOM Level 3 Recommendation에서도 정의하고 있습니다. 페이지 가시성 스펙 문서에서 이용하고 있는 열거 타입을 지원하는 idlharness.js 업데이트와 함께, Web IDL 관련 안정성은 디렉터로부터 승인을 얻었습니다. 확장 그 자체는 본질적으로 Doucment 인터페이스의 다른 부분에 변경을 가하지 않은 순수한 확장이므로, 페이지 가시성의 구현이 DOM4의 변경에 영향을 받지 않으리라 볼 수 있습니다. 이런 특성을 감안하여 현재 스펙 문서가 충분히 독립적이며, W3C 권고안으로 승격될 수 있다는 것이 결정되었습니다.
이 문서는 W3C Interaction Domain 내 Rich Web Clients Activity의 일부인 Web Performance 워킹 그룹에서 제공합니다.
이 문서는 W3C 멤버, 소프트웨어 개발자, 그리고 다른 W3C 그룹 및 관계자들이 평가를 진행하여, 디렉터에 의해 W3C 권고안으로 발표했습니다. 이 문서는 안정적이며, 참고자료로 사용하거나 다른 문서에서 인용해도 좋습니다. 스펙 문서의 권고를 통해 W3C가 하는 역할은 스펙 문서에 관심을 모으고 다방면으로 퍼뜨리는 일입니다. 이를 통해 웹의 기능과 상호운용성 향상을 기대할 수 있습니다.
이 문서는 2004년 2월 6일 W3C 특허 정책을 따르는 그룹에서 작성하였습니다. W3C는 그룹의 성과물에 관련하여 모든 공개 특허 공개 리스트를 관리합니다. 여기에는 특허 공개에 대한 지시사항도 포함합니다. 특허에 대해서 충분한 지식이 있는 사람이, 스펙 문서의 Essential Claim(s)에 인정된다고 파악되는 경우, W3C 특허 정책 제 6장에 의거하여 정보를 공개해야 할 필요가 있습니다.
이 섹션은 표준에 준하는 내용이 아닙니다.
페이지 가시성 스펙 문서는, 사이트 개발자를 위해 프로그램이 문서의 현재 가시성 상태를 판별하거나, 가시성 상태가 변화할 때 신호를 받을 수 있는 방법을 정합니다. 페이지의 가시성 상태의 판별 기능이 없는 경우, 웹 개발자들은 웹 페이지를 항상 가시상태로 두어 설계해야 합니다. 이는 머신 리소스를 더 많이 소비할 뿐만 아니라, 웹 개발자들이 페이지가 유저가 볼 수 있다는 것에 기본을 두고 실행할 때 동작을 바꾸는 것도 어려워 집니다. 웹 페이지의 디자인을, 가시성에 대해서 판별 가능한 케이스에서 할 수 있다면, 사용자 경험 및 사이트 효율성을 향상시킬 수 있습니다.
이 인터페이스는 웹 어플리케이션을 유저가 볼 수 있는 상태인지 아닌지에 기반을 두어 동작을 바꿀 수 있습니다. 예를 들어, 페이지는 페이지가 보이지 않는 시점부터 사용량을 줄이기 위한 용도로 이 인터페이스를 사용할 수 있습니다. 더 구체적으로 설명하자면, 웹 메일 클라이언트에서 보고 있는 경우에는 몇초마다 새로운 메세지의 수신을 서버에 확인하고 숨겨놓았을 때는, 몇분에 한번씩 확인하는 등입니다. 이 인터페이스는 전력 관리와 관계가 없는 경우에도, 더 쾌적한 사용자 경험을 제공하는 목적으로 사용할 수 있습니다. 예를 들어 퍼즐 게임이 있을 때, 사용자가 보고 있지 않는 경우에는 게임을 중지시키거나, 광고의 업데이트를 정지시키는 데 사용할 수 있습니다.
아래 스크립트에 페이지 가시성이 판별 불가능한 경우, 새로운 메시지의 확인을 몇초동안 하며, 웹 상에서 이론상 메일 클라이언트를 나타냅니다.
<!DOCTYPE html> <html> <head> <script> var timer = 0; var PERIOD = 1000; function onLoad() { timer = setInterval(checkEmail, PERIOD); } function checkEmail() { // Check server for new messages } </script> </head> <body onload="onLoad()"> </body> </html>
스크립트는 유저가 페이지를 보이지 않게 하여 비활성화 상태에 두었다고 하더라도 항상 몇초마다 메시지를 체크할 것입니다. 이는 리소스 관리 효율성이 낮습니다.
Document 인터페이스의 hidden
속성 및 visibilitychange
이벤트를 이용하여 페이지가 보이지 않을 때는 착신 메시지 확인 빈도를 몇분씩으로 줄일 수 있습니다.
아래 스크립트에서 페이지를 볼 수 있을 때는 1초마다, 페이지를 볼 수 없을 때는 1분마다 새로운 메시지 확인을 하는 상상의 메일 클라이언트를 나타냅니다.
<!DOCTYPE html> <html> <head> <script> var timer = 0; var PERIOD_VISIBLE = 1000; var PERIOD_NOT_VISIBLE = 60000; function onLoad() { timer = setInterval(checkEmail, (document.hidden) ? PERIOD_NOT_VISIBLE : PERIOD_VISIBLE); if(document.addEventListener) document.addEventListener("visibilitychange", visibilityChanged); } function visibilityChanged() { clearTimeout(timer); timer = setInterval(checkEmail, (document.hidden) ? PERIOD_NOT_VISIBLE : PERIOD_VISIBLE); } function checkEmail() { // Check server for new messages } </script> </head> <body onload="onLoad()"> </body> </html>
이 스펙문서에서 표준에 준하지 않는 내용이 아닙니다라 표기된 섹션, 작성 가이드라인, 다이어그램, 예제 및 노트는 표준에 준하는 내용이 아닙니다. 그 외의 모든 건 표준에 준하는 내용입니다.
이 스펙 문서 내 키워드 "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"는 RFC 2119에 기술되어있는대로 해석합니다. 가독성을 위해, 이 스펙문서에서 이 키워드들을 모두 대문자로 표기하지는 않습니다.
알고리즘 중 명령적 표현에 따른 요건(예를 들면: "선두 공백문자열 제거", "false를 반환하여 이 절차를 완료" 등) 은 알고리즘을 도입할 때 사용할 수 있는 키워드("must", "should", "may", etc)의 의미로 해석합니다.
일부 적합성 요구사항은 속성, 메소드, 오브젝트에 대한 요구사항으로 언급합니다. 이러한 요구 사항은 사용자 에이전트(UA)에 부과하는 요구사항으로 해석해야 합니다.
알고리즘 또는 특정 스텝으로 기록하는 적합성 요구사항은 최종 결과가 같은 값인 경우, 어떤 방식으로 구현해도 상관 없습니다. (특히, 이 스펙 문서에서 정의하는 알고리즘은 쫓기 쉽도록 기술되어 있어, 성능을 고려하지 않습니다)
이 스펙의 IDL 코드는 Web IDL 스펙에서 언급한 적합 IDL 코드에 부과한 요구 사항에 따르는 것으로 해석해야 합니다. [Web IDL]
Foo
를 인터페이스로 할 때,
"Foo
인터페이스를 구현하는 객체"의 약어로,
용어 "Foo
객체"를 사용합니다.
이 섹션은 표준에 준하는 내용이 아닙니다.
이 스펙문서는 웹 어플리케이션이 프로그램에서 페이지의 현재 가시성을 판별하여, 가시성 변화를 감지하는 기능을 제공하는 인터페이스를 제공합니다.
Document
인터페이스 확장이 스펙은 HTML5 스펙 [HTML5]에서 정의하고 있는 Document 인터페이스를 확장합니다
enum VisibilityState { "hidden", "visible", "prerender", "unloaded" }; partial interface Document { readonly attribute boolean hidden; readonly attribute VisibilityState visibilityState; };
hidden
속성
hidden
속성을 가져올 때,
최상위 레벨 브라우징 콘텍스트(브라우저 뷰포트의 루트 윈도우)[HTML5]에 포함하는 문서에 전체가 가시성을 가지지 않는 경우는 true가, 1개 이상의 스크린에서 일부라도 가시성을 가지는 경우에는 false를 반환해야 합니다. [MUST]
문서의
defaultView가 null인 경우는
hidden
속성을 얻을 때 true를 반환해야 합니다. [MUST]
대체로 full screen이면서, 페이지 뷰도 표시하게 하는 접근성 도구에 대응하는 목적으로는 적용 가능하다면, UA가 최소화 상태는 아니지만, 다른 어플리케이션에 전체가 덮여있는 경우, false를 반환할 수도 있습니다.
예를 들어, 아래의 경우에 hidden
속성은 true를 반환합니다:
마찬가지 예제로, 아래와 같은 경우에는 hidden
속성이 false를 리턴합니다
visibilityState
속성visibilityState
속성 값을 가져올 때, 아래의 DOMString
, 혹은 4.5 벤더 프리픽스에서 정하는 벤더 프리픽스를 붙인 DOMString
을 반환해야만 합니다. [MUST]
hidden
,visible
,prerender
,unloaded
.hidden
최상위 레벨 브라우징 콘텍스트에 포함되어있는 문서가 모든 스크린에서 보이지 않을 때, DOMString
hidden
을 반환해야만 합니다. [MUST]
문서의 defaultView가 null인 경우, visibilityState
속성을 얻을 때 DOMString
hidden
을 반환해야만 합니다. [MUST]
대체로 full screen이면서 페이지 뷰도 표시하게 하는 접근성 도구를 대응하는 경우, 적용이 가능하다면 유저 에이전트가 최소화되어있지 않지만,
다른 어플리케이션에 전체적으로 가려져있는 경우에 visibilityState
속성 값을
hidden
대신에 DOMString
visible
을 취해도 좋습니다. [MAY]
예를 들어 아래와 같은 경우 visibilityState
속성은 DOMString
hidden
을 반환할 것입니다:
visible
최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document가
한개 이상의 스크린에서 특정 일부라도 보이는 경우, visibilityState
속성을 얻을 때 반드시 DOMString
visible
을 반환해야만 합니다. [MUST] hidden
속성이 false값을 가졌을 때와 동일한 상태입니다.
대체로 full screen이면서 페이지 뷰도 표시하는 접근성 도구에서, 유저 에이전트가 최소화 상태가 아니지만 다른 어플리케이션에 가려져 있을 때,
visibilityState
속성 값을 얻을 때
DOMString
visible
을 반환할 수도 있습니다.
prerender
최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document가
로딩을 하였으나 아직 스크린에 나타나지 않았거나 보이지 않는 경우,
visibilityState
속성을 얻을 때 DOMString
prerender
를 반환해야합니다. [MAY]
유저에이전트의 visibilityState 속성의 반환 값 prerender
지원은 옵션입니다.
unloaded
최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document의
유저에이전트가 unload 상태인 경우
visibilityState
속성을 얻을 때 DOMString
unloaded
를
반환해야 합니다. [SHOULD]
유저에이전트의 visibilityState 속성의 반환 값 unloaded
지원은 옵션입니다.
visibilitychange
event
유저 에이전트는
최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document의 가시성이 변경될 때,
Document 이벤트 visibilitychange
를 반드시 발생시켜야 합니다. [MUST]
최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document의 가시성이 변경될 때, 유저에이전트는 반드시 아래 순서대로 동작해야합니다. [MUST]
최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document가 현재 하나 이상의 스크린에서 일부라도 보이고 있는 경우,
session history entry 탐색 중에는 pageshow
이벤트 발생 전에
now visible algorithm을 실행합니다.
그 외의 경우에는 now visible algorithm 실행 태스크를 queue에 쌓아둡니다.
혹은 최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document가 볼 수 없는 상태이거나 유저 에이전트가 Document를 unload한 경우
유저에이전트가 Document를 unload한 경우 unloading document visibility change steps 사이에 now hidden algorithm를 실행합니다.
그 외의 경우에는, now hidden algorithm 실행 태스크를 queue에 쌓아둡니다.
now visible algorithm은 아래 순서대로 동기 실행합니다:
hidden
속성을 false
로 지정합니다.
visibilityState
속성을 visible
로 지정합니다.
버블링이 일어나는 visiblitychange
이벤트를 발생시키며, 취소 불가능하며, Document에 기본 동작은 없습니다.
now hidden algorithm은 아래 순서대로 동기 실행합니다:
hidden
속성을 true
로 지정합니다.
visibilityState
속성을 hidden
으로 지정합니다.
만약 유저 에이전트에서 Document가 unload인 경우
visibilityState
속성을 unloaded
로 지정합니다.
visibilityState
속성을 hidden
대신에 unloaded
로도 사용할 수도 있습니다.
버블링이 일어나는 visiblitychange
이벤트를 발생시키며, 취소 불가능하며, Document에 기본 동작은 없습니다.
벤더 고유 특허 유저 에이전트 확장을 권장하지는 않습니다. 만약 실험적 목적을 위해 확장이 필요한 경우, 벤더는 반드시 아래 확장 메커니즘을 따라야 합니다. [MUST]
벤더가, 실험적 가시성 상태를 위해 visibilityState
속성의 반환값을 확장해야할 필요가 있는 경우,
유저 에이전트는 그 VisibilityState 열거를 갱신할 때, 아래 컨벤션에 따라 DOMString
을 사용해야 합니다.
[vendorprefix]-[name]
여기서,
[vendorprefix]
는 벤더 식별자이며, 대문자가 아니며[name]
은 가시성 상태에 붙은 이름이며, 대문자가 아니며Page Visibility API는 웹 페이지 상 서드 파티 콘텐츠에서도, 최상위 레벨 브라우징 콘텍스트에 포함되어있는 Document의 가시성을 focus나 blur 이벤트의 기존 메커니즘보다 정확하게 판별하도록 설계되어있습니다. 그러나 실용적인 관점에서, 이 추가 노출은 프라이버시에 크게 영향을 주는 수준은 아닙니다.
We would like to sincerely thank Karen Anderson, Nic Jansma, Alex Komoroske, Cameron McCormack, James Robinson, Jonas Sicking, Kyle Simpson, Jason Weber, and Boris Zbarsky to acknowledge their contributions to this work.