CSS 작성 모드 레벨 3

1. 작성 모드 소개

CSS 작성 모드 레벨 3은 왼쪽에서 오른쪽(예: 라틴 문자 또는 인도 문자), 오른쪽에서 왼쪽(예: 히브리어 또는 아랍어), 양방향(예: 혼합 라틴과 아랍어), 수직(예: 아시아 문자) 등 다양한 국제 작성 모드를 지원하는 CSS 기능을 정의합니다.

CSS의 작성 모드는 writing-mode, direction, text-orientation 속성으로 결정됩니다. 이는 주로 인라인 기본 방향과 블록 흐름 방향 관점으로 정의됩니다:

라틴 기반 작성 모드

몽골어 기반 작성 모드

한자 기반 작성 모드

인라인 기본 방향은 한 줄에서 콘텐츠의 주된 정렬 방향이며, 줄의 "시작"과 "끝"이 어느 쪽인지를 정의합니다. direction 속성은 박스의 인라인 기본 방향을 지정하며, unicode-bidi 속성, 그리고 텍스트 콘텐츠의 고유 방향성과 함께 한 줄 내 인라인 콘텐츠의 정렬 순서를 결정합니다.

블록 흐름 방향은 블록 수준 박스가 쌓이는 방향과 블록 컨테이너 내에서 줄 박스가 쌓이는 방향입니다. writing-mode 속성이 블록 흐름 방향을 결정합니다.

타이포그래픽 모드는 세로 문자에 대해 텍스트가 세로 흐름의 타이포그래픽 관습을 적용하는지 결정합니다. 이 개념은 세로 문자의 세로 흐름과 회전된 가로 흐름을 구분합니다.

가로 작성 모드는 텍스트 줄이 수평인 모드(즉, 아래쪽 혹은 위쪽으로 블록 흐름)입니다. 세로 작성 모드는 텍스트 줄이 수직인 모드(즉, 왼쪽 혹은 오른쪽으로 블록 흐름)입니다.

이 용어들은 세로 블록 흐름 (아래쪽 혹은 위쪽 블록 흐름)과 가로 블록 흐름 (왼쪽 혹은 오른쪽 블록 흐름)과 혼동하지 마세요. 혼란을 피하기 위해 CSS 명세에서는 후자의 용어 사용을 피합니다.

문자 체계에는 보통 한 가지 또는 두 가지 고유 작성 모드가 있습니다. 예시:

• 라틴 문자 체계는 일반적으로 왼쪽에서 오른쪽 인라인 방향과 아래쪽(위에서 아래로) 블록 흐름 방향을 사용합니다.
• 아랍 문자 체계는 일반적으로 오른쪽에서 왼쪽 인라인 방향과 아래쪽(위에서 아래로) 블록 흐름 방향을 사용합니다.
• 몽골어 문자 체계는 일반적으로 위에서 아래로 인라인 방향과 오른쪽(왼쪽에서 오른쪽) 블록 흐름 방향을 사용합니다.
• 한자 문자 체계는 일반적으로 왼쪽에서 오른쪽 인라인 방향과 아래쪽(위에서 아래로) 블록 흐름 방향, 또는 위에서 아래로 인라인 방향과 왼쪽(오른쪽에서 왼쪽) 블록 흐름 방향을 사용합니다. 많은 잡지와 신문에서는 이 두 작성 모드를 한 페이지에 혼용합니다.

작성 모드의 text-orientation 구성요소는 글리프 방향을 제어합니다.

작성 모드와 세로 텍스트에 대한 더 깊은 소개는 Unicode Technical Note #22 [UTN22] (HTML 버전)을 참고하세요.

1.1. 모듈 상호작용

이 모듈은 unicode-bidi 및 direction 기능을 [CSS2] 8.6, 9.10절에서 대체 및 확장합니다. 이 기능들이 다른 텍스트 연산과 상호작용하여 텍스트 줄을 설정하는 방식은 CSS Text 3 § 텍스트 처리 순서에서 설명합니다.

계산값은 writing-mode, direction, text-orientation 속성에서(해당 속성이 적용되지 않는 요소에서도 [CSS-CASCADE-4] 참고) 기타 관련 없는 속성의 계산값에도 폭넓게 영향을 줄 수 있습니다. 예를 들어 폰트-상대 길이 계산이나, 흐름-상대 속성의 계단식이 계산된 작성 모드나 폰트 메트릭에 따라 달라질 수 있기 때문입니다. 작성 모드에 따라 달라질 수 있습니다.

1.2. 값 유형 및 용어

이 명세는 CSS 속성 정의 규약 ([CSS2])을 따릅니다. 명세에 정의되지 않은 값 유형은 CSS Values & Units [CSS-VALUES-3]에서 정의됩니다. 다른 CSS 모듈에서 이러한 값 유형의 정의가 확장될 수 있습니다.

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

이 명세서에서 사용하는 주요 용어와 개념은 [CSS2], [CSS-TEXT-3]에 정의되어 있습니다.

2. 인라인 방향과 양방향성

대부분의 문자 체계에서 문자는 왼쪽에서 오른쪽으로 쓰이지만, 일부 문자 체계는 오른쪽에서 왼쪽으로 쓰여집니다. 특히 아랍어나 히브리어 문자, 그리고 일부 혼합 언어 상황에서는 한 (시각적으로 표시된) 블록 내에서 혼합 방향성이 나타날 수 있습니다. 이러한 현상을 양방향성 또는 줄여서 "bidi"라고 합니다.

유니코드 표준(Unicode Standard Annex #9)은 양방향 텍스트의 올바른 정렬을 결정하는 복잡한 알고리즘을 정의합니다. 이 알고리즘은 문자 속성에 기반한 암시적 부분과, 임베딩 및 오버라이드를 위한 명시적 제어로 구성되어 있습니다. CSS는 올바른 양방향 렌더링을 위해 이 알고리즘에 의존합니다.

CSS의 두 속성 direction, unicode-bidi는 CSS 레이어에서 임베딩, 격리, 오버라이드 제어를 제공합니다. 텍스트의 기본 방향성은 문서의 구조와 의미에 따라 달라지므로, direction 및 unicode-bidi 속성은 대부분의 경우 마크업 내의 bidi 정보를 해당 CSS 스타일로 매핑하는 데만 사용해야 합니다.

HTML 명세([HTML401] 8.2절, [HTML] 14.3.5절)은 HTML 요소의 양방향성 동작을 정의합니다.

문서 언어가 bidi 제어를 위한 마크업 기능을 제공한다면, 저자와 사용자는 반드시 해당 기능을 사용해야 하며 CSS 규칙으로 이를 오버라이드해서는 안 됩니다.

2.1. 방향 지정: direction 속성

HTML UA가 CSS 스타일을 끌 수 있으므로, HTML 저자는 올바른 양방향 레이아웃을 보장하기 위해 HTML dir 속성과 <bdo> 요소를 사용할 것을 권장합니다. 저자는 HTML 문서에서 direction을 사용하지 않아야 합니다.

이 속성은 박스가 설정하는 모든 bidi 문단, 임베딩, 격리, 오버라이드의 인라인 기본 방향(방향성)을 지정합니다. (unicode-bidi 참고.) 또한 테이블 열 레이아웃 순서, 수평 overflow 방향, 한 줄 내의 텍스트 기본 정렬 등 박스의 인라인 기본 방향에 의존하는 기타 레이아웃 효과에도 영향을 줍니다.

이 속성의 값 의미:

ltr

이 값은 인라인 기본 방향(bidi 방향성)을 줄-왼쪽에서 줄-오른쪽으로 설정합니다.

rtl

이 값은 인라인 기본 방향(bidi 방향성)을 줄-오른쪽에서 줄-왼쪽으로 설정합니다.

direction 속성은 unicode-bidi 값이 normal인 인라인 박스에서는 양방향 재정렬에 영향을 주지 않습니다. 박스가 양방향 알고리즘에서 추가 임베딩 레벨을 열지 않기 때문입니다.

direction 속성이 테이블 열 박스에 지정된 경우, 열이 문서 트리에서 셀의 상위가 아니므로 셀에는 상속되지 않습니다. 따라서 CSS에서는 [HTML401] 11.3.2.1절에서 설명된 "dir" 속성 상속 규칙을 쉽게 캡처할 수 없습니다.

2.2. 임베딩 및 오버라이드: unicode-bidi 속성

HTML UA가 CSS 스타일을 끌 수 있으므로, HTML 저자는 올바른 양방향 레이아웃을 보장하기 위해 HTML dir 속성, <bdo> 요소, 그리고 텍스트 수준과 그룹 수준 HTML 요소 타입을 적절히 구분하여 사용할 것을 권장합니다. 저자는 HTML 문서에서 unicode-bidi를 사용하지 않아야 합니다.

일반적으로(unicode-bidi가 normal일 때) 인라인 박스는 유니코드 bidi 알고리즘에 투명합니다; 박스의 경계가 존재하지 않는 것처럼 콘텐츠가 정렬됩니다. unicode-bidi 속성의 다른 값은 인라인 박스가 알고리즘 내에서 범위를 생성하게 하며, 텍스트의 고유 방향성을 오버라이드합니다.

다음 안내 표는 unicode-bidi의 박스 내부/외부 효과를 요약합니다:

이 속성의 값 의미(규범):

normal

박스는 양방향 알고리즘에 대해 추가 임베딩 레벨을 열지 않습니다. 인라인 박스의 경우, 암시적 재정렬이 박스 경계를 넘어 동작합니다.

embed

박스가 인라인이면 이 값은 방향 임베딩을 생성하여 양방향 알고리즘에 대해 추가 임베딩 레벨을 엽니다. 임베딩 레벨의 방향은 direction 속성으로 결정됩니다. 박스 내부에서는 암시적으로 재정렬됩니다.

이 값은 인라인이 아닌 박스에서는 효과가 없습니다.

isolate

인라인 박스에서 이 값은 bidi-격리를 수행합니다. 이는 방향 임베딩과 유사하며(임베딩 레벨 증가), 블록 경계나 강제 문단 분리 없이 연속된 인라인 박스 시퀀스 각각을 격리 시퀀스로 처리한다는 점이 다릅니다:

• 시퀀스 내의 콘텐츠는 박스의 direction 속성으로 지정된 기본 방향을 가진 독립 문단처럼 정렬됩니다.
• 포함하는 양방향 문단에서, 시퀀스는 단일 Object Replacement Character(U+FFFC)처럼 취급됩니다.

결과적으로 박스 내부 콘텐츠는 외부 콘텐츠에 의해 양방향 영향을 받지 않고, 박스 외부 콘텐츠도 박스 내부나 지정 방향성에 의해 영향을 받지 않습니다. 단, 박스 내부의 강제 문단 분리는 포함 문단에서도 대응되는 분리를 만듭니다.

이 값은 인라인이 아닌 박스에서는 효과가 없습니다.

bidi-override

이 값은 박스의 즉시 인라인 콘텐츠를 방향 오버라이드로 둡니다. 인라인의 경우, 박스는 양방향 알고리즘에서 방향 임베딩처럼 동작하지만, 내부 재정렬은 direction 속성에 따라 순차적으로만 수행되고, 암시적 알고리즘 부분은 무시됩니다. 블록 컨테이너의 경우, 오버라이드는 모든 콘텐츠를 감싸는 익명 인라인 박스에 적용됩니다.

isolate-override

이 값은 isolation 동작(isolate)과 directional override 동작(bidi-override)을 결합합니다: 주변 콘텐츠에는 isolate와 동일하지만, 박스 내부는 bidi-override가 지정된 것처럼 정렬됩니다. 실질적으로 방향 오버라이드를 격리 시퀀스 안에 중첩합니다.

plaintext

이 값은 isolate와 동일하게 동작하나, 유니코드 양방향 알고리즘에서 박스의 bidi 문단(블록 컨테이너인 경우) 또는 격리 시퀀스(인라인인 경우)의 기본 방향은 유니코드 양방향 알고리즘의 규칙 P2, P3 휴리스틱을 따라 결정되며, 박스의 direction 속성을 사용하지 않습니다.

유니코드 양방향 알고리즘 HL3 절 [UAX9]에 따라, normal이 아닌 값은 해당 유니코드 bidi 제어 코드를 인라인 요소의 시작/끝에 텍스트 스트림에 삽입한 후, 문단을 유니코드 양방향 알고리즘에 전달하여 재정렬합니다. (§ 2.4.2 CSS–유니코드 양방향 제어 변환, 텍스트 재정렬 참고.)

unicode-bidi 속성은 상속되지 않으므로, 블록 박스에 bidi-override나 plaintext를 지정해도 하위 블록에는 영향을 주지 않습니다. 따라서 이 값들은 블록 및 인라인 중 블록 수준 구조를 포함하지 않는 곳에 사용하는 것이 좋습니다.

참고로 unicode-bidi는 direction 속성에 영향을 주지 않으며, plaintext의 경우에도 direction 기반 레이아웃 계산에 영향을 주지 않습니다.

유니코드 알고리즘은 임베딩 125단계 제한이 있으므로, unicode-bidi에서 normal이 아닌 값을 과하게 사용하는 것을 주의해야 합니다. 특히 inherit 값은 깊게 중첩된 인라인 마크업에서 매우 신중히 사용해야 합니다. 하지만 일반적으로 블록으로 표시되는 요소에는 unicode-bidi: isolate 설정을 권장하며, display를 inline으로 변경했을 때도 요소가 함께 유지되도록 할 수 있습니다(아래 예시 참고).

2.3. 양방향 텍스트 예시

다음 예시는 양방향 텍스트가 포함된 XML 문서를 보여줍니다. 중요한 설계 원칙을 설명합니다: 문서 언어 설계자는 언어 자체(요소와 속성)와 관련 스타일 시트 모두에서 양방향성을 반드시 고려해야 합니다. 스타일 시트는 양방향 규칙이 다른 스타일 규칙과 분리되도록 설계되어야 하며, 이러한 규칙은 다른 스타일 시트에 의해 오버라이드되지 않도록 해서 문서 언어의 양방향 동작이 보존되어야 합니다.

<section dir=rtl>
  <para>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</para>
  <para>HEBREW6 <emphasis>HEBREW7</emphasis> HEBREW8</para>
</section>
<section dir=ltr>
  <para>english9 english10 english11 HEBREW12 HEBREW13</para>
  <para>english14 english15 english16</para>
  <para>english17 <quote dir=rtl>HEBREW18 english19 HEBREW20</quote></para>
</section>

/* 양방향성 규칙 */
[dir=rtl] {direction: rtl; unicode-bidi: isolate; }
[dir=ltr] {direction: ltr; unicode-bidi: isolate; }

/* 표현 규칙 */
section, para  {display: block;}
emphasis       {font-weight: bold;}
quote          {font-style: italic;}

               5WERBEH 4WERBEH english3 2WERBEH 1WERBEH

                                8WERBEH 7WERBEH 6WERBEH

english9 english10 english11 13WERBEH 12WERBEH

english14 english15 english16

english17 20WERBEH english19 18WERBEH

       2WERBEH 1WERBEH
  -EH 4WERBEH english3
                 5WERB

   -EH 7WERBEH 6WERBEH
                 8WERB

english9 english10 en-
glish11 12WERBEH
13WERBEH

english14 english15
english16

english17 18WERBEH
20WERBEH english19

2.4. 양방향 재정렬 알고리즘 적용

양방향 텍스트를 지원하는 사용자 에이전트는 블록 경계나 “bidi type B” 강제 문단 분리로 중단되지 않은 인라인 수준 박스의 모든 시퀀스에 대해 유니코드 양방향 알고리즘을 반드시 적용해야 합니다. 이 시퀀스는 양방향 알고리즘의 문단 단위를 형성합니다.

2.4.1. 문단의 양방향 임베딩 레벨

CSS에서는 문단 임베딩 레벨을 반드시 (UAX9 HL1 절에 따라) 유니코드 알고리즘의 단계 P2, P3의 휴리스틱이 아니라, 문단을 포함하는 블록의 direction 속성에 따라 설정해야 합니다.

단, 예외가 하나 있습니다: 문단을 포함하는 블록의 계산된 unicode-bidi가 plaintext인 경우, 유니코드 알고리즘의 P2, P3에서 설명한 휴리스틱이 HL1 오버라이드 없이 사용됩니다. [UAX9] 참고.

2.4.2. CSS–유니코드 양방향 제어 변환, 텍스트 재정렬

각 양방향 문단 내의 문자 최종 순서는 위에서 unicode-bidi에 대해 설명한 대로 양방향 제어 코드가 추가되고, 마크업이 제거된 후, 결과 문자 시퀀스가 일반 텍스트에 대한 유니코드 양방향 알고리즘 구현에 전달되어 스타일된 텍스트와 동일한 줄 바꿈을 생성한 것과 같습니다.

소스 텍스트 내의 양방향 제어 코드도 여전히 존중되며, 문서 트리 구조와 일치하지 않을 수 있습니다. 이는 인라인을 분할하거나 양방향 제어의 시작/끝 페어링을 예상치 못하게 방해할 수 있습니다.

2.4.3. 원자 인라인의 양방향 처리

이 과정에서 치환 요소 중 display: inline인 경우는 중립 문자로 처리합니다. 단, unicode-bidi 속성이 embed 또는 bidi-override이면, 해당 요소는 지정된 direction에 따라 강한 문자로 처리합니다. (치환 요소가 인라인 텍스트 콘텐츠 렌더링으로 폴백될 경우, 주변 텍스트에 대한 양방향 효과가 치환 렌더링과 일관되도록 하기 위함입니다.)

기타 모든 원자 인라인 수준 박스는 항상 중립 문자로 처리합니다.

2.4.4. 임베딩 및 격리 내 문단 분리

인라인 박스가 양방향 문단 경계(예: 블록이나 강제 문단 분리로 분할)에서 끊어진 경우, 박스 끝에 할당된 HL3 양방향 제어 코드도 끊김 전에 추가되고, 박스 시작에 할당된 코드도 끊김 이후에 추가됩니다. (즉, 박스에서 시작된 임베딩 레벨, 격리, 오버라이드는 문단 분리점에서 닫히고 반대편에서 다시 열립니다.)

<para>...<i1><i2>...<BR/>...</i2></i1>...</para>

<para>...<i1><i2>...</i2></i1><BR/><i1><i2>...</i2></i1>...</para>

이 동작은 박스 트리에 적용된 CSS 선언 양방향 제어에 대해 CSS에서 적용되는 것이며, 유니코드의 양방향 서식 제어에는 적용되지 않습니다. 유니코드에서는 양방향 문단 끝에서 효과가 종료되도록 정의되어 있습니다.

2.4.5. 재정렬로 인한 박스 단편화

양방향 재정렬로 인해 논리적으로 연속된 텍스트가 분할되고 재배치될 수 있으므로, 양방향 텍스트는 해당 텍스트를 포함하는 인라인 박스가 분할되어 한 줄 내에서 그 단편들이 재배치될 수 있습니다.

각 줄 박스마다 UA는 각 인라인 박스의 단편을 시각적 순서(논리적 순서 아님)로 마진, 테두리, 패딩을 할당해야 합니다. 첫 줄 박스에서 박스가 등장하는 start쪽 단편이 start 에지의 마진, 테두리, 패딩을 갖고, 마지막 줄 박스에서 박스가 등장하는 end 쪽 단편이 end 에지의 마진, 테두리, 패딩을 갖습니다. 예를 들어 horizontal-tb 작성 모드에서는:

• 부모의 direction 속성이 ltr인 경우, 첫 줄 박스의 가장 왼쪽 단편이 왼쪽 마진, 테두리, 패딩을 갖고, 마지막 줄 박스의 가장 오른쪽 단편이 오른쪽 패딩, 테두리, 마진을 갖는다.
• 부모의 direction 속성이 rtl인 경우, 첫 줄 박스의 가장 오른쪽 단편이 오른쪽 패딩, 테두리, 마진을 갖고, 마지막 줄 박스의 가장 왼쪽 단편이 왼쪽 마진, 테두리, 패딩을 갖는다.

수직 작성 모드도 유사한 규칙이 적용됩니다.

box-decoration-break 속성은 이 동작을 오버라이드하여 각 단편 양쪽에 박스 장식을 그릴 수 있습니다. [CSS3-BREAK]

3. 수직 작성 모드

양방향 텍스트에 대한 CSS2.1 확장 외에도, 이 모듈은 CSS에서 수직 텍스트 레이아웃을 지원하는 데 필요한 규칙과 속성을 소개합니다.

3.1. 수직 작성 소개

이 하위절은 비규범적입니다.

주로 수평으로 배치되는 라틴 문자를 사용하는 언어와 달리, 중국어와 일본어 같은 아시아 언어는 수직으로도 배치할 수 있습니다. 아래 일본어 예시는 동일한 텍스트가 수평과 수직으로 배치된 모습을 보여줍니다. 수평의 경우 텍스트는 왼쪽에서 오른쪽, 위에서 아래로 읽습니다. 수직의 경우 텍스트는 위에서 아래로, 오른쪽에서 왼쪽으로 읽습니다. 왼쪽-오른쪽 수평 케이스에서 왼쪽 가장자리로부터의 들여쓰기는, 위에서 아래로 수직 케이스에서는 위쪽 가장자리로부터의 들여쓰기로 변환됩니다.

중국어와 일본어는 줄이 오른쪽에서 왼쪽 또는 위에서 아래로 정렬되지만, 몽골어와 만주어는 줄이 왼쪽에서 오른쪽으로 정렬됩니다.

수평에서 수직 작성으로의 변화는 레이아웃뿐 아니라 조판에도 영향을 줄 수 있습니다. 예를 들어, 구두점의 위치가 수평과 수직 케이스에서 다를 수 있고, 경우에 따라 대체 글리프가 사용됩니다.

수직 텍스트에 라틴 문자나 일반적으로 수평으로 표시되는 다른 문자가 포함된 경우, 해당 텍스트를 여러 방식으로 표시할 수 있습니다. 예를 들어, 라틴어 단어를 옆으로 회전시키거나, 각 문자를 똑바로 세울 수도 있습니다:

날짜의 두 자리 숫자처럼 특수한 경우에는 텍스트가 단일 수직 문자 박스에 조밀하게 들어갑니다:

레이아웃에는 수직과 수평 요소가 혼합되는 경우가 많습니다:

수직 텍스트 레이아웃에서도 양방향 텍스트 레이아웃을 처리해야 합니다; 예를 들어 시계 방향 회전된 아랍어는 아래에서 위로 배치됩니다.

3.2. 블록 흐름 방향: writing-mode 속성

이 속성은 텍스트 줄이 수평 또는 수직으로 배치되는지, 블록이 진행되는 방향을 지정합니다. 가능한 값:

horizontal-tb

위에서 아래로 블록 흐름 방향. 작성 모드와 타이포그래픽 모드 모두 수평입니다.

vertical-rl

오른쪽에서 왼쪽 블록 흐름 방향. 작성 모드와 타이포그래픽 모드 모두 수직입니다.

vertical-lr

왼쪽에서 오른쪽 블록 흐름 방향. 작성 모드와 타이포그래픽 모드 모두 수직입니다.

writing-mode 속성은 블록 흐름 방향을 지정하며, 이는 블록 포매팅 컨텍스트에서 블록 수준 박스의 정렬 방향, 인라인을 포함하는 블록 컨테이너에서 줄 박스의 정렬 방향, 테이블의 행 정렬 방향 등을 결정합니다. 줄 박스의 쌓이는 방향을 결정하는 특성상, writing-mode 속성은 줄 박스의 방향(즉 작성 모드)이 수평 또는 수직인지도 결정합니다. text-orientation 속성이 줄 박스 내 텍스트 레이아웃 방식을 결정합니다.

치환 요소의 콘텐츠는 writing-mode에 따라 회전되지 않습니다: 예를 들어 이미지나 <iframe> 등의 외부 콘텐츠는 똑바로 유지되며, 300px×150px의 기본 객체 크기도 방향이 변경되지 않습니다. 단, 텍스트가 포함된 치환 콘텐츠(MathML 콘텐츠, 폼 요소 등)는 UA가 해당 치환 콘텐츠에 대해 수직 작성 모드를 지원한다면 치환 요소의 작성 모드와 줄 방향에 맞춰 렌더링되어야 합니다.

<style>
  form { writing-mode: vertical-rl; }
</style>
...
<form>
<p><label>姓名　<input value="艾俐俐"></label>
<p><label>语言　<select><option>English
                       <option>français
                       <option>فارسی
                       <option>中文
                       <option>日本語</select></label>
</form>

박스가 부모 박스(즉 display: contents가 아닌 가장 가까운 상위)와 다른 writing-mode 값을 갖는 경우:

• 박스가 in-flow 박스가 되고, display가 inline으로 계산될 경우, display는 대신 inline-block으로 계산됩니다.
• 박스가 block container라면, 독립적인 블록 포매팅 컨텍스트를 설정합니다.
• 더 일반적으로, 지정된 내부 display type이 flow라면, 계산된 내부 display type은 flow-root가 됩니다. [CSS-DISPLAY-3]

svg { writing-mode: initial; }

3.2.1. 폐기된 SVG1.1 writing-mode 값

SVG1.1 [SVG11]에서는 lr, lr-tb, rl, rl-tb, tb, tb-rl과 같은 추가 값을 정의합니다.

이 값들은 SVG1 문서 이외의 모든 상황에서는 폐기됨이며, 비SVG UA에서는 선택적입니다.

3.2.1.1. CSS 문법에서 SVG1.1 writing-mode 값 지원

이 값들을 CSS 문맥에서 지원하려는 UA는 아래와 같이 계산해야 합니다:

SVG1.1 값들은 CSS writing-mode 명세의 과거 버전에도 있었으나, 이 명세에 의해 폐기되었습니다. 그 버전의 추가 값 tb-lr은 vertical-lr로 대체되었습니다.

3.2.1.2. 프레젠테이션 속성에서 SVG1.1 writing-mode 값 지원

레거시 콘텐츠의 프레젠테이션 속성을 지원하고, 저자가 이전 클라이언트까지 지원하는 문서를 만들 수 있게 하려면, SVG UA는 기본 UA 스타일시트에 아래 스타일 규칙을 추가해야 합니다:

@namespace svg "http://www.w3.org/2000/svg";
svg|*[writing-mode=lr], svg|*[writing-mode=lr-tb],
svg|*[writing-mode=rl], svg|*[writing-mode=rl-tb] {
  writing-mode: horizontal-tb; }
svg|*[writing-mode=tb], svg|*[writing-mode=tb-rl] {
  writing-mode: vertical-rl; }

svg|text { writing-mode: tb; writing-mode: vertical-rl; }

4. 인라인 수준 정렬

한 줄에 여러 종류의 인라인 콘텐츠가 함께 배치될 때, 콘텐츠의 기준선과 vertical-align 속성 설정이 줄 박스의 교차 방향에서 어떻게 정렬되는지를 제어합니다. 이 절에서는 기준선이 무엇인지, 어떻게 찾는지, 그리고 vertical-align 속성과 함께 인라인 콘텐츠의 정렬을 어떻게 결정하는지 설명합니다.

4.1. 기준선 소개

이 절은 비규범적입니다.

기준선은 줄 박스의 인라인 축을 따라, 개별 글리프가 정렬되는 선입니다. 기준선은 폰트 디자인의 지침이 되며(예를 들어 알파벳 글리프 대부분은 알파벳 기준선에 맞춰 하단이 정렬됨), 서로 다른 폰트나 크기의 글리프도 조판 시 기준선을 따라 정렬됩니다.

문자 체계마다 선호하는 기준선 테이블이 다릅니다.

잘 설계된 폰트에는 기준선 테이블이 포함되어 있으며, 폰트 디자인 좌표 공간 내 하나 이상의 기준선 위치를 나타냅니다. (디자인 좌표 공간은 폰트 크기에 따라 스케일됨.)

기준선 테이블은 폰트의 속성이며, 다양한 기준선의 위치는 폰트 내 모든 글리프에 적용됩니다.

수평 및 수직 텍스트 정렬을 위해 서로 다른 기준선 테이블을 제공할 수 있습니다. UA는 수직 타이포그래픽 모드에서는 수직 테이블을, 그 외에는 수평 테이블을 사용해야 합니다.

4.2. 텍스트 기준선

이 명세에서는 아래 기준선만 다룹니다:

alphabetic

알파벳 기준선은 일반적으로 라틴 대문자 글리프의 하단에 맞춰집니다.

central

중앙 기준선은 일반적으로 em 박스의 중앙을 가로지릅니다. 폰트에 이 기준선이 없으면, em 박스의 상승부(over)와 하강부(under) 에지의 중간으로 간주합니다.

수직 타이포그래픽 모드에서, 중앙 기준선이 text-orientation이 mixed 또는 upright일 때 지배적 기준선이 됩니다. 그렇지 않으면 알파벳 기준선이 사용됩니다.

향후 CSS 모듈에서 기준선을 더 자세히 다루고, 다른 지배적 기준선과 정렬 옵션도 선택할 수 있도록 할 예정입니다.

4.3. 원자 인라인 기준선

원자 인라인(예: inline-block, inline-table, 치환 인라인 요소)에 기준선이 없는 경우, UA는 다음과 같이 기준선 테이블을 합성합니다:

alphabetic

알파벳 기준선은 under 마진 에지에 있다고 간주합니다.

central

중앙 기준선은 박스의 under와 over 마진 에지의 중간에 있다고 간주합니다.

vertical-align 속성은 [CSS2]에서 inline-table, inline-block 박스 기준선을 예외와 함께 정의합니다.

4.4. 기준선 정렬

지배적 기준선(타이포그래픽 모드에 따라 변경될 수 있음)은 CSS에서 두 가지 정렬 상황에 사용됩니다:

• 동일 인라인 박스 내 서로 다른 폰트의 글리프 정렬. 글리프는 각 폰트의 지배적 기준선 위치를 맞추어 정렬됩니다.
• 부모 내 자식 인라인 박스 정렬. vertical-align 값이 baseline일 때, 부모의 지배적 기준선을 자식의 동일 기준선에 맞춰 정렬합니다. (예: 부모 기준선이 알파벳 기준선이면, 자식의 알파벳 기준선을 부모와 맞춥니다. 자식의 지배적 기준선이 다르더라도.) sub, super, <length>, <percentage> 값의 경우도 baseline과 같이 기준선 정렬하지만, 자식은 vertical-align 값에서 지정한 오프셋만큼 이동합니다.

  예시 마크업:

  <p><span class="outer">Ap <span class="inner">ji</span></span></p>

  그리고 스타일 규칙:

  span.inner { font-size: .75em; }

  부모(.outer)와 자식(.inner)의 기준선 테이블은 폰트 크기 차이로 맞지 않습니다. 지배적 기준선이 알파벳 기준선이므로, 자식 박스는 부모와 알파벳 기준선을 맞추어 정렬됩니다.

  

  위 예시에서 .inner 요소에 vertical-align: super를 지정하면, 동일한 규칙으로 부모에 자식이 정렬됩니다. 차이점은 기준선 정렬에 더해 자식이 위 첨자 위치로 이동한다는 점입니다.

  span.inner { vertical-align: super; font-size: .75em; }

  

5. 세로 텍스트 레이아웃 소개

각 문자 체계는 하나 이상의 고유 방향성을 가집니다. 현대 문자 체계는 따라서 세 가지 방향성 범주로 분류할 수 있습니다:

horizontal-only

수평 방향만 고유 방향으로 갖는 문자 체계. 예시: 라틴, 아랍어, 히브리어, 데바나가리

vertical-only

수직 방향만 고유 방향으로 갖는 문자 체계. 예시: 몽골어, 파스파 문자

bi-orientational

수직과 수평 모두 고유 방향을 갖는 문자 체계. 예시: 한자, 한글, 일본어 가나

세로 문자란 고유의 수직 방향을 갖는 문자 체계입니다: 즉, vertical-only이거나 bi-orientational인 경우입니다. 가로 문자란 고유의 수평 방향을 갖는 문자 체계입니다: 즉, horizontal-only이거나 bi-orientational입니다. (문자 체계별 고유 방향 분류는 부록 A 참고)

현대 타이포그래픽 시스템에서는 모든 글리프가 수평 방향을 할당받으며, 이는 텍스트를 수평으로 배치할 때 사용됩니다. 세로 텍스트를 배치하려면, UA가 텍스트의 수평 방향을 변환해야 합니다. 이 변환을 방향 변환이라 하며, 두 가지 유형이 있습니다:

rotate

글리프를 수평에서 수직으로 회전

translate

글리프를 수평에서 수직으로 변환

고유의 수직 방향을 갖는 문자 체계는 내재된 방향 변환을 가지고 있어, 세로 텍스트에서 올바르게 배치됨: 대부분의 CJK(중국어/일본어/한국어) 문자는 변환(translate)되어 항상 똑바로 세워짐. 몽골어 같은 다른 문자 체계는 회전됨.

고유의 수직 방향이 없는 문자 체계는 회전(옆으로 놓기) 또는 변환(똑바로 세우기) 둘 다 가능함: 어떤 변환이 쓰이는지는 텍스트 용도에 따른 스타일 선호이지, 올바름의 문제는 아님. text-orientation 속성의 mixed와 upright 값을 사용하여 horizontal-only 텍스트의 회전과 변환을 지정할 수 있습니다.

5.1. 텍스트 방향 지정: text-orientation 속성

이 속성은 한 줄 내에서 텍스트의 방향을 지정합니다. 현재 값들은 오직 수직 타이포그래픽 모드에서만 효과가 있습니다: 속성은 수평 타이포그래픽 모드 박스에는 영향을 주지 않습니다.

값의 의미는 다음과 같습니다:

mixed

수직 작성 모드에서, 타이포그래픽 문자 단위 중 horizontal-only 문자 체계는 옆으로 조판됩니다. 즉, 수평 텍스트의 표준 방향에서 시계 방향 90° 회전됩니다. 타이포그래픽 문자 단위 중 세로 문자 체계는 고유 방향을 유지하여 조판됩니다. 자세한 내용은 Vertical Orientations 참조.

이 값은 주로 세로 문자 중심 텍스트 레이아웃에 사용됩니다.

upright

수직 작성 모드에서 타이포그래픽 문자 단위 중 horizontal-only 문자 체계는 똑바로 조판됩니다, 즉 수평 텍스트의 표준 방향 그대로입니다. 타이포그래픽 문자 단위 중 세로 문자 체계는 고유 방향대로 조판되며, 일반적으로 형태가 유지됩니다. 자세한 내용은 Vertical Orientations 참조.

이 값은 사용 값의 direction을 ltr로 만듭니다. 양방향 재정렬 목적상 모든 문자를 강한 LTR로 처리합니다.

참고: 사용 값이 계산 값이 아니라, direction에 영향을 주므로 rtl이 이 방향 오버라이드가 적용되지 않는 하위 요소(예: 수평 inline-block)의 내용 등에도 올바르게 상속될 수 있습니다.

sideways

수직 작성 모드에서는 모든 텍스트가 옆으로 조판되어, 수평 레이아웃처럼 보이지만 시계 방향 90° 회전됩니다.

mixed	upright	sideways

text-orientation 값 (writing-mode가 vertical-rl일 때)

이 속성의 값을 변경하면 인라인 수준 정렬에 영향을 줄 수 있습니다. 자세한 내용은 텍스트 기준선을 참고하세요.

UA는 sideways-right 값을 필요 시 sideways로 계산할 수 있습니다(호환성 목적).

.vertical-upright-hebrew {
    writing-mode: vertical-rl;
    text-orientation: upright;
    unicode-bidi: bidi-override;
    direction: ltr;
}

5.1.1. 세로 조판과 폰트 기능

vertical-rl, vertical-lr 모드에서 텍스트를 조판할 때, 텍스트는 아래에서 정의된 "upright" 또는 "sideways"로 조판됩니다:

upright 조판

타이포그래픽 문자 단위는 세로 줄에서 개별적으로 똑바로 조판되고, 세로 폰트 메트릭을 사용합니다. UA는 해당 폰트에 세로 메트릭이 없다면 이를 합성해야 합니다. (이 명세는 그런 메트릭 합성 휴리스틱을 정의하지 않습니다.) 또한, 세로 조판을 위한 폰트 기능(대체 글리프 등)도 함께 사용해야 합니다. (예: OpenType vert 기능을 반드시 활성화해야 합니다.) 더불어, 수평 필기체 문자(아랍어 등)는 똑바로 조판할 때 고립 형태로 모양이 변형됩니다.

"upright"로 조판되어도, 일부 글리프는 회전되어야 할 수 있습니다. 예를 들어 대시, 괄호 등은 인라인 축 기준으로 방향이 맞춰져야 합니다. OpenType에서는 글리프 치환으로 처리하지만, 모든 폰트에 모든 코드포인트에 대한 대체 글리프가 있진 않습니다. (동아시아 폰트는 동아시아 코드에 대해 대체를 제공하지만, 서양 폰트는 세로 조판 기능이 거의 없고, 동아시아 폰트도 서양 코드 대체는 거의 없음.) Unicode는 SVO 속성으로 어떤 문자가 옆으로 보여야 할지 임시 데이터(이 데이터 파일)를 공개했지만, 이 속성은 [UAX50]의 현 개정에서는 폐기됨.

타이포그래픽 문자 단위가 [UAX50]에서 Tr 또는 Tu로 분류되면, 세로 텍스트에서 똑바로 조판할 때 대체 글리프나 위치가 있어야 합니다. Tr 문자의 경우, 폰트에 세로 대체 글리프가 없다면, UA는 [RFC6919]에 따라(필수는 아님) 옆으로 조판 등으로 부족한 글리프를 합성할 수 있습니다.

sideways 조판

타이포그래픽 문자 단위가 한 번에 옆으로, 즉 똑바로일 때에서 시계 방향 90° 회전되어 조판되며, 수평 메트릭과 조합을 사용하고, 세로 조판 기능은 사용하지 않습니다. 단, 폰트가 세로 줄에서 옆으로 조판해야 할 때 활성화할 기능(붓 스트로크 각도, 정렬 등)을 제공한다면, 그 기능을 사용해야 합니다. (예시: OpenType vrtr 기능 제안 )

5.1.2. 혼합 세로 방향

[UAX50]은 혼합 방향의 세로 텍스트에서 기본 글리프 방향을 위한 Vertical_Orientation 속성을 정의합니다. text-orientation이 mixed일 때, UA는 각 타이포그래픽 문자 단위의 Vertical_Orientation 속성에 따라 방향을 결정해야 합니다: 속성이 U, Tu, Tr인 경우 똑바로 조판; 속성이 R인 경우 옆으로 조판(수평에서 시계방향 90° 회전)합니다.

UAX50은 세로 컨텍스트에서 -90°로 회전하는 문자 체계를 처리하지 않으므로, mixed 방향에서는 올바르게 조판되지 않습니다. sideways-lr 값은 Level 4에서 이러한 문자 체계를 올바르게 표시할 수 있습니다.

혼합 방향 조판을 위한 OpenType vrt2 기능은 CSS에서 사용되지 않습니다. 글리프 방향 지정 책임을 폰트 디자이너에게 위임합니다. CSS는 [UAX50]을 통해 방향을 지정하며 글리프를 옆으로 또는 똑바로 조판합니다.

5.1.3. 폐기됨: SVG1.1 glyph-orientation-vertical 속성

일부 SVG 사용자 에이전트는 폐기된 SVG glyph-orientation-vertical 속성을 포함한 문서를 처리해야 하며, 이 속성은 auto 키워드와, <angle> 및 <integer> 값(90°의 배수)도 허용하도록 정의되었습니다. 이 속성을 지원하는 것은 선택적이지만, 지원하는 UA는 glyph-orientation-vertical을 text-orientation의 약어로 다음과 같이 취급해야 합니다:

UA는 glyph-orientation-vertical 속성의 기타 값은 모두 무시하고 잘못된 값으로 처리해야 하며, glyph-orientation-horizontal 속성 전체도 잘못된 것으로 처리해야 합니다.

참고: 180deg, 270deg 값, radian과 gradian 값, 그리고 glyph-orientation-horizontal 속성은 알려진 사용 사례나 의존 콘텐츠가 없으므로 CSS의 일부가 아니며, SVG에서도 마찬가지로 제외되었습니다.

6. 추상 박스 용어

CSS2.1 [CSS2]는 CSS의 박스 레이아웃 모델을 horizontal-tb 작성 모드만 상세히 정의합니다. 다른 작성 모드의 레이아웃도 유사하지만, CSS2.1의 방향/차원 용어는 추상화되어 적절히 다시 매핑되어야 합니다.

이 절에서는 박스 레이아웃을 다른 작성 모드에도 정의하고, 향후 명세에서 추상적으로 레이아웃 개념을 정의할 용어를 제공하기 위해 추상 방향/차원 용어와 그 매핑을 정의합니다. (다음 절에서는 이를 CSS2.1의 레이아웃 계산에 적용하는 방법과 직교 흐름 처리 방법을 설명합니다.) 이러한 추상 매핑은 텍스트의 동작에서 유래하지만, 줄 박스를 포함하지 않는 박스에도 존재하며: writing-mode, direction 속성 값에서 직접 계산됩니다.

CSS에는 방향 용어가 세 가지 집합이 있습니다:

물리적

작성 모드와 독립적으로 페이지를 기준으로 해석됩니다. 물리적 방향은 left, right, top, bottom입니다.

흐름-상대

콘텐츠 흐름을 기준으로 해석됩니다. 흐름-상대 방향은 start와 end, 또는 차원이 모호한 경우 block-start, block-end, inline-start, inline-end입니다.

줄-상대

줄 박스 방향을 기준으로 해석됩니다. 줄-상대 방향은 line-left, line-right, line-over, line-under입니다.

물리적 차원은 width와 height이며, 각각 x축(수평 차원), y축(수직 차원)에 해당합니다. 추상 차원은 흐름-상대/줄-상대 용어 모두에서 동일하므로 이 용어 집합은 하나만 있습니다.

참고: [CSS3-FLEXBOX]에서도 flex-상대 용어를 정의하여 flex 레이아웃 설명에 사용합니다.

6.1. 추상 차원

추상 차원은 아래와 같이 정의됩니다:

block 차원

한 줄 내 텍스트 흐름에 수직인 차원. 즉, 수평 작성 모드에서는 수직 차원, 수직 작성 모드에서는 수평 차원.

inline 차원

한 줄 내 텍스트 흐름과 평행한 차원. 즉, 수평 작성 모드에서는 수평 차원, 수직 작성 모드에서는 수직 차원.

block 축

block 차원의 축. 즉, 수평 작성 모드에서는 y축, 수직 작성 모드에서는 x축.

inline 축

inline 차원의 축. 즉, 수평 작성 모드에서는 x축, 수직 작성 모드에서는 y축.

block 크기

논리적 높이

block 차원의 측정값: 수평 작성 모드에서는 물리적 높이(수직 차원), 수직 작성 모드에서는 물리적 너비(수평 차원)를 의미합니다.

inline 크기

논리적 너비

inline 차원의 측정값: 수평 작성 모드에서는 물리적 너비(수평 차원), 수직 작성 모드에서는 물리적 높이(수직 차원)를 의미합니다.

6.2. 흐름-상대 방향

흐름-상대 방향, block-start, block-end, inline-start, inline-end는 페이지 콘텐츠의 흐름을 기준으로 정의됩니다. LTR horizontal-tb 작성 모드에서는 각각 위, 아래, 왼쪽, 오른쪽에 해당합니다. 정의는 다음과 같습니다:

block-start

block 흐름 방향에서 먼저 오는 쪽. writing-mode 속성에 따라 결정: horizontal-tb에서는 물리적 top, vertical-rl에서는 오른쪽, vertical-lr에서는 왼쪽.

block-end

block-start의 반대쪽.

inline-start

인라인 기본 방향에서 텍스트가 시작되는 쪽. direction 값이 ltr일 때는 line-left 쪽. direction 값이 rtl일 때는 line-right 쪽.

inline-end

start의 반대쪽.

맥락상 모호하지 않거나 두 의미 모두 포함할 때, start와 end를 block-start/inline-start, block-end/inline-end 대신 사용합니다.

박스의 block-start와 block-end를 결정하는 것은 writing-mode 속성에만 의존하지만, inline-start와 inline-end는 writing-mode뿐 아니라 direction 속성도 참조합니다.

6.3. 줄-상대 방향

줄 방향은 한 줄 박스에서 논리적 "위"(상승부 방향)가 어느 쪽인지 결정합니다. writing-mode 속성으로 결정됩니다. 일반적으로 줄-상대 "위"는 block-start 쪽과 일치하지만, 항상 그런 것은 아닙니다: 몽골어 조판(즉 vertical-lr 작성 모드)에서는 줄-상대 "위"가 block-end 쪽과 일치합니다. 그래서 구분된 용어가 필요합니다.

위와 같은 몽골어 중심 문서는 수직 줄이 왼쪽에서 오른쪽으로 쌓이지만, 라틴 텍스트의 위쪽이 오른쪽을 향합니다. 즉, 텍스트가 몽골어(위에서 아래)와 같은 인라인 방향으로 흐르고, 다른 동아시아 레이아웃(수직 줄이 오른쪽에서 왼쪽으로 쌓임)과 같은 방향을 가집니다. 하지만 글리프의 위쪽은 줄 스택의 아래쪽을 향해, 영어 단락에서는 뒤집어진 형태가 됩니다. (몽골어 텍스트 레이아웃 다이어그램 참고)

줄-상대 "위"와 "아래"는 'vertical-align: top' 등의 매핑에 필요하며, CSS에서는 'text-align: left' 등의 매핑을 위해 줄-상대 "왼쪽"과 "오른쪽"도 필요합니다. 따라서 줄-상대 방향이 네 가지 있으며, 줄 방향 기준으로 다음과 같이 정의됩니다:

over 또는 line-over

명목상 줄 박스의 상승부, 즉 "위"쪽. (overline이 보통 그려지는 쪽.)

under 또는 line-under

over의 반대쪽: 줄-상대 "아래" 또는 하강부. (underline이 보통 그려지는 쪽.)

line-left

줄 박스의 줄-상대 "왼쪽" 쪽. 명목상 LTR 텍스트가 시작되는 쪽.

line-right

줄 박스의 줄-상대 "오른쪽" 쪽. 명목상 RTL 텍스트가 시작되는 쪽. (line-left의 반대쪽.)

물리적/줄-상대 방향 간 정확한 매핑은 아래 표 참고.

horizontal-tb에서의 줄 방향

vertical-rl, vertical-lr에서의 줄 방향

6.4. 추상-물리적 매핑

아래 표는 추상-물리적 매핑을 요약합니다 (사용된 direction, writing-mode 기준):

참고: used direction은 계산된 writing-mode, text-orientation에 따라 달라집니다: vertical writing modes에서, text-orientation 값이 upright이면 used direction이 ltr로 강제됩니다.

7. 추상 박스 레이아웃

7.1. 수직 작성 모드 레이아웃의 원칙

수직 작성 모드에서의 CSS 박스 레이아웃은 수평 작성 모드의 레이아웃과 유사하며, 아래 원칙을 따릅니다:

수평 작성 모드에서 수평 차원에 적용되는 레이아웃 계산 규칙(CSS2.1 10.3절 등)은 수직 작성 모드에서는 수직 차원에 적용됩니다. 마찬가지로, 수평 작성 모드에서 수직 차원에 적용되는 레이아웃 계산 규칙(CSS2.1 10.6절 등)은 수직 작성 모드에서는 수평 차원에 적용됩니다. 즉:

• width를 참조하는 레이아웃 규칙은 height를 대신 사용하고, 반대도 마찬가지입니다.

• *-left 및 *-right 박스 속성(border, margin, padding, 위치 오프셋)을 참조하는 레이아웃 규칙은 *-top 및 *-bottom을 대신 사용하고, 반대도 마찬가지입니다. 이는 CSS2.1의 수평 작성 모드 규칙을 흐름-상대 방향을 사용하여 수직 작성 모드 규칙으로 매핑합니다. 이 속성이 적용되는 박스의 방향 자체는 바뀌지 않고, 어떤 값이 어떤 레이아웃 계산에 입력되는지만 달라집니다. 예를 들어 margin-left 속성은 여전히 왼쪽 마진에 영향을 주지만, vertical-rl 작성 모드에서는 margin-bottom 대신 margin-left가 margin-collapsing에 참여합니다.

• direction 속성을 기준으로 left/right를 선택하는 레이아웃 규칙(예: 오버플로우, 제약 해소, text-align의 초기값, 테이블 열 순서 등)은 추상적으로 start 및 end 쪽으로 변환되어 적절히 적용됩니다.

텍스트 정렬, 플로팅, 목록 마커 위치 등 주로 줄 박스의 왼쪽/오른쪽이나 그와 평행한 방향을 참조하며 위/아래 대응이 없는 기능에서는, line-left와 line-right를 각각 왼쪽/오른쪽 참조로 사용합니다.

밑줄, 윗줄, 기준선 정렬(vertical-align) 등 주로 줄 박스의 위/아래 또는 그와 교차하는 방향을 참조하며 왼쪽/오른쪽 대응이 없는 기능에서는, line-over와 line-under를 각각 위/아래 참조로 사용합니다.

이러한 매핑의 자세한 내용은 아래에 설명합니다.

7.2. 차원 매핑

특정 속성은 다음과 같이 논리적으로 동작합니다:

• border-spacing 속성의 첫 번째, 두 번째 값은 각각 열과 행 간격을 의미하며, 반드시 수평/수직 간격은 아닙니다. [CSS2]
• line-height 속성은 항상 논리적 높이를 의미합니다. [CSS2]

height, min-height, max-height 등의 height 속성은 물리적 높이를, width, min-width, max-width 등의 width 속성은 물리적 너비를 의미합니다. 하지만, 박스 크기와 위치 계산 규칙은 논리적으로 적용됩니다.

예를 들어, CSS2.1 10.3절의 계산 규칙은 인라인 차원 측정에 사용되며: inline 크기 (이는 물리적 너비 또는 높이일 수 있음)와 inline-start, inline-end 마진, 패딩, 테두리에 적용됩니다. 마찬가지로 CSS2.1 10.6절의 계산 규칙은 블록 차원에 사용되며: block 크기, block-start, block-end 마진, 패딩, 테두리에 적용됩니다. [CSS2]

따라서 margin과 padding 속성의 백분율은 CSS2.1에서 항상 포함 블록의 너비 기준으로 계산되지만, CSS3에서는 포함 블록의 inline 크기 기준으로 계산됩니다.

7.3. 직교 흐름

박스가 포함 블록과 다른 writing-mode를 갖는 경우 두 가지가 가능합니다:

• 두 작성 모드가 평행한 경우(예: vertical-rl과 vertical-lr).
• 두 작성 모드가 수직인 경우(예: horizontal-tb와 vertical-rl).

박스가 포함 블록과 수직인 작성 모드를 갖는 경우, 직교 흐름에 있다고 하거나, 직교 흐름을 설정한다고 합니다.

이 경우를 처리하기 위해 CSS 레이아웃 계산은 박스의 크기 결정과 흐름 내 위치 결정의 두 단계로 나뉩니다.

• 크기 결정 단계(박스의 너비와 높이 계산)에서는 박스와 포함 블록의 차원이 inline 크기와 block 크기로 매핑되며, 박스가 직교 흐름을 설정하는 작성 모드를 기준으로 계산합니다.
• 위치 결정 단계(박스의 위치 오프셋, 마진, 테두리, 패딩 계산)에서는 박스와 포함 블록의 차원이 inline 크기와 block 크기로 매핑되며, 박스가 직교 흐름을 설정할 때는 포함 블록의 작성 모드로 계산합니다.

auto 마진은 포함 블록의 작성 모드에 따라 처리되므로, 직교 흐름을 설정하는 박스는 크기가 결정된 후에도 다른 블록 수준 박스처럼 auto 마진으로 포함 블록 내에서 정렬/가운데 정렬할 수 있습니다.

7.3.1. 직교 흐름의 사용 가능한 공간

CSS에서는 포함 블록이 명확한 inline 크기는 있지만, 명확한 block 크기는 없는 경우가 흔합니다. 이는 보통 CSS2.1에서 포함 블록이 auto height일 때 발생하며, 예를 들어 width는 10.3.3에서 계산되지만, block 크기는 콘텐츠에 따라 달라집니다. 이런 경우 사용 가능한 inline 공간은 포함 블록의 inline 크기로 정의됩니다; 하지만 사용 가능한 block 공간(즉, 포함 블록의 block 크기)은 무한대로 간주됩니다.

박스를 직교 흐름에 놓으면 반대 현상이 발생할 수 있습니다: 박스의 사용 가능한 block 공간은 명확해지지만, 사용 가능한 inline 공간은 불명확해질 수 있습니다. 이런 경우 포함 블록의 inline 크기의 퍼센트 값을 정의할 수 없으며, inline 축 계산도 불가능합니다. 이런 경우, 계산에 명확한 사용 가능한 inline 공간이 필요한 경우 대체 크기를 사용 가능한 inline 공간 대신 사용합니다: 이 크기는 아래 중 가장 작은 값입니다.

• 포함 블록의 내부 최대 크기(이 값이 고정일 때)에서 내부 최소 크기(이 값이 고정일 때)를 내림하여 결정
• 가장 가까운 상위 scrollport의 내부 크기(고정일 때), 아니면 내부 최대 크기(고정일 때)로 제한, 내부 최소 크기(고정일 때)로 내림
• 초기 포함 블록의 크기

CSS 크기 관련 용어와 개념의 자세한 내용은 [css-sizing-3]를 참고하세요.

7.3.2. 직교 흐름 루트의 자동 크기 조정

inline 축 자동 크기는 블록 수준 또는 블록 컨테이너 직교 흐름에서 (선호 크기 속성이 auto일 때 사용하는 크기) fit-content 크기로 계산됩니다. 즉, min(max-content inline size, max(min-content inline size, stretch-fit inline size) 여기서 사용 가능한 공간은 stretch-fit inline size 계산 시 포함 블록의 크기(명확할 경우) 또는 위에서 정의한 대체 크기입니다.

자동 크기 조정은 직교 다단 컨테이너(양 축 모두) 및 위에서 언급되지 않은 기타 display 타입에 대해서는 본 명세에서 정의하지 않습니다.

참고: CSS Writing Modes Level 4도 참고하세요.

7.3.3. 직교 흐름 단편화

이 절은 안내(설명)입니다.

단편화와 관련하여, CSS2.1의 규칙은 수직 작성 모드와 직교 흐름에서도 그대로 적용됩니다: 줄 박스 내부에서는 분할 지점이 발생하지 않고, 줄 박스 사이에서만 발생합니다. [CSS3COL]을 지원하는 UA는 (폭이 0일 수도 있는) 열 사이 간격에서 분할할 수 있습니다.

콘텐츠가 루트 요소에서 설정된 페이지네이션 스트림을 벗어나면, UA가 해당 콘텐츠를 인쇄할 필요는 없습니다. 작성자가 여러 작성 모드와 긴 텍스트 스트림을 혼합하고 싶다면, 모든 콘텐츠가 문서의 페이지네이션 방향으로 흐르도록 CSS columns를 사용하는 것이 좋습니다.

7.4. 흐름-상대 매핑

흐름-상대 방향은 박스의 포함 블록의 작성 모드를 기준으로 계산되며, 레이아웃 규칙(마진, 테두리, 패딩) 및 박스의 포함 블록 내 위치 지정과 관련된 속성(float, clear, top, bottom, left, right, caption-side)을 추상화하는 데 사용됩니다. 인라인 수준 박스의 경우 부모 박스의 작성 모드를 대신 사용합니다. (left/right/top/bottom 이름의 속성과 값 자체는 여전히 물리적으로 매핑되며, caption-side만 특별 예외로, top/top-outside와 bottom/bottom-outside 값은 각각 테이블의 block-start와 block-end 쪽에 연결됩니다.)

예를 들어, 박스의 인라인 차원이 제약 초과일 때 삭제되는 마진은 포함 블록의 작성 모드 기준 end 마진입니다.

margin collapsing 규칙은 block-start 마진을 top 마진 대신, block-end 마진을 bottom 마진 대신 사용하여 그대로 적용됩니다. 마찬가지로 block-start 패딩/테두리는 top 패딩/테두리 대신, block-end 패딩/테두리는 bottom 패딩/테두리 대신 사용합니다. 이는 block-start와 block-end 마진만이 margin-collapsing에 참여한다는 의미입니다.

흐름-상대 방향은 박스의 작성 모드를 기준으로 계산되며, 박스 콘텐츠의 레이아웃에도 추상적으로 적용됩니다:

• text-align 속성의 초기값은 줄 박스의 start 에지에 정렬됩니다.
• text-indent 속성은 줄 박스의 start 에지에서 들여쓰기합니다.
• 테이블의 경우, 열 순서는 테이블의 inline-start 쪽에서 시작하고, 행 순서는 block-start 쪽에서 시작합니다.

7.5. 줄-상대 매핑

줄-상대 방향은 over, under, line-left, line-right입니다. LTR horizontal-tb 작성 모드에서는 각각 위, 아래, 왼쪽, 오른쪽에 해당합니다.

line-right와 line-left 방향은 박스의 작성 모드를 기준으로 계산되어, 아래 속성의 left, right 값을 해석하는 데 사용됩니다:

• text-align 속성 [CSS2]

line-right와 line-left 방향은 박스의 포함 블록의 작성 모드를 기준으로 계산되어, 아래 속성의 left, right 값을 해석하는 데 사용됩니다:

• float 속성 [CSS2]
• clear 속성 [CSS2]
• caption-side 속성 [CSS2]

over와 under 방향은 박스의 작성 모드를 기준으로 계산되어, 줄 박스의 "top"(over)과 "bottom"(under) 쪽 해석에 사용됩니다:

• vertical-align 속성의 경우, 줄 박스의 "top"은 over 에지, "bottom"은 under 에지이며, 양수의 길이 및 백분율 값은 기준선을 line-over 에지 쪽으로 이동시킵니다. [CSS2]
• text-decoration 속성의 경우, 밑줄은 텍스트의 under 쪽에 그려지고, 윗줄은 텍스트의 over 쪽에 그려집니다. [CSS2] CSS Text Decoration Module은 밑줄/윗줄 위치를 더 자세히 정의하고, 위치 제어 기능도 추가로 제공합니다. [CSS3-TEXT-DECOR]

7.6. 순수 물리적 매핑

다음 값들은 정의상 완전히 물리적이며 writing-mode가 변해도 반응하지 않습니다:

• rect() 표기법을 사용하는 clip 속성 [CSS2]
• background 속성들 [CSS2] [CSS3BG]
• border-image 속성들 [CSS3BG]
• box-shadow와 text-shadow 속성의 오프셋

8. 문서의 주요 작성 모드

주요 작성 모드는 루트 요소의 used writing-mode, direction, text-orientation 값으로 결정됩니다. 이 작성 모드는 예를 들어 스크롤 방향이나 기본 페이지 진행 방향을 결정하는 데 사용됩니다.

HTML 문서를 처리할 때의 특별 케이스로, 루트 요소에 body 자식 요소가 있으면 [HTML], 루트 요소의 used value writing-mode와 direction 속성은 루트 요소 자신의 값이 아니라 첫 번째 자식 요소의 computed writing-mode, direction에서 가져옵니다. UA는 text-orientation도 이 방식으로 전달할 수 있습니다. 이 동작은 루트 요소 자체의 writing-mode, direction, text-orientation 계산 값에는 영향을 주지 않습니다.

참고: 전달은 computed 값이 아닌 used 값에 대해 수행되므로, 상속, 논리 속성 매핑 로직, 길이 값 계산 등 스타일 계산의 다른 측면을 방해하지 않습니다.

8.1. 초기 포함 블록으로의 전달

주요 작성 모드는 초기 포함 블록과 뷰포트에 전달되며, 루트 요소의 레이아웃과 뷰포트의 스크롤 방향에 영향을 줍니다.

8.2. 페이지 흐름: 페이지 진행 방향

페이지 미디어에서 CSS는 모든 페이지를 왼쪽 또는 오른쪽 페이지로 분류합니다. 페이지 진행 방향([CSS3PAGE] 참고)은, 펼침면에서 왼쪽/오른쪽 페이지 중 어느 쪽이 흐름에서 먼저이고 첫 페이지가 기본적으로 왼쪽인지 오른쪽인지 결정하며, 주요 작성 모드에 따라 다음과 같이 결정됩니다:

참고: 별도로 오버라이드하지 않을 경우, 문서의 첫 페이지는 펼침면의 두 번째 절반(예: 왼쪽-오른쪽 페이지 진행에서는 오른쪽 페이지)에서 시작합니다.

9. 글리프 조합

9.1. 세로 내 수평 조합: text-combine-upright 속성

이 속성은 여러 타이포그래픽 문자 단위를 하나의 타이포그래픽 문자 단위 공간에 결합하는 방식을 지정합니다. 결합된 텍스트가 1em보다 넓으면, UA는 1em 내에 내용을 맞춰야 하며, 아래 참조. 결과물은 레이아웃/장식상 하나의 똑바로 선 글리프로 취급됩니다. 이 속성은 수직 작성 모드에서만 효과가 있습니다. 값의 의미는 다음과 같습니다:

none

특별한 처리 없음.

all

박스 내 모든 연속된 타이포그래픽 문자 단위를 수직 줄 박스 내에서 하나의 타이포그래픽 문자 단위 공간에 들어가도록 수평으로 조판 시도.

date span { text-combine-upright: all; }

<date>平成<span>20</span>년4월<span>16</span>일에</date>

CSS Writing Modes 향후 레벨에서는 흔히 영향을 받는 시퀀스를 자동 감지하는 값을 도입할 예정입니다. 예: CSS Writing Modes Level 4는 숫자 시퀀스를 결합하는 digits 값을 도입합니다.

9.1.1. 텍스트 런 규칙

렌더링과 레이아웃의 복잡성을 피하기 위해, text-combine-upright 는 일반 텍스트만 결합할 수 있습니다: 박스 경계로 끊기지 않은 연속된 타이포그래픽 문자 단위만 결합 대상.

그러나 이 속성은 상속되므로, UA는 결합 효과를 내는 박스의 내용이 실제로 결합 가능한 시퀀스의 일부가 박스 외부에서 시작/끝나는 경우 결합하지 않고, text-combine-upright가 none인 것처럼 일반적으로 레이아웃해야 합니다.

tcy { text-combine-upright: all; }

<tcy>12<span>34</span></tcy>

9.1.2. 레이아웃 규칙

text-combine-upright: all로 텍스트를 결합하는 경우, 결합된 텍스트의 글리프는 bidi-isolated 상태로 수평으로 조합됩니다 (letter-spacing 및 강제 줄바꿈은 무시하고, 지정된 폰트 설정은 사용함), inline-block 박스의 내용과 유사하게, 수평 작성 모드와 line-height 1em을 가집니다. 결합된 텍스트에 포함된 문서 공백의 처리는 이 레벨에서는 정의되지 않습니다. 조합의 유효 크기는 1em 정사각형으로 간주하며, 정사각형 밖의 것은 레이아웃 측정에 포함되지 않습니다. UA는 글리프를 1em 정사각형 내에서 수평·수직으로 중앙에 배치해야 합니다.

결과 조합의 기준선은 정사각형이 부모 인라인 박스의 text-over와 text-under 기준선 사이에 (어떠한 기준선 정렬 이동(vertical-align) 전) 중앙에 오도록 선택해야 합니다. 양방향 재정렬에서는 조합을 타이포그래픽 문자 단위와 text-orientation: upright과 동일하게 취급합니다. 줄 바꿈 시에는 조합 전후를 실제 내용이 있는 일반 인라인과 같이 취급합니다. 기타 텍스트 레이아웃(강조 표시, 텍스트 장식, 간격 등)에서는 결과 조합을 객체 치환 문자 U+FFFC를 나타내는 단일 글리프로 취급합니다.

9.1.3. 압축 규칙

UA는 조합된 텍스트의 advance width가 1em 내에 들어가도록 필요시 텍스트를 압축해야 합니다. (이는 글리프 자체가 1em 내에 들어간다는 뜻은 아니며, 일부 글리프는 기하학적 경계를 넘어 그려질 수 있음.) OpenType 구현은 반드시 width-specific variant (OpenType hwid/twid/qwid 기능; fwid나 pwid 등 기타 글리프 폭 기능은 포함하지 않음) 를 사용해 조합 내 모든 타이포그래픽 문자 단위에 대해 그 변형이 모두 있을 때 텍스트를 압축해야 합니다. 그렇지 않으면 UA는 폰트가 제공하는 반폭, 3분폭, 4분폭 글리프 대체, 기타 수평 압축용 폰트 기능, 기하학적 스케일링, 또는 이들의 조합 등 어떤 방법을 사용해도 됩니다.

일부 폰트에서는 표의문자 글리프가 1em 폭이지만 높이가 더 낮게 설계되어 있습니다. 이런 폰트에 맞추기 위해 UA는 조합의 수직 크기를 지정 폰트 설정에 따라 렌더링된 水 U+6C34의 advance height에 맞게 수직 스케일링할 수 있습니다. 이 경우 결과 조합은 1em 대신 水 U+6C34의 advance height를 갖게 됩니다.

9.1.3.1. 전각 문자

텍스트를 1em로 압축할 때 타이포그래픽 컬러를 유지하기 위해, 결합된 텍스트가 2개 이상의 타이포그래픽 문자 단위로 구성된 경우, 전각 타이포그래픽 문자 단위는 text-transform: full-width의 알고리즘을 반대로 적용해 비전각 등가로 먼저 변환한 후 기타 압축 기법을 적용해야 합니다. [CSS-TEXT-3] 참고.

글리프 선택에 영향을 주는 속성들, 예를 들어 font-variant, font-feature-settings ([CSS3-FONTS] 정의) 는 결합된 텍스트 런 내 문자 변형 선택에 영향을 줄 수 있습니다. text-combine-upright 를 함께 사용할 때는 이런 속성 사용에 주의하세요.

10. 개인정보 및 보안 고려사항

이 명세는 새로운 개인정보 유출이나, "올바르게 구현" 외의 추가 보안 고려사항을 도입하지 않습니다.

변경사항

2019년 9월 3일 CSS Writing Modes Module Level 3 Candidate Recommendation 이후 변경사항 링크

실질적 변경 없음; 사소한 편집 수정 (이슈 4293, 4272, 4273 참고).

2019년 7월 30일 CSS Writing Modes Module Level 3 Candidate Recommendation 이후 변경사항 링크

• 누락된 직교 흐름 크기 규칙 복구. 최신 [css-sizing-3] 용어로 업데이트. (이슈 4220)

2018년 5월 24일 CSS Writing Modes Module Level 3 Candidate Recommendation 이후 변경사항 링크

• body 요소에서 초기 포함 블록 및 뷰포트로 주요 작성 모드 전달이 루트 요소의 used value에도 영향을 주지만, computed value에는 영향을 주지 않음을 명확히 함. text-orientation도 옵션으로 전달 가능. (이슈 3066)
• text-combine-upright 결합 텍스트 시퀀스의 공백 처리 미정의 명확화 (이슈 4139)

  text-combine-upright: all 결합 시, 결합된 텍스트의 글리프는 bidi-isolated 상태로 수평으로 조합됨 (letter-spacing, 강제 줄바꿈 무시, 지정 폰트 설정 사용), inline-block 박스 내용과 유사, 수평 작성 모드와 line-height 1em. 결합된 텍스트 내 문서 공백 처리는 이 레벨에서 미정의.

2017년 12월 7일 CSS Writing Modes Module Level 3 Candidate Recommendation 이후 변경사항 링크

• 직교 흐름의 대체 "사용 가능한 공간"이 max-height 및 min-height를 올바르게 처리하도록 수정하였습니다. (이슈 2239)

2015년 12월 15일 CSS Writing Modes Module Level 3 Candidate Recommendation 이후 변경사항 링크

• sideways-lr 및 sideways-rl 값이 writing-mode에서 Level 4로 이관되었습니다.
• digits 값이 text-combine-upright에서 Level 4로 이관되었습니다.
• 직교 흐름의 자동 다단 동작이 Level 4로 이관되었습니다.
• 직교 흐름의 대체 "사용 가능한 공간"이, 가능한 경우 가장 가까운 고정 크기 scrollport를 사용하도록 변경되었습니다. (이슈 1391)
• 개인정보 및 보안 고려사항 섹션이 추가되었습니다.
• 기타 편집상 명확화가 이루어졌습니다.

코멘트 처리 현황을 확인할 수 있습니다.

2014년 3월 20일 CSS Writing Modes Module Level 3 Candidate Recommendation 이후 변경사항 링크

• 직교 흐름의 auto-sizing 규칙이 shrink-wrapping을 더 잘 처리하도록 수정되었습니다.
• sideways-left 및 sideways-right 값이 text-orientation에서 삭제되었고, sideways가 sideways-right처럼 동작하도록 재정의되었습니다. 또한 sideways-lr 및 sideways-rl 값이 writing-mode에 추가되어 비수직 문자 체계에서도 사용할 수 있게 되었습니다. (관련 토론 참고)
• use-glyph-orientation 값이 text-orientation에서 삭제되고, glyph-orientation-vertical이 text-orientation의 별칭으로 정의되었습니다(CSS에서 별칭 처리 방식에 따라, page-break-inside 예시 참고).
• glyph-orientation-vertical에서 SVG 호환성을 위해 정수 각도를 처리하도록 추가되었습니다.
• run-in 박스 관련 내용이 CSS2.1에서 삭제되었고, CSS Display Level 3에서는 모델이 달라졌으므로 해당 내용이 삭제되었습니다. 대신 모든 display 타입에 대한 일반화된 설명으로 대체되었으며, 새로운 [CSS-DISPLAY-3] 용어가 사용되었습니다.
• body 자식 요소에서 computed 값을 전달하여 writing-mode와 direction 속성이 초기 포함 블록에 전달되도록 변경되었습니다.
• caption-side 속성이 flow-relative mappings으로 변경되었습니다.
• SVG writing-mode 값이 새로운 값으로 올바르게 계산되도록 명시되었습니다.
• writing-mode가 ruby base containers 및 ruby annotation containers에는 적용되지 않음을 명시하였습니다.
• 여러 편집상 개선이 이루어졌으며 일부 기능이 위험으로 표시되었습니다.

감사의 글

L. David Baron, Brian Birtles, James Clark, John Daggett, Nami Fujii, Daisaku Hataoka, Martin Heijdra, Laurentiu Iancu, Richard Ishida, Jonathan Kew, Yasuo Kida, Tatsuo Kobayashi, Toshi Kobayashi, Ken Lunde, Shunsuke Matsuki, Nat McCully, Eric Muller, Paul Nelson, Kenzou Onozawa, Chris Pratley, Xidorn Quan, Florian Rivoal, Dwayne Robinson, Simon Sapin, Marcin Sawicki, Dirk Schulze, Hajime Shiozawa, Alan Stearns, Michel Suignard, Takao Suzuki, Gérard Talbot, Masataka Yakura, Taro Yamamoto, Steve Zilles

부록 A: 유니코드의 세로 문자 체계

이 절은 안내(설명)입니다.

이 부록은 유니코드 6.0 [UNICODE]의 vertical-only 및 bi-orientational 문자 체계와, 수평에서 세로 방향으로의 변환 방식을 나열합니다. 명시적으로 나열되지 않은 문자 체계는 horizontal-only로 간주합니다. 유니코드 문자의 문자 체계 분류는 [UAX24]에서 제공합니다.

예외: 이 명세에서는 모든 전각(F) 및 와이드(W) 문자는 세로 문자 체계로 간주하며, 반각(H) 문자는 가로 문자 체계로 간주합니다. [UAX11]

vertical-only 문자(몽골어, 파스파 문자 등)의 경우, 유니코드 코드 차트의 글리프는 세로 방향으로 표시됩니다. 수평 텍스트에서는 이 방향에서 90° 반시계 방향으로 회전되어 조판됩니다.

현재 유니코드 기술 보고서 50과 CSS Writing Modes의 기능 한계로 인해, 세로 mixed 조판에서는 오검 문자나 고대 튀르크 문자를 자동 처리할 수 없습니다. 이런 문자 체계에는 sideways-lr(CSS Writing Modes Level 4 참고)를 사용해 조판할 수 있습니다.