이 명세서는 다소 깁니다. 읽기 쉽고 특정 영역에 집중할 수 있도록, 아래에 몇 개의 체크박스를 제공합니다. 체크하면 명세의 일부가 숨겨집니다. 이는 단순히 읽기 보조 도구로 제공된 것이며, 명세 자체는 전체 문서로 남아 있습니다.
1. 소개
이 섹션은 규범적이지 않습니다.
역사적으로 대부분의 브라우저는 사용자가 포커스를 방향적으로 이동할 수 있는 기능을 제공하지 않았습니다. TV 브라우저와 같은 일부 브라우저는 사용자가 화살표 키로 포커스를 이동할 수 있도록 했는데, 이는 일반적인 TV 리모컨에 다른 입력 장치가 없기 때문입니다.
다른 브라우저들은 Shift
키와 화살표 키를 함께 누르는 등
다양한 키 조합으로 공간 탐색을 제어할 수 있도록 했습니다.
이렇게 페이지를 방향적으로 이동하는 기능을 공간 탐색이라고 합니다.
공간 탐색은
그리드와 같은 레이아웃이나 주로 비선형 레이아웃으로 구성된
웹 페이지에서 유용하게 사용할 수 있습니다.
아래 그림은 그리드 레이아웃으로 배치된 포토 갤러리의 예시입니다.
사용자가 Tab
키로 이미지를 이동할 때,
원하는 이미지 요소에 도달하려면 키를 여러 번 눌러야 합니다.

또한 공간 탐색은
포커스 가능한 요소들 사이에서 위치에 따라 포커스를 이동하므로
사용자가 예측 가능한 요소로 포커스를 이동할 수 있습니다.
때로는 페이지의 요소가 소스 순서와 관계없이 배치되어 있습니다.
따라서 과 달리,
Tab
키를 사용하는 순차적 탐색은 포커스 이동이 예측 불가능해집니다.
화살표 키는 공간 탐색을 제어하기에 자연스럽지만, 이전 명세에서는 그 동작 방식이나 제어 방법을 정의하지 않았습니다. 이 명세서는 공간 탐색을 위한 처리 모델과 공간 탐색의 동작 방법을 저자가 제어 및 오버라이드할 수 있는 API를 소개합니다.
참고: 이 명세의 일부(예: 자바스크립트 이벤트 및 API)는 순차 탐색에도 확장될 수 있으며, 키보드 탐색이 일관되고 명확한 모델을 갖도록 하는 데 도움이 됩니다.
참고: 일반 원칙으로, 키보드 탐색, 특히 공간 탐색은 자바스크립트 없이도 사용할 수 있고 제어 가능해야 합니다. 따라서 선언적 솔루션이 권장됩니다. 공간 탐색은 레이아웃에 따라 달라지므로, CSS가 공간 탐색 관련 제어를 정의하는 데 적합한 메커니즘입니다. 하지만 Extensible Web Manifesto [EXTENSIBLE]의 취지를 반영하여, 저자가 문제 영역을 실험하고 탐구할 수 있도록 적절한 자바스크립트 프리미티브를 제공하는 것이 중요하다고 생각합니다. 이후 자바스크립트 사용을 통한 피드백과 경험을 바탕으로 더 많은 선언적 기능이 추가될 수도 있습니다.
참고: 일부 기능은 위험(at-risk)으로 표시되어 있습니다. 이 명세의 에디터들은 해당 기능들이 명세에서 정의한 기능의 사용자 또는 저자 경험에 중요한 부분이라고 생각합니다. 동시에 명세의 핵심 기능은 이 기능들을 구현하지 않아도 가능하므로, 구현자는 첫 번째 구현 범위를 줄이기 위해 우선순위를 낮출 수도 있습니다. 이러한 기능들이 구현되기를 바라지만, 우선적으로 구현되지 않을 수 있음을 인정하며 위험으로 표시하였습니다.
2. 모듈 상호작용
이 문서는 Infra Standard [infra]에 의존합니다.
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" 등의 키워드는 RFC 2119에서 설명한 대로 해석되어야 합니다. [RFC2119]
3. 개요
이 섹션은 규범적이지 않습니다.
UA에서 정의한 메커니즘
(일반적으로 화살표 키, 필요에 따라 Shift
나 Control
과 같은 수정 키 조합)
을 이용해 사용자는 User Agent에 특정 방향으로 탐색을 요청할 수 있습니다.
이 요청은
현재 위치에서 지정된 방향의 새 포커스 가능 항목으로 포커스를 이동시키거나,
적절한 항목이 없으면 스크롤합니다.
좀 더 구체적으로, User Agent는 우선 현재 공간 탐색 컨테이너 내에서 지정된 방향의 보이고 포커스 가능한 항목을 찾습니다(기본적으로 루트 요소, 스크롤 가능한 요소, iframe, 또는 공간 탐색 컨테이너로 만들 수 있는 다른 요소들은 spatial-navigation-contain 속성으로 지정할 수 있습니다).
찾은 경우, 해당 방향에 가장 적합한 항목을 선택하여 포커스를 이동시킵니다.
찾지 못하면, 공간 탐색 컨테이너를 요청된 방향으로 스크롤하며 포커스를 이동하지 않습니다. 그렇게 하면 포커스 가능한 요소가 나타나 다음에 같은 방향으로 공간 탐색을 요청할 때 포커스 이동 대상이 될 수 있습니다.
공간 탐색 컨테이너가 스크롤 불가능할 경우, 예를 들어 해당 요소가 스크롤 가능한 요소가 아니거나 이미 해당 방향으로 최대치까지 스크롤된 경우, User Agent는 상위 컨테이너( )를 선택해 위의 과정을 재귀적으로 반복합니다. 포커스 또는 스크롤할 요소를 찾거나 루트 요소에 도달할 때까지 반복합니다.
참고: 이 처리 모델의 결과로 순차 탐색과 공간 탐색 모두에서 접근 가능한 요소는 거의 동일합니다. 스크롤 가능한 요소의 뷰포트 밖에 있는 요소는 해당 요소가 뷰 안에 들어와야만 공간 탐색으로 접근할 수 있습니다. 따라서 기본적으로 스크롤로 뷰에 들어올 수 없는 요소는 접근할 수 없습니다.
preventDefault()
를
호출하여
예정된 동작을 방지하거나,
원한다면 focus()
메서드를 활용해
원하는 다른 요소에 포커스를 줄 수도 있습니다.
저자가 이러한 대체 동작을 작성할 수 있도록 돕고, Extensible Web 원칙에 따라 기본 플랫폼 프리미티브를 노출하기 위해, 이 명세는 기본 모델의 핵심 개념을 노출하는 자바스크립트 API도 정의합니다.
자바스크립트 API에 대한 자세한 내용은 § 5 JavaScript API, 다양한 이벤트에 대한 내용은 § 6.2 Navigation Event Types, CSS 속성에 대한 내용은 § 9 선언적 방법을 통한 공간 탐색 제어를 참고하세요.


그림 2의 좌측에서 "Box 2"가 포커스되어 있습니다.
ArrowDown
키를 누르면
"Box 3"이 scrollport
내에 보이기 때문에 스크롤 없이 "Box 3"으로 포커스가 이동합니다.




그림 3의 첫 번째에서 "Box 3" 아래에는 scrollport
내에 보이는 요소가 없습니다.
따라서 ArrowDown
키를 누르면 두 번째 그림처럼 아래로 스크롤됩니다.
ArrowDown
키를 다시 누르면 "Box 4"가 scrollport에 들어오고,
추가로 ArrowDown
키를 누르면 네 번째 그림과 같이 포커스가 이동합니다.
이 예제의 마크업은 다음과 같습니다:
#scroller { width : 700 px ; height : 700 px ; overflow-x : hidden; overflow-y : auto; } .box { width : 150 px ; height : 110 px ; background-color : blue; } .box:focus { background-color : red; }
< div id = "scroller" > < div class = "box" tabindex = "0" > Box 1</ div > < div class = "box" tabindex = "0" > Box 2</ div > < div class = "box" tabindex = "0" > Box 3</ div > < div class = "box" tabindex = "0" > Box 4</ div > </ div >
4. 공간 탐색 트리거
사용자가 특정 방향으로 공간 탐색을 트리거하면, User Agent는 해당 방향으로 공간 탐색 단계를 실행해야 합니다.
이 명세서는 User Agent가 사용자가 공간 탐색을 트리거할 수 있도록 제공해야 하는 UI 메커니즘을 정의하지 않습니다. 이는 의도적으로 User Agent의 선택에 맡겨져 있습니다.
User Agent는 명세에서 정의한 처리 모델과 API를 구현할 수 있지만, 본 명세서는 User Agent가 사용자가 직접 공간 탐색을 트리거할 수 있는 수단을 제공할 것을 권장합니다. API를 반드시 사용하지 않아도 됩니다.
참고: 반대로, 저자는 User Agent가 사용자 동작에 응답해 공간 탐색을 트리거할 수 있음을 가정해야 하며, 저자가 어떤 API도 호출하지 않은 경우에도 발생할 수 있습니다.
공간 탐색을 트리거하기 위해 선택된 실제 메커니즘과 관계없이, 아래 요구사항이 적용됩니다:
-
사용자가 공간 탐색을 트리거하는 메커니즘이 일반적으로
UIEvent
를 발생시킨다면, 해당 이벤트는 공간 탐색 단계를 실행하기 전에 발생해야 하며, 그 이벤트의 canceled flag가 설정된 경우 공간 탐색 단계를 실행하면 안 됩니다.게임 기기에서는 D-패드 버튼을 눌러 공간 탐색을 트리거할 수 있습니다. 이 경우 keydown 이벤트가ArrowDown
,ArrowLeft
,ArrowRight
,ArrowUp
중 하나로 설정되어 발생하며, 취소되지 않은 경우 공간 탐색 단계와 관련NavigationEvent
발생이 실행됩니다.데스크톱 컴퓨터의 User Agent가 키보드의 화살표 키로 공간 탐색을 트리거하는 경우에도 동일한 순서를 따릅니다.
-
사용자가 공간 탐색을 트리거하는 메커니즘이 일부 문맥에서는 다른 동작도 수행한다면, User Agent는 해당 문맥에서 이러한 다른 동작에 우선 순위를 두고 공간 탐색 대신 해당 동작을 실행해야 합니다. 두 가지를 동시에 트리거하면 안 됩니다.
User Agent가 수정 키 없이 화살표 키로 공간 탐색을 트리거하는 동시에, 동일한 화살표 키를 편집 가능한 요소가 포커스된 경우 텍스트 입력 커서를 이동시키는 데 사용하는 경우, 기본적으로 커서 이동에 우선해야 합니다. 공간 탐색은 포커스된 요소가 편집 가능하지 않거나, 편집 가능한 경우에도 커서가 해당 방향으로 더 이상 이동할 수 없을 때에만 화살표 키로 트리거됩니다.스크롤과 관련해서는 예외가 있습니다: 공간 탐색 자체가 스크롤을 처리하므로 (포커스 이동 외에도) User Agent는 공간 탐색과 별도의 스크롤 동작을 동일한 메커니즘으로 트리거해서는 안 됩니다. 하지만, User Agent는 사용자가 서로 다른 모드를 전환하거나, UI 메커니즘에 따라 둘 다 제공할 수 있습니다.
5. 자바스크립트 API
5.1. 프로그래밍 방식으로 탐색 트리거
navigate()
메서드는 저자가 프로그래밍 방식으로 공간 탐색을 트리거할 수 있게 해줍니다.
사용자가 직접(예: 브라우저에서 화살표 키를 눌러 공간 탐색을 트리거하는 방식 등) 실행한 것처럼 동작합니다.
참고: 이 메서드는 수동 탐색과 동일한 처리 모델을 트리거하므로 동일한 결과가 예상됩니다: 동일한 이벤트 체인이 발생하고 동일한 요소가 스크롤 또는 포커스됩니다.
참고: 저자는 User Agent가 지정한 것과 다른 UI 메커니즘에 매핑하거나, 클릭 가능한 화면 내 방향 패드 등에서 공간 탐색을 트리거하거나, UI 이벤트가 아닌 다른 이벤트에 반응해 공간 탐색을 트리거하는 등 다양한 방식으로 사용할 수 있습니다. 저자가 비동기 작업(예: 무한 스크롤에서 콘텐츠 추가) 후 탐색을 중단하고, 다시 탐색을 이어가고자 할 때도 사용할 수 있습니다.
참고: 이 API는 테스트 목적에도 유용합니다. 벤더별 UI 관행에 의존하지 않고 공간 탐색을 트리거하는 것이 어렵기 때문입니다.
enum {
SpatialNavigationDirection ,
"up" ,
"down" ,
"left" , };
"right" partial interface Window {void navigate (SpatialNavigationDirection ); };
dir
navigate(dir)
메서드가 호출되면,
User Agent는 다음 단계를 실행해야 합니다:
-
방향 dir이
"up"
,"down"
,"left"
,"right"
중 하나라면, dir 방향으로 공간 탐색 단계를 실행합니다.
이 API의 이름은 논의 중입니다 <https://github.com/w3c/csswg-drafts/issues/3387>
5.2. 저수준 API
이 API들은 처리 모델을 밀접하게 따르는 저수준 구성요소로 설계되었습니다. 따라서 공간 탐색의 동작 방식을 확장하거나 오버라이드하고자 하는 저자가 쉽게 사용할 수 있어야 합니다.
enum {
FocusableAreaSearchMode ,
"visible" };
"all" dictionary {
FocusableAreasOption FocusableAreaSearchMode ; };
mode dictionary {
SpatialNavigationSearchOptions sequence <Node >?;
candidates Node ?; };
container partial interface Element {Node getSpatialNavigationContainer ();sequence <Node >focusableAreas (optional FocusableAreasOption );
option Node ?(
spatialNavigationSearch SpatialNavigationDirection ,
dir optional SpatialNavigationSearchOptions ); };
options
참고: 방향을 표현하는 방식은 향후 필요할 경우 4방향 이상의 탐색으로 확장될 수 있도록 해줍니다. 더 많은 방향 키워드나 숫자 각도가 추가될 수 있습니다.
참고: focusableAreas()
와 getSpatialNavigationContainer()
메서드는 위험(at-risk)입니다.
이 메서드들이 호출되면, User Agent는 아래에 설명된 단계를 실행해야 합니다:
getSpatialNavigationContainer()
-
-
요소의 가장 가까운 상위 요소 중 공간 탐색 컨테이너인 요소를 반환하거나, 가장 가까운 가 뷰포트인 경우 문서(document)를 반환합니다.
참고: 해당 요소가 공간 탐색 컨테이너인 경우,
getSpatialNavigationContainer()
역시 가장 가까운 를 반환하며, 자기 자신은 반환하지 않습니다. -
focusableAreas(option)
-
-
option이 존재하고 그 값이
all
과 같으면 visibleOnly를false
로, 그렇지 않으면true
로 합니다. -
areas는 해당 요소 내에서 visibleOnly를 인자로 포커스 가능한 영역 찾기의 결과로 합니다.
-
areas를 반환합니다.
-
focusableAreas()
를
사용해
현재 페이지에서 모든 보이는 포커스 가능한 요소를 얻는 방법을 보여줍니다.
만약 해당 메서드가 공간 탐색 컨테이너를 찾으면, 내부의 포커스 가능한 영역도 재귀적으로 찾습니다.
이 메서드의 mode
속성 값이 visible
이므로,
scrollport 내부에 있지 않은 포커스 가능한 요소는 결과에서 제외됩니다.
< body >
< button ></ button >
< div style = "width:300px; height:200px; overflow-x: scroll;" >
< button style = "left:25px;" ></ button >
< button style = "left:150px;" ></ button >
< button style = "left:350px;" ></ button >
</ div >
</ body >
const focusableAreas = document. body. focusableAreas({ mode: 'visible' });
focusableAreas && focusableAreas. forEach( focusable => {
focusable. style. outline = '5px solid red' ;
});
아래 그림은 해당 코드의 결과입니다.

spatialNavigationSearch(dir, options)
-
-
dir의 값을 direction으로 합니다.
-
container는 다음과 같습니다.
-
options의
container
속성 값이 null이 아니면,-
그것이 공간 탐색 컨테이너이면 자기 자신.
-
그렇지 않으면 가장 가까운 공간 탐색 컨테이너 상위 요소.
-
-
그 외에는 요소의 가장 가까운 공간 탐색 컨테이너 상위 요소.
-
-
areas는 다음과 같습니다.
-
options의
candidates
속성 값이null
이 아니면 그 값을, -
그 외에는 container 내에서 포커스 가능한 영역 찾기의 결과.
-
-
요소에서 direction 방향으로 container 내의 areas 중 최적의 후보 선택의 결과를 반환합니다.
-
참고: container와 후보 리스트가 모두 없는 경우,
가장 가까운 공간 탐색 컨테이너 상위 요소의 보이는 포커스 가능한 영역만 검색합니다. 만약
없으면 상위 체인을 더 오르지 않으며,
결과는 null
입니다.
6. 내비게이션 이벤트
6.1. NavigationEvent 인터페이스
NavigationEvent
인터페이스는 공간 탐색과 관련된 특정 컨텍스트 정보를 제공합니다.
NavigationEvent
인터페이스 인스턴스를 생성하려면 NavigationEvent
생성자에, 선택적으로 NavigationEventInit
딕셔너리를 넘깁니다.
[Exposed =Window ]interface :
NavigationEvent UIEvent {(
constructor DOMString ,
type optional NavigationEventInit );
eventInitDict readonly attribute SpatialNavigationDirection ;
dir readonly attribute EventTarget ?; };
relatedTarget dictionary :
NavigationEventInit UIEventInit {SpatialNavigationDirection ;
dir EventTarget ?=
relatedTarget null ; };
6.2. 내비게이션 이벤트 타입
이 섹션과 하위 섹션은 규범적이지 않습니다.
내비게이션 이벤트 타입은 아래에 요약되어 있습니다. 완전한 규범적 세부사항은 § 8 처리 모델을 참고하세요.
6.2.1. navbeforefocus
이 이벤트는 최적의 후보 선택의 결과가 유효할 때 발생합니다.
Type | navbeforefocus
|
---|---|
Interface | NavigationEvent
|
Bubbles | 예 |
Cancelable | 예 |
이벤트의 속성 |
|
User Agent는 공간 탐색으로 포커스를 이동하기 전에 navbeforefocus 이벤트를
dispatch합니다.
이벤트 타겟은 포커스된 요소이며,
relatedTarget
은 포커스를 받을 예정인 요소입니다.
navigation-override가 eventTarget의 노드 문서에서, active document의 origin에 대해 비활성화되어 있다면, 이 이벤트는 dispatch되지 않습니다.
ArrowRight
키를 눌렀을 때의 동작을 보여줍니다.
설명을 간단히 하기 위해,
이 예시는 공간 탐색이 화살표 키로 트리거되는 User Agent를 가정합니다.
이벤트 타입 | KeyboardEvent .key
| 설명 | |
---|---|---|---|
1 | keydown | ArrowRight
| 공간 탐색을 활성화할 수 있는 키여야 하며, (화살표 키 등), 아니면 공간 탐색이 활성화되지 않음 |
2 | navbeforefocus | 공간 탐색 후보가 null 이 아니면 전송,
아니면 생성되지 않음
| |
3 | focusin | 타겟 요소가 포커스를 받기 전에 전송 | |
4 | focus | 타겟 요소가 포커스를 받은 후 전송 |
document. addEventListener( 'navbeforefocus' , e => {
e. preventDefault();
let nextTarget = e. relatedTarget;
if ( isSpatialNavigationContainer( nextTarget)) {
const areas = nextTarget. focusableAreas();
if ( areas. length > 0 ) {
nextTarget = nextTarget. spatialNavigationSearch( e. dir, { candidates: areas });
}
}
nextTarget. focus();
});
function isSpatialNavigationContainer( element) {
return ( ! element. parentElement) ||
( element. nodeName === 'IFRAME' ) ||
( isScrollContainer( element)) ||
( isCSSSpatNavContain( element));
}
6.2.2. navnotarget
이 이벤트는 공간 탐색이 현재 공간 탐색 컨테이너에서 후보를 찾으려고 트리 내를 올라가기 전에 발생합니다. 가 스크롤 가능하며, 더 이상 스크롤할 수 없는 경우에도 발생합니다.
내에서 후보를 찾지 못했을 때, 가장 가까운 상위Type | navnotarget
|
---|---|
Interface | NavigationEvent
|
Bubbles | 예 |
Cancelable | 예 |
이벤트의 속성 |
|
User Agent는 navnotarget 이벤트를 dispatch합니다.
이 때 이벤트 타겟은 포커스된 요소이며,
relatedTarget
은 이벤트 타겟의 공간 탐색
컨테이너입니다.
navigation-override가 eventTarget의 노드 문서에서, active document의 origin에 대해 비활성화되어 있다면, 이 이벤트는 dispatch되지 않습니다.
ArrowDown
키를 눌렀을 때 UI
Events §event-order의 동작을 보여줍니다.
설명을 간단히 하기 위해,
이 예시는 공간 탐색이 화살표 키로 트리거되는 User Agent를 가정합니다.

이벤트 타입 | 이벤트 타겟 | relatedTarget
| 설명 | |
---|---|---|---|---|
1 | keydown | #box2
| N/A | 공간 탐색을 활성화할 수 있는 키여야 하며, (화살표 키 등), 아니면 공간 탐색이 트리거되지 않음 |
2 | navnotarget | #box2
| #scrollContainer
| #scrollContainer 에 후보가 없고
더 이상 스크롤할 수 없으면 전송,
아니면 생성되지 않음
|
3 | navbeforefocus | #box2
| #box3
| #container 에 후보가 null 이 아니면 전송,
아니면 발생하지 않음
|
4 | focusin | #box3
| #box2
| 타겟 요소가 포커스를 받기 전에 전송 |
5 | focus | #box3
| #box2
| 타겟 요소가 포커스를 받은 후 전송 |
이 예시의 결과는 다음 그림과 같습니다:

이 예제의 마크업은 다음과 같습니다:
#container { width : 900 px ; height : 1400 px ; } #scrollContainer { width : 700 px ; height : 700 px ; overflow-x : hidden; overflow-y : auto; } .item { width : 150 px ; height : 110 px ; background-color : blue; } .item:focus { background-color : red; }
< div id = "container" > < div id = "scrollContainer" > < div id = "box1" class = "item" tabindex = "0" > Box 1</ div > < div id = "box2" class = "item" tabindex = "0" > Box 2</ div > </ div > < div id = "box3" class = "item" tabindex = "0" > Box 3</ div > </ div >
단, 순차적 탐색, 마우스 상호작용,
혹은 focus()
를
통한 프로그래밍 호출로는 컨테이너 바깥으로 이동할 수 있습니다.
scrollContainer. addEventListener( 'navnotarget' , e => {
let nextTarget = null ;
const verticalDir = [ 'up' , 'down' ];
const candidates = e. relatedTarget. focusableAreas({ 'mode' : 'all' });
// y축 방향일 때만 preventDefault
if ( verticalDir. includes( e. dir) && ( candidates. length > 0 )) {
e. preventDefault();
if ( e. dir === 'down' ) {
nextTarget = candidates[ 0 ];
} else if ( e. dir === 'up' ) {
nextTarget = candidates[ candidates. length- 1 ];
}
nextTarget. focus();
}
});
7. navigation-override 정책 제어 기능
navigation-override 정책 제어 기능은 페이지 저자가 공간 탐색 동작을 제어하거나 완전히 취소할 수 있는 메커니즘의 사용 가능성을 제어합니다.
-
기능 이름은 "
navigation-override
"입니다. -
기본 허용 목록은 navigation-override의 경우 "
self
"입니다.
§ 8.3 Navigation에서 더 자세히 정의한 대로, 만약 문서에서 navigation-override가 비활성화되어 있으면, 내비게이션 이벤트(§ 6 Navigation Events 참고)는 발생하지 않습니다.
참고: 이것은 악의적인 iframe이 포커스를 탈취하기 위해 이러한 이벤트를 사용하는 것을 방지하기 위한 것입니다. 공간 탐색 이전부터 저자가 사용자의 포커스 제어 능력을 방해할 수 있는 다른 메커니즘이 존재함을 인식합니다. 그럼에도, 이 공격 표면을 넓히지 않는 것이 가치 있다고 판단되며, 이미 그러한 공격이 충분히 쉽게 수행될 수 있다면 효과가 없을 수도 있습니다. 구현 또는 대응 경험을 바탕으로 한 추가 피드백을 환영합니다.
8. 처리 모델
이 섹션은 해당하는 규범적 동작을 정의하며, 동작을 완전히 정의하는 데 필요한 만큼의 세부사항을 목표로 합니다.
8.1. 용어집
공간 탐색의 처리 모델을 설명하기 위해 다음 용어 정의가 지정되었습니다. 정의 내의 링크를 참고하면 더 많은 정보를 얻을 수 있습니다.
객체의 경계 박스는 다음과 같이 정의됩니다:
-
객체가 점(point)인 경우, 경계 박스는 그 점입니다.
-
객체가 포커스 가능한 영역이지만 요소가 아닌 경우, 경계 박스는 해당 포커스 가능한 영역의 축에 정렬된 바운딩 박스입니다.
객체의 내부 영역은 다음과 같이 정의됩니다:
-
객체가 문서(document)인 경우, 해당 브라우징 컨텍스트의 뷰포트입니다.
참고: 객체가 화면 밖에 있을 경우, 내부 영역은 가장 가까운 보이는 상위 컨테이너여야 합니다.
CSS는 "border-radius와 같은 코너 쉐이핑 속성을 고려한 테두리 박스"를 위한 용어를 가져야 합니다. <https://github.com/w3c/csswg-drafts/issues/2324>
탐색 기점은 다음 타겟을 찾기 위한 기준점입니다.
공간 탐색 시작점은 User Agent가 설정하는 다음 타겟 탐색의 기준점입니다. 초기에는 설정되지 않으며, 요소 또는 점일 수 있습니다.
참고: 예를 들어, User Agent는 사용자가 문서 내용을 클릭하면 그 위치로 설정할 수 있으며, 포커스가 이동하면(공간 탐색 또는 다른 방법으로) 설정을 해제할 수 있습니다.
User Agent가 공간 탐색 시작점과 순차 포커스 탐색 시작점을 모두 설정한 경우, 서로 다르게 설정하면 안 됩니다.
8.2. 요소 그룹화
공간 탐색의 처리 모델은 문서의 레이아웃과 포커스 가능한 요소의 상대적 위치를 기반으로 작동하지만, User Agent는 로컬 논리적 그룹에서 우선적으로 요소를 찾도록 요구됩니다. 그룹 내부에서 적합한 요소를 찾을 수 없을 때만 그룹 밖에서 포커스 가능한 요소를 찾도록 해야 합니다(§ 8.3 Navigation 참고).
이러한 그룹을 공간 탐색 컨테이너라고 합니다.
기본적으로, 공간 탐색 컨테이너는 다음에 의해 설정됩니다:
8.3. 탐색
공간 탐색의 처리 모델은 공간 탐색이 일반적으로 어떻게 동작하는지 설명합니다.
이 그림은 규범적이지 않습니다. 이 섹션에서 더 자세히 정의된 처리 모델의 개요를 제공합니다. spatial-navigation-action 속성이 초기값 auto일 때를 가정합니다.
-
searchOrigin을 탐색 기점 설정의 결과로 합니다.
-
eventTarget이 Document나 문서 요소(document element)라면, eventTarget을 body 요소로(만약
null
이 아니면), 아니면 문서 요소로 설정합니다. -
- eventTarget이 스크롤 컨테이너이고, spatial-navigation-action 속성의 계산값이 scroll이며, eventTarget이 수동 스크롤 가능하다면, 해당 요소를 방향 기반으로 스크롤 eventTarget 하고 반환합니다.
-
그 외, eventTarget이 스크롤 컨테이너 또는 문서라면
-
candidates를 포커스 가능한 영역 찾기의 결과로, eventTarget 내에서 visibleOnly를
false
로 설정하여 구합니다. 만약 spatial-navigation-action 속성의 계산값이 focus이면false
, 아니면true
. -
- spatial-navigation-action 계산값이 focus가 아니고, eventTarget이 수동 스크롤 가능하다면, 해당 요소를 방향 기반으로 스크롤 eventTarget을 direction 방향으로 실행하고 반환합니다.
-
그 외 candidates에 1개 이상의 항목이 있다면:
-
bestCandidate를 최적의 후보 선택의 결과로, candidates 내에서 direction 방향으로 searchOrigin을 기준으로 구합니다.
-
navbeforefocus 이벤트 발생을 eventTarget에서 direction과 bestCandidate로 실행합니다.
-
포커스 단계를 bestCandidate에 실행하고 반환합니다.
-
- 그 외, 다음 단계로 넘어갑니다.
-
- 그 외, 다음 단계로 넘어갑니다.
-
container를 eventTarget의 가장 가까운 상위 공간 탐색 컨테이너로 합니다.
-
Loop: candidates를 포커스 가능한 영역 찾기의 결과로, container 내에서 visibleOnly를
false
로 설정하여 구합니다. 만약 spatial-navigation-action 속성의 계산값이 focus이면false
, 아니면true
, eventTarget을 제외합니다. -
candidates가 비어 있으면:
- spatial-navigation-action 속성의 계산값이 focus가 아니고, container가 스크롤 컨테이너이며 수동 스크롤 가능하다면, 해당 요소를 방향 기반으로 스크롤 container를 direction 방향으로 실행하고 반환합니다.
- 그 외,
-
navnotarget 이벤트 발생을 eventTarget에서 direction과 container로 실행합니다.
-
-
container가 문서 요소(document element)이고, 최상위 브라우징 컨텍스트라면, 반환합니다. User Agent는 direction 방향을 존중하여(있다면) 자체 컨트롤로 포커스를 이동할 수 있습니다.
-
그 외, container가 문서 요소(document element)이고, 중첩 브라우징 컨텍스트라면:
-
searchOrigin을 container의 브라우징 컨텍스트 컨테이너로 설정합니다.
-
eventTarget을 searchOrigin으로 합니다.
-
container를 eventTarget의 가장 가까운 상위 공간 탐색 컨테이너로 합니다.
-
loop 단계로 돌아갑니다.
-
-
그 외, container를 자기 자신의 가장 가까운 상위 공간 탐색 컨테이너로 설정하고 loop 단계로 돌아갑니다.
-
-
-
bestCandidate를 최적의 후보 선택의 결과로, candidates 내에서 direction 방향으로 eventTarget을 기준으로 구합니다.
-
navbeforefocus 이벤트 발생을 eventTarget에서 direction과 bestCandidate로 실행합니다.
-
포커스 단계를 bestCandidate에 실행하고 반환합니다.
8.4. 포커스 탐색 휴리스틱
참고: 다음 알고리즘은 Chrome의 구현과 옛 WICD 명세에서 영감을 받았습니다. 더 나은 접근 방식이나 개선점을 발견한 구현자는 적극적으로 피드백을 제공하여 이 명세의 상호 운용성을 극대화하는 데 도움을 주시길 바랍니다. 특히, User Agent가 포커스 가능한 영역 찾기 방식이 서로 다르면 일부 요소가 어떤 User Agent에서는 포커스 가능하지만 다른 곳에서는 불가능한 문제가 발생하여, 사용자에게 좋지 않을 수 있습니다.
이 섹션의 모든 기하 연산은 CSS 레이아웃의 결과에 대해 동작하도록 정의되며, 상대 위치 지정이나 [CSS-TRANSFORMS-1]과 같은 모든 그래픽 변환을 포함합니다.
탐색 기점 설정을 위해, 다음 단계를 실행합니다:
-
searchOrigin을 DOM 앵커의 최상위 브라우징 컨텍스트의 현재 포커스된 영역으로 합니다.
-
공간 탐색 시작점이
null
이 아니고 searchOrigin 내부에 있으면, 그 값을 반환합니다. -
그렇지 않으면 searchOrigin을 반환합니다.
만약 focus target의 상태가 포커스 이동이 아닌 이유로 변경되었다면, 탐색 기점 업데이트를 다음과 같이 수행합니다:
-
focus target이 실제로 비활성화되거나 명시적으로 inert되었거나 렌더링되지 않음이라면, searchOrigin을 focus target의 경계 박스로 합니다.
-
focus target이 제거됨이면, searchOrigin을 focus target이 존재했을 때 위치의 경계 박스로 합니다.
-
focus target이 완전히 화면 밖에 있다면, searchOrigin을 focus target의 가장 가까운 보이는 공간 탐색 컨테이너의 뷰포트로 합니다.
참고: User Agent는 예를 들어, 포커스된 요소가 마우스 스크롤로 뷰포트 밖으로 나가거나 사라진 경우 탐색 기점 업데이트를 해야 합니다.
포커스 가능한 영역 찾기를 포함 요소 C 내에서,
true
를 기본값으로 하는 선택적 visibleOnly 인자와 함께 실행하려면 다음 단계를 수행합니다:
-
focusables을 C의 자손인 포커스 가능한 영역의 DOM 앵커의 집합(set)으로 합니다. 박스가 여러 박스 조각을 가지는 경우, 각 박스 조각을 별도로 취급합니다.
-
User Agent는 focusables에서 DOM 앵커의
tabindex
속성이 음수로 설정된 항목을 제거해야 합니다.참고: 이는 순차 포커스 탐색 순서에서 음수 tabindex를 가진 요소를 제외하는 tabindex 규정과 맞추기 위한 "SHOULD"입니다.
-
visibleOnly가
false
이면, focusables을 반환합니다.참고: focusables가 비어있을 수 있습니다
-
visibles을 focusables 중 경계 박스가 C의 내부 영역에 일부라도 포함되어 있는 항목의 부분집합으로 합니다.
스크롤러의 현재 보이지 않는 부분에 있는 요소를 제외하면, 공간 탐색은 클릭할 수 없는 요소(예: 다른 요소에 의해 가려진 경우)를 자동으로 제외하지 않습니다. 사용자가 실질적으로 포커스하고 활성화할 때 애플리케이션 로직의 가정을 깨뜨리거나, 사용자에게 보이지 않거나 접근 불가능한 요소에 포커스가 이동해 혼란을 줄 수 있으므로, 저자는tab-index="-1"
또는inert
속성 등 순차 탐색과 동일한 모범 사례로 공간 탐색에서도 이런 요소들을 접근 불가로 만드는 것이 좋습니다. -
visibles을 반환합니다.
참고: visibles가 비어있을 수 있습니다
최적의 후보 선택을 집합(set) candidates에서, 방향 dir과 searchOrigin을 기준으로 실행하려면 다음 단계를 수행합니다:
-
candidates가 비어있으면
null
을 반환합니다. -
candidates에 단일 항목만 있으면 그 항목을 반환합니다.
-
insiders를 candidates의 부분집합으로 합니다.
-
경계 박스가 searchOrigin의 내부 영역과 완전히 겹치는 항목
-
경계 박스가 searchOrigin의 내부 영역과 부분적으로 겹치는 항목으로서
참고: 요소가 탐색 기점과 어떻게 겹치는지 더 상세한 조건은 포커스 이동 순서에 영향을 주며, 포커스 이동 순서는 UX와 관련이 있으므로 UA 정의 메커니즘에 따라 달라집니다.
참고: 이 부분집합 설정은 요청한 방향과 반대 방향으로 이동하는 것을 방지하기 위해 필요합니다.
-
-
-
insiders가 비어있지 않으면,
-
그 외
-
distance = euclidean + displacement - alignment - sqrt(Overlap)
각 용어의 의미는 다음과 같습니다:
- euclidean
- P1과 P2 사이의 유클리드 거리
- displacement
-
reference와 candidate 사이 dir에서의 변위 정도.
아래와 같이 정의됨:
displacement = (dir에 직교하는 축에서 P1과 P2 사이의 절대 거리 + orthogonalBias) * orthogonalWeight
- orthogonalBias:
- orthogonalWeight:
- alignment
-
reference와 candidate 사이 dir에서의 정렬 정도.
아래와 같이 정의됨:
alignment = alignBias * alignWeight
- alignBias:
- projectedOverlap:
-
-
dir이
left
또는right
면, reference와 candidate의 수직축에 수평 투영된 부분의 겹치는 길이 -
그 외 dir이
up
또는down
면, reference와 candidate의 수평축에 수직 투영된 부분의 겹치는 길이
projectedOverlap -
- alignWeight:
- 5
- sqrt(Overlap)
- reference와 candidate 사이의 겹친 영역의 제곱근 값, 겹치지 않으면 0
참고: 이 일반 공식은 여러 가능한 대안 중에서 직관적으로 가장 자주 맞는 결과를 주는 공식을 UX 테스트 케이스(UX test cases)에서 선택하여 채택한 것입니다. alignWeight와 orthogonalWeight의 값도 같은 테스트 케이스를 기반으로 실험적으로 결정되었습니다. 결과 공식은 다소 복잡하지만, 좋은 결과를 주는 듯합니다. 개선이나 단순화 제안도 환영합니다.
9. 선언적 방법을 통한 공간 탐색 제어
9.1. 추가 공간 탐색 컨테이너 생성: spatial-navigation-contain 속성
이름: | spatial-navigation-contain |
---|---|
값: | auto | contain |
초기값: | auto |
적용 대상: | 모든 요소 |
상속: | 아니오 |
백분율: | 해당 없음 |
계산값: | 명시된 그대로 |
정규 순서: | 문법 순서에 따라 |
애니메이션 유형: | 불연속(discrete) |
- auto
- 해당 요소가 스크롤 컨테이너인 경우 공간 탐색 컨테이너를 생성하며, 그렇지 않으면 생성하지 않습니다.
- contain
- 해당 요소가 공간 탐색 컨테이너를 생성합니다.
참고: 또한 § 8.2 요소 그룹화에 따라, 브라우징 컨텍스트의 뷰포트(최상위 브라우징 컨텍스트에 한정되지 않음) 역시 공간 탐색 컨테이너를 생성합니다.
이 경우, 그리드가 비교적 드물게 배치되어 있어 사용자가 "Foo"에서 아래로 이동하려고 하면, 포커스가 "Next Week"로 옮겨집니다. 왜냐하면 실제로 아래 방향에서 가장 가까운 위치이기 때문입니다. "Bar"에서 아래로 이동할 때도 마찬가지로 포커스가 "Previous Week"로 이동합니다.
< div >
< button > Previous Week</ button >
< table >
< tr >< td >< th > M< th > T< th > W< th > T< th > F< th > S< th > S
< tr >< td > 0-6< td >< td >< td >< td >< td >< td >< td >< a href = "#" > Foo</ a >
< tr >< td > 6-9< td >< a href = "#" > Bar</ a >< td >< td >< td >< td >< td >< td >
< tr >< td > 9-12< td >< td >< a href = "#" > Bat</ a >< td >< td >< td >< td >< td >
< tr >< td > 12-18< td >< td >< td >< td >< td >< td >< td >
< tr >< td > 18-21< td >< td >< td >< td >< td >< td >< td >< a href = "#" > Woo</ a >
< tr >< td > 21-24< td >< td >< td >< td >< td >< td >< a href = "#" > Baz</ a >< td >
</ table >
< button > Next Week</ button >
</ div >
하지만 저자가 테이블 내의 항목에 포커스가 맞춰졌을 때 그리드 내부 이동을 우선시하는 다른 탐색 경험을 제공하고 싶을 수도 있습니다. 왜냐하면 테이블의 요소들은 서로 의미적으로 관련되어 있기 때문입니다.
스타일시트에
을 추가하면 이런 동작을 얻을 수 있습니다.
이후에는 "Foo"에서 아래로 이동하면 "Next Week" 대신 "Woo"로, "Bar"에서 아래로 이동하면 "Previous Week" 대신 "Bat"로 포커스가 이동합니다.
여전히 테이블 밖으로 포커스를 이동하는 것도 가능합니다. 예를 들어, "Foo"에서 오른쪽으로 이동하면 그리드에 오른쪽에 아무것도 없으므로 포커스가 "Next week"로 이동합니다.
참고: spatial-navigation-contain 속성은 위험(at-risk)입니다.
9.2. 스크롤과의 상호작용 제어: spatial-navigation-action 속성
이름: | spatial-navigation-action |
---|---|
값: | auto | focus | scroll |
초기값: | auto |
적용 대상: | 스크롤 컨테이너 |
상속: | 아니오 |
백분율: | 해당 없음 |
계산값: | 명시된 그대로 |
정규 순서: | 문법 순서에 따라 |
애니메이션 유형: | 불연속(discrete) |
포커스가 스크롤 컨테이너 안에 있을 때 사용자가 공간 탐색을 트리거하면, 포커스를 해당 방향으로 이동하려는 것인지, 아니면 문서를 해당 방향으로 스크롤하려는 것인지가 다소 모호합니다. 기본적으로 이 동작은 자동으로 결정되지만, 이 속성을 통해 저자가 포커스 이동 또는 스크롤 중 하나를 명확하게 지정할 수 있습니다.
정확한 동작은 § 8.3 탐색에서 정의되지만, 각 값의 효과에 대한 상위 설명은 아래에 제공합니다.
공간 탐색이 트리거될 때, 동작은 현재 포커스된 요소의 spatial-navigation-action 값을 따르며, 해당 요소가 스크롤 컨테이너인 경우에는 그 요소의, 아니면 가장 가까운 상위 스크롤 컨테이너의 값을 따릅니다.
- auto
- 요청된 방향에 스크롤 컨테이너 내에 보이는 포커스 가능한 요소가 있다면, 가장 가까운 요소에 포커스가 이동합니다. 그렇지 않으면 해당 스크롤 컨테이너가 요청된 방향으로 스크롤됩니다.
- focus
-
스크롤 컨테이너 내에서 가장 가까운 포커스 가능한 요소로 포커스를 이동합니다.
해당 요소가 보이지 않더라도 이동합니다.
만약 포커스 가능한 요소가 없다면,
스크롤 컨테이너는 스크롤되지 않으며,
대신 상위 체인으로 탐색이 이어집니다.
참고: 스크롤 컨테이너는 포커스 이동으로 인해 보이지 않던 요소가 보이게 되어 스크롤될 수 있지만, 방향 기반 스크롤은 아닙니다.
참고: focus 값이 spatial-navigation-action에 지정된 경우, 뷰포트 내에 보이는 후보가 없는 방향으로 공간 탐색을 시도하면(컨테이너가 더 스크롤될 수 있더라도) navnotarget 이벤트가 발생합니다.
- scroll
-
현재 포커스된 요소가 스크롤 컨테이너가 아니라면,
상위 스크롤 컨테이너에서 이 값을 지정한 것은 auto와 동일하게 동작합니다.
현재 포커스된 요소가 스크롤 컨테이너라면, 포커스된 요소를 변경하지 않고 요청된 방향으로 스크롤만 하며, 포커스 가능한 하위 요소의 존재와 관계없이 동작합니다.
참고: 이는 공간 탐색을 통해 스크롤 컨테이너로 포커스를 옮기고 스크롤할 수 있지만, 하위 요소로 포커스를 이동하는 것은 불가능함을 의미합니다. 다만 Tab 키를 누르거나 <
focus()
> 메서드를 사용하는 등 다른 방법으로 하위 요소에 포커스가 이동한 경우, 공간 탐색을 이용해 다른 포커스 가능한 하위 요소로 이동할 수 있습니다.참고: scroll 값은 위험(at-risk)입니다.
참고: 이 명세의 이전 버전에서는 focus 동작을 선언적으로 사용하도록 하는 방법이 없었고, 대신 스크롤 전에 발생하는 취소 가능한 이벤트를 제공하여 저자가 직접 해당 동작을 구현할 수 있게 했습니다. 하지만 스크롤과 관련된 취소 가능한 이벤트는 성능 문제를 일으킬 수 있으므로, 해당 이벤트는 제거되고 spatial-navigation-action 속성이 도입되었습니다.
spatial-navigation-action: focus
가 지정된 스크롤 가능한 컨테이너가 있습니다.
컨테이너 내부에 scrollport 뷰 안에 보이지 않는 요소가 있습니다.
아래쪽 화살표 키를 누르면 수동 스크롤 없이 바로 해당 요소로 포커스가 이동합니다.

< div class = 'scroller' >
< button class = 'item' > Box 1</ button >
< button class = 'item' > Box 2</ button >
< button class = 'item' > Box 3</ button >
</ div >
.scroller {
display : grid;
grid-template-columns : repeat ( 1 , 1 fr );
height : 300 px ;
width : 200 px ;
overflow-y : scroll;
spatial-navigation-action : focus;
}
.item {
height : 100 px ;
width : 100 px ;
margin : 50 px auto;
background-color : blue;
}
:focus {
background-color : red;
}
9.3. 탐색 알고리즘 선택: spatial-navigation-function 속성
이름: | spatial-navigation-function |
---|---|
값: | normal | grid |
초기값: | normal |
적용 대상: | 공간 탐색 컨테이너 |
상속: | 아니오 |
백분율: | 해당 없음 |
계산값: | 명시된 그대로 |
정규 순서: | 문법 순서에 따라 |
애니메이션 유형: | 불연속(discrete) |
§ 8 처리 모델에서 지정된 공간 탐색의 기본 알고리즘은 레이아웃 유형에 따라 미세 조정이 필요할 수 있습니다. 이 속성을 통해 저자가 공간 탐색 동작에 적합한 탐색 알고리즘을 지정할 수 있습니다.
값 정의는 다음과 같습니다:
- normal
-
UA가 정의한 기본 포커스 탐색 알고리즘으로 포커스를 이동합니다.
일반적으로, 포커스는 최단 거리 계산을 통해 가장 가까운 요소로 이동합니다.
- grid
-
탐색 방향으로 가장 정렬된 요소로 포커스를 이동합니다.
-
탐색 방향으로 둘 이상의 정렬 후보가 있다면, 탐색 방향과 일치하는 축에서 가장 가까운 요소를 선택합니다. 여러 요소가 동일 거리일 경우, 정렬 정도가 가장 작은 요소를 선택합니다.
-
지정된 방향에 정렬된 후보가 없다면, 탐색 방향과 일치하는 축에서 가장 가까운 요소를 선택합니다. 여러 요소가 동일 거리일 경우, 탐색 방향에 직교하는 축에서 거리가 가장 짧은 요소를 선택합니다.
-
참고: 이러한 값들은 사용자의 페이지에서 자연스러운 공간 탐색 동작으로 보이는 사용자의 선호와 협의되어 결정됩니다.
spatial-navigation-function
값에 따라 포커스가 다르게 이동하는 방식을 보여줍니다.

"A", "B", "C"를 포함하는 요소가 공간 탐색 컨테이너라고 가정합니다.
사용자가 아래쪽 화살표 키를 누를 때,
해당 요소의 spatial-navigation-function
값이 normal
이면 포커스가 "B"로 이동합니다.
반면 grid
값이 지정되면 포커스가 "C"로 이동합니다.
부록 A. 스크롤 확장
이 섹션에서는 CSS에 대한 몇 가지 확장 제안을 다룹니다. 향후 공식 명세에 통합되어야 하지만, 그 전까지는 여기에서 관리합니다.
이런 용어는 [CSSOM-VIEW-1], [CSS-OVERFLOW-3], [CSS-SCROLL-SNAP-1]에 포함되어야 합니다. <https://github.com/w3c/csswg-drafts/issues/2322>
요소 e는 주어진 방향 d로 수동으로 스크롤될 수 있다:
-
e가 생성하는 주 박스(principal box)가 스크롤 컨테이너일 것, 그리고
-
d가
up
또는down
일 때, overflow-y 속성의 계산값이 이 아닐 것, 그리고 -
d가
left
또는right
일 때, overflow-x 속성의 계산값이 이 아닐 것, 그리고 -
e가 방향 d에서 스크롤 경계에 있지 않을 것
-
e가 방향 d에서 마지막 mandatory 스냅 포인트에 스냅되어 있지 않을 것
[CSSOM-VIEW-1]에서는 명시적 위치 없이 주어진 방향으로 스크롤하는 방법을 정의해야 합니다. 그 전까지는 직접 정의함. <https://github.com/w3c/csswg-drafts/issues/2323>
요소 e를 방향 dir로 방향 기반 스크롤하려면:
-
d를 User Agent가 정의한 거리로 설정합니다.
-
x를 e의 현재 x축 스크롤 위치로 설정합니다.
-
y를 e의 현재 y축 스크롤 위치로 설정합니다.
-
scroll an element 알고리즘([CSSOM-VIEW-1])을 e에 적용하여
-
dir이
up
일 때 (x, y - d) -
dir이
down
일 때 (x, y + d) -
dir이
left
일 때 (x - d, y) -
dir이
right
일 때 (x + d, y)
-
부록 B. 개인정보 및 보안 고려사항
명세 기여자들은 이 명세와 관련된 모든 알려진 잠재적 보안 위험이 충분히 해결되었다고 믿습니다. 자세한 내용은 아래에 있습니다.
TAG에서는 명세의 위험을 평가할 수 있도록 셀프 리뷰 질문지를 개발했습니다. 이에 대한 답변은 아래에 있습니다.
- 이 명세가 개인 식별 정보와 관련되어 있습니까?
- 아닙니다.
- 이 명세가 고가치 데이터와 관련되어 있습니까?
- 아닙니다.
- 이 명세가 오리진에 대해 브라우징 세션 간에 지속되는 새로운 상태를 도입합니까?
- 아닙니다.
- 이 명세가 웹에 지속적이고 크로스 오리진 상태를 노출합니까?
- 아닙니다.
- 이 명세가 오리진에 현재 접근할 수 없는 다른 데이터를 노출합니까?
-
거의 없습니다.
예외가 있을 수 있는 시나리오: 저자가 `window.navigate`를 사용하고 포커스가 크로스 오리진 iframe에 있을 때 이벤트를 받지 못하면, iframe 내에 스크롤 가능하거나 포커스 가능한 것이 있었다는 의미가 됩니다. 이벤트가 발생하는 유일한 경우는 탐색이 아무것도 못 찾고 트리 상위로 올라갈 때입니다.
이 정보는 매우 제한적이어서 실질적인 보안 위험을 초래한다고 보긴 어렵지만, 저자가 일반적으로 얻을 수 없는 정보임은 분명합니다.
- 이 명세가 새로운 스크립트 실행/로딩 메커니즘을 허용합니까?
- 아닙니다.
- 이 명세가 오리진에 사용자의 위치 접근을 허용합니까?
- 아닙니다.
- 이 명세가 오리진에 사용자 장치의 센서 접근을 허용합니까?
- 아닙니다.
- 이 명세가 오리진에 사용자 로컬 컴퓨팅 환경의 측면 접근을 허용합니까?
- 아닙니다.
- 이 명세가 오리진에 다른 장치 접근을 허용합니까?
- 아닙니다.
- 이 명세가 오리진에 User Agent의 네이티브 UI에 대한 일부 제어권을 허용합니까?
- User Agent UI의 모양에 대한 제어권은 제공되지 않습니다. User Agent가 공간 탐색을 수행하는 방식에 대한 일부 제어권은 제공합니다. 이는 저자가 페이지에 맞게 공간 탐색 동작을 맞춤화할 수 있도록 의도된 것입니다. 악의적인 저자가 사용자의 포커스 제어 및 문서 탐색을 방해하는 것을 막기 위해 이 오버라이드 메커니즘은 기본적으로 크로스 오리진 iframe에서는 비활성화되어 있습니다. § 7 navigation-override 정책 제어 기능 참고.
- 이 명세가 웹에 임시 식별자를 노출합니까?
- 아닙니다.
- 이 명세가 1st-party와 3rd-party 맥락에서 동작을 구분합니까?
- 아닙니다.
- 이 명세는 User Agent의 "시크릿 모드"에서 어떻게 동작해야 합니까?
- 차이 없음.
- 이 명세가 사용자의 로컬 장치에 데이터를 저장합니까?
- 아닙니다.
- 이 명세에 "보안 및 개인정보 고려사항" 섹션이 있습니까?
- 네, 지금 읽고 계신 바로 이 섹션입니다.
- 이 명세가 기본 보안 특성의 다운그레이드를 허용합니까?
-
관련 없는 보안 메커니즘의 다운그레이드는 허용하지 않습니다.
신뢰하는 크로스 오리진 iframe에서 공간 탐색의 기본 동작을 오버라이드하는 데 필요한 이벤트를 허용하도록 저자가 명시적으로 opt-in할 수 있게 [feature-policy]를 통해 허용합니다. § 7 navigation-override 정책 제어 기능 참고.
감사의 글
이 명세의 에디터들은 피드백과 기여를 해주신 다음 분들께 감사드립니다(알파벳 순):
-
Alice Boxhall
-
Brian Kardell
-
Elika Etemad
-
Eric Seong
-
Hugo Holgersson
-
Hyojin Song
-
Jeonghee Ahn
-
Junho Seo
-
Rob Dodson
-
Seungcheon Baek
변경 사항
이 섹션은 규범적이지 않습니다.
다음은 2019년 4월 23일 첫 공개 작업 초안 이후 변경된 내용입니다.
-
getSpatialNavigationContainer()
의 결과를 가장 가까운 공간 탐색 컨테이너 상위 요소를 반환하도록 변경함 -
탐색 기점 업데이트 단계 추가
-
spatialNavigationSearch()
의 IDL을SpatialNavigationSearchOptions
에서 dir 속성을 분리하도록 변경함 -
검색 기점과 완전히 겹치는 포커스 가능한 요소(공간 탐색 컨테이너가 아닌 경우)를 후보에 포함시켜 도달 불가능 문제를 해결함