1. 소개

이 섹션은 규범적입니다.

CSS는 트리로 구성된 소스 문서를 받아 요소(다른 요소와 텍스트 노드가 혼합될 수 있음)와 텍스트 노드(텍스트를 포함할 수 있음)로 조직하고, 이를 캔버스에 렌더링합니다. 예를 들어 화면, 종이, 오디오 스트림 등입니다. 이러한 모든 소스 문서는 CSS로 렌더링할 수 있지만, 가장 일반적으로 사용되는 유형은 DOM입니다. [DOM] (이러한 더 복잡한 트리 유형에는 주석 노드와 같이 추가적인 노드 타입이 있을 수 있습니다. CSS 관점에서는 이러한 추가 노드 타입은 모두 무시되어 존재하지 않는 것처럼 간주합니다.)

이를 위해 중간 구조인 박스 트리를 생성하는데, 이는 렌더링된 문서의 포맷 구조를 나타냅니다. 박스 트리의 각 박스는 해당하는 요소(또는 의사요소)를 캔버스의 공간/시간상에서 나타내며, 박스 트리의 각 텍스트 시퀀스 역시 해당 텍스트 노드의 내용을 나타냅니다.

박스 트리를 만들기 위해, CSS는 먼저 캐스케이딩과 상속을 사용하여, 각 CSS 속성의 계산된 값을 소스 트리의 각각의 요소와 텍스트 노드에 할당합니다. (자세한 내용은 [CSS-CASCADE-3] 참조.)

그리고 각 요소마다, CSS는 해당 요소의 display 속성에 따라 0개 이상의 박스를 생성합니다. 일반적으로 요소는 하나의 박스(주 박스)를 생성하며, 이는 자신을 나타내고 박스 트리에 내용을 포함합니다. 하지만 일부 display 값(예: display: list-item)은 여러 박스(예: 주 블록 박스와 자식 마커 박스)를 생성합니다. 그리고 일부 값(none 또는 contents 등)은 요소 및/또는 그 자손이 박스를 전혀 생성하지 않게 합니다. 박스들은 종종 display 타입으로 불립니다—예를 들어 박스가 display: block이면 “블록 박스” 또는 “블록”이라고 부릅니다.

박스는 생성한 요소와 동일한 스타일을 할당받으며, 달리 명시되지 않으면 그대로입니다. 일반적으로 상속 속성은 주 박스에 할당되고, 박스 트리를 따라 같은 요소가 생성한 다른 박스에도 상속됩니다. 비상속 속성은 기본적으로 주 박스에 적용되지만, 요소가 여러 박스를 생성할 경우 다른 박스에 적용되도록 정의될 수 있습니다: 예를 들어, border 속성이 테이블 요소에 적용될 때는, 테이블 그리드 박스에 적용되고, 주 테이블 래퍼 박스에는 적용되지 않습니다. 만약 값 계산 과정에서 박스의 스타일이 변경된다면, 요소의 스타일을 요청할 경우(getComputedStyle() 등), 해당 속성이 적용된 박스의 값을 요소가 반영합니다.

마찬가지로, 인접한 형제 텍스트 노드의 연속 시퀀스는 텍스트 시퀀스를 생성하며, 그 텍스트 내용을 포함합니다. 생성한 텍스트 노드와 동일한 스타일을 할당받습니다. 단, 시퀀스에 텍스트가 없으면 텍스트 시퀀스도 생성되지 않습니다.

박스 트리를 구성할 때, 요소가 생성한 박스는 조상 요소의 주 박스의 자손이 됩니다. 일반적으로, 요소의 부모 박스는 가장 가까운 상위 요소가 생성한 박스의 주 박스입니다; 단, run-in 박스, 여러 컨테이너 박스를 생성하는 테이블과 같은 display 타입, 그리고 중간 익명 박스 등 예외도 있습니다.

익명 박스는 어떤 요소와도 연결되지 않은 박스입니다. 익명 박스는 박스 트리가 특정 중첩 구조를 필요로 하는데 요소 트리에서 생성된 박스가 이를 제공하지 않을 때 생성됩니다. 예를 들어, 테이블 셀 박스는 특정 부모 박스(즉, 테이블 행 박스)를 필요로 하며, 부모가 테이블 행 박스가 아니면 익명 테이블 행 박스가 자신을 감싸도록 생성됩니다. (자세한 내용은 [CSS2] § 17.2.1 참조.) 요소가 생성한 박스와 달리, 스타일은 요소 트리를 따라 엄격하게 상속되지만, 익명 박스(박스 트리에만 존재)는 박스 트리의 부모를 통해 상속됩니다. inherit

레이아웃 과정에서 박스와 텍스트 시퀀스는 여러 조각(fragment)으로 나뉠 수 있습니다. 예를 들어 인라인 박스 및/또는 텍스트 시퀀스가 줄을 넘어갈 때, 블록 박스가 페이지나 컬럼을 넘어갈 때 (이 과정을 단편화(fragmentation)라고 함) 발생합니다. 또한 텍스트의 양방향 정렬(bidi reordering; 양방향 알고리즘 적용 및 CSS Writing Modes 참고), 또는 상위 display type 박스 분할, 예를 들어 block-in-inline 분할(CSS2§9.2 참고), column-spanner-in-block 분할(CSS 다단 레이아웃 참고) 등에서도 발생할 수 있습니다. 따라서 박스는 하나 이상의 박스 조각으로 구성되고, 텍스트 시퀀스는 하나 이상의 텍스트 조각으로 구성됩니다. 단편화(fragmentation)에 대한 자세한 내용은 [CSS-BREAK-3]를 참고하세요.

참고: 많은 CSS 명세들이 이런 용어가 정립되기 전에 작성되었거나, 용어를 잘못 참조하는 경우가 있으니, 오래된 명세에서 이 용어를 사용할 때 주의하세요. 실제로 어떤 용어를 의미하는지는 문맥에서 추론할 수 있어야 합니다. 명세에서 오류를 발견하면 오류를 보고해 주세요. 수정될 수 있도록 도와주세요.

참고: "오럴 박스 트리"와 display 속성의 상호작용에 대한 추가 정보는 CSS Speech Module에서 확인할 수 있습니다. [CSS-SPEECH-1]

1.1. 모듈 상호작용

이 모듈은 display 속성의 정의를 [CSS2] 9.2.4절에서 대체 및 확장합니다.

이 모듈의 어떤 속성도 ::first-line이나 ::first-letter 의사요소에는 적용되지 않습니다.

1.2. 값 정의

이 명세는 CSS 속성 정의 규약을 [CSS2]에서 따르며, 값 정의 문법을 [CSS-VALUES-3]에서 사용합니다. 이 명세에서 정의되지 않은 값 타입은 CSS 값 및 단위 [CSS-VALUES-3]에서 정의됩니다. 다른 CSS 모듈과의 조합으로 이러한 값 타입의 정의가 확장될 수 있습니다.

속성 정의에 나열된 속성별 값 외에도, 이 명세에서 정의되는 모든 속성은 CSS-wide 키워드도 속성 값으로 허용합니다. 가독성을 위해 명시적으로 반복하지 않았습니다.

2. 박스 레이아웃 모드: display 속성

사용자 에이전트는 모든 미디어, 비시각적 미디어도 포함하여 이 속성을 지원해야 합니다. display 속성은 요소의 display 타입을 정의하며, 이는 요소가 박스를 생성하는 두 가지 기본 특성으로 구성됩니다:

• 내부 display 타입: 비대체 요소인 경우 어떤 포맷팅 컨텍스트를 생성할지 정의하며, 자손 박스가 어떻게 배치될지 결정합니다. (대체 요소의 내부 display는 CSS 범위 외입니다.)

• 외부 display 타입: 주 박스가 흐름 레이아웃에 어떻게 참여할지 결정합니다.

텍스트 시퀀스는 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” 열을 사용합니다. [CSSOM]

2.1. 플로우 레이아웃의 외부 디스플레이 역할: block, inline, run-in 키워드

<display-outside> 키워드는 요소의 외부 display 타입을 지정합니다. 이는 본질적으로 주 박스가 플로우 레이아웃에서 갖는 역할입니다. 각각 다음과 같이 정의됩니다:

block

요소는 플로우 레이아웃에서 블록 레벨 박스를 생성합니다. [CSS2]

inline

요소는 플로우 레이아웃에서 인라인 레벨 박스를 생성합니다. [CSS2]

run-in

요소는 run-in 박스를 생성하며, 이는 다음 블록 컨테이너와 병합을 시도하는 특별한 동작의 인라인 레벨 박스 유형입니다. 자세한 내용은 § 5 Run-In 레이아웃을 참고하세요.

참고: 외부 display 타입은 대체 요소에도 영향을 줍니다.

<display-outside> 값이 지정되고 <display-inside>가 생략된 경우, 요소의 내부 display 타입은 기본적으로 flow가 됩니다.

2.2. 내부 디스플레이 레이아웃 모델: flow, flow-root, table, flex, grid, ruby 키워드

<display-inside> 키워드는 요소의 내부 display 타입을 지정합니다. 이는 해당 요소가 포함하는 내용이 어떻게 레이아웃되는지 결정하는 포맷팅 컨텍스트 타입을 정의합니다 (요소가 비대체 요소인 경우). 각각 다음과 같이 정의됩니다:

flow

요소는 플로우 레이아웃(블록 및 인라인 레이아웃)을 사용해 내용을 배치합니다.

요소의 외부 display 타입이 inline 또는 run-in이고, 블록 또는 인라인 포맷팅 컨텍스트에 참여하는 경우, 인라인 박스를 생성합니다.

그 외에는 블록 컨테이너 박스를 생성합니다.

다른 속성(position, float, overflow 등) 값 및 요소가 블록 또는 인라인 포맷팅 컨텍스트에 참여하는지 여부에 따라, 자체 내용에 대해 새 블록 포맷팅 컨텍스트를 생성하거나, 부모 포맷팅 컨텍스트에 내용을 통합할 수 있습니다. 자세한 내용은 CSS2.1 Chapter 9 참고. [CSS2] 새 블록 포맷팅 컨텍스트를 생성하는 블록 컨테이너는 사용된 내부 display 타입이 flow-root로 간주됩니다.

flow-root

요소는 블록 컨테이너 박스를 생성하며, 플로우 레이아웃을 사용해 내용을 배치합니다. 항상 자체 내용에 대해 새 블록 포맷팅 컨텍스트를 생성합니다. [CSS2]

table

요소는 주 테이블 래퍼 박스를 생성하며, 해당 박스는 블록 포맷팅 컨텍스트를 생성합니다. 그리고 그 안에 추가로 테이블 그리드 박스를 생성하며, 이는 테이블 포맷팅 컨텍스트를 생성합니다. [CSS2]

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>가 생략된 경우, 요소의 외부 display 타입은 기본적으로 block입니다. 단, ruby는 기본값이 inline입니다.

2.3. 마커 박스 생성: list-item 키워드

list-item 키워드는 요소가 ::marker 의사요소 [CSS-PSEUDO-4]를 생성하게 하며, 그 내용은 list-style 속성으로 지정됩니다 (CSS 2.1§12.5 리스트) [CSS2]와 함께 자신의 내용에 대해 지정된 타입의 주 박스를 생성합니다.

내부 display 타입 값이 지정되지 않은 경우, 주 박스의 내부 display 타입은 기본적으로 flow가 됩니다. 외부 display 타입 값이 지정되지 않은 경우, 주 박스의 외부 display 타입은 기본적으로 block입니다.

참고: 이 단계에서는 문법에서 제한되듯, list-items는 플로우 레이아웃 display 타입 (block/inline/run-in과 flow/flow-root 내부 타입)에 한정됩니다. 이 제한은 향후 단계에서 완화될 수 있습니다.

2.4. 레이아웃 내부 display 타입: table-*, ruby-* 키워드

일부 레이아웃 모델(예: table 및 ruby)은 내부 구조가 복잡하여, 자식 및 자손이 채울 수 있는 여러 역할이 있습니다. 이 섹션은 해당 레이아웃 모드 내에서만 의미를 가지는 “레이아웃 내부” display 값을 정의합니다.

달리 명시되지 않은 한, 이러한 display 값을 사용하는 요소의 내부 display 타입과 외부 display 타입 모두 해당 키워드로 설정됩니다.

display 속성이 대체 요소에서 레이아웃 내부 값으로 계산되는 경우, 실제 사용 값은 inline으로 처리됩니다. 해당 inline 값을 기준으로, 대체 요소 주변의 공백 축약 및 익명 박스 생성이 이루어집니다. 즉, 레이아웃 내부 display 값이 적용되지 않은 것처럼 동작합니다.

저자는 레이아웃 내부 display 값을 대체 요소에 지정하지 않아야 합니다.

<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 내부 display 타입을 가집니다.

table-caption

요소는 테이블 캡션 박스를 생성하며, 이는 블록 박스로, 테이블 및 테이블 래퍼 박스와 관련하여 특별한 동작을 가집니다. 자세한 내용은 CSS2§17.2 [CSS2] 참고.

table-caption 박스는 flow-root 내부 display 타입을 가집니다.

ruby-base, ruby-text, ruby-base-container, ruby-text-container

요소는 내부 ruby 요소입니다. 해당 내부 ruby 박스를 생성하며, ruby 포맷팅 컨텍스트에 참여합니다. [CSS-RUBY-1]

ruby-base 및 ruby-text는 flow 내부 display 타입을 가집니다.

레이아웃 내부 display 타입을 가진 박스는 올바르지 않은 부모에 배치될 때, 해당 명세에서 정의한 대로 자신을 감싸는 익명 래퍼 박스를 생성합니다.

<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

2.5. 박스 생성: none 및 contents 키워드

display는 요소가 생성할 박스의 타입을 제어할 수 있을 뿐만 아니라, 요소가 박스를 생성할지 여부도 제어할 수 있습니다.

<display-box> 키워드는 다음과 같이 정의됩니다:

contents

해당 요소 자체는 박스를 생성하지 않지만, 자식과 의사요소는 평소처럼 박스 및 텍스트 시퀀스를 생성합니다. 박스 생성과 레이아웃 관점에서, 해당 요소는 element tree에서 자식(문서 소스 자식과 ::before, ::after 등 의사요소 포함)으로 대체된 것처럼 취급됩니다.

참고: 박스 트리만 영향을 받으므로, 셀렉터 매칭, 이벤트 처리, 속성 상속 등 문서 트리 기반 의미에는 영향이 없습니다. 단, 현재 주요 브라우저에서는 올바르게 구현되어 있지 않으므로 이 기능을 사용할 때는 접근성 도구가 해당 요소의 의미에 접근하지 못할 수 있으니 주의해야 합니다.

이 값은 대체 요소 및 렌더링이 완전히 CSS로 제어되지 않는 요소에서는 display: none으로 계산됩니다. 자세한 내용은 부록 B: display: contents가 특이 요소에 미치는 영향을 참고하세요.

참고: 대체 요소 및 폼 컨트롤은 해당 요소 자체의 박스만 제거하는 것이 거의 정의되지 않은 동작이므로 특별하게 처리됩니다. 만약 더 구체적인 렌더링 모델과 사용 사례가 발전한다면 이 동작이 조정될 수 있으니, 저자는 이런 요소에 대해 display: contents 대신 display: none을 사용하여 호환성을 확보하는 것이 좋습니다.

none

요소와 그 자손은 박스나 텍스트 시퀀스를 생성하지 않습니다.

마찬가지로, 텍스트 노드가 display: none 동작을 하도록 정의된 경우, 텍스트 시퀀스도 생성하지 않습니다.

이 두 값을 가진 요소는 내부 또는 외부 display 타입을 가지지 않습니다. 박스를 전혀 생성하지 않기 때문입니다.

참고: 해당 값들은 요소가 박스를 생성하지 않게 하므로, 익명 박스 생성 규칙은 생략된 요소를 박스 트리에서 존재하지 않는 것처럼 완전히 무시합니다.

그러나 마크업 기반 관계는 이러한 값에 영향을 받지 않습니다. 이것은 렌더링 시점에만 적용되는 효과입니다. 예를 들어, 어떤 테이블 셀이 보이는지에는 영향을 줄 수 있지만, 어떤 셀이 특정 컬럼 element와 연결되어 있는지는 영향을 주지 않습니다. 마찬가지로, 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키워드 조합 대신 가장 짧고 하위 호환이 좋은 직렬화 원칙을 따릅니다.

2.7. 박스 타입 자동 변환

일부 레이아웃 효과는 박스 타입의 blockification 또는 inlinification을 요구하며, 이로 인해 박스의 계산된 외부 display 타입이 각각 block 또는 inline으로 설정됩니다. (display 타입이 박스를 전혀 생성하지 않는 경우, 예를 들어 none 또는 contents처럼, 이 동작은 적용되지 않습니다.) 추가적으로:

• 블록 박스(block flow)가 inlinified 되면, 해당 박스의 내부 display 타입은 flow-root로 설정되어 블록 컨테이너 특성을 유지합니다.

• 인라인 박스(inline flow)가 inlinified 되면, in-flow 자식들도 재귀적으로 inlinify 되어, 블록 레벨 자손이 인라인 포맷팅 컨텍스트를 깨지 않도록 합니다.

• 레거시 이유로, 인라인 블록 박스 (inline flow-root)가 blockified 되면, block 박스가 되어 flow-root 특성을 잃습니다. 일관성을 위해, run-in flow-root 박스도 blockify되어 block 박스가 됩니다.

• 레이아웃 내부 박스가 blockified 되면, 내부 display 타입이 flow로 변환되어 블록 컨테이너가 됩니다. inlinification은 레이아웃 내부 박스에는 효과가 없습니다. (다만, 인라인 컨텍스트에 배치되면 적절한 타입의 익명 인라인 레벨 박스에 래핑되는 경우가 일반적입니다.)

참고: 박스 타입이 컨텍스트에 맞지 않는 경우 이를 정정하는 방법은 두 가지입니다. 하나는 계산 값의 변환(여기서 설명된 blockification과 inlinification 등)입니다. 다른 하나는 박스 트리 구성(계산 값이 결정된 이후)에 중간 익명 박스를 생성하는 것이며, 이는 테이블, ruby, flow 레이아웃 등에서 발생합니다.

2.8. 루트 요소의 주 박스

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

또한, 루트 요소에 display가 contents로 지정되면 block으로 계산됩니다.

3. 표시 순서: order 속성

박스들은 일반적으로 소스 문서에 나타나는 순서대로 표시되고 레이아웃됩니다. 일부 포매팅 컨텍스트에서는 order 속성을 사용하여 박스의 순서를 변경하여 요소의 논리적 순서와 2D 시각적 캔버스에서의 공간 배치 순서 간의 차이를 의도적으로 만들 수 있습니다. (§ 3.1 재정렬 및 접근성 참고.)

특히, order 속성은 플렉스 아이템 또는 그리드 아이템이 컨테이너 내에서 나타나는 순서를 순서 그룹에 할당함으로써 제어합니다. 단일 <integer> 값을 가지며, 아이템이 속하는 순서 그룹을 지정합니다.

여기 카탈로그 아이템 카드의 예제가 있습니다. 카드에는 제목, 사진, 설명이 있습니다. 각 항목 내에서는 소스 문서의 콘텐츠가 논리적으로 제목→설명→사진 순으로 배치되어 있습니다. 이는 음성 렌더링 및 CSS가 없는 브라우저에서 합리적인 순서를 제공합니다. 더 흥미로운 시각적 표현을 위해서는 order를 사용하여 콘텐츠의 후반에 있던 이미지를 카드의 맨 위로 끌어올릴 수 있습니다.

article.sale-item {
  display: flex;
  flex-flow: column;
}
article.sale-item > img {
  order: -1; /* 레이아웃 순서에서 이미지를 다른 콘텐츠 앞에 배치 */
  align-self: center;
}

<article class="sale-item">
  <h1>컴퓨터 스타터 키트</h1>
  <p>이 제품은 돈이 많지 않다면 살 수 있는 최고의 컴퓨터입니다.
  <ul>
    <li>컴퓨터
    <li>모니터
    <li>키보드
    <li>마우스
  </ul>
  <img src="images/computer.jpg"
    alt="제공 품목: 흰색 데스크탑 컴퓨터와 일치하는 주변기기.">
</article>

컴퓨터 스타터 키트

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

• 컴퓨터
• 모니터
• 키보드
• 마우스

플렉스 및 그리드 컨테이너는 내용을 order로 수정된 문서 순서로 배치하며, 가장 낮은 순서 그룹부터 시작하여 높은 순서 그룹으로 올라갑니다. 동일한 순서 그룹의 아이템은 소스 문서에 나타나는 순서대로 배치됩니다. 이는 페인팅 순서에도 영향을 주며 [CSS2], 플렉스/그리드 아이템이 소스 문서에서 재정렬된 것처럼 동작합니다. 플렉스/그리드 컨테이너의 절대 위치 자식은 페인팅 순서를 결정할 때 order: 0로 간주되며, 플렉스/그리드 아이템과의 상대적 순서가 결정됩니다.

추후 명시되지 않는 한, 이 속성은 플렉스 아이템 또는 그리드 아이템이 아닌 박스에는 아무런 효과가 없습니다.

3.1. 재정렬 및 접근성

order 속성은 비시각적 미디어(예: 음성)의 순서에는 영향을 주지 않습니다. 마찬가지로 order는 기본 순차 탐색 모드(예: 링크 반복 탐색, tabindex [HTML] 참고)의 기본 순서에도 영향을 주지 않습니다.

저자들은 order를 오직 공간적(시각적) 콘텐츠 재정렬에만 사용해야 합니다. order를 논리적 재정렬에 사용하는 스타일 시트는 비준수입니다.

참고: 이는 비시각적 미디어와 CSS가 없는 사용자 에이전트에서 일반적으로 콘텐츠를 선형적으로 표시할 수 있도록 논리적 소스 순서에 의존할 수 있게 하며, order는 레이아웃 순서만 조정하는 데 사용됩니다. (시각적 인식은 2차원이고 비선형이므로 원하는 레이아웃 순서가 항상 논리적 순서와 일치하지 않습니다.)

모든 표현 모드에서 저자가 의도한 순서를 유지하기 위해 WYSIWYG 에디터 및 웹 기반 저작 도구를 포함한 저작 도구들은 기본 문서 소스를 재정렬해야 하며, order를 사용하여 재정렬을 수행해서는 안 됩니다. 단, 저자가 공간적 순서가 기본 문서 순서(음성 및 탐색 순서 결정)와 동기화되지 않음을 명시적으로 지정한 경우에는 제외합니다.

참고: 브라우저, 접근성 기술, 확장 프로그램을 포함한 사용자 에이전트는 공간 탐색 기능을 제공할 수 있습니다. 이 섹션은 그런 공간 탐색 모드에서 order 속성을 고려하는 것을 금지하지 않습니다. 오히려 이런 기능이 작동하려면 반드시 고려해야 합니다. 하지만 order는 이런 공간 탐색 기능을 위해 고려해야 할 CSS 속성 중 유일하거나 주요 속성이 아닙니다. 잘 구현된 공간 탐색 기능은 공간 관계를 수정하는 모든 CSS 레이아웃 기능을 고려해야 합니다.

4. 투명성: visibility 속성

visibility 속성은 박스가 렌더링되는지 여부를 지정합니다. 투명한 박스도 레이아웃에는 영향을 줍니다. (박스 생성 자체를 완전히 막으려면 display 속성을 none으로 설정하세요.) 값의 의미는 다음과 같습니다:

visible

생성된 박스가 일반적으로 표시됩니다.

hidden

요소가 생성한 모든 박스가 투명해집니다. 하지만 자식 요소가 visibility: visible을 가지고 있다면 자식은 표시될 수 있습니다.

collapse

박스가 접힘 상태임을 나타내며, 포매팅 컨텍스트에 따라 공간을 덜 차지할 수 있습니다. 테이블의 동적 행/열 효과 [CSS2]와 플렉스 레이아웃에서의 collapsed flex items 참고 [CSS-FLEXBOX-1]. 그 외의 경우(별도 명시 없을 때)는 단순히 박스를 투명하게 만들며, hidden과 동일합니다.

참고: 현재 많은 사용자 에이전트 및 접근성 도구들이 투명 요소와 의미상 관계가 있는 표시된 요소의 접근성 문제를 올바르게 구현하지 못하고 있습니다. 예를 들어, 부모 요소(테이블 행 등)를 투명하게 하고 자식 요소(테이블 셀 등)는 표시 상태로 두면 그런 도구를 사용하는 사용자에게 문제가 될 수 있습니다. 저자들은 도구 상황이 개선될 때까지 이런 상황을 만들지 않는 것이 좋습니다.

투명 박스는 렌더링되지 않으며(완전히 투명한 것처럼), 상호작용할 수 없으며 (pointer-events: none과 동일하게 동작), 탐색에서 제외되며 (display: none과 유사), 음성 렌더링에서도 렌더링되지 않습니다. (단, speak가 always인 경우는 예외 [CSS-SPEECH-1]). 하지만 display: contents처럼 컨테이너로서의 의미론적 역할은 유지되어 visible 자식 요소가 올바르게 해석됩니다.

참고: speak가 always인 경우, 투명 박스도 음성으로 렌더링되며, 비시각적/공간적 방법으로 상호작용할 수 있습니다.

<p>영화 초반의 상징주의는 마지막에 명확해지는데,
  <spoiler-text><span>루크가 자신의 아버지임이 드러날 때</span></spoiler-text>,
  마법사의 수수께끼가 의미를 갖게 됩니다.
<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>

5. 런인 레이아웃

런인 박스는 자신의 뒤에 오는 블록에 합쳐져, 해당 블록의 인라인 수준 콘텐츠의 시작 부분에 자신을 삽입하는 박스입니다. 이는 간결한 제목, 정의, 기타 유사한 항목을 포맷할 때 유용하며, 적절한 DOM 구조는 본문 앞에 제목을 두지만, 원하는 표시는 인라인 제목이 텍스트와 함께 레이아웃되는 것입니다.

<dl class='dict'>
  <dt>dictionary
  <dd>언어의 단어를 알파벳순으로 나열하고 의미를 제공하는 책,
      또는 다른 언어의 해당 단어를 제공하는 책.
  <dt>glossary
  <dd>특정 주제, 텍스트, 방언에 나타나거나 관련된 용어 또는 단어를 알파벳순으로 나열하고 설명을 덧붙인 것; 간단한 사전.
</dl>
<style>
.dict > dt {
  display: run-in;
}
.dict > dt::after {
  content: ": "
}
</style>

dictionary: 언어의 단어를 알파벳순으로 나열하고 의미를 설명하는 책.

glossary: 특정 주제, 텍스트, 방언에 나타나거나 관련된 용어 또는 단어를
알파벳순으로 나열하고 설명을 덧붙인 것; 간단한 사전.

런인 박스는 다른 인라인 수준 박스와 정확히 동일하게 동작하지만, 다음과 같은 예외가 있습니다:

• 런인 박스가 flow 내부 디스플레이 타입을 가지면 그 내용을 인라이니파이합니다.
• 런인 시퀀스가 바로 뒤에 새로운 블록 포매팅 컨텍스트를 생성하지 않는 블록 박스로 이어지면, 해당 블록 박스의 직접 자식으로 삽입됩니다: ::marker 의 박스(있는 경우) 뒤에, 하지만 블록 내부의 다른 콘텐츠가 생성한 박스들(예: ::before 박스 포함) 앞에 위치합니다. 이런 리패런팅은 가능하면 재귀적으로 일어나며 (따라서 런인 박스가 포매팅 컨텍스트 내에서 가장 깊은 “문단”의 일부가 되고, 인접한 런인 박스들을 모으게 됩니다).

  리패런팅된 콘텐츠는 원래 그 위치에 부모가 있었던 것처럼 포맷됩니다. 레이아웃만 영향을 받으며, 속성 상속에는 영향이 없습니다. 비익명 박스의 속성 상속은 오직 요소 트리를 기준으로 합니다.

• 그렇지 않은 경우 (즉, 런인 시퀀스 뒤에 그런 블록이 없을 때), 런인 시퀀스와 바로 뒤따르는 모든 인라인 수준 콘텐츠(다음 런인 시퀀스 전까지, 있다면 제외)를 감싸는 익명 블록 박스가 생성됩니다.

런인 시퀀스는 연속된 형제 런인 박스들과 그 사이의 공백 및/또는 플로우 밖 박스의 최대 시퀀스입니다.

참고: 이 설명은 플로우 밖 박스가 두 런인 박스 사이에 있으면 리패런팅된다는 의미입니다. 다른 대안으로는 중간에 있는 플로우 밖 박스를 남겨두거나, 플로우 밖 박스가 이전 박스의 런인 동작을 방해하도록 할 수도 있습니다. 구현자 및 저자들은 원하는 동작이 있다면 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) 및 플렉스 컨테이너(display: flex) 등은 블록 컨테이너가 아닙니다.

블록

블록 박스, 블록 수준 박스, 블록 컨테이너 박스를 의미하며, 명확할 때 약어로 사용.

치환 요소

이미지나 임베디드 문서처럼 CSS 포매팅 모델의 범위를 벗어난 콘텐츠를 가진 요소. 예를 들어, HTML img 요소의 콘텐츠는 종종 src 속성이 지정한 이미지로 대체됩니다.

치환 요소는 고유 크기를 가지는 경우가 많습니다. 예를 들어, 비트맵 이미지는 절대 단위로 지정된 고유 너비와 높이가 있고, 고유 비율도 그로부터 결정할 수 있습니다. 반면, 다른 객체는 고유 크기가 없을 수 있습니다 (예: 빈 HTML 문서). [css-images-3] 참고.

사용자 에이전트는 치환 요소가 고유 크기를 가지지 않는 것으로 간주할 수 있는데, 그 크기가 제3자에게 민감한 정보를 유출할 가능성이 있다고 판단되는 경우입니다. 예를 들어, HTML 문서가 사용자의 은행 잔고에 따라 자연 크기가 달라진다면, UA는 해당 리소스가 고유 크기가 없다고 간주할 수 있습니다.

치환 요소의 콘텐츠는 CSS 포매팅 모델에 포함되지 않지만, 고유 크기는 다양한 레이아웃 계산에 사용됩니다. 치환 요소는 항상 독립 포매팅 컨텍스트를 생성합니다.

비치환 요소는 치환되지 않은 요소로, 즉 렌더링이 CSS 모델에 의해 결정되는 요소입니다.

컨테이닝 블록

박스와 관련된 크기와 위치의 기준이 되는 사각형. 특히 컨테이닝 블록은 박스가 아닙니다 (사각형임), 하지만 종종 박스의 크기를 기반으로 정의됩니다. 각 박스는 자신의 컨테이닝 블록 기준으로 위치가 부여되지만, 그 컨테이닝 블록에 제한되지는 않습니다; overflow될 수 있습니다. “박스의 컨테이닝 블록”은 “박스가 속한 컨테이닝 블록”을 의미하며, 박스가 생성하는 블록이 아닙니다.

일반적으로 박스의 가장자리가 자식 박스의 컨테이닝 블록 역할을 합니다; 박스가 자식의 컨테이닝 블록을 “생성한다”고 표현합니다. 컨테이닝 블록의 속성이 참조되는 경우, 박스의 값을 참조합니다. (초기 컨테이닝 블록의 경우, 별도 명시 없으면 루트 요소의 값을 사용합니다.)

[CSS2] Section 9.1.2, Section 10.1, CSS Positioned Layout 3 § 2.1 위치 지정 박스의 컨테이닝 블록 참고.

컨테이닝 블록 체인

컨테이닝 블록들의 연속된 시퀀스로, 컨테이닝 블록 관계를 통해 조상-자손 체인을 형성합니다. 예시: 인라인 박스의 컨테이닝 블록은 가장 가까운 블록 컨테이너 조상의 콘텐츠 박스; 해당 블록 컨테이너가 인플로우 블록이라면, 그의 컨테이닝 블록은 부모 블록 컨테이너가 형성; 그 조부모 블록 컨테이너가 절대 위치라면, 그의 컨테이닝 블록은 가장 가까운 포지셔닝된 조상의 패딩 가장자리 (반드시 부모일 필요는 없음)이고, 이런 식으로 초기 컨테이닝 블록까지 올라감.

초기 컨테이닝 블록

루트 요소의 컨테이닝 블록. 초기 컨테이닝 블록은 블록 포매팅 컨텍스트를 생성합니다. CSS2.1§10.1에서 연속 미디어 참고; [CSS-PAGE-3]에서 페이지 미디어의 위치와 크기 참고.

포매팅 컨텍스트

포매팅 컨텍스트란 관련 박스 집합이 레이아웃되는 환경을 의미합니다. 다양한 포매팅 컨텍스트는 박스를 서로 다른 규칙으로 레이아웃합니다. 예를 들어, 플렉스 포매팅 컨텍스트는 플렉스 레이아웃 규칙으로 박스를 배치하며 [CSS-FLEXBOX-1] 참고, 블록 포매팅 컨텍스트는 블록-인라인 레이아웃 규칙([CSS2])을 따름. 또한 일부 포매팅 컨텍스트 타입은 서로 섞여 존재: 예를 들어 인라인 포매팅 컨텍스트는 블록 포매팅 컨텍스트 내에서 존재하며, 루비 컨테이너는 루비 포매팅 컨텍스트를 인라인 포매팅 컨텍스트 위에 오버레이합니다.

박스는 새로운 독립 포매팅 컨텍스트를 생성하거나 부모 포매팅 컨텍스트를 계속 사용합니다. 경우에 따라 추가로 새로운(비독립) 포매팅 컨텍스트를 생성할 수 있습니다. 별도 명시 없으면, 새로운 포매팅 컨텍스트를 생성하면 독립 포매팅 컨텍스트가 생깁니다. 박스가 생성하는 포매팅 컨텍스트의 종류는 내부 디스플레이 타입에 의해 결정됩니다. 예: 그리드 컨테이너는 새로운 그리드 포매팅 컨텍스트를 생성, 루비 컨테이너는 새로운 루비 포매팅 컨텍스트를 생성, 블록 컨테이너는 새로운 블록 포매팅 컨텍스트와/또는 인라인 포매팅 컨텍스트를 생성할 수 있습니다. display 속성 참고.

독립 포매팅 컨텍스트

박스가 독립 포매팅 컨텍스트를 생성할 때 (그 포매팅 컨텍스트가 부모와 같은 타입이든 아니든), 사실상 새로운 독립 레이아웃 환경을 만듭니다: 박스 자체의 크기를 제외하고는, 자손의 레이아웃은(일반적으로) 박스 외부 포매팅 컨텍스트의 규칙과 내용에 영향을 받지 않으며, 반대도 마찬가지입니다.

예를 들어, 블록 포매팅 컨텍스트에서는 플로트 박스가 주변 박스의 레이아웃에 영향을 줍니다. 하지만 그 영향은 포매팅 컨텍스트 경계를 넘지 않습니다: 그 포매팅 컨텍스트를 생성하는 박스가 플로트를 모두 감싸고, 박스 외부의 플로트는 내부 내용에 영향을 줄 수 없습니다.

또 다른 예: 마진은 포매팅 컨텍스트 경계를 넘어 합쳐지지 않습니다.

익스클루전은 독립 포매팅 컨텍스트 경계를 넘어 콘텐츠에 영향을 줄 수 있습니다. (작성 시점 기준, 유일하게 그런 기능이 있음) [CSS3-EXCLUSIONS]

특정 속성은 박스가 독립 포매팅 컨텍스트를 생성하도록 강제할 수 있습니다. 예를 들어, 박스를 플로우 밖으로 만들면 블록화와 함께 독립 포매팅 컨텍스트 생성도 일어납니다. 또 다른 예: contain 속성의 특정 값은 박스가 독립 포매팅 컨텍스트 생성을 하게 만듭니다. 블록을 스크롤 컨테이너로 만들면 독립 포매팅 컨텍스트 생성이 일어나지만, 서브그리드를 스크롤 컨테이너로 만들면 그렇게 되지 않고, 자식은 부모 그리드 컨테이너의 레이아웃에 참여하게 됩니다.

블록 박스가 독립 포매팅 컨텍스트를 생성하면 자손을 위한 새로운 블록 포매팅 컨텍스트가 만들어집니다. 대부분의 다른 경우, 박스에 독립 포매팅 컨텍스트 생성을 강제하는 것은 아무런 효과가 없습니다—이미 해당 박스가 독립 포매팅 컨텍스트를 생성하든(예: 플렉스 컨테이너), 해당 박스 타입에서는 완전히 독립적인 새 포매팅 컨텍스트를 생성할 수 없든(예: 비치환 인라인 박스).

블록 포매팅 컨텍스트

인라인 포매팅 컨텍스트

블록과 인라인 포매팅 컨텍스트는 CSS 2.1 Section 9.4에서 정의됨. 인라인 포매팅 컨텍스트는 블록 포매팅 컨텍스트 내에 존재(속함); 예를 들어, 인라인 포매팅 컨텍스트의 라인 박스는 블록 포매팅 컨텍스트에 속한 플로트와 상호작용함.

블록 레이아웃

블록 수준 박스의 레이아웃이며, 블록 포매팅 컨텍스트 내에서 수행됨.

블록 포매팅 컨텍스트 루트

새로운 블록 포매팅 컨텍스트를 생성하는 블록 컨테이너.

BFC

블록 포매팅 컨텍스트 또는 블록 포매팅 컨텍스트 루트의 약어. 내부 플로트를 포함하고 외부 플로트를 배제하며 마진 합침을 억제하는 박스를 뜻하는 다양한 비공식적 정의가 있음. 그러므로 다음 중 하나를 지칭할 수 있음:

• 자식 콘텐츠를 위한 새로운 블록 포매팅 컨텍스트를 생성하는 블록 컨테이너

• 자식 콘텐츠를 위한 블록 포매팅 컨텍스트를 생성하는 블록 박스(즉, 블록 수준 블록 컨테이너) (블록 포매팅 컨텍스트를 생성하지 않는 블록 박스와 구별됨)

• (매우 느슨하게) 새로운 포매팅 컨텍스트를 생성하는 모든 블록 수준 박스(인라인 포매팅 컨텍스트 제외)

플로우 밖

플로우 내

박스가 플로우 밖이면, 기대되는 위치와 주변 콘텐츠와의 상호작용에서 추출되어 부모 포매팅 컨텍스트의 정상적인 콘텐츠 흐름 밖에서 다른 패러다임으로 레이아웃됩니다. 이는 박스가 플로트(float)되거나 절대 위치(position 사용)된 경우 발생. 박스가 플로우 내이면 플로우 밖이 아닌 경우임.

참고: 일부 포매팅 컨텍스트는 플로트 동작을 억제하므로, float: left가 반드시 플로우 밖임을 의미하지는 않습니다.

문서 순서

박스 또는 콘텐츠가 문서에서 나타나는 순서 (렌더링 시 나타나는 순서와 다를 수 있음). 의사 요소의 상대적 순서를 결정할 때는 박스 트리 순서를 사용합니다. 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: contents는 display: none으로 계산됩니다.

legend

HTML에 따라, legend 요소에 display: contents가 지정되면 rendered legend가 아니게 되므로, 특별한 display 동작이 없습니다. (따라서 display: contents 동작이 일반적으로 적용됩니다.)

button

details

fieldset

이 요소들은 특별한 동작을 가지지 않습니다; display: contents는 그들의 주요 박스만 제거하고, 내용은 정상적으로 렌더링됩니다.

그 외 모든 HTML 요소

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

SVG 요소

CSS 박스 레이아웃을 가지는 svg 요소 (HTML 요소의 자식이거나, 문서 루트 요소인 모든 svg 포함)

display: contents는 display: none으로 계산됩니다.

그 외 모든 SVG 컨테이너 요소이면서 렌더링 가능한 요소

SVG 텍스트 콘텐츠 자식 요소

use

display: contents는 해당 요소를 포매팅 트리에서 제거하고, 그 내용물을 위치에 끌어올려 렌더링합니다. 이 내용에는 use 요소의 shadow-DOM 콘텐츠도 포함됩니다.

그 외 모든 SVG 요소

display: contents는 display: none으로 계산됩니다.

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

MathML 요소

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

부록 C: 스펙 저자를 위한 박스 구성 가이드라인

이 섹션은 스펙 저자를 위한 비규범적 안내입니다.

• 박스는 blockify와 inlinify를 동시에 할 수 없습니다; 그런 상황이 발생한다면, 어느 쪽이 우선하는지 정의하세요.

• 비주요 비익명 박스는 blockify될 수 없습니다: blockification은 요소의 계산된 값에 영향을 주며, 따라서 주요 박스의 타입을 결정합니다.

• 내용을 blockify하는 박스는 인라인 수준 콘텐츠를 직접 포함할 수 없습니다; 해당 요소 내에서 생성되는 박스나 텍스트 시퀀스는 모두 blockify되거나 익명 블록 컨테이너로 감싸져야 합니다.

• 내용을 inlinify하는 박스는 블록 수준 박스를 직접 포함할 수 없습니다; 해당 요소 내에서 생성되는 박스는 모두 인라인 수준이어야 합니다.

• 근본적으로 독립 포매팅 컨텍스트를 생성할 수 없는 박스(예: 비치환 인라인)는 독립 포매팅 컨텍스트 생성을 요구받으면 안 됩니다. 먼저 blockify하거나, 박스 타입을 독립 포매팅 컨텍스트를 생성할 수 있는 것으로 변경하세요.

감사의 글

박스 생성의 다양한 세부사항을 수년간 분리하려고 시도한 많은 사람들께 감사드립니다. 특히 Bert Bos, display-model과 display-role로 마지막 시도를 했으나 결실은 없었지만, 현 스펙의 바탕을 마련해 주셨고, Anton Prowse, CSS2.1 9장에 대한 끊임없는 공격으로 혼돈 속에서 어느 정도의 질서를 만들어냈으며, Oriol Brufau, 이 스펙의 수십 가지 미세한 구분과 오류를 밝혀낸 분, David Baron, Mats Palmgren, Ilya Streltsyn, Boris Zbarsky에게도 의견을 주셔서 명예의 언급을 드립니다.

변경 사항

2020 후보 권고 이후 변경 사항

코멘트 처리 결과가 2020년 5월 19일 후보 권고 이후 공개되었습니다.

2020년 5월 19일 후보 권고 이후의 변경 사항:

• “text run”을 “text sequence”로 이름 변경. (이슈 7768)
• 루트 요소 정의 및 레이아웃을 블록 수준으로 명확히 함 (§ 2.8 루트 요소의 주요 박스 및 초기 컨테이닝 블록 정의). (PR 8095, 이슈 7207, 이슈 6480, 이슈 7786)
• order 속성 정의를 [CSS-FLEXBOX-1]에서 가져옴. 이제 grid item에도 적용됨. (이슈 5865)
• visibility 속성 정의를 [CSS2]에서 가져와 더 철저하고 완전하게 업데이트. (이슈 6123)
• 치환 요소가 layout-internal display를 가지면 display: inline으로 처리됨 명시. (이슈 6000)
• <display-legacy> 값이 실제로 두 키워드 동등값과 같게 계산됨을 명확히 함. (이슈 5575)

  inline-…

  Behaves as Computes to inline ….

  참고: 이 키워드와 동등한 값은 계산 결과는 같지만, 명시된 값은 서로 다름.

  참고: getComputedStyle() 직렬화 규칙은 항상 이 미리 조합된 키워드를 출력하며, 동등한 두 키워드 쌍이 아닌 가장 짧고, 가장 하위 호환 직렬화 원칙에 따라 처리됨.

• blockification과 inlinification이 계산된 값 변화임을 명확히 함. (이슈 6251)

  일부 레이아웃 효과는 박스 타입의 blockification 또는 inlinification을 요구하며, 박스의 계산된 외부 디스플레이 타입을 각각 block 또는 inline으로 설정함.

• 편의를 위해 block layout 정의를 용어집에 추가.
• CSS Grid Layout 참조 업데이트.
• 여러 자잘한 편집상 명확화 및 교차링크 개선.

2019 후보 권고 이후 변경 사항

2019년 7월 11일 후보 권고 이후의 변경 사항:

• [CSS2]의 추가 설명을 containing block 정의에 합침.
• CSS 관점에서 요소와 텍스트가 아닌 DOM 노드는 무시됨을 명확히 함.

  (일부 소스 문서는 DOM과 같은 더 복잡한 트리에서 시작하며, 그 안에는 코멘트 노드 등 다양한 타입이 있을 수 있습니다. CSS에서는 이런 추가 노드 타입을 모두 무시하며, 존재하지 않는 것처럼 취급합니다.)

• absolute positioning 관련 용어집 정의를 개선/이동.

2018년 8월 28일 후보 권고 이후의 변경 사항:

• 박스 트리의 부모 개념 정의; parent box 참고.
• absolutely positioned 정의를 용어집에 추가; CSS2에서 복사하여 참조하기 쉽게 함.
• § 1 소개에서 다양한 단편화 형태에 대한 교차 참조 추가.
• "table box"를 "table grid box"로 명칭 변경하여 "table wrapper box"와 구분 용이하게 함.
• root → initial containing block 전파에 "별도 명시 없으면" 추가, HTML body 요소에 예외가 있기 때문.

후보 권고 이전 변경 사항

코멘트 처리 결과가 제공됩니다.

2018년 4월 20일 워킹 드래프트 이후의 변경 사항:

• display: contents가 display: none으로 동작하는 요소들이 이제 display: none으로 계산됨. (이슈 2755)
• formatting context와 independent formatting context를 구분(일부 formatting context가 겹칠 수 있으므로). (이슈 2597, 이슈 1457)
• block boxes가 independent formatting context를 생성할 때 display 값은 flow-root 사용 명시. (이슈 1550)
• display는 애니메이션 불가(이산 애니메이션은 별도)임을 명확히 함. (이슈 2938)
• 사소한 편집상 수정.

2017년 7월 20일 워킹 드래프트 이후의 변경 사항:

• blockification 규칙을 inline-block / inline flow-root에 대해 CSS2와 호환되도록 강화. (이슈 1246) run-in flow-root 처리도 이에 맞게 수정. (이슈 1715)

• display의 문법을 수정해 list-item 키워드를 마지막에 위치시킴. 직렬화 순서에 영향. (이슈 1621)

• block formatting contexts와 inline formatting contexts의 상호작용 정의를 block container에서 inline formatting context를 생성하는 경우에 대해 개선. (이슈 1553)

• 요소가 여러 박스를 생성할 경우 속성 값이 요소와 박스 간 어떻게 반영되는지 더 명확히 정의. (이슈 1643)

• 빈 텍스트 객체는 CSS 렌더링에서 무시됨을 명확히 함. (이슈 1808)

• display가 문서 의미론에 영향을 주지 않음을 명확히 함(UA에서 흔한 버그). (이슈 2355)

• display의 computed value 정의 오류 수정 (다양한 속성에 의해 blockification, inlinification이 일어나므로 "as specified"가 아님). (이슈 1716)

• document order 정의 추가.

• 누락된 SVG 요소를 부록 B의 display: contents 설명에 추가(이슈 2118), SVG 속성 영향 명확화(이슈 2502), MathML 동작 정의(이슈 2167).

• 익명 박스 생성 규칙 관련 가이드라인 추가. (이슈 1643)

• “포매팅 컨텍스트가 되기” 관련 섹션을 CSS Containment로 이동.

• 기타 사소한 문구 수정 및 명확화.

2017년 1월 26일 워킹 드래프트 이후의 변경 사항:

• inline-list-item 값을 inline list-item과 동일하므로 제거.

• text nodes 개념을 element tree에, text runs를 box tree에 추가하여 display: contents 맥락에서 동작 정의. (이슈 19, 이슈 32)

• 루트 요소가 "in flow"임을 정의. (이슈 3)

• ::first-line/::first-letter와 run-in의 상호작용 정의. (이슈 5, 이슈 42)

• block/inline/run-in은 flow layout에서만 동작을 결정하며, 다른 맥락에서는 무시됨을 명확히 함.

• run-in은 인라인 박스의 한 종류임을 명확히 함(단순히 "like"가 아님).

• run-in의 박스 트리 처리에 재귀가 누락된 부분 수정. (이슈 45)

• “unusual elements”에 display: contents가 적용되는 방식 부록 추가. (이슈 8, 이슈 18)

• blockification, inlinification 규칙 및 layout-internal 타입 처리 수정. (이슈 35, 이슈 57)

• 다양한 박스 트리 보정 동작의 상호작용 명확화. (이슈 38, 이슈 48)

• “포매팅 컨텍스트가 되기” 정의 추가.

• 기타 사소한 수정 및 명확화.

코멘트 처리 결과도 제공됩니다.

2015년 10월 15일 워킹 드래프트 이후의 변경 사항:

• box-suppress/display-or-not 속성은 다음 Display 레벨로 이관(사용 사례 논의를 위한 시간 확보 목적).
• display: contents가 치환 요소, 폼 컨트롤 등 특이 요소에 미치는 영향 명시.
• 요소의 ::before, ::after 의사 요소는 그 박스가 display: contents로 인해 생성되지 않아도 여전히 존재함을 명확히 함.
• display: contents가 이벤트 버블링에 영향을 주지 않음을 명확히 함.
• run-in과 out-of-flow 요소, ::first-letter와의 상호작용 명확화.
• table-caption과 table-cell이 flow-root를 inner display type으로 사용(항상 formatting context root 생성).
• 남은 이슈 처리 및 위험 목록 추가.

2015년 7월 21일 워킹 드래프트 이후의 변경 사항:

• in-flow, out-of-flow 용어 정의 추가.

2014년 9월 11일 워킹 드래프트 이후의 변경 사항:

• display-inside, display-outside, display-extras 롱핸드 제거, display를 다중 값으로 만듦. (조합 제약을 두기 위함. 향후 스펙 레벨에서 필요/불필요에 따라 일부 또는 전체 제약을 완화할 수 있음.)
• flow, flow-root inner display type 추가로 flow 레이아웃 display type을 더 잘 표현하고, 요소를 BFC root로 명확히 전환할 수 있게 함. (이를 통해 ::after { clear: both; } 및 overflow: hidden 등의 해킹이 불필요해질 것임.)

개인정보 보호 사항

이 명세는 새로운 개인정보 보호 사항을 도입하지 않습니다.

보안 사항

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

자체 검토 질문지

보안 및 개인정보 자체 검토 질문지: 고려해야 할 질문

1. 이 명세는 개인 식별 정보와 관련이 있습니까?

   아니오.

2. 이 명세는 고가치 데이터와 관련이 있습니까?

   아니오.

3. 이 명세는 브라우징 세션 간에 지속되는 출처의 새로운 상태를 도입합니까?

   아니오.

4. 이 명세는 웹에 지속적이고 교차 출처 상태를 노출합니까?

   아니오.

5. 이 명세는 출처에 현재 접근할 수 없는 다른 데이터를 노출합니까?

   아니오.

6. 이 명세는 새로운 스크립트 실행/로드 메커니즘을 가능하게 합니까?

   아니오.

7. 이 명세는 출처가 사용자의 위치에 접근할 수 있도록 허용합니까?

   아니오.

8. 이 명세는 출처가 사용자의 기기 센서에 접근할 수 있도록 허용합니까?

   아니오.

9. 이 명세는 출처가 사용자의 로컬 컴퓨팅 환경의 일부에 접근할 수 있도록 허용합니까?

   아니오.

10. 이 명세는 출처가 다른 기기에 접근할 수 있도록 허용합니까?

    아니오.

11. 이 명세는 출처가 사용자 에이전트의 기본 UI를 일정 부분 제어할 수 있도록 허용합니까?

    아니오.

12. 이 명세는 웹에 임시 식별자를 노출합니까?

    아니오.

13. 이 명세는 1자 및 3자 맥락에서의 동작을 구분합니까?

    아니오.

14. 이 명세는 사용자 에이전트의 "시크릿 모드" 맥락에서 어떻게 동작해야 합니까?

    다르게 동작하지 않습니다.

15. 이 명세는 사용자의 로컬 기기에 데이터를 저장합니까?

    아니오.

16. 이 명세에는 "보안 사항"과 "개인정보 보호 사항" 섹션이 있습니까?

    예.

17. 이 명세는 기본 보안 특성을 다운그레이드하도록 허용합니까?

    아니오.