1. 소개
이 섹션은 규범적입니다.
CSS는 트리 구조의 요소(다른 요소 및 텍스트 노드가 섞여 있을 수 있음), 그리고 텍스트 노드(텍스트를 포함할 수 있음)로 구성된 소스 문서를 받아, 이를 화면, 종이, 오디오 스트림 등과 같은 캔버스에 렌더링합니다. 이와 같은 소스 문서는 어떤 종류든 CSS로 렌더링할 수 있지만, 가장 널리 사용되는 유형은 DOM입니다. [DOM] (이러한 더 복잡한 트리 유형에는 주석 노드 등 추가적인 노드 타입이 포함될 수 있습니다. CSS의 목적상 이러한 추가 노드 타입들은 모두 무시되어, 존재하지 않는 것처럼 취급됩니다.)
이를 위해, CSS는 중간 구조인 박스 트리를 생성합니다. 이 구조는 렌더링된 문서의 포매팅 구조를 나타냅니다. 박스 트리의 각 박스는 해당 요소(또는 가상 요소)를 캔버스의 공간 또는 시간에 표현합니다. 텍스트 시퀀스는 박스 트리 내에서 해당 텍스트 노드의 내용을 동일하게 표현합니다.
박스 트리를 생성하기 위해, CSS는 먼저 계단식과 상속을 이용하여, 소스 트리의 각 요소 및 텍스트 노드마다 각 CSS 속성의 계산값을 할당합니다. (자세한 내용은 [CSS-CASCADE-3] 참고.)
그 후 각 요소마다, 해당 요소의 display 속성에 따라 0개 이상의 박스를 만듭니다. 일반적으로, 하나의 요소는 하나의 박스, 즉 주 박스를 생성하며, 이 주 박스는 자신을 나타내고 박스 트리 내에 자식 컨텐츠를 포함합니다. 그러나 일부 display 값 (예: display: list-item)은 하나 이상의 박스(예: 주 블록 박스와 자식 마커 박스)를 생성합니다. 또 일부 값(none 또는 contents 등)은 해당 요소 및/또는 그 자손이 아예 박스를 생성하지 않게 만듭니다. 박스는 보통 display 타입으로 칭해집니다. 예를 들어, display: block인 요소가 생성한 박스는 “블록 박스” 또는 “블록”이라 부릅니다.
박스는 별도의 명시가 없는 한,
이를 생성한 요소와 동일한 스타일을 가집니다.
일반적으로 상속 속성은 주 박스에 할당되고,
박스 트리를 따라 동일 요소에서 생성된 다른 박스로 상속됩니다.
비상속 속성은 기본적으로 주 박스에 적용되지만,
요소가 여러 박스를 생성할 때는 특정 박스에만 적용되도록 정의될 수 있습니다.
예를 들어 border
속성은
table 요소에 적용 시 table grid box에 적용되고,
주 table
wrapper box에는 적용되지 않습니다.
만약 값 계산 과정에서 이러한 박스의 스타일이 변경되고,
요소의 스타일이 요청되면(예: getComputedStyle()
호출 시),
요소는 각 속성별로 해당 속성이 적용된 박스의 값을 반영합니다.
마찬가지로, 연속된 형제 텍스트 노드 시퀀스는 해당 텍스트 내용을 포함하는 텍스트 시퀀스를 생성합니다. 이 시퀀스는 생성한 텍스트 노드와 동일한 스타일을 할당받습니다. 단, 시퀀스에 텍스트가 없다면 텍스트 시퀀스를 생성하지 않습니다.
박스 트리를 구성할 때, 한 요소가 생성한 박스들은 상위 요소의 주 박스의 자손이 됩니다. 일반적으로, 한 요소의 부모 박스는 가장 가까운 상위 요소의 주 박스입니다. 다만, run-in 박스, 여러 컨테이너 박스를 생성하는 테이블 등, 중간 익명 박스가 개입하는 경우 등 예외도 있습니다.
익명 박스란 어떤 요소와도 연관되지 않은 박스입니다. 익명 박스는 박스 트리가 특정 중첩 구조를 필요로 하지만 요소 트리에서 생성된 박스만으로는 만족할 수 없을 때 생성됩니다. 예를 들어, 테이블 셀 박스는 반드시 테이블 행 박스가 부모여야 하므로, 부모가 해당하지 않을 경우 익명 테이블 행 박스가 생성되어 감쌉니다. (자세한 내용은 [CSS2] § 17.2.1 참고.) 요소 기반 박스는 스타일이 요소 트리를 따라 엄격히 상속되는 반면, 익명 박스(오직 박스 트리에만 존재)는 박스 트리 상의 부모를 통해 상속됩니다.
레이아웃 과정에서 박스와 텍스트 시퀀스는 여러 조각(fragment)으로 나뉠 수 있습니다. 예를 들어 인라인 박스 및/또는 텍스트 시퀀스가 여러 줄로 분리되거나, 블록 박스가 페이지나 열을 넘어 분리될 때 (fragmentation이라 부름) 발생합니다. 또한 텍스트의 bidi 재정렬(자세한 내용은 양방향 재정렬 알고리즘 적용 참고)이나 상위 display type 박스 분할(예: block-in-inline splitting 또는 column-spanner-in-block 분할)에서도 일어날 수 있습니다. 그러므로 박스는 하나 이상의 박스 조각으로, 텍스트 시퀀스는 하나 이상의 텍스트 조각으로 구성됩니다. [CSS-BREAK-3]에서 fragmentation 관련 상세 내용을 확인할 수 있습니다.
참고: 많은 CSS 명세들이 이 용어가 정립되기 전에 작성되었거나 잘못 참조하고 있으니, 이런 용어를 쓴 옛 명세를 볼 때 주의해야 합니다. 실제로 어떤 용어를 의미하는지 문맥상 유추가 가능해야 하며, 발견 시 명세 오류를 보고해 주시면 수정될 수 있습니다.
참고: “오럴(aural)” 박스 트리와 display 속성의 상호작용에 대한 추가 정보는 CSS Speech 모듈에서 확인할 수 있습니다. [CSS-SPEECH-1]
1.1. 모듈 상호작용
이 모듈은 display 속성에 대한 [CSS2] 9.2.4절의 정의를 대체 및 확장합니다.
이 모듈의 어떤 속성도 ::first-line 또는 ::first-letter 가상 요소에는 적용되지 않습니다.
1.2. 값 정의
이 명세는 CSS 속성 정의 규약을 [CSS2]에서 따르며, 값 정의 문법은 [CSS-VALUES-3]을 사용합니다. 이 명세에서 정의되지 않은 값 타입은 CSS Values & Units [CSS-VALUES-3]에서 정의되어 있습니다. 다른 CSS 모듈과의 결합으로 이러한 값 타입의 정의가 확장될 수 있습니다.
속성 정의에 명시된 속성별 값 외에, 이 명세에서 정의된 모든 속성은 CSS 전역 키워드(CSS-wide keywords) 역시 속성 값으로 허용합니다. 가독성을 위해 별도로 반복하지 않았습니다.
2. 박스 레이아웃 모드: display 속성
| 이름: | display |
|---|---|
| 값: | [ <display-outside> || <display-inside> ] | <display-listitem> | <display-internal> | <display-box> | <display-legacy> |
| 초기값: | inline |
| 적용 대상: | 모든 요소 |
| 상속: | 아니오 |
| 퍼센트값: | 해당 없음 |
| 계산된 값: | inner와 outer display 타입을 나타내는 키워드 쌍과 선택적 list-item 플래그, 또는 <display-internal> 또는 <display-box> 키워드; 계산 규칙은 여러 명세의 본문 참조 |
| 정식 순서: | 문법에 따름 |
| 애니메이션 유형: | § 2.9 display의 애니메이션 및 보간 참조 |
UA는 비시각적 매체를 포함한 모든 매체에서 이 속성을 지원해야 합니다. display 속성은 요소의 display 타입을 정의합니다. 이는 요소가 박스를 생성하는 두 가지 기본 특성으로 구성됩니다:
-
inner display 타입: (비치환 요소인 경우) 후손 박스가 어떻게 배치되는지 결정하는 포매팅 컨텍스트의 종류를 정의합니다. (치환 요소의 inner display는 CSS의 범위 밖입니다.)
-
outer display 타입: 주 박스 자체가 flow layout에 어떻게 참여하는지 결정합니다.
텍스트 시퀀스는 display 타입이 없습니다.
일부 display 값은 추가적인 부작용이 있습니다. 예를 들어 list-item은 ::marker 가상 요소도 생성하며, none은 요소 전체 서브트리를 박스 트리에서 제외합니다.
값은 다음과 같이 정의됩니다:
<display-outside> = block | inline | run-in
<display-inside> = flow | flow-root | table | flex | grid | ruby
<display-listitem> = <display-outside>? && [ flow | flow-root ]? && list-item
<display-internal> = table-row-group | table-header-group |
table-footer-group | table-row | table-cell |
table-column-group | table-column | table-caption |
ruby-base | ruby-text | ruby-base-container |
ruby-text-container
<display-box> = contents | none
<display-legacy> = inline-block | inline-table | inline-flex | inline-grid
다음 정보성 표는 display 값들을 요약합니다:
| 간략 display | 전체 display | 생성 박스 |
|---|---|---|
| none | — | 박스 트리에서 서브트리 생략 |
| contents | — | 박스 트리에서 요소를 컨텐츠로 대체 |
| block | block flow | 블록 레벨 블록 컨테이너 (aka 블록 박스) |
| flow-root | block flow-root | 블록 레벨 블록 컨테이너 (새로운 블록 포매팅 컨텍스트 (BFC) 생성) |
| inline | inline flow | 인라인 박스 |
| inline-block | inline flow-root | 인라인-레벨 블록 컨테이너 (aka 인라인 블록) |
| run-in | run-in flow | run-in 박스 (인라인 박스에 특수 박스 트리 규칙 적용) |
| list-item | block flow list-item | 블록 박스와 추가 마커 박스 |
| inline list-item | inline flow list-item | 인라인 박스와 추가 마커 박스 |
| flex | block flex | 블록 레벨 flex 컨테이너 |
| inline-flex | inline flex | 인라인-레벨 flex 컨테이너 |
| grid | block grid | 블록 레벨 그리드 컨테이너 |
| inline-grid | inline grid | 인라인-레벨 그리드 컨테이너 |
| ruby | inline ruby | 인라인-레벨 ruby 컨테이너 |
| block ruby | block ruby | 블록 박스와 ruby 컨테이너 포함 |
| table | block table | 블록 레벨 table wrapper box와 table grid box 포함 |
| inline-table | inline table | 인라인-레벨 table wrapper box와 table grid box 포함 |
| <display-internal> 타입 | — | 레이아웃 전용 내부 박스 |
참고: “가장 후방 호환, 그리고 가장 짧게”라는 우선순위 규칙에 따라, 동등한 display 값의 직렬화는 “간략 display” 열을 사용합니다. [CSSOM]
2.1. 플로우 레이아웃의 외부 디스플레이 역할: block, inline, 그리고 run-in 키워드
<display-outside> 키워드는 요소의 외부 디스플레이 타입을 지정합니다. 이는 본질적으로 주 박스가 플로우 레이아웃에서 어떤 역할을 하는지를 의미합니다. 정의는 다음과 같습니다:
- block
- 요소는 플로우 레이아웃에 배치될 때 블록-레벨 박스를 생성합니다. [CSS2]
- inline
- 요소는 플로우 레이아웃에 배치될 때 인라인-레벨 박스를 생성합니다. [CSS2]
- run-in
- 요소는 run-in 박스를 생성하며, 이는 인라인-레벨 박스의 한 종류로, 이후 블록 컨테이너에 병합을 시도하는 특수 동작을 가집니다. 자세한 내용은 § 6 Run-In 레이아웃을 참고하세요.
참고: 외부 디스플레이 타입은 치환 요소에도 영향을 미칩니다.
<display-outside> 값은 지정되었지만 <display-inside>가 생략된 경우, 요소의 내부 디스플레이 타입은 기본적으로 flow가 됩니다.
2.2. 내부 디스플레이 레이아웃 모델: flow, flow-root, table, flex, grid, ruby 키워드
<display-inside> 키워드는 요소의 내부 디스플레이 타입을 지정하며, 이는 해당 요소의 컨텐츠를 어떤 포매팅 컨텍스트에서 배치할지 정의합니다 (치환 요소가 아닐 경우). 정의는 다음과 같습니다:
- flow
-
요소는 흐름
레이아웃을 사용하여(블록 및 인라인 레이아웃) 콘텐츠를 배치합니다.
만약 외부 display 타입이 inline 또는 run-in이고, 그리고 블록 또는 인라인 포매팅 컨텍스트에 참여한다면, 인라인 박스를 생성합니다.
그렇지 않은 경우 블록 컨테이너 박스를 생성합니다.
다른 속성 값(예: position, float, overflow 등)에 따라, 그리고 해당 요소가 블록 또는 인라인 포매팅 컨텍스트에 직접 참여하는지에 따라, 새 블록 포매팅 컨텍스트를 생성하거나 자신의 콘텐츠를 상위 포매팅 컨텍스트에 통합합니다. CSS2.1 9장 참조. [CSS2] 블록 컨테이너가 새 블록 포매팅 컨텍스트를 생성할 경우, 사용 내부 display 타입은 flow-root로 간주합니다.
- flow-root
- 요소는 블록 컨테이너 박스를 생성하고, 흐름 레이아웃을 사용하여 콘텐츠를 배치합니다. 항상 자신의 콘텐츠를 위해 새로운 블록 포매팅 컨텍스트를 생성합니다. [CSS2]
- table
- 요소는 주요 테이블 래퍼 박스를 생성하며, 해당 박스는 블록 포매팅 컨텍스트를 생성합니다. 그리고 추가적으로 생성되는 테이블 그리드 박스가 테이블 포매팅 컨텍스트를 생성합니다. [CSS2]
- flex
- 요소는 주요 flex 컨테이너 박스를 생성하고, flex 포매팅 컨텍스트를 생성합니다. [CSS-FLEXBOX-1]
- grid
-
요소는 주요 그리드 컨테이너 박스를 생성하고,
그리드 포매팅 컨텍스트를 생성합니다. [CSS-GRID-1]
(subgrid를 사용하는 그리드는 반드시 새로운 그리드 포매팅 컨텍스트를 생성하지 않을 수도 있습니다; 자세한 내용은 [CSS-GRID-2] 참조.)
- ruby
- 요소는 ruby 컨테이너 박스를 생성하고, ruby 포매팅 컨텍스트를 생성합니다. 추가로, 기본 수준(base-level) 콘텐츠를 상위 포매팅 컨텍스트(인라인인 경우)로 통합하거나, 인라인이 아닌 경우 적절한 외부 display 타입의 래퍼 박스를 생성합니다. [CSS-RUBY-1]
<display-inside> 값을 지정했으나 <display-outside>가 생략된 경우, 요소의 외부 디스플레이 타입은 기본적으로 block이 됩니다. 단, ruby는 inline이 기본값입니다.
2.3. 마커 박스 생성: list-item 키워드
list-item 키워드는 요소가 ::marker 가상 요소[CSS-PSEUDO-4]를 생성하게 하며, 해당 내용은 list-style 속성에 의해 지정됩니다 (CSS 2.1§12.5 리스트) [CSS2] 그리고 해당 요소 자신의 컨텐츠를 위한 주 박스도 함께 생성됩니다.
내부 디스플레이 타입이 지정되지 않은 경우 주 박스의 내부 디스플레이 타입은 기본적으로 flow가 됩니다. 외부 디스플레이 타입이 지정되지 않은 경우 주 박스의 외부 디스플레이 타입은 기본적으로 block이 됩니다.
참고: 이 레벨에서는 문법에 의해 제한되어, list-item은 플로우 레이아웃 디스플레이 타입(block/inline/run-in + flow/flow-root 내부 타입)에만 허용됩니다. 이 제한은 모듈의 차기 레벨에서 완화될 수 있습니다.
2.4. 레이아웃 내부 디스플레이 타입: table-* 및 ruby-* 키워드
일부 레이아웃 모델(table, ruby 등)은 자식과 후손이 맡는 역할이 다양한 복잡한 내부 구조를 가집니다. 본 절에서는 해당 레이아웃 모드 내에서 의미를 가지는 “레이아웃 내부” display 값을 정의합니다.
별도 명시가 없는 한, 이러한 display 값을 사용하는 요소의 내부 디스플레이 타입과 외부 디스플레이 타입은 각각 해당 키워드로 설정됩니다.
display 속성이 치환 요소에서 레이아웃 내부 값 중 하나로 계산되는 경우, 해당 요소는 사용된 값이 inline인 것처럼 처리됩니다. 공백 압축 및 익명 박스 생성은 해당 치환 요소 주위에서 inline 값 기준으로 동작하며, 레이아웃 내부 디스플레이 값이 적용되지 않은 것처럼 취급됩니다.
작성자는 레이아웃 내부 디스플레이 값을 치환 요소에 지정하지 않아야 합니다.
<display-internal> 키워드의 정의는 다음과 같습니다:
- table-row-group, table-header-group, table-footer-group, table-row, table-cell, table-column-group, table-column
-
요소는 내부
테이블 요소입니다.
테이블 포매팅 컨텍스트에 참여하는 적절한 내부 테이블 박스를 생성합니다.
자세한 내용은 CSS2§17.2 [CSS2] 참고.
table-cell 박스는 flow-root 내부 디스플레이 타입을 가집니다.
- table-caption
-
요소는 테이블 캡션
박스를 생성합니다.
이 박스는 블록 박스이며, 테이블 및 테이블 래퍼 박스와
관련해 특별한 동작을 가집니다.
자세한 내용은 CSS2§17.2 [CSS2] 참고.
table-caption 박스는 flow-root 내부 디스플레이 타입을 가집니다.
-
- ruby-base, ruby-text, ruby-base-container, ruby-text-container
-
요소는 내부
ruby 요소입니다.
ruby 포매팅 컨텍스트에 참여하는 적절한 내부 ruby 박스를 생성합니다. [CSS-RUBY-1]
ruby-base 및 ruby-text는 flow 내부 디스플레이 타입을 가집니다.
레이아웃 전용 디스플레이 타입을 가진 박스는, 호환되지 않는 부모에 배치될 때 각각의 명세에 정의된 대로 자신을 감싸는 익명 래퍼 박스를 생성합니다.
잘못된 부모에 배치된 경우:
< div style = "display:block;" > < div style = "display:table-cell" > ...</ div > </ div >
아래와 같이 익명 래퍼 박스가 생성됩니다:
block box └anonymous table box └anonymous table-row-group box └anonymous table-row box └table-cell box
부모가 또 다른 내부 테이블 요소라 해도 올바른 부모가 아니면 래퍼 박스가 생성됩니다. 예를 들어 아래 마크업에서는:
< div style = "display:table;" > < div style = "display:table-row" > < div style = "display:table-cell" > ...</ div > </ div > </ div >
익명 래퍼 박스 생성 결과:
table box └anonymous table-row-group box └table-row box └table-cell box
이러한 "수정(fix-up)" 덕분에 테이블 레이아웃은 예측 가능한 구조를 갖게 됩니다.
2.5. 박스 생성: none 및 contents 키워드
display 속성은 요소가 생성할 박스의 종류뿐 아니라, 박스를 생성할지의 여부도 제어할 수 있습니다.
<display-box> 키워드의 정의는 다음과 같습니다:
- contents
-
해당 요소 자체는 박스를 생성하지 않지만,
자식과 가상 요소는 평소처럼 박스와 텍스트 시퀀스를 생성합니다.
박스 생성 및 레이아웃을 위해,
해당 요소는 요소 트리에서
그 컨텐츠(자식 및 ::before, ::after 등 가상 요소 포함)로 대체된 것처럼 취급해야 합니다.
참고: 오직 박스 트리만 영향을 받으므로, 셀렉터 매칭, 이벤트 처리, 속성 상속 등 문서 트리 기반 의미에는 영향이 없습니다. 하지만 현재 주요 브라우저에서 올바르게 구현되어 있지 않으므로, 이 기능을 웹에서 사용할 때는 주의해야 하며, 접근성 도구가 요소의 의미에 접근하지 못할 수 있습니다.
이 값은 치환 요소 및 CSS로 렌더링이 완전히 제어되지 않는 요소의 경우 display: none으로 계산됩니다. 자세한 내용은 부록 B: display: contents가 비정상 요소에 미치는 영향을 참고하세요.
참고: 치환 요소와 폼 컨트롤은 요소 자신의 박스만 제거하는 것이 사실상 정의되지 않은 동작이기 때문에 특별 처리됩니다. 향후 더 정밀한 렌더링 모델이 등장하거나 실제 사용 사례가 늘어나면 이 동작이 변경될 수 있으므로, 이런 요소에는 display: contents 대신 display: none 사용을 권장합니다.
- none
-
요소 및 그 자손은
어떤 박스나 텍스트 시퀀스도 생성하지 않습니다.
마찬가지로, 텍스트 노드가 display: none으로 동작하도록 정의된 경우, 텍스트 시퀀스를 생성하지 않습니다.
이 값들이 적용된 요소는 내부 또는 외부 디스플레이 타입이 없습니다. 박스를 전혀 생성하지 않기 때문입니다.
참고: 이 값들은 영향을 받는 요소가 박스를 생성하지 않게 하므로, 익명 박스 생성 규칙은 완전히 무시된 것처럼 동작합니다.
하지만 마크업 기반의 관계는 이러한 값에 영향을 받지 않습니다.
이는 오직 렌더링 시점의 효과이기 때문입니다. 예를 들어,
어떤 테이블 셀이 화면상 어떤 열에 표시되는가에는 영향을 줄 수 있지만,
특정 열 요소와 어떤 테이블 셀이 연결되는지에는 영향을 주지 않습니다.
마찬가지로, 어떤 HTML
summary
요소가 어느 테이블에 연결되는지나,
legend
가 특정
fieldset
의 내용을 레이블링하는지 여부에는 영향을 미치지 않습니다.
2.6. 미리 조합된 인라인 수준 display 값
CSS 레벨 2는 display에 대해 단일 키워드 문법을 사용했으며, 동일한 레이아웃 모드의 블록 수준과 인라인 수준 변형에 대해 별도의 키워드를 요구했습니다. 이러한 <display-legacy> 키워드는 다음과 같이 매핑됩니다:
- inline-block
- inline flow-root로 계산됩니다.
- inline-table
- inline table로 계산됩니다.
- inline-flex
- inline flex로 계산됩니다.
- inline-grid
- inline grid로 계산됩니다.
참고: 이 키워드와 그에 해당하는 값은 계산 결과는 동일하지만, 지정값은 서로 다릅니다.
참고: getComputedStyle()
직렬화 규칙은
항상 동등한 두 키워드 쌍 대신 이러한 미리 조합된 키워드로 출력합니다.
이는 가장 짧고, 하위 호환성이 높은 직렬화 원칙 때문입니다.
2.7. 박스 타입 자동 변환
일부 레이아웃 효과는 박스 타입의 블록화 또는 인라인화가 필요하며, 이는 박스의 계산된 외부 display 타입을 각각 block 또는 inline으로 설정합니다. (이는 display 타입이 박스를 생성하지 않는 경우, 예를 들어 none이나 contents 같은 값에는 영향을 주지 않습니다.) 추가적으로:
-
블록 박스(block flow)가 인라인화될 경우, 내부 display 타입이 flow-root로 설정되어 블록 컨테이너 성질을 유지합니다.
-
인라인 박스(inline flow)가 인라인화될 경우, 자신의 인플로우 자식을 재귀적으로 모두 인라인화하여, 어떤 블록 수준 자손도 해당 인라인 포매팅 컨텍스트를 끊지 않도록 합니다.
-
호환성 이유로, 인라인 블록 박스 (inline flow-root) 가 블록화되면, block 박스가 되며 (flow-root 특성을 잃음). 일관성을 위해, run-in flow-root 박스도 블록화되면 block 박스가 됩니다.
-
layout-internal 박스가 블록화될 경우, 내부 display 타입이 flow로 변환되어 블록 컨테이너가 됩니다. 인라인화는 layout-internal 박스에는 영향을 주지 않습니다. (단, 이런 인라인 컨텍스트에 배치될 경우, 보통 적절한 타입의 익명 인라인 수준 박스로 감싸집니다.)
참고: 박스가 컨텍스트에 맞지 않을 때 박스 타입을 보정하는 방법은 두 가지가 있습니다. 하나는 여기서 설명하는 계산값 변환으로, display의 블록화 및 인라인화가 이에 해당합니다. 다른 하나는 박스 트리 구성 중(계산값이 결정된 이후) 중간 익명 박스를 생성하는 것으로, 테이블, 루비, flow 레이아웃에서 발생합니다.
- 요소를 절대 위치시키거나 플로트시키면 블록화되어 박스의 display 타입이 블록이 됩니다. [CSS2]
- 루비 컨테이너에 포함되면 인라인화되어 박스의 display 타입이 인라인이 됩니다. [CSS-RUBY-1] 참조.
- 부모가 grid 또는 flex display값을 가지면 블록화되어 박스의 display 타입이 블록이 됩니다. [CSS-GRID-1] [CSS-FLEXBOX-1]
2.8. 루트 요소의 주요 박스
루트 요소의 display 타입은 항상 블록화되며, 주요 박스는 항상 독립 포매팅 컨텍스트를 생성합니다. 이 박스의 컨테이닝 블록은 초기 컨테이닝 블록입니다.
또한, 루트 요소에서 display가 contents일 경우, block으로 계산됩니다.
2.9. display의 애니메이션 및 보간
일반적으로 display 속성의 애니메이션 타입은 불연속(discrete)입니다. 하지만, visibility의 보간과 유사하게(Web Animations § visibility 애니메이션 참조), none과 다른 display 값 사이 보간에서는, 0과 1 사이의 p 값이 비-none 값에 매핑됩니다. 또한, 해당 요소는 display 값이 Transitions 및 Animations cascade origin을 무시했을 때 none으로 계산되면 inert 상태가 됩니다.
3. 표시 순서: order 속성
| 이름: | order |
|---|---|
| 값: | <integer> |
| 초기값: | 0 |
| 적용 대상: | flex 아이템 및 grid 아이템 |
| 상속: | 아니오 |
| 백분율: | 해당 없음 |
| 계산값: | 지정한 정수 |
| 정규 순서: | 문법에 따름 |
| 애니메이션 타입: | 계산값 타입에 따라 |
박스는 일반적으로 소스 문서에 나타나는 순서대로 표시 및 레이아웃됩니다. 일부 포매팅 컨텍스트에서는 order 속성을 사용하여 박스의 순서를 재배열하여 요소의 논리적 순서와 2D 시각적 캔버스에서의 공간적 배치가 다르게 만들 수 있습니다. (§ 3.1 재정렬 및 접근성 참조.)
구체적으로, order 속성은 flex 아이템 또는 grid 아이템이 컨테이너 내에서 어떤 순서로 나타날지 제어하며, 이들을 순서 그룹(ordinal group)에 할당합니다. 단일 <integer> 값을 가지며, 이 값은 해당 아이템이 속할 순서 그룹을 지정합니다.
article.sale-item{ display : flex; flex-flow : column; } article.sale-item > img{ order : -1 ; /* Shift image before other content (in layout order) */ align-self: center; }
< article class = "sale-item" > < h1 > Computer Starter Kit</ h1 > < p > This is the best computer money can buy, if you don’t have much money.< ul > < li > Computer< li > Monitor< li > Keyboard< li > Mouse</ ul > < img src = "images/computer.jpg" alt = "You get: a white desktop computer with matching peripherals." > </ article >
Computer Starter Kit
이것은 돈이 많지 않다면 살 수 있는 최고의 컴퓨터입니다.
- Computer
- Monitor
- Keyboard
- Mouse
Flex 및 grid 컨테이너는 콘텐츠를 order로 수정된 문서 순서에 따라, 가장 낮은 순서 그룹부터 시작해 배치합니다. 동일한 순서 그룹 내 아이템은 소스 문서에 나타나는 순서대로 배치됩니다. 이는 페인팅 순서에도 영향을 주며 [CSS2], 마치 flex/grid 아이템이 소스 문서에서 재배열된 것과 같습니다. flex/grid 컨테이너의 절대 위치 자식은 order: 0으로 간주되어 flex/grid 아이템과의 페인팅 순서가 결정됩니다.
향후 명세에서 별도로 지정하지 않는 한, 이 속성은 flex 아이템이나 grid 아이템이 아닌 박스에는 효과가 없습니다.
3.1. 재정렬 및 접근성
order
속성은 비시각적 미디어(예: 음성)의 순서에는 영향을 주지 않습니다.
마찬가지로, order는
시퀀스 탐색 모드(예: 링크 순환, tabindex
[HTML] 등)의 기본 탐색 순서에도 영향을 주지 않습니다.
저자는 order를 반드시 공간적(시각적) 재정렬에만 사용해야 하며, 논리적 순서 재정렬에는 사용해서는 안 됩니다. order로 논리적 재정렬을 수행하는 스타일 시트는 비적합합니다.
참고: 비시각적 미디어 및 비CSS UA는 일반적으로 콘텐츠를 선형적으로 제시하므로, 논리적 소스 순서를 신뢰할 수 있습니다. order는 레이아웃 순서를 조정하는 데만 사용합니다. (시각적 인식은 2차원·비선형적이므로, 원하는 레이아웃 순서가 항상 논리적이진 않습니다.)
모든 프레젠테이션 모드에서 저자의 의도된 순서를 보존하기 위해, 저작 도구(위지윅 편집기, 웹 기반 저작 도구 포함)는 기본 문서 소스를 재정렬해야 하며, order로 재정렬을 수행해서는 안 됩니다. 단, 저자가 공간적 순서가 문서 순서(음성·탐색 순서 결정)에 동기화되지 않음을 명시적으로 지시한 경우는 예외입니다.
대부분의 경우, 재정렬은 모든 화면 크기·탐색·음성 순서에 영향을 주므로, 도구는 DOM 계층에서 드래그-앤-드롭 재정렬을 수행해야 합니다. 그러나 저자가 화면 크기별로 다른 레이아웃을 원할 수도 있습니다. 이때 도구는 order와 미디어 쿼리를 함께 사용해 가장 작은 화면 크기에서는 DOM 순서를 그대로 두고(논리적 선형 순서), 다른 화면 크기에서는 order로 시각적 순서를 정의하는 기능을 제공할 수 있습니다.
이 도구는 적합하지만, 오직 order만으로 드래그-앤-드롭 재정렬을 처리한다면 (구현은 편리할지라도) 비적합하게 됩니다.
참고: 브라우저, 보조기술, 확장기능 등 UA는 공간적 탐색 기능을 제공할 수 있습니다. 이 절은 그러한 공간 탐색 모드에서 요소 순서 결정 시 order 속성을 존중하는 것을 금지하지 않습니다; 오히려 그런 기능이 동작하려면 반드시 고려해야 합니다. 단, order는 공간 탐색 기능에 고려해야 할 유일하거나 주된 CSS 속성이 아닙니다. 잘 구현된 공간 탐색 기능은 CSS의 모든 공간적 관계를 변경하는 레이아웃 기능을 함께 고려해야 합니다.
4. 읽기 순서: reading-flow 속성
읽기 흐름 컨테이너란 유효한 reading-flow 값이 normal이 아닌 flex 또는 grid 컨테이너를 말합니다.
렌더링-정의 형제 읽기 흐름은 읽기 흐름 컨테이너의 inflow 자식들의 순서가 지정된 목록입니다. 모든 자식은 렌더링 시 요소로 나타나야 하며, 읽기 흐름 컨테이너 안에서 형제로 간주됩니다. 순서는 reading-flow 속성에 의해 결정됩니다.
이 속성이 테이블에도 적용되어야 할까요? [이슈 #9922]
reading-flow가 포커스 가능한 display: contents 요소와 어떻게 상호작용하는지 정의해야 합니다. [이슈 #9230]
| 이름: | reading-flow |
|---|---|
| 값: | normal | flex-visual | flex-flow | grid-rows | grid-columns | grid-order |
| 초기값: | normal |
| 적용 대상: | flex 및 grid 컨테이너 |
| 상속: | 아니오 |
| 퍼센트값: | 해당 없음 |
| 계산값: | 지정된 대로 |
| 정식 순서: | 문법에 따름 |
| 애니메이션 유형: | 애니메이션 불가 |
reading-flow 속성은 flex 또는 grid 레이아웃의 요소들이 음성 렌더링되거나 (선형) 순차 내비게이션 시 탐색되는 순서를 제어합니다.
이 속성은 키워드 하나만 값을 가집니다. 값의 정의는 다음과 같습니다:
- normal
- DOM의 요소 순서를 따릅니다.
- flex-visual
- flex 컨테이너에만 적용됩니다. flex 아이템의 시각적 읽기 순서를 따르며, writing mode를 고려합니다. 예를 들어 영어 문서에서 flex-direction: row-reverse 및 reading-flow: flex-visual이면 읽기 순서는 왼쪽에서 오른쪽이 됩니다.
- flex-flow
- flex 컨테이너에만 적용됩니다. flex-flow 방향을 따릅니다.
- grid-rows
- grid 컨테이너에만 적용됩니다. writing mode를 고려하여, grid 아이템의 행별 시각적 순서를 따릅니다.
- grid-columns
- grid 컨테이너에만 적용됩니다. writing mode를 고려하여, grid 아이템의 열별 시각적 순서를 따릅니다.
- grid-order
- grid 컨테이너에만 적용됩니다. order로 변경된 문서 순서를 따릅니다. 따라서 normal과 같으나, order 속성으로 아이템 순서가 바뀐 경우 영향을 받습니다.
< div class = "wrapper" > < a href = "#" > Item 1</ a > < a href = "#" > Item 2</ a > < a href = "#" > Item 3</ a > </ div >
.wrapper{ display : flex; flex-direction : row-reverse; reading-flow : flex-visual; }
< div class = "wrapper" > < a class = "a" href = "#" > Item 1</ a > < a class = "b" href = "#" > Item 2</ a > < a class = "c" href = "#" > Item 3</ a > < a class = "d" href = "#" > Item 4</ a > </ div >
.wrapper{ display : grid; grid-template-columns : repeat ( 3 , 150 px ); grid-template-areas : "d b b" "c c a" ; reading-flow : grid-rows; } .a{ grid-area : a; } .b{ grid-area : b; } .c{ grid-area : c; } .d{ grid-area : d; }
reading-flow 속성은 레이아웃이나 페인팅 순서에는 영향을 주지 않으므로 시각적 캔버스 렌더링에는 영향을 주지 않습니다.
flex-* 또는 grid-* 키워드 값을 사용할 때는 order 속성도 고려됩니다.
order=-1이 있습니다.
따라서 읽기 순서는
"Item 3", "Item 1", "Item 2" 입니다.
< div class = "wrapper" > < a href = "#" > Item 1</ a > < a href = "#" > Item 2</ a > < a href = "#" > Item 3</ a > </ div >
.wrapper a:nth-child ( 3 ) { order : -1 ; } .wrapper{ display : flex; reading-flow : flex-flow; }
소스 문서는 요소의 근본 논리 순서를 표현해야 합니다. reading-flow 속성은 동일 문서가 레이아웃 변경(예: 미디어 쿼리 반응) 등으로 읽기 순서가 여러 개가 될 수 있는 경우를 위해 존재합니다. 이러한 경우 가장 일반적이거나 근본적인 읽기 순서는 소스 순서에 반영되어야 하며, CSS가 없어도 문서가 의미 있게 읽히도록 해야 합니다.
설계 고려사항 및 배경
reading-flow 설계에 반영된 고려사항은 다음과 같습니다:
-
박스의 레이아웃 순서와 읽기/내비게이션 순서를 분리할 필요가 분명히 있습니다. 가장 근본적인 이유는 시각적 인지 순서와 박스 레이아웃 순서가 다를 때, 읽기/내비 순서가 시각 인지 순서와 일치해야 하기 때문입니다. (시각 인지는 비선형이고, 요소의 크기, 색상 대비, 간격 등에도 좌우되므로 단순한 좌표로만 판단할 수 없습니다.)
-
웹 플랫폼 아키텍처의 핵심 원칙에 따라, 현재와 미래의 다양한 디바이스에서 최대한 많은 사용자가 접근할 수 있도록, CSS와 무관하게 문서 자체가 의미 있게 작성되어야 합니다. 따라서 시각적 표현과 상관없이, 소스 문서의 순서는 논리적이어야 합니다.
-
페이지의 본질적 순서가 강하지 않은 부분에 대해, 문서는 다양한 레이아웃 및 시각적 표현을 가질 수 있고, 모두 동일한 의미 정보를 전달할 수 있습니다. 모든 표현이 접근성에 우수할 수 있도록 해야 합니다.
-
선형 내비, 포커스 이동, 스크린 리더 순서는 항상 일치해야 하며, 이 세 가지를 동시에 사용하는 사용자도 있습니다.
-
페이지의 각 구성 요소나 계층마다 재배치 요구가 다르므로, CSS의 재배치 컨트롤은 box-sizing처럼 일괄 적용하기보다는, flow-relative vs. physical 속성/값과 유사하게 상황에 맞게 사용해야 합니다.
DOM에 소스 순서 재배치 기능이 필요합니다. 그래야 작성자가(평소 JS를 안 쓰는 사람도) order나 reading-flow를 오용하지 않고 손쉽게 소스 순서 재배치를 할 수 있습니다. [이슈 #7387]
5. 비가시성: visibility 속성
| 이름: | visibility |
|---|---|
| 값: | visible | hidden | collapse |
| 초기값: | visible |
| 적용 대상: | 모든 요소 |
| 상속: | 예 |
| 퍼센트값: | 해당 없음 |
| 계산값: | 지정한 대로 |
| 정식 순서: | 문법에 따름 |
| 애니메이션 유형: | 이산(discrete) |
| 미디어: | 시각적(visual) |
visibility 속성은 박스가 렌더링될지 여부를 지정합니다. 비가시 박스도 레이아웃에는 영향을 미칩니다. (박스 자체 생성을 완전히 억제하려면 display 속성을 none으로 설정하세요.) 값의 의미는 다음과 같습니다:
- visible
- 생성된 박스는 정상적으로 보입니다.
- hidden
- 요소가 생성한 모든 박스가 비가시가 됩니다. 그러나 자손이 visibility: visible이면 보일 수 있습니다.
- collapse
- 박스가 접힘(collapsed) 상태임을 나타냅니다. 이는 포매팅 컨텍스트별로 박스가 원래보다 더 적은 공간을 차지하게 만들 수 있습니다. 자세한 내용은 테이블의 동적 행/열 효과 [CSS2] 및 flex 레이아웃의 collapsed flex items [CSS-FLEXBOX-1] 참고. 그 외 대부분의 경우(별도 명시 없는 한) 비가시가 되며, hidden과 동일하게 동작합니다.
참고: 현재 많은 사용자 에이전트/접근성 도구가 의미적 관계를 가진 비가시 요소와 연결된 visible 요소의 접근성을 올바르게 처리하지 못합니다. 예를 들어, 특수 역할의 부모(예: table row)를 비가시로 두고 자식(예: table cell)은 보이게 하면 해당 도구 사용자에게 문제가 될 수 있습니다. 도구가 개선되기 전까지는 이러한 상황을 만들지 않는 것이 좋습니다.
비가시(Invisible) 박스는 렌더링되지 않으며 (완전히 투명한 것과 같음), 상호작용할 수 없고 (pointer-events: none처럼 동작), 내비게이션에서 제외됩니다 (display: none과 유사). 음성 렌더링에도 포함되지 않습니다 (단, speak 속성이 always일 때는 예외 [CSS-SPEECH-1]). 단, display: contents와 마찬가지로 컨테이너로서의 의미론적 역할은 유지되어, visible 자손이 올바르게 해석됩니다.
참고: speak가 always라면, 비가시 박스라도 음성 출력에는 포함되며, 비시각적/공간적 방법으로 상호작용이 가능합니다.
예를 들어, 다음은 클릭 시 숨은 텍스트가 드러나는 "스포일러" 요소의 (의도적으로 단순화된) 구현 예시입니다:
< p > The symbolism earlier in the movie becomes obvious at the end, when it's revealed that< spoiler-text >< span > Luke is his own father</ span ></ spoiler-text > , making the wizard's cryptic riddles meaningful.< style > spoiler-text { border-bottom : 1 px solid ; } spoiler-text > span { visibility : hidden ; } spoiler-text . shown > span { visibility : visible ; } </ style > < script > [... document. querySelectorAll( "spoiler-text" )]. forEach( el=>{ el. addEventListener( "click" , e=> el. classList. toggle( "shown" )); }); </ script >
이 예시는 의도적으로 많이 단순화된 것입니다. 실제 스포일러 요소라면 접근성 및 UX를 보장하는 다양한 기능이 더 필요합니다. visibility 사용법 설명을 위해 단순화된 코드이니, 실제 사이트에서는 이 코드를 그대로 사용하지 마세요.
6. 런인 레이아웃
런인 박스는 자신 뒤에 오는 블록에 합쳐져서 그 블록의 인라인 수준 콘텐츠 시작 부분에 자신을 삽입하는 박스입니다. 이는 간결한 헤드라인, 정의, 기타 유사한 항목을 포매팅할 때 유용합니다. 적합한 DOM 구조는 헤드라인이 뒤따르는 본문 이전에 위치하는 것이지만, 원하는 디스플레이는 텍스트와 함께 인라인으로 정렬된 헤드라인입니다.
<dl class='dict'>
<dt>dictionary
<dd>a book that lists the words of a language in alphabetical
order and gives their meaning, or that gives the equivalent
words in a different language.
<dt>glossary
<dd>an alphabetical list of terms or words found in or relating
to a specific subject, text, or dialect, with explanations; a
brief dictionary.
</dl>
<style>
.dict > dt {
display: run-in;
}
.dict > dt::after {
content: ": "
}
</style>
이렇게 포매팅됩니다:
dictionary: a book that lists the words of a language in alphabetical order and explains their meaning. glossary: an alphabetical list of terms or words found in or relating to a specific subject, text, or dialect, with explanations; a brief dictionary.
런인 박스는 다른 인라인 수준 박스처럼 정확히 동작하지만, 예외는 다음과 같습니다:
- 런인 박스가 flow 내부 디스플레이 타입을 가질 때 인라이니파이됩니다.
-
런인 시퀀스가 바로 뒤따르는 블록 박스가
새로운 블록
포매팅 컨텍스트를 생성하지 않을 때,
해당 박스의 직접 자식으로 삽입됩니다:
::marker 의 박스(있는 경우) 뒤에,
그리고 그 블록의 내용에서 생성된 다른 박스들(블록의 ::before 의 박스 포함, 있다면) 앞에 위치합니다.
이 재부모화는 가능하다면 재귀적으로 일어납니다
(즉, 런인이 해당 포매팅 컨텍스트의 가장 깊은 “문단” 일부가 되도록 하며,
인접한 다른 런인들도 함께 수집합니다).
재부모화된 콘텐츠는 그 위치에 원래 있었던 것처럼 포매팅됩니다. 참고: 레이아웃에만 영향을 미치며, 상속에는 영향이 없습니다. 비익명 박스의 속성 상속은 오로지 요소 트리를 기반으로 하기 때문입니다.
- 그렇지 않은 경우 (런인 시퀀스 뒤에 위와 같은 블록이 없다면), 익명 블록 박스가 런인 시퀀스와 그 뒤에 바로 따라오는 모든 인라인 수준 콘텐츠(다음 런인 시퀀스 전까지, 있다면)를 감싸도록 생성됩니다.
런인 시퀀스는 연속된 형제 런인 박스와 그 사이의 공백 및/또는 out-of-flow 박스들의 최대 시퀀스입니다.
참고: 이 설명은 out-of-flow 박스가 두 런인 박스 사이에 있을 때 재부모화됨을 의미합니다. 또 다른 대안은 중간 out-of-flow 박스를 남겨두거나, out-of-flow 박스가 이전 런인의 합쳐짐을 방해하도록 하는 것입니다. 구현자와 저자는 선호하는 동작이 있다면 CSSWG에 연락하기를 권장합니다. 이 동작은 임의로 선택된 것입니다.
이 수정 작업은 CSS2§9.2에서 설명된 익명 블록 및 인라인 박스 수정 이전에 발생하며, 첫 번째 포매팅 라인의 결정에 영향을 미칩니다. 런인 시퀀스가 박스 트리에서 최종 위치에 있었던 것처럼 간주됩니다.
참고: 가장 앞선 런인은 자신의 포함 블록의 첫 번째 포매팅 라인의 첫 텍스트를 나타내므로, 해당 블록 요소에 적용된 ::first-letter 가상 요소는 런인의 첫 글자를 선택합니다. 이는 해당 블록 자신의 콘텐츠가 아닙니다.
참고: 이 런인 모델은 이전 [CSS2] 제안과 약간 다릅니다.
부록 A: 용어집
편의를 위해 다음 용어들을 정의합니다:
- 루트 요소
- 요소 중 문서
트리의 루트에 있는 것.
문서 트리가 DOM에서 생성된 경우,
이것은 document element입니다;
HTML에서는
html요소입니다. [DOM] [HTML] - 주요 박스
-
요소가 하나 이상의 박스를 생성할 때,
그 중 하나는 주요 박스입니다.
이 박스는 자식 박스와 생성된 콘텐츠를 포함하며,
포지셔닝 스킴에도 관여합니다.
일부 요소는 주요 박스 외에 추가 박스를 생성할 수 있습니다 (예: list-item 요소는 마커 박스를 추가로 생성하거나, table 요소는 주요 테이블 래퍼 박스와 테이블 그리드 박스를 생성합니다). 이러한 추가 박스들은 주요 박스를 기준으로 위치합니다.
- 인라인 수준
- 인라인 레이아웃에 참여하는 콘텐츠. 구체적으로 인라인 수준 박스와 텍스트 시퀀스가 해당됩니다.
- 블록 수준
- 블록 레이아웃에 참여하는 콘텐츠. 구체적으로 블록 수준 박스가 해당됩니다.
- 인라인 박스
- 인라인 수준의 비치환 박스이며, 내부 디스플레이 타입이 flow인 박스입니다. 인라인 박스의 콘텐츠는 인라인 박스 자신과 동일한 인라인 포매팅 컨텍스트에 참여합니다.
- 인라인
- 인라인 박스 또는 인라인 수준 박스의 의미로 사용되며, 또는 인라인 수준이라는 의미의 형용사로 사용됩니다. 후자의 사용은 더 이상 권장되지 않습니다.
- 아토믹 인라인
-
치환(예: 이미지)되었거나 새로운 포매팅 컨텍스트를 생성하는(예: inline-block 또는 inline-table) 인라인 수준 박스이며,
줄을 나눌 수 없습니다
(인라인 박스 및 루비 컨테이너는 분할할 수 있음).
내부 디스플레이 타입이 flow가 아닌 모든 인라인 수준 박스는 지정된 내부 디스플레이 타입의 새로운 포매팅 컨텍스트를 생성합니다.
- 블록 컨테이너
-
블록 컨테이너는 인라인 수준 박스만 포함하여 인라인 포매팅 컨텍스트에 참여하거나,
블록 수준 박스만 포함하여 블록 포매팅 컨텍스트에 참여합니다(이 요구사항을 만족하기 위해 익명 블록 박스를 생성할 수 있습니다.
CSS2§9.2.1.1 참조).
인라인 수준 콘텐츠만 포함하는 블록 컨테이너는 새로운 인라인 포매팅 컨텍스트를 생성합니다. 이때 요소는 모든 인라인 콘텐츠를 감싸는 루트 인라인 박스도 생성합니다. 참고: 이 루트 인라인 박스 개념은 CSS2§9.2.2.1에서 소개된 "익명 인라인 요소" 개념을 실질적으로 대체합니다.
부모 포매팅 컨텍스트가 블록 포매팅 컨텍스트가 아닐 때 블록 컨테이너는 새로운 블록 포매팅 컨텍스트를 생성합니다; 그렇지 않으면, 자신이 블록 포매팅 컨텍스트에 참여할 때, 그 컨텍스트를 그대로 따르거나(또는 계속), 다른 속성의 제약에 따라(예: overflow 또는 align-content) 새로운 블록 포매팅 컨텍스트를 생성합니다.
참고: 블록 컨테이너 박스는 블록 포매팅 컨텍스트와 인라인 포매팅 컨텍스트를 동시에 생성할 수 있습니다.
- 블록 박스
-
블록 수준 박스이면서 블록 컨테이너인 박스입니다.
참고: 모든 블록 컨테이너 박스가 블록 수준 박스는 아닙니다: 비치환 인라인 블록 및 비치환 테이블 셀 등은 블록 컨테이너이지만, 블록 수준 박스는 아닙니다. 마찬가지로, 모든 블록 수준 박스가 블록 컨테이너는 아닙니다: 블록 수준 치환 요소(display: block) 및 flex 컨테이너(display: flex) 등은 블록 컨테이너가 아닙니다.
- 블록
- 블록 박스나 블록 수준 박스, 블록 컨테이너 박스를 명확한 경우에 축약하여 사용합니다.
- 치환 요소
-
콘텐츠가 CSS 포매팅 모델의 범위를 벗어나는 요소(예: 이미지, 임베디드 문서). 예를 들어, HTML
img요소의 콘텐츠는src속성이 지정한 이미지로 대체되는 경우가 많습니다.치환 요소는 종종 자연 치수를 가집니다. 예를 들어, 비트맵 이미지는 절대 단위로 지정된 자연 너비와 높이를 가집니다. 반면, 다른 객체는 자연 치수가 없을 수 있습니다 (예: 빈 HTML 문서). [css-images-3] 참고.
사용자 에이전트는 치환 요소가 자연 치수를 갖지 않는다고 간주할 수 있습니다. 만약 이러한 치수가 제3자에게 민감한 정보를 유출할 수 있다고 판단된다면, 예를 들어 HTML 문서가 사용자의 은행 잔고에 따라 자연 크기가 변한다면, UA는 해당 리소스가 자연 치수가 없는 것으로 동작할 수 있습니다.
치환 요소의 콘텐츠는 CSS 포매팅 모델에 고려되지 않습니다; 그러나 그들의 자연 치수는 다양한 레이아웃 계산에 사용됩니다. 치환 요소는 항상 독립 포매팅 컨텍스트를 생성합니다.
비치환 요소는 치환이 아닌 요소, 즉 CSS 모델에 의해 렌더링이 결정되는 요소입니다.
- 컨테이닝 블록
-
관련 박스의 크기와 위치 지정의 기준이 되는 사각형.
특히, 컨테이닝 블록은 박스가 아닙니다 (단지 사각형임).
그러나 종종 박스의 치수에서 유도됩니다.
각 박스는 자신의 컨테이닝 블록을 기준으로 위치가
지정되지만,
이 컨테이닝 블록에 갇히지는 않습니다;
오버플로우할 수 있습니다.
“박스의 컨테이닝 블록”이란
“박스가 속한 컨테이닝 블록”을 의미하며,
자체적으로 생성한 컨테이닝 블록이 아닙니다.
일반적으로, 박스 엣지가 박스의 후손 박스의 컨테이닝 블록 역할을 합니다; 즉, 박스가 자신의 후손을 위한 컨테이닝 블록을 생성한다고 말합니다. 컨테이닝 블록의 속성이 참조된다면, 해당 박스의 값을 참조합니다. (초기 컨테이닝 블록의 경우, 별도 지정이 없는 한 루트 요소에서 값을 가져옵니다.)
[CSS2] Section 9.1.2, Section 10.1, CSS Positioned Layout 3 § 2.1 Positioned 박스의 컨테이닝 블록 참고.
- 컨테이닝 블록 체인
- 컨테이닝 블록들의 연속된 조상-자손 체인. 예를 들어, 인라인 박스의 컨테이닝 블록은 가장 가까운 블록 컨테이너 조상의 컨텐트 박스입니다; 그 블록 컨테이너가 인플로우 블록이면, 그것의 컨테이닝 블록은 부모 블록 컨테이너입니다; 그 조부모 블록 컨테이너가 절대 위치라면, 그것의 컨테이닝 블록은 가장 가까운 positioned 조상의 패딩 에지입니다(부모일 필요는 없음), 이렇게 초기 컨테이닝 블록까지 이어집니다.
- 초기 컨테이닝 블록
- 루트 요소의 컨테이닝 블록. 초기 컨테이닝 블록은 블록 포매팅 컨텍스트를 생성합니다. CSS2.1§10.1에서 연속 미디어의 위치 및 크기를 참조; [CSS-PAGE-3]에서 페이지 미디어 참고.
- 포매팅 컨텍스트
-
포매팅 컨텍스트란
관련 박스들이 레이아웃되는 환경입니다.
포매팅 컨텍스트마다 박스를 배치하는 규칙이 다릅니다.
예를 들어, 플렉스 포매팅 컨텍스트는 플렉스 레이아웃 규칙을
따르고 [CSS-FLEXBOX-1],
블록 포매팅
컨텍스트는 블록-인라인 레이아웃 규칙을 따릅니다 [CSS2].
또한 일부 포매팅 컨텍스트는 서로 중첩되거나 공존할 수 있습니다:
예를 들어, 인라인 포매팅 컨텍스트는
자신의 블록 포매팅 컨텍스트 내에 존재하며 상호작용하고,
루비 컨테이너는 루비 포매팅 컨텍스트를 자신의 인라인 포매팅 컨텍스트 위에 오버레이합니다.
박스는 새로운 독립 포매팅 컨텍스트를 생성하거나 자신의 포매팅 컨텍스트를 계속 따릅니다. 드물게, 새로운 (비독립) 포매팅 컨텍스트를 추가로 생성하기도 합니다. 별도 명시되지 않는 한, 새로운 포매팅 컨텍스트 생성은 독립 포매팅 컨텍스트를 만듭니다. 박스가 생성하는 포매팅 컨텍스트의 종류는 내부 디스플레이 타입에 따라 결정됩니다. 예: 그리드 컨테이너는 그리드 포매팅 컨텍스트를, 루비 컨테이너는 루비 포매팅 컨텍스트를, 블록 컨테이너는 블록 포매팅 컨텍스트와/또는 인라인 포매팅 컨텍스트를 생성할 수 있습니다. display 속성 참조.
- 독립 포매팅 컨텍스트
-
박스가 독립 포매팅 컨텍스트를 생성하면
(해당 포매팅 컨텍스트가
부모와 같은 종류이든 아니든),
사실상 새로운 독립 레이아웃 환경을 만듭니다:
해당 박스 자체의 크기를 제외하면,
후손의 레이아웃은 (일반적으로)
박스 외부의 포매팅 컨텍스트의 규칙과 내용에 영향을 받지 않고,
반대도 마찬가지입니다.
예를 들어, 블록 포매팅 컨텍스트에서 플로트 박스는 주변 박스의 레이아웃에 영향을 줍니다. 하지만 이 효과는 포매팅 컨텍스트를 벗어나지 않습니다: 해당 포매팅 컨텍스트를 생성한 박스가 플로트를 완전히 포함하도록 성장하고, 외부 플로트는 해당 박스 내부로 침범할 수 없습니다.
또 다른 예로, 마진은 포매팅 컨텍스트 경계에서 병합되지 않습니다.
Exclusions(제외)은 독립 포매팅 컨텍스트 경계를 넘어 콘텐츠에 영향을 줄 수 있습니다. (작성 시점엔, 이것만이 경계를 넘는 유일한 레이아웃 기능입니다.) [CSS3-EXCLUSIONS]
특정 속성은 박스가 독립 포매팅 컨텍스트를 생성하도록 강제할 수 있습니다. 예를 들면, 박스를 out-of-flow로 만들면 블록화와 독립 포매팅 컨텍스트 생성이 동시에 일어납니다. 또 다른 예로, contain 속성의 특정 값은 박스가 독립 포매팅 컨텍스트를 생성하게 할 수 있습니다. 블록을 스크롤 컨테이너로 만들면 독립 포매팅 컨텍스트를 생성하게 됩니다; 단, 서브그리드를 스크롤 컨테이너로 바꿔도—계속해서 상위 그리드 컨테이너의 레이아웃에 참여합니다.
블록 박스가 독립 포매팅 컨텍스트를 생성하면, 그 후손을 위해 새로운 블록 포매팅 컨텍스트를 생성합니다. 대부분의 경우, 박스가 독립 포매팅 컨텍스트를 생성하도록 강제해도 아무 효과가 없습니다—이미 해당 박스가 독립 포매팅 컨텍스트를 생성하는 경우(예: 플렉스 컨테이너), 혹은 해당 타입의 박스에서 완전히 독립적인 새 포매팅 컨텍스트를 생성하는 것이 불가능한 경우(예: 비치환 인라인 박스).
- 블록 포매팅 컨텍스트
- 인라인 포매팅 컨텍스트
- 블록 및 인라인 포매팅 컨텍스트는 CSS 2.1 Section 9.4에서 정의합니다. 인라인 포매팅 컨텍스트는 (자신이 속한) 블록 포매팅 컨텍스트 내에 존재합니다; 예를 들어, 인라인 포매팅 컨텍스트에 속한 라인 박스는 블록 포매팅 컨텍스트에 속한 플로트와 상호작용합니다.
- 블록 레이아웃
- 블록 수준 박스의 레이아웃, 블록 포매팅 컨텍스트 내에서 수행됩니다.
- 블록 포매팅 컨텍스트 루트
- 블록 컨테이너 중 새로운 블록 포매팅 컨텍스트를 생성하는 것.
- BFC
-
블록 포매팅
컨텍스트 또는 블록 포매팅 컨텍스트 루트의 약자.
내부 플로트 포함, 외부 플로트 제외, 마진 겹침 방지 등 다양한 비공식적인 의미로 사용되며,
다음 중 하나를 의미할 수 있습니다:
-
자신의 콘텐츠를 위해 새로운 블록 포매팅 컨텍스트를 생성하는 블록 컨테이너
-
새로운 블록 포매팅 컨텍스트를 생성하는 블록 박스(즉, 블록 수준 블록 컨테이너) (그렇지 않은 블록 박스와 구별됨)
-
(아주 느슨하게) 새로운 포매팅 컨텍스트를 생성하는 모든 블록 수준 박스(단, 인라인 포매팅 컨텍스트 제외)
-
- out-of-flow
- in-flow
-
박스가 out-of-flow이면,
예상 위치와 주변 콘텐츠와의 상호작용에서 분리되어
부모 포매팅 컨텍스트의 일반 흐름과는 다른 방식으로 배치됩니다.
이는 박스가 플로트(float 사용)
또는 절대 위치(position 사용)일 때 발생합니다.
박스가 in-flow이면 out-of-flow가 아닙니다.
참고: 일부 포매팅 컨텍스트는 플로트를 억제하므로, float: left이어도 반드시 out-of-flow가 되는 것은 아닙니다.
- 문서 순서
- 박스 또는 콘텐츠가 문서 내에서 나타나는 순서 (렌더링되는 순서와 다를 수 있음). 가상 요소의 상대적 순서를 결정할 때는, 박스 트리 순서가 사용됩니다, CSS Pseudo-Elements 4 § 4 트리 기반 가상 요소 참고.
[CSS2] 9장에서 이 용어들의 더욱 완전한 정의를 확인할 수 있습니다.
부록 B: display: contents가 특수 요소에 미치는 영향
이 절은 (현재) 비규범적입니다.
일부 요소는 CSS 박스 개념만으로 렌더링되지 않습니다;
예를 들어, 치환 요소(예:
img),
많은 폼 컨트롤(예:
input),
그리고 SVG 요소 등이 해당합니다.
이 부록에서는 이들이 display: contents와 어떻게 상호작용하는지 정의합니다.
HTML 요소
-
brwbrmeterprogresscanvasembedobjectaudioiframeimgvideoframeframesetinputtextareaselect -
display: contents는 display: none으로 계산됩니다.
-
legend -
HTML 명세에 따라,
legend에 display: contents가 지정되면 렌더링된 legend가 아니게 되므로, 특별한 디스플레이 동작을 갖지 않습니다. (따라서 display: contents에 정상적으로 반응합니다.) -
buttondetailsfieldset -
이 요소들은 특별한 동작이 없습니다; display: contents는 해당 요소의 주요 박스만 제거하며, 콘텐츠는 정상적으로 렌더링됩니다.
- 그 외 모든 HTML 요소
-
display: contents에 대해 일반적으로 동작합니다.
SVG 요소
- CSS 박스 레이아웃을 가지는
svg요소 (여기에는 부모가 HTML 요소인 모든svg와 문서 루트 요소가 포함됩니다) -
display: contents는 display: none으로 계산됩니다.
- 그 외 모든 SVG 컨테이너
요소이면서 렌더러블 요소인 것
- SVG 텍스트 콘텐츠 자식 요소
use - SVG 텍스트 콘텐츠 자식 요소
-
display: contents는 해당 요소를 포매팅 트리에서 제거하고, 그 콘텐츠를 끌어올려 그 자리에 표시합니다. 이 콘텐츠에는
use의 섀도우-DOM 콘텐츠도 포함됩니다. - 그 외 모든 SVG 요소
-
display: contents는 display: none으로 계산됩니다.
예를 들어, SVG의 텍스트 콘텐츠 및 텍스트 포매팅 요소는
text
요소 컨텍스트가 필요합니다;
text를
제거하면,
그 자식 텍스트 콘텐츠 및 요소들은 더 이상 유효하지 않습니다.
그래서 display: contents가
text에
적용되면 전체 text 요소가 렌더링되지 않습니다.
반면,
tspan
이나
textPath
내부의 유효한 콘텐츠는 부모 텍스트 포매팅 컨텍스트에도 유효하므로,
이러한 요소에는 끌어올리기 동작이 적용됩니다.
마찬가지로, 끌어올리기가 자식들을 비렌더러블 요소 (예:
pattern
또는
symbol
내부의 도형)에서
렌더러블 요소(예:
svg의
자식 도형)로 바꾼다면,
이는 렌더링 컨텍스트의 잘못된 변화입니다.
절대 렌더링되지 않는 컨테이너 요소는 display: contents로 "언박싱"될 수 없습니다.
요소가 포매팅 트리에서 제거되면, 해당 요소에 적용된 SVG 속성 중 레이아웃과 시각적 포매팅을 제어하는 속성은 해당 콘텐츠를 렌더링할 때 무시됩니다. 하지만 SVG 프레젠테이션 속성—CSS 속성에 매핑되는 것—은 값 처리와 상속에 계속 영향을 미칩니다 [CSS-CASCADE-3]; 따라서 이러한 속성은 그 자손의 해당 속성 값에 영향을 주어 레이아웃과 시각적 포매팅에 영향을 줄 수 있습니다.
MathML 요소
모든 MathML 요소에 대해, display: contents는 display: none으로 계산됩니다.
부록 C: 명세 작성자를 위한 박스 구성 지침
이 절은 명세 작성자를 위한 비규범적 가이드입니다.
-
박스는 블록화와 인라인화를 동시에 할 수 없습니다; 만약 그런 일이 발생한다면, 어느 쪽이 우선하는지 정의해야 합니다.
-
비주요 비익명 박스는 블록화될 수 없습니다: 블록화는 요소의 계산값에 영향을 주며, 그로 인해 주요 박스의 유형이 결정됩니다.
-
자신의 콘텐츠를 블록화하는 박스는 인라인 수준 콘텐츠를 직접 포함할 수 없습니다; 그러한 요소 내에서 생성되는 박스나 텍스트 시퀀스는 반드시 블록화되거나 익명 블록 컨테이너로 감싸야 합니다.
-
자신의 콘텐츠를 인라인화하는 박스는 블록 수준 박스를 직접 포함할 수 없습니다; 그러한 요소 내에서 생성되는 박스는 인라인 수준이어야 합니다.
-
근본적으로 독립 포매팅 컨텍스트를 생성할 수 없는 박스(예: 비치환 인라인)는 독립 포매팅 컨텍스트 생성을 요구받아서는 안 됩니다. 먼저 블록화하거나, 아니면 그런 컨텍스트를 생성할 수 있는 박스 유형으로 바꿔야 합니다.
감사의 글
수년에 걸쳐 박스 생성의 다양한 세부사항을 분리하기 위해 노력해주신 많은 분들께 감사드립니다. 특히 Bert Bos께 감사드리며, 그의 마지막 display-model 및 display-role 시도는 채택되지 못했지만, 현재 명세를 준비하는 데 큰 도움이 되었습니다. Anton Prowse, 그의 끈질긴 CSS2.1 9장 비판이 혼돈 속에서 질서를 찾게 만들었습니다. 그리고 Oriol Brufau, 이 명세에서 수십 가지 미묘한 차이와 오류를 밝혀주셨습니다. David Baron, Mats Palmgren, Ilya Streltsyn, 그리고 Boris Zbarsky의 피드백에도 감사드립니다.
변경 이력
Level 3 이후 추가 사항
다음 기능들이 CSS Display Module Level 3 이후 추가되었습니다:
-
reading-flow 속성 (이슈 8589)
-
display 속성의 애니메이션 지원
프라이버시 고려사항
이 명세는 새로운 프라이버시 고려사항을 도입하지 않습니다.
보안 고려사항
이 명세는 새로운 보안 고려사항을 도입하지 않습니다.