1. 소개
이 문서는 [css-position-3]에 대한 초기 델타 명세입니다.
2. 스크롤 가능한 포함 블록
스크롤 컨테이너가 절대 위치 지정 포함 블록을 절대 위치 지정 박스에 대해 설정할 때, 세 가지 포함 블록 중 하나가 사용됩니다:- 고정 포함 블록
-
고정 포함 블록은 스크롤 컨테이너의 스크롤포트에 해당합니다. 즉, 스크롤 컨테이너의 내부 패딩 박스의 경계이지만, 외부 컨텍스트와 함께 스크롤되고, 스크롤 컨테이너의 내용과는 함께 스크롤되지 않습니다.
문서에 의해 설정된 고정 포함 블록은 고정 위치 지정 포함 블록입니다.
- 로컬 포함 블록
-
로컬 포함 블록은 스크롤 컨테이너의 패딩 박스의 경계에 해당하지만, 스크롤 가능한 오버플로우 영역에 고정되어 있으며, 스크롤 컨테이너의 내용과 함께 스크롤됩니다.
- 스크롤 가능한 포함 블록
-
스크롤 가능한 포함 블록은 스크롤 컨테이너의 패딩 에지에 해당하며, 스크롤 컨테이너의 스크롤 가능한 오버플로우 영역의 바깥쪽 에지에 해당합니다. 즉, 패딩이 콘텐츠를 감싸고 있을 때, 스크롤 가능한 오버플로우 영역의 범위를 결정할 때 바깥쪽 에지로 사용됩니다. 자세한 내용은 CSS Overflow 3 § 2.2 Scrollable Overflow를 참고하세요. 모든 경우에 스크롤 가능한 포함 블록은 최소한 로컬 포함 블록을 포함합니다.
참고: 여기에는 플로트(float)가 포함되지만, 절대 위치 지정된 후손, 후손 박스에서 넘치는 콘텐츠, 상대 위치 지정 및 변형(transform)의 효과 등은 무시됩니다. 이러한 것들은 스크롤 영역을 확장하여 표시되도록 하지만, 이 정의에서는 포함되지 않습니다.
문서에 의해 설정된 스크롤 가능한 포함 블록은 초기 포함 블록과 마진 박스를 합친 영역이며, 루트 요소가 생성한 박스의 마진 박스를 포함합니다.
참고: 이 모든 블록이 어느 정도 패딩 박스와 대응하지만, 스크롤 가능한 오버플로우가 있는 박스에서는 일치하지 않습니다.
최상위 레이어에 필요한 정확한 개념을 결정해야 합니다. 아마도 레이어에 따라 약간 다르게 작동하도록 할 필요가 있습니다.
별도의 명시가 없는 한, 절대 위치 지정 박스는 로컬 포함 블록을 사용합니다. 특정 CSS 기능은 다른 포함 블록을 지정할 수 있습니다. 예를 들어, 고정 위치 지정 박스는 일반적으로 문서의 고정 포함 블록을 사용하며, position-area 값이 none이 아닌 경우에는 절대 위치 지정 박스를 스크롤 가능한 포함 블록으로 선택할 수 있습니다.
참고: 현재 고정 포함 블록을 고정 위치 지정 포함 블록 외에는 참조할 방법이 없습니다. 하지만 앞으로 추가될 수도 있습니다.
3. 최상위 레이어
Document
에는
최상위
레이어가 있습니다.
이는 문서의 순서가 지정된 집합이며,
요소들을 포함합니다.
최상위 레이어에 있는 요소들은
문서 내 위치에 따라 일반적으로 레이아웃되지 않으며,
대신 루트 요소의 형제처럼 박스를 생성합니다.
최상위 레이어의 요소들은 해당 최상위
레이어에 등장하는 순서대로 렌더링됩니다;
최상위 레이어의 마지막 요소가 모든 것 위에 렌더링됩니다.
참고: 이 특수 렌더링 동작은 최상위 레이어의 요소가 문서 내 다른 어떤 것에도 잘리거나 가려지지 않도록 보장합니다. 즉, 최상위 레이어에서 더 나중에 등장하는 요소를 제외하고는 가려지지 않습니다. 이를 통해 팝오버와 같은 요소들이 상위 요소의 동작과 관계없이 안정적으로 표시될 수 있습니다.
최상위 레이어 루트는 요소의 가장 가까운 상위 요소 중 최상위 레이어에 속한 요소이며, 그렇지 않으면 없으며 (이 경우에는 문서의 일반적인 부분으로 페인팅됩니다.)
두 요소가 같은 최상위 레이어에 있다고 하려면 최상위 레이어 루트가 같아야 하며 (둘 다 없는 경우도 포함). A 요소가 B 요소보다 더 높은 최상위 레이어에 있다면 A가 최상위 레이어 루트를 가지고 있고, B가 최상위 레이어 루트를 A보다 먼저 최상위 레이어에 가지고 있거나, B가 최상위 레이어 루트가 전혀 없을 때입니다.
참고: 최상위 레이어는 전적으로 사용자 에이전트에 의해 관리됩니다. 저자가 직접 조작할 수 없습니다. 이를 통해 팝업 내부에 또 다른 팝업 등, 최상위 레이어를 사용하는 API의 "중첩" 호출도 올바르게 표시됩니다.
참고: 최상위 레이어는 overlay 속성과 특이하게 상호작용합니다. 자세한 내용은 overlay를 참고하세요.
Document
에는
최상위 레이어 삭제 예정
목록
순서가 지정된
집합이 있으며,
삭제가 예정된 요소들을 포함합니다.
(아래 알고리즘에서 사용 방법을 자세히 설명합니다.)
최상위 레이어 (그리고 최상위 레이어 삭제 예정 목록)은 명세 알고리즘에서 직접적으로 다루어져서는 안 됩니다. (최상위 레이어를 사용하는 개별 기능은 최상위 레이어 내의 다양한 객체, 예를 들어 팝오버 내부의 팝오버 등, 그룹으로 재배치 및 이동할 필요가 있을 수 있습니다.) 대신, 아래의 알고리즘을 사용해야 합니다.
3.1. 최상위 레이어 스타일링
모든 최상위 레이어에서 렌더링된 요소와 해당 ::backdrop 의사 요소는 다음 특성으로 렌더링됩니다:
-
새로운 스태킹 컨텍스트를 생성합니다.
-
부모 스태킹 컨텍스트는 루트 스태킹 컨텍스트입니다.
-
문서의 루트의 형제처럼 원자 단위로 렌더링됩니다.
-
position 속성이 fixed로 계산되면, 포함 블록은 뷰포트가 되고, 그렇지 않으면 초기 포함 블록이 됩니다.
-
요소일 경우, 해당 ::backdrop 의사 요소는 shadow-including inclusive ancestor가 display: none일 경우 렌더링되지 않습니다.
-
다른 명세에서 재정의하지 않는 한, left, right, top의 static position은 0입니다.
3.2. ::backdrop 의사 요소
각 최상위 레이어에서 렌더링된 요소는 ::backdrop 의사 요소를 가지며, 해당 요소가 기준 요소(originating element)입니다.
계산된 content 값이 none이 아니면, ::backdrop 의사 요소는 루트 요소의 형제처럼 박스를 생성합니다. 자동으로 최상위 레이어 내에서 별도의 항목으로 렌더링되며, 해당 기준 요소 아래에 표시됩니다. (자세한 내용은 "문서 페인팅(paint a document)" 참고.)
참고: ::backdrop 의사 요소는 최상위 레이어의 요소에 대해 하위 문서를 가릴 수 있는 배경(backdrop)을 생성하는 데 사용할 수 있습니다 (예: 전체 화면 표시된 요소 등).
::backdrop 의사 요소는 완전히 스타일링 가능한 의사 요소입니다.
사용자 에이전트는 UA 스타일 시트에 다음 규칙을 포함해야 합니다:
::backdrop{ position : fixed; inset : 0 ; }
다른 명세에서 ::backdrop 기본 렌더링에 속성을 추가할 수 있습니다.
참고: 예를 들어, 전체 화면 요소 ([FULLSCREEN] 참고)는 기본적으로 ::backdrop을 불투명한 검정색으로 스타일링합니다.
추가적인 § 3.1 최상위 레이어 스타일링 내용을 참고하여 ::backdrop 요소가 어떻게 렌더링되는지 확인하세요.
3.3. 최상위 레이어 조작
참고: 명세에서는 최상위 레이어에서 렌더링됨을 사용하는 대신 이 개념을 사용해야 합니다. 이 개념을 사용하면 overlay 전환이 있는지, 또는 두 동작이 렌더링 업데이트 사이에 발생하는지 이후에 발생하는지에 따라 동작이 달라지는 것을 방지할 수 있습니다.
참고: 명세에서는 최상위 레이어에 있다가 아닌 이 개념을 사용해야 하며, 최상위 레이어 자체를 조작하는 것이 아니라, "모든 것 위에" 렌더링되는 동작에 응답하는 경우에 사용합니다. 예를 들어, ::backdrop 의사 요소의 존재는 해당 요소가 최상위 레이어에서 렌더링되고 있어야 하며, 요소가 삭제 예정이어도, "모든 것 위에" 표시되는 한 ::backdrop을 가집니다.
Element
el이 주어졌을 때 다음과 같이 동작합니다:
-
doc를 el의 노드 문서로 설정한다.
-
el이 이미 포함되어 있다면 doc의 최상위 레이어에:
-
단언: el은 doc의 최상위 레이어 삭제 예정 목록에도 포함되어 있어야 한다. (그렇지 않으면 명세 오류임.)
-
제거 el을 doc의 최상위 레이어와 최상위 레이어 삭제 예정 목록 모두에서 제거한다.
-
-
UA !important cascade origin에서, el을 대상으로 하는 overlay: auto 선언이 포함된 규칙을 추가한다.
Element
el이 주어졌을 때 다음과 같이 동작합니다:
-
doc를 el의 노드 문서로 설정한다.
-
el이 포함되어 있지 않거나 doc의 최상위 레이어에, 혹은 el이 이미 포함되어 있다면 doc의 최상위 레이어 삭제 예정 목록에, return.
-
UA !important overlay: auto 규칙을 el에 대해 제거한다.
-
추가 el을 doc의 최상위 레이어 삭제 예정 목록에 추가한다.
Element
el이 주어졌을 때 다음과 같이 동작합니다:
-
doc를 el의 노드 문서로 설정한다.
-
제거 el을 doc의 최상위 레이어와 최상위 레이어 삭제 예정 목록에서 제거한다.
-
UA !important overlay: auto 규칙을 el에 대해 제거한다(존재할 경우).
참고: 이 알고리즘은 overlay 전환 등 즉시 최상위 레이어에서 제거해야 하는 특수한 경우에만 사용됩니다. 대부분의 경우에는 최상위 레이어 삭제 요청을 사용하는 것이 더 적합합니다.
Document
doc이 주어졌을 때 다음과 같이 동작합니다:
-
doc의 최상위 레이어 삭제 예정 목록에 있는 각 el에 대해: el의 overlay 계산값이 none이거나, el이 렌더링되지 않은 경우, 즉시 최상위 레이어에서 제거 el을 수행한다.
참고: 이 알고리즘은 HTML 렌더링 알고리즘의 "렌더링 업데이트" 단계에서 호출되는 것을 목적으로 합니다. 다른 알고리즘에서 호출되는 것은 의도되지 않았습니다.
참고: overlay 검사는 저자 수준의 전환에 의해 임의로 지연될 수 있습니다. 자세한 내용은 § 3.4 최상위 레이어 제어: overlay 속성을 참고하세요.
3.4. 최상위 레이어 제어: overlay 속성
Name: | overlay |
---|---|
Value: | none | auto |
Initial: | none |
Applies to: | 모든 요소 |
Inherited: | 아니오 |
Percentages: | 해당 없음 |
Computed value: | 지정된 그대로 |
Canonical order: | 문법 기준 |
Animation type: | 본문 참고 |
요소가 최상위 레이어에 있다면, overlay 속성은 실제로 최상위 레이어에서 렌더링되는지 여부를 결정합니다.
- none
- auto
-
요소가 최상위 레이어에 있다면 최상위 레이어에서 렌더링됩니다.
문서 내에서 정상 위치에 따라 박스를 생성하는 대신, 루트 요소의 형제로 박스를 생성하고, "위"에 렌더링됩니다.
그러나, 저자는 언제 overlay 값이 변경되는지에 영향을 줄 수 있습니다. transition을 속성에 설정함으로써 가능합니다. 이를 통해 저자는 애니메이션과 전환을 맞추어, 원하는 시점에만 요소가 최상위 레이어로 이동하거나, 그 밖으로 이동하도록 할 수 있습니다. 예를 들어, 페이지의 일반 위치에서 서서히 사라진 후 최상위 레이어 위치에서 서서히 나타나거나, 그 반대의 애니메이션을 만들 수 있습니다.
애니메이션에서는
auto가
이산 단계로 보간(interpolation)되어,
0 < p < 1
인 p값은 auto에 매핑되고,
그 외의 값은 더 가까운 끝점에 매핑됩니다;
두 값 모두 auto가 아니면 이산 애니메이션이 사용됩니다.
참고: 이는 visibility가 애니메이션되는 방식과 유사합니다. 대부분의 easing 함수에서는, 요소가 전환 전체 동안 최상위 레이어에서 렌더링됩니다. 진입/이탈 모두 해당합니다. step-start/step-end/linear()는 값이 언제 변경되는지 더 정밀하게 제어할 수 있습니다.
사용자 에이전트는 UA 스타일 시트에 다음 규칙을 반드시 포함해야 합니다:
*{ overlay : none !important; }
참고: 이는 overlay 속성은 저자나 사용자가 설정할 수 없으며—오로지 사용자 에이전트가 완전히 제어합니다. (사용자 에이전트는 overlay: auto로 UA-!important 규칙을 사용하여 최상위 레이어에 있는 요소에 적용합니다.)
사용자 에이전트는 필요에 따라, transition이 overlay에서 실행 중인 경우 이를 제거할 수 있습니다. 그 조건은 의도적으로 정의되어 있지 않습니다. (이는 transition: overlay 1e9s; 같은 경우, 요소를 최상위 레이어에 영구적으로 남겨두는 잠재적 악용을 방지하기 위함입니다.)
4. 페인팅 순서와 스태킹 컨텍스트
이 챕터는 CSS의 박스 트리의 페인팅 순서를 설명합니다.
박스 트리를 순회할 때, 트리 순서가 자주 사용됩니다. 프래그먼트의 경우, 이는 프래그먼트의 논리적 순서를 의미하며, 시각적 순서가 아닙니다. (예를 들어, 양방향 텍스트가 렌더링될 때 관련될 수 있습니다.)
페인팅 순서는 "페인터 모델"을 기준으로 정의됩니다. 요소들이 스택에 페인팅되는 것으로 설명되며, 스택의 바닥이 "먼저" 렌더링되고, 스택에서 더 위에 있는 항목들 아래에 위치합니다. 사용자는 스택의 맨 위에 존재하는 것으로 간주되며, 아래를 내려다봅니다:
| | | | | | ⇦ 🧑🎨 | | user z-index: canvas -1 0 1
스태킹 컨텍스트의 배경과 대부분의 음수 위치 스태킹 컨텍스트가 스택의 바닥에 위치하며, 가장 양수 위치의 스태킹 컨텍스트가 스택의 맨 위에 위치합니다.
캔버스가 다른 캔버스 안에 포함되어 있을 때는 투명하며, 포함되어 있지 않을 경우 UA 정의 색상이 지정됩니다. 캔버스는 무한한 크기를 가지며 루트 요소를 포함합니다. 처음에 뷰포트는 캔버스의 원점에 왼쪽 상단 모서리가 고정됩니다.
-
스태킹 컨텍스트 페인팅을 doc의 루트 요소와 canvas에 대해 수행한다.
-
doc의 최상위 레이어에 있는 각 요소 el에 대해:
-
스태킹 컨텍스트 페인팅을 el의 ::backdrop 의사 요소와 canvas에 대해 수행한다.
-
스태킹 컨텍스트 페인팅을 el과 canvas에 대해 수행한다. el을 스태킹 컨텍스트로 취급하며, 초기 포함 블록을 포함 블록으로 사용한다.
-
-
root가 요소라면, 스태킹 컨텍스트 페인팅을 root의 주 박스와 canvas에 대해 수행하고, return.
-
root가 루트 요소의 주 박스라면, root의 배경을 canvas 전체에 페인팅한다. 배경 위치 영역의 원점은 root의 배경이 일반적으로 페인팅되는 위치를 canvas에서 사용한다.
-
root가 블록 레벨 박스라면, 블록의 장식 페인팅을 root, canvas에 대해 수행한다.
-
root의 위치 지정된 후손 중 음수(0이 아님) z-index 값을 가진 후손에 대해, 해당 후손들을 z-index 순서(가장 음수부터) 그 다음 트리 순서로 정렬한 후, 각 후손과 canvas에 대해 스태킹 컨텍스트 페인팅을 수행한다.
-
root의 in-flow, 위치 지정되지 않은, 블록 레벨 후손에 대해, 트리 순서로, 해당 후손과 canvas에 대해 블록의 장식 페인팅을 수행한다.
-
root의 위치 지정되지 않은 부동 후손에 대해, 트리 순서로, 해당 후손과 canvas에 대해 스태킹 컨테이너 페인팅을 수행한다.
-
- root가 인라인 레벨 박스라면
-
root가 속한 각 라인 박스에 대해, 라인 박스 내 박스 페인팅을 root, 라인 박스, canvas에 대해 수행한다.
- 그 외
-
먼저 root에 대해, 그 다음 모든 in-flow, 위치 지정되지 않은, 블록 레벨 후손 박스에 대해, 트리 순서로:
-
박스가 치환 요소라면, 치환된 콘텐츠를 canvas에 원자적으로 페인팅한다.
-
그 외, 박스의 각 라인 박스에 대해, 라인 박스 내 박스 페인팅을 박스, 라인 박스, canvas에 대해 수행한다.
-
UA가 인밴드 윤곽선을 사용한다면, 박스의 윤곽선을 canvas에 페인팅한다.
-
-
root의 위치 지정된 후손 중 z-index: auto 또는 z-index: 0 값을 가진 후손에 대해, 트리 순서로:
- 후손이 z-index: auto인 경우
-
스태킹 컨테이너 페인팅을 해당 후손과 canvas에 대해 수행한다.
- 후손이 z-index: 0인 경우
-
스태킹 컨텍스트 페인팅을 해당 후손과 canvas에 대해 수행한다.
-
root의 위치 지정된 후손 중 양수(0이 아님) z-index 값을 가진 후손에 대해, 해당 후손들을 z-index 순서(가장 작은 것부터) 그 다음 트리 순서로 정렬한 후, 각 후손과 canvas에 대해 스태킹 컨텍스트 페인팅을 수행한다.
-
UA가 아웃오브밴드 윤곽선을 사용한다면, root의 모든 윤곽선을 그린다 (이번 알고리즘 호출에서 인밴드 윤곽선 사용으로 인해 그리지 않은 윤곽선) canvas에 페인팅한다.
-
root가 테이블 래퍼 박스가 아니라면:
-
root가 테이블 래퍼 박스인 경우:
-
root의 각 컬럼 그룹에 대해 트리 순서로, 컬럼 그룹의 배경을 canvas에 페인팅한다.
-
root의 각 컬럼에 대해 트리 순서로, 컬럼의 배경을 canvas에 페인팅한다.
-
root의 각 행 그룹에 대해 트리 순서로, 행 그룹의 배경을 canvas에 페인팅한다.
-
root의 각 행에 대해 트리 순서로, 행의 배경을 canvas에 페인팅한다.
-
root의 각 셀에 대해 트리 순서로, 셀의 배경을 canvas에 페인팅한다.
-
root의 모든 테이블 요소의 테두리를 페인팅한다. 테두리가 분리되어 있으면, 트리 순서로 페인팅한다; 연결되어 있으면, [css-tables-3]에서 지정된 대로 수행한다.
-
root의 프래그먼트 중 line box에 속한 것들의 배경을 canvas에 페인팅한다.
-
root의 프래그먼트 중 line box에 속한 것들의 테두리를 canvas에 페인팅한다.
-
- root가 인라인 박스라면
-
root의 in-flow, 위치 지정되지 않은, 인라인 레벨 자식 중 line box에 프래그먼트를 생성하는 자식, 그리고 텍스트 시퀀스 자식 중 line box에 프래그먼트를 생성하는 자식에 대해, 트리 순서로:
- 이 자식이 텍스트 시퀀스라면:
-
-
텍스트에 적용된 밑줄을 페인팅한다. 밑줄을 적용한 요소의 트리 순서대로(가장 깊은 요소의 밑줄이 가장 위에 페인팅되고, 루트 요소의 밑줄이 가장 아래에 그려짐) canvas에 페인팅한다.
-
텍스트에 적용된 오버라인을 페인팅한다. 오버라인을 적용한 요소의 트리 순서대로(가장 깊은 요소의 오버라인이 가장 위에 페인팅되고, 루트 요소의 오버라인이 가장 아래에 그려짐) canvas에 페인팅한다.
-
텍스트를 canvas에 페인팅한다.
-
텍스트에 적용된 취소선(line-through)을 페인팅한다. 취소선을 적용한 요소의 트리 순서대로(가장 깊은 요소의 취소선이 가장 위에 페인팅되고, 루트 요소의 취소선이 가장 아래에 그려짐) canvas에 페인팅한다.
-
- 이 자식이 박스라면:
-
라인 박스 내 박스 페인팅을 해당 자식, line box, canvas에 대해 수행한다.
- root가 인라인 레벨 블록 또는 테이블 래퍼 박스라면
-
스태킹 컨테이너 페인팅을 root, canvas에 대해 수행한다.
- root가 인라인 레벨 치환 요소라면
-
치환된 콘텐츠를 canvas에 원자적으로 페인팅한다.
-
UA가 인밴드 윤곽선을 사용한다면, root의 프래그먼트 중 line box에 속한 것들의 윤곽선을 canvas에 페인팅한다.
참고: 인라인 박스의 프래그먼트의 시각적 순서가 양방향 재배치로 인해 라인 내에서 재배열될 수 있지만, 프래그먼트들은 트리 순서로 페인팅됩니다.
-
스태킹 컨텍스트 페인팅을 root, canvas에 대해 수행한다. root가 새로운 스태킹 컨텍스트를 생성하는 것처럼 취급하되, 위치 지정된 후손이나 실제로 스태킹 컨텍스트를 생성하는 후손은 생략한다 (부모 스태킹 컨텍스트가 대신 페인팅하도록 한다).
UA는 outline 속성의 윤곽선을 인밴드 윤곽선 (각 요소를 따라 페인팅되어, 이후의 콘텐츠에 의해 가려지거나 겹칠 수 있음) 또는 아웃오브밴드 윤곽선 (스태킹 컨텍스트의 끝에서 모든 윤곽선이 페인팅되어, 스태킹 컨텍스트 내의 어느 것도 윤곽선을 가릴 수 없음)으로 그릴 수 있습니다. UA가 아웃오브밴드 윤곽선을 사용하는 것이 권장되며, 윤곽선을 쉽게 볼 수 있도록 하는 것은 중요한 접근성 기능입니다.
5. 변경 사항
2025년 7월 8일 최초 공개 작업 초안 이후의 주요 변경 사항:
-
없음(마크업 및 링크 수정만 있음).
개인정보 고려사항
이 명세에 대해 보고된 새로운 개인정보 고려사항은 없습니다.
보안 고려사항
이 명세에 대해 보고된 새로운 보안 고려사항은 없습니다.