CSS 디스플레이 모듈 레벨 4

W3C 최초 공개 워킹 드래프트,

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2024/WD-css-display-4-20241219/
최신 발행 버전:
https://www.w3.org/TR/css-display-4/
에디터스 드래프트:
https://drafts.csswg.org/css-display/
히스토리:
https://www.w3.org/standards/history/css-display-4/
구현 보고서:
https://wpt.fyi/results/css/css-display?label=master&label=experimental&aligned
피드백:
CSSWG 이슈 저장소
명세 내 인라인
에디터:
Tab Atkins Jr. (Google)
Elika J. Etemad / fantasai (Apple)
이 명세 편집 제안:
GitHub 에디터
테스트 스위트:
https://wpt.fyi/results/css/css-flexbox/

요약

이 모듈은 CSS 포매팅 박스 트리가 문서 요소 트리에서 어떻게 생성되는지 설명하고, 이를 제어하는 display 속성을 정의합니다.

CSS는 구조화된 문서(HTML, XML 등)가 화면, 인쇄물 등에서 어떻게 렌더링되는지 기술하는 언어입니다.

이 문서의 현황

이 섹션은 본 문서가 발행된 시점에서의 상태를 설명합니다. 현재 W3C의 전체 발행물과 이 기술 보고서의 최신 버전은 W3C 기술 보고서 색인 https://www.w3.org/TR/에서 확인할 수 있습니다.

이 문서는 CSS 워킹 그룹권고 프로세스에 따라 최초 공개 워킹 드래프트로 발행한 것입니다. 최초 공개 워킹 드래프트로 발행되었다고 해서 W3C 및 그 회원의 승인을 의미하지는 않습니다.

이 문서는 초안으로, 언제든지 갱신, 교체 또는 폐기될 수 있습니다. 진행 중인 작업 이외의 용도로 본 문서를 인용하는 것은 부적절합니다.

피드백은 GitHub에 이슈 등록(권장)으로 보내주시고, 제목에 “css-display” 명세 코드를 포함하여 “[css-display] …의견 요약…”과 같이 작성해 주세요. 모든 이슈와 의견은 아카이브에 저장됩니다. 또는 (아카이브됨) 공개 메일링 리스트 www-style@w3.org로 보낼 수도 있습니다.

이 문서는 2023년 11월 3일 W3C 프로세스 문서의 적용을 받습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성되었습니다. W3C는 관련 산출물에 대해 공개 특허 공개 목록을 유지합니다. 해당 페이지에는 특허 공개 방법 안내도 포함되어 있습니다. 어떤 개인이 본인이 알고 있는 특허가 필수 청구항을 포함한다고 판단하는 경우, W3C 특허 정책 6항에 따라 정보를 공개해야 합니다.

예비 구현 보고서가 제공됩니다. CR 기간 동안 추가 테스트가 진행될 예정입니다.

다음 기능들은 위험(at-risk) 상태이며, CR 기간 동안 제외될 수 있습니다:

“위험(at-risk)”은 W3C 프로세스의 용어로, 해당 기능이 반드시 제외되거나 지연될 것이라는 의미는 아닙니다. 다만 WG가 해당 기능이 빠른 시일 내에 상호운용성 있게 구현되기 어렵다고 판단하여, 필요 시 Proposed Rec 단계로 전환할 때 기능을 제외할 수 있도록 표시한 것입니다. 이때 별도의 Candidate Rec를 새로 발행하지 않아도 됩니다.

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
적용 대상: 모든 요소
상속: 아니오
퍼센트값: 해당 없음
계산된 값: innerouter display 타입을 나타내는 키워드 쌍과 선택적 list-item 플래그, 또는 <display-internal> 또는 <display-box> 키워드; 계산 규칙은 여러 명세의 본문 참조
정식 순서: 문법에 따름
애니메이션 유형: § 2.9 display의 애니메이션 및 보간 참조

UA는 비시각적 매체를 포함한 모든 매체에서 이 속성을 지원해야 합니다. display 속성은 요소의 display 타입을 정의합니다. 이는 요소가 박스를 생성하는 두 가지 기본 특성으로 구성됩니다:

텍스트 시퀀스display 타입이 없습니다.

일부 display 값은 추가적인 부작용이 있습니다. 예를 들어 list-item::marker 가상 요소도 생성하며, none은 요소 전체 서브트리를 박스 트리에서 제외합니다.

display 속성은 요소의 의미론(semantics)에 영향을 주지 않습니다: 이는 문서 언어에 의해 정의되며 CSS에 의해 변경되지 않습니다. none 값(이 값은 오럴/음성 출력 및 요소와 자손의 상호작용성에도 영향을 줌)을 제외하면, display 속성은 오직 시각적 레이아웃에만 영향을 미칩니다: 이 속성의 목적은 디자이너가 문서의 근본 의미를 바꾸지 않으면서 레이아웃 동작을 자유롭게 변경할 수 있게 해주는 것입니다.

값은 다음과 같이 정의됩니다:

<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 boxtable grid box 포함
inline-table inline table 인라인-레벨 table wrapper boxtable 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이 됩니다. 단, rubyinline이 기본값입니다.

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-baseruby-textflow 내부 디스플레이 타입을 가집니다.

레이아웃 전용 디스플레이 타입을 가진 박스는, 호환되지 않는 부모에 배치될 때 각각의 명세에 정의된 대로 자신을 감싸는 익명 래퍼 박스를 생성합니다.

예를 들어, 테이블 레이아웃에서는 table-cell 박스의 부모가 반드시 table-row 박스여야 합니다.

잘못된 부모에 배치된 경우:

<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. 박스 생성: nonecontents 키워드

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 같은 값에는 영향을 주지 않습니다.) 추가적으로:

참고: 박스가 컨텍스트에 맞지 않을 때 박스 타입을 보정하는 방법은 두 가지가 있습니다. 하나는 여기서 설명하는 계산값 변환으로, display블록화인라인화가 이에 해당합니다. 다른 하나는 박스 트리 구성 중(계산값이 결정된 이후) 중간 익명 박스를 생성하는 것으로, 테이블, 루비, flow 레이아웃에서 발생합니다.

계산값 보정의 예시는 다음과 같습니다:

2.8. 루트 요소의 주요 박스

루트 요소의 display 타입은 항상 블록화되며, 주요 박스는 항상 독립 포매팅 컨텍스트를 생성합니다. 이 박스의 컨테이닝 블록초기 컨테이닝 블록입니다.

또한, 루트 요소에서 displaycontents일 경우, 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> 값을 가지며, 이 값은 해당 아이템이 속할 순서 그룹을 지정합니다.

다음은 카탈로그 아이템 카드의 예시입니다. 타이틀, 사진, 설명이 있습니다. 각 항목 내에서, 소스 문서의 콘텐츠는 논리적으로 타이틀, 설명, 사진 순으로 배치되어 있습니다. 이는 음성 렌더링이나 CSS를 지원하지 않는 브라우저에서 합리적인 순서를 제공합니다. 좀 더 시각적으로 매력적인 배치를 위해, order를 사용해 이미지가 콘텐츠 후반에서 카드 상단으로 올라오도록 했습니다.
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>
You get: a white desktop computer with matching keyboard and monitor.

Computer Starter Kit

이것은 돈이 많지 않다면 살 수 있는 최고의 컴퓨터입니다.

  • Computer
  • Monitor
  • Keyboard
  • Mouse
위 코드의 렌더링 예시.

Flexgrid 컨테이너는 콘텐츠를 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로 재정렬을 수행해서는 안 됩니다. 단, 저자가 공간적 순서가 문서 순서(음성·탐색 순서 결정)에 동기화되지 않음을 명시적으로 지시한 경우는 예외입니다.

예를 들어, 도구가 flex 아이템의 드래그-앤-드롭 재정렬을 제공하고, 미디어 쿼리로 화면 크기별 대체 레이아웃도 다룬다고 가정합시다.

대부분의 경우, 재정렬은 모든 화면 크기·탐색·음성 순서에 영향을 주므로, 도구는 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-reversereading-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 속성으로 아이템 순서가 바뀐 경우 영향을 받습니다.
이 예시에서는 세 개의 flex 아이템이 한 줄에 표시되고, reading-flow: flex-visualflex-direction: row-reverse가 적용되어 있습니다. 언어는 영어이고, 텍스트 방향은 왼쪽에서 오른쪽입니다. 따라서 읽기 순서는 왼쪽에서 오른쪽으로 "Item 3", "Item 2", "Item 1" 입니다.
<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;
}
이 예시에서는 4개의 grid 아이템이 grid에 배치되고, 시각적으로 DOM 순서와 다르게 표시됩니다. reading-flow 속성은 grid-rows 값이며, 문서는 영어로 작성되어 있습니다. 따라서 읽기 순서는 "Item 4", "Item 2", "Item 3", "Item 1" 입니다.
<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, 150px);
  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 속성도 고려됩니다.

이 예시에서는 세 개의 flex 아이템이 한 줄에 표시되고, reading-flow: flex-flow가 적용되어 있습니다. DOM의 세 번째 아이템에 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 설계에 반영된 고려사항은 다음과 같습니다:

DOM에 소스 순서 재배치 기능이 필요합니다. 그래야 작성자가(평소 JS를 안 쓰는 사람도) orderreading-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 자손이 올바르게 해석됩니다.

참고: speakalways라면, 비가시 박스라도 음성 출력에는 포함되며, 비시각적/공간적 방법으로 상호작용이 가능합니다.

display: none으로 임시로 숨기는 것만으로도 충분한 경우가 많지만, 이 방법은 해당 요소를 레이아웃에서 완전히 제외시켜, 요소가 숨겨지거나 나타날 때 페이지의 예기치 않은 이동이나 리플로우가 발생할 수 있습니다. visibility: hidden을 사용하면 요소를 숨기거나 보일 때 페이지 레이아웃을 안정적으로 유지할 수 있습니다.

예를 들어, 다음은 클릭 시 숨은 텍스트가 드러나는 "스포일러" 요소의 (의도적으로 단순화된) 구현 예시입니다:

<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: 1px 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.

런인 박스는 다른 인라인 수준 박스처럼 정확히 동작하지만, 예외는 다음과 같습니다:

런인 시퀀스는 연속된 형제 런인 박스와 그 사이의 공백 및/또는 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 요소

br
wbr
meter
progress
canvas
embed
object
audio
iframe
img
video
frame
frameset
input
textarea
select

display: contentsdisplay: none으로 계산됩니다.

legend

HTML 명세에 따라, legenddisplay: contents가 지정되면 렌더링된 legend가 아니게 되므로, 특별한 디스플레이 동작을 갖지 않습니다. (따라서 display: contents에 정상적으로 반응합니다.)

button
details
fieldset

이 요소들은 특별한 동작이 없습니다; display: contents는 해당 요소의 주요 박스만 제거하며, 콘텐츠는 정상적으로 렌더링됩니다.

그 외 모든 HTML 요소

display: contents에 대해 일반적으로 동작합니다.

SVG 요소

CSS 박스 레이아웃을 가지는 svg 요소 (여기에는 부모가 HTML 요소인 모든 svg 와 문서 루트 요소가 포함됩니다)

display: contentsdisplay: none으로 계산됩니다.

그 외 모든 SVG 컨테이너 요소이면서 렌더러블 요소인 것
SVG 텍스트 콘텐츠 자식 요소
use

display: contents는 해당 요소를 포매팅 트리에서 제거하고, 그 콘텐츠를 끌어올려 그 자리에 표시합니다. 이 콘텐츠에는 use의 섀도우-DOM 콘텐츠도 포함됩니다.

그 외 모든 SVG 요소

display: contentsdisplay: none으로 계산됩니다.

여기서의 의도는 요소 내부의 "렌더링 컨텍스트"가 외부와 다를 때마다 display: none 동작이 적용된다는 점입니다. 만약 요소의 자식들이 그 부모의 유효한 자식이 아닐 경우, 트리에서 단순히 끌어올릴 수 없습니다.

예를 들어, SVG의 텍스트 콘텐츠 및 텍스트 포매팅 요소는 text 요소 컨텍스트가 필요합니다; text를 제거하면, 그 자식 텍스트 콘텐츠 및 요소들은 더 이상 유효하지 않습니다. 그래서 display: contentstext에 적용되면 전체 text 요소가 렌더링되지 않습니다. 반면, tspan 이나 textPath 내부의 유효한 콘텐츠는 부모 텍스트 포매팅 컨텍스트에도 유효하므로, 이러한 요소에는 끌어올리기 동작이 적용됩니다.

마찬가지로, 끌어올리기가 자식들을 비렌더러블 요소 (예: pattern 또는 symbol 내부의 도형)에서 렌더러블 요소(예: svg의 자식 도형)로 바꾼다면, 이는 렌더링 컨텍스트의 잘못된 변화입니다. 절대 렌더링되지 않는 컨테이너 요소는 display: contents로 "언박싱"될 수 없습니다.

요소가 포매팅 트리에서 제거되면, 해당 요소에 적용된 SVG 속성 중 레이아웃과 시각적 포매팅을 제어하는 속성은 해당 콘텐츠를 렌더링할 때 무시됩니다. 하지만 SVG 프레젠테이션 속성—CSS 속성에 매핑되는 것—은 값 처리와 상속에 계속 영향을 미칩니다 [CSS-CASCADE-3]; 따라서 이러한 속성은 그 자손의 해당 속성 값에 영향을 주어 레이아웃과 시각적 포매팅에 영향을 줄 수 있습니다.

MathML 요소

모든 MathML 요소에 대해, display: contentsdisplay: none으로 계산됩니다.

부록 C: 명세 작성자를 위한 박스 구성 지침

이 절은 명세 작성자를 위한 비규범적 가이드입니다.

감사의 글

수년에 걸쳐 박스 생성의 다양한 세부사항을 분리하기 위해 노력해주신 많은 분들께 감사드립니다. 특히 Bert Bos께 감사드리며, 그의 마지막 display-modeldisplay-role 시도는 채택되지 못했지만, 현재 명세를 준비하는 데 큰 도움이 되었습니다. Anton Prowse, 그의 끈질긴 CSS2.1 9장 비판이 혼돈 속에서 질서를 찾게 만들었습니다. 그리고 Oriol Brufau, 이 명세에서 수십 가지 미묘한 차이와 오류를 밝혀주셨습니다. David Baron, Mats Palmgren, Ilya Streltsyn, 그리고 Boris Zbarsky의 피드백에도 감사드립니다.

변경 이력

Level 3 이후 추가 사항

다음 기능들이 CSS Display Module Level 3 이후 추가되었습니다:

프라이버시 고려사항

이 명세는 새로운 프라이버시 고려사항을 도입하지 않습니다.

보안 고려사항

이 명세는 새로운 보안 고려사항을 도입하지 않습니다.

적합성

문서 규약

적합성 요구사항은 설명적 단언과 RFC 2119 용어의 조합으로 표현됩니다. 본 명세의 규범적 부분에서 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”과 같은 핵심 단어는 RFC 2119에 따라 해석되어야 합니다. 다만, 가독성을 위해 이 단어들은 본 명세에서 모두 대문자로 표기하지 않습니다.

이 명세의 모든 문장은 예시, 주석, 비규범적임을 명시한 절을 제외하고는 규범적입니다. [RFC2119]

이 명세의 예시는 “예를 들어”라는 문구로 시작하거나 class="example"로 구분되어 아래와 같이 표시됩니다:

이것은 정보 제공용 예시입니다.

정보 제공용 주석은 “Note”로 시작하며, class="note"로 구분되어 아래와 같이 표시됩니다:

Note, 이것은 정보 제공용 주석입니다.

권고(advisement)는 특별한 주의를 환기하도록 스타일링된 규범적 절이며, 다른 규범적 텍스트와는 <strong class="advisement">로 구분되어 아래와 같이 표시됩니다: UA는 반드시 접근 가능한 대안을 제공해야 합니다.

적합성 클래스

이 명세에 대한 적합성은 세 가지 적합성 클래스로 정의됩니다:

스타일 시트
CSS 스타일 시트.
렌더러
UA로, 스타일 시트의 의미를 해석하고 이를 사용하는 문서를 렌더링합니다.
저작 도구
UA로, 스타일 시트를 작성합니다.

스타일 시트가 본 명세에 적합하려면 이 모듈에서 정의한 구문을 사용하는 모든 선언이 일반 CSS 문법 및 이 모듈에서 정의한 각 기능의 개별 문법에 따라 유효해야 합니다.

렌더러가 이 명세에 적합하려면 해당 스타일 시트를 관련 명세에 따라 해석함과 더불어, 이 명세에서 정의한 모든 기능을 올바르게 파싱하고 문서를 그에 맞게 렌더링해야 합니다. 단, UA가 디바이스의 한계로 인해 문서를 올바르게 렌더링하지 못하는 경우에는 비적합으로 간주하지 않습니다. (예: UA가 흑백 모니터에서 색상을 렌더링할 필요는 없습니다.)

저작 도구가 이 명세에 적합하려면 스타일 시트를 일반 CSS 문법과 이 모듈 내 각 기능의 개별 문법에 맞게 문법적으로 올바르게 작성하고, 이 모듈에 기술된 스타일 시트의 모든 다른 적합성 요구사항을 충족해야 합니다.

부분 구현

저자들이 미래 호환 파싱 규칙을 활용해 폴백 값을 지정할 수 있도록, CSS 렌더러는 지원하지 않는 at-규칙, 속성, 속성값, 키워드, 기타 구문 구조에 대해 반드시 무효로 처리(그리고 적절히 무시)해야 합니다. 특히, 사용자 에이전트는 절대로 지원하지 않는 값만 무시하고 지원하는 값만 적용하는 선택적 무시를 해서는 안 되며: 어떤 값이라도 무효로 판단되면(CSS에서 지원하지 않는 값은 반드시 무효로 간주), 전체 선언을 무시해야 합니다.

불안정 및 독점 기능의 구현

향후 안정적인 CSS 기능과의 충돌을 방지하기 위해, CSSWG는 모범 사례를 따를 것을 권장합니다. 이는 불안정 기능 및 독점 확장의 구현에 적용됩니다.

비실험적 구현

명세가 Candidate Recommendation 단계에 도달하면, 비실험적 구현이 가능하며, 구현자는 명세에 따라 올바르게 구현되었음을 입증할 수 있는 CR-레벨 기능에 대해 접두어 없는 구현을 배포해야 합니다.

CSS의 상호운용성을 구축하고 유지하기 위해, CSS 워킹 그룹은 비실험적 CSS 렌더러가 어떤 CSS 기능이라도 접두어 없는 구현을 배포하기 전에 구현 보고서(필요하다면 구현 보고서에 사용된 테스트케이스 포함)를 W3C에 제출할 것을 요청합니다. W3C에 제출된 테스트케이스는 CSS 워킹 그룹의 검토 및 수정 대상이 됩니다.

테스트케이스 및 구현 보고서 제출에 대한 자세한 정보는 CSS 워킹 그룹 웹사이트 https://www.w3.org/Style/CSS/Test/에서 확인할 수 있습니다. 질문은 public-css-testsuite@w3.org 메일링 리스트로 문의하십시오.

색인

이 명세에서 정의한 용어

참조로 정의된 용어

참고 문헌

규범적 참고 문헌

[CSS-ALIGN-3]
Elika Etemad; Tab Atkins Jr.. CSS Box Alignment Module Level 3. 2023년 2월 17일. WD. URL: https://www.w3.org/TR/css-align-3/
[CSS-BACKGROUNDS-3]
Elika Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 2024년 3월 11일. CR. URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS-BOX-4]
Elika Etemad. CSS Box Model Module Level 4. 2024년 8월 4일. WD. URL: https://www.w3.org/TR/css-box-4/
[CSS-BREAK-3]
Rossen Atanassov; Elika Etemad. CSS Fragmentation Module Level 3. 2018년 12월 4일. CR. URL: https://www.w3.org/TR/css-break-3/
[CSS-BREAK-4]
Rossen Atanassov; Elika Etemad. CSS Fragmentation Module Level 4. 2018년 12월 18일. WD. URL: https://www.w3.org/TR/css-break-4/
[CSS-CASCADE-3]
Elika Etemad; Tab Atkins Jr.. CSS Cascading and Inheritance Level 3. 2021년 2월 11일. REC. URL: https://www.w3.org/TR/css-cascade-3/
[CSS-CASCADE-5]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 5. 2022년 1월 13일. CR. URL: https://www.w3.org/TR/css-cascade-5/
[CSS-CASCADE-6]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 6. 2024년 9월 6일. WD. URL: https://www.w3.org/TR/css-cascade-6/
[CSS-CONTAIN-2]
Tab Atkins Jr.; Florian Rivoal; Vladimir Levin. CSS Containment Module Level 2. 2022년 9월 17일. WD. URL: https://www.w3.org/TR/css-contain-2/
[CSS-FLEXBOX-1]
Tab Atkins Jr.; 외 다수. CSS Flexible Box Layout Module Level 1. 2018년 11월 19일. CR. URL: https://www.w3.org/TR/css-flexbox-1/
[CSS-GRID-1]
Tab Atkins Jr.; 외 다수. CSS Grid Layout Module Level 1. 2020년 12월 18일. CR. URL: https://www.w3.org/TR/css-grid-1/
[CSS-GRID-2]
Tab Atkins Jr.; Elika Etemad; Rossen Atanassov. CSS Grid Layout Module Level 2. 2020년 12월 18일. CR. URL: https://www.w3.org/TR/css-grid-2/
[CSS-IMAGES-3]
Tab Atkins Jr.; Elika Etemad; Lea Verou. CSS Images Module Level 3. 2023년 12월 18일. CR. URL: https://www.w3.org/TR/css-images-3/
[CSS-INLINE-3]
Elika Etemad. CSS Inline Layout Module Level 3. 2024년 8월 12일. WD. URL: https://www.w3.org/TR/css-inline-3/
[CSS-OVERFLOW-3]
Elika Etemad; Florian Rivoal. CSS Overflow Module Level 3. 2023년 3월 29일. WD. URL: https://www.w3.org/TR/css-overflow-3/
[CSS-PAGE-3]
Elika Etemad. CSS Paged Media Module Level 3. 2023년 9월 14일. WD. URL: https://www.w3.org/TR/css-page-3/
[CSS-POSITION-3]
Elika Etemad; Tab Atkins Jr.. CSS Positioned Layout Module Level 3. 2024년 8월 10일. WD. URL: https://www.w3.org/TR/css-position-3/
[CSS-PSEUDO-4]
Daniel Glazman; Elika Etemad; Alan Stearns. CSS Pseudo-Elements Module Level 4. 2022년 12월 30일. WD. URL: https://www.w3.org/TR/css-pseudo-4/
[CSS-RUBY-1]
Elika Etemad; 외 다수. CSS Ruby Annotation Layout Module Level 1. 2022년 12월 31일. WD. URL: https://www.w3.org/TR/css-ruby-1/
[CSS-SPEECH-1]
Léonie Watson; Elika Etemad. CSS Speech Module Level 1. 2023년 2월 14일. CR. URL: https://www.w3.org/TR/css-speech-1/
[CSS-TABLES-3]
François Remy; Greg Whitworth; David Baron. CSS Table Module Level 3. 2019년 7월 27일. WD. URL: https://www.w3.org/TR/css-tables-3/
[CSS-TEXT-4]
Elika Etemad; 외 다수. CSS Text Module Level 4. 2024년 5월 29일. WD. URL: https://www.w3.org/TR/css-text-4/
[CSS-UI-4]
Florian Rivoal. CSS Basic User Interface Module Level 4. 2021년 3월 16일. WD. URL: https://www.w3.org/TR/css-ui-4/
[CSS-VALUES-3]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3. 2024년 3월 22일. CR. URL: https://www.w3.org/TR/css-values-3/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 2024년 3월 12일. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS-WRITING-MODES-3]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 3. 2019년 12월 10일. REC. URL: https://www.w3.org/TR/css-writing-modes-3/
[CSS2]
Bert Bos; 외 다수. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 2011년 6월 7일. REC. URL: https://www.w3.org/TR/CSS21/
[CSS22]
Bert Bos. Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification. 2016년 4월 12일. WD. URL: https://www.w3.org/TR/CSS22/
[CSSOM]
Daniel Glazman; Emilio Cobos Álvarez. CSS Object Model (CSSOM). 2021년 8월 26일. WD. URL: https://www.w3.org/TR/cssom-1/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML]
Anne van Kesteren; 외 다수. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[MEDIAQUERIES-5]
Dean Jackson; 외 다수. Media Queries Level 5. 2021년 12월 18일. WD. URL: https://www.w3.org/TR/mediaqueries-5/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997년 3월. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-4]
Elika Etemad; Tab Atkins Jr.. Selectors Level 4. 2022년 11월 11일. WD. URL: https://www.w3.org/TR/selectors-4/
[SVG2]
Amelia Bellamy-Royds; 외 다수. Scalable Vector Graphics (SVG) 2. 2018년 10월 4일. CR. URL: https://www.w3.org/TR/SVG2/
[WEB-ANIMATIONS-1]
Brian Birtles; 외 다수. Web Animations. 2023년 6월 5일. WD. URL: https://www.w3.org/TR/web-animations-1/

참고용 참고 문헌

[CSS-SIZING-3]
Tab Atkins Jr.; Elika Etemad. CSS Box Sizing Module Level 3. 2021년 12월 17일. WD. URL: https://www.w3.org/TR/css-sizing-3/
[CSS3-EXCLUSIONS]
Rossen Atanassov; Vincent Hardy; Alan Stearns. CSS Exclusions Module Level 1. 2015년 1월 15일. WD. URL: https://www.w3.org/TR/css3-exclusions/

속성 색인

이름 초기값 적용 대상 상속 % 허용 애니메이션 타입 정규 순서 계산된 값 미디어
display [ <display-outside> || <display-inside> ] | <display-listitem> | <display-internal> | <display-box> | <display-legacy> inline 모든 요소 아니오 해당 없음 참조 문법에 따름 내부 및 외부 display 타입을 나타내는 키워드 쌍 + 선택적 list-item 플래그, 또는 <display-internal>이나 <display-box> 키워드; 계산 규칙은 여러 명세의 본문 참조
order <integer> 0 flex 아이템 및 grid 아이템 아니오 해당 없음 계산값 타입에 따라 문법에 따름 지정한 정수
reading-flow normal | flex-visual | flex-flow | grid-rows | grid-columns | grid-order normal flex 및 grid 컨테이너 아니오 해당 없음 애니메이션 불가 문법에 따름 지정된 값
visibility visible | hidden | collapse visible 모든 요소 N/A 불연속 문법에 따름 지정된 값 visual

이슈 색인

이 속성이 테이블에도 적용되어야 할까요? [이슈 #9922]
reading-flow가 포커스 가능한 display: contents 요소와 어떻게 상호작용하는지 정의해야 합니다. [이슈 #9230]
DOM에 편리한 재정렬 함수가 필요합니다. 저자(특히 JS를 자주 쓰지 않는 저자)도 필요할 때 소스 순서 재정렬을 쉽게 할 수 있어야 하며, orderreading-flow를 오남용하지 않게 해야 합니다. [이슈 #7387]