CSS 텍스트 모듈 레벨 4

1. 소개

이 모듈은 CSS의 조판 제어를 설명한다; 즉, 원본 텍스트를 서식이 지정되고 줄바꿈된 텍스트로 변환하는 것을 제어하는 CSS의 기능들이다. 다양한 CSS 속성은 대소문자 변환, 공백 병합, 텍스트 줄바꿈, 줄 나누기 규칙 및 하이픈 넣기, 정렬과 양쪽 맞춤, 간격, 그리고 들여쓰기에 대한 제어를 제공한다. 레벨 3 이후 추가 사항은 레벨 3 이후 추가 사항을 참조하라.

전 세계의 다양한 언어와 문자 체계의 조판 요구사항에 대한 추가 정보는 국제화 작업 그룹의 언어 지원 색인에서 확인할 수 있다. [TYPOGRAPHY]

1.1. 모듈 상호작용

이 모듈은 CSS 텍스트 장식 모듈과 함께, Cascading Style Sheets Level 2 16장에서 정의된 텍스트 수준 기능을 대체하고 확장한다. [CSS-TEXT-DECOR-3] [CSS2]

아래에서 정의된 용어 외에도, 이 명세에서 사용하는 다른 용어와 개념은 Cascading Style Sheets Level 2 및 CSS 쓰기 모드 모듈에서 정의된다. [CSS2] 및 [CSS-WRITING-MODES-4].

1.2. 값 정의

이 명세는 CSS 속성 정의 규약을 [CSS2]에서 따르며, 값 정의 구문은 [CSS-VALUES-3]에서 가져온 것을 사용한다. 이 명세에서 정의되지 않은 값 유형은 CSS Values & Units [CSS-VALUES-3]에서 정의된다. 다른 CSS 모듈과 결합하면 이러한 값 유형의 정의가 확장될 수 있다.

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

1.3. 언어와 조판

작성자는 최상의 조판 동작을 위해 자신의 콘텐츠에 정확한 언어 태그를 지정해야 한다.

많은 조판 효과는 언어적 맥락에 따라 달라진다. 언어와 문자 체계의 관례는 줄 나누기, 하이픈 넣기, 양쪽 맞춤, 글리프 선택, 그리고 많은 다른 조판 효과에 영향을 줄 수 있다. CSS에서는 콘텐츠 언어가 알려진(선언된) 경우에만 언어별 조판 조정이 적용된다. 따라서, 더 높은 품질의 조판을 위해서는 작성자가 문서의 텍스트에 대한 올바른 언어적 맥락을 UA에 전달해야 한다.

요소의 콘텐츠 언어는 문서 언어의 규칙에 따라 해당 요소가 속한다고 선언된 (인간) 언어이다. 요소의 콘텐츠 언어가 알려지지 않을 수 있다는 점에 유의하라—​예를 들어 태그가 없는 콘텐츠, 또는 언어 태그 지정 기능이 없는 문서 언어의 콘텐츠는 알 수 없는 콘텐츠 언어를 가진 것으로 간주된다.

참고: 작성자는 HTML의 전역 lang 속성 또는 XML의 범용 xml:lang 속성을 사용하여 콘텐츠 언어를 선언할 수 있다. HTML의 HTML 요소의 콘텐츠 언어를 결정하는 규칙과 XML 1.0의 XML 요소의 콘텐츠 언어를 결정하는 규칙을 참조하라. [HTML] [XML10]

요소가 속한다고 선언된 콘텐츠 언어는 또한 그 요소에서 사용되는 해당 언어의 구체적인 문자 형태를 식별하며, 이를 콘텐츠 문자 체계라고 한다. 콘텐츠 언어를 식별하기 위한 문서 언어의 기능에 따라, 이 정보는 명시적일 수도 암시적일 수도 있다. 규범적인 부록 F: 콘텐츠 작성 체계 식별을 참조하라.

참고: 일부 언어는 둘 이상의 문자 체계 전통을 가지며; 다른 경우에는 언어가 외래 문자 체계로 음역될 수도 있다. 작성자는 이러한 경우에 하위 태그를 지정하여 UA가 적절하게 조정할 수 있게 해야 한다.

1.4. 문자와 글자

조판의 기본 단위는 문자이다. 그러나 문자 체계가 항상 기본 영어 알파벳만큼 단순하지는 않기 때문에, 문자가 실제로 무엇인지는 그 용어가 사용되는 맥락에 따라 달라진다. 예를 들어, 한글(한국어 문자 체계)에서는, 음절의 각 정사각형 표현 (예: 한=Han)을 문자로 간주할 수 있다. 그러나 그 정사각형 기호는 실제로는 음소를 나타내는 여러 글자로 구성되어 있으며 (예: ㅎ=h, ㅏ=a, ㄴ=n) 이것들도 각각 문자로 간주될 수 있다.

주어진 인코딩에 대해 컴퓨터 텍스트 인코딩의 기본 단위도 문자라고 부르며, 인코딩에 따라 단일 인코딩 문자는 전체 선조합 음절 문자(예: 한)에 대응할 수도 있고, 개별 음소 문자(예: ㅎ)에 대응할 수도 있으며, 또는 기본 글자 형태(예: ㅇ)와 그것을 변화시키는 결합 표식(예: 거센소리를 나타내는 추가 획) 같은 더 작은 단위에 대응할 수도 있다.

나아가, 단일 인코딩 문자는 데이터 스트림에서 하나 이상의 바이트로 표현될 수 있으며; 프로그래밍 환경에서는 한 바이트를 때때로 문자라고 부르기도 한다.

따라서 기술적 정확성이 요구되는 곳에서는 문자라는 용어가 상당히 모호하다.

텍스트 레이아웃에서는 텍스트의 기본 단위로 조판 문자 단위를 가리키겠다. 텍스트 레이아웃 영역 안에서도, 관련 문자 단위는 작업에 따라 달라진다. 예를 들어, 줄 나누기와 자간 조절은 U+0E33 ำ THAI CHARACTER SARA AM을 포함하는 태국어 문자 시퀀스를 서로 다르게 분할할 수 있으며; 또는 데바나가리와 같은 문자 체계에서 결합 자음의 동작은 사용 중인 글꼴에 따라 달라질 수 있다. 따라서 조판 문자는 특정 조판 작업 (줄 나누기, 첫 글자 효과, 자간 조절, 양쪽 맞춤, 세로 배열 등)에 대해 더 나눌 수 없는 문자 체계의 단위—​예컨대 라틴 알파벳 글자(발음 구별 기호 포함), 한글 음절, 중국어 표의 문자, 미얀마 음절 클러스터—​를 나타낸다.

Unicode Standard Annex #29: Text Segmentation는 조판 문자에 근사하는 자소 클러스터라는 단위를 정의한다. [UAX29] UA는 UAX29에서 정의한 확장 자소 클러스터 (레거시 자소 클러스터가 아님)를 자신의 조판 문자 단위의 기초로 사용해야 한다. 그러나 기본 규칙이 항상 적절하거나 이상적인 것은 아니므로, UA는 조판 전통에 따라 필요에 맞게 정의를 조정해야 하며, 필요에 따라 작업별로 다르게 조정할 것으로 기대된다.

참고: 이러한 조정에 대한 규칙은 CSS의 범위를 벗어난다.

조판 글자 단위 (또는 이 명세의 목적상 글자)는 Letter 또는 Number 일반 범주 중 하나에 속하는 조판 문자 단위이다. 조판 문자 단위의 Unicode 속성을 결정하는 방법은 부록 E: 문자와 속성을 참조하라.

요소 경계에 의해 분리된 조판 문자 단위의 렌더링 특성은 정의되지 않는다. 이상적으로는 각 구성 요소가 해당 요소의 속성에 따른 서식 요구사항에 맞게 렌더링되는 동시에 조판 문자 단위 전체의 올바른 셰이핑과 위치 지정이 유지되어야 한다. 그러나 그 부분들 사이의 서식 차이의 성격과 사용 중인 글꼴 기술의 능력에 따라, 이것이 항상 가능한 것은 아니다. 따라서 그러한 조판 문자 단위는 경계의 어느 한쪽에 속하는 것으로 렌더링되거나, 양쪽 모두에 속하는 어떤 근사치로 렌더링될 수 있다. 작성자는 자소 클러스터 또는 합자를 요소 경계로 나누면 일관되지 않거나 원하지 않는 결과가 발생할 수 있음을 유의해야 한다.

1.5. 텍스트 처리

CSS는 Unicode 위에 구축된다. [UNICODE] Unicode를 지원하는 UA는 CSS에 의해 명시적으로 재정의된 경우를 제외하고 Unicode Core Standard의 모든 규범적 요구사항을 준수해야 한다. 비-Unicode 텍스트 인코딩 모델을 기반으로 구현된 UA도 적절한 매핑과 유사한 동작을 가정함으로써 동일한 텍스트 처리 요구사항을 충족할 것으로 기대된다.

텍스트 처리 (예: 공백 처리, 텍스트 변환, 줄 나누기 등)를 위한 인접성 판단의 목적상, 그리고 따라서 일반적으로 이 명세 안에서는, 중간에 있는 인라인 박스 경계와 out-of-flow 요소를 무시해야 한다. 그러나 텍스트 셰이핑과 관련해서는 § 8.7 요소 경계를 가로지르는 셰이핑을 참조하라.

2. 텍스트 변환

2.1. 대소문자 변환: text-transform 속성

이 속성은 스타일링 목적을 위해 텍스트를 변환한다. 이는 기반 콘텐츠에는 영향을 주지 않으며, 일반 텍스트 복사 및 붙여넣기 작업의 콘텐츠에 영향을 주어서는 안 된다.

작성자는 의미론적 목적을 위해 text-transform에 의존해서는 안 된다; 대신 올바른 대소문자와 의미론은 원본 문서 텍스트와 마크업에 인코딩되어야 한다.

값은 다음 의미를 가진다:

none

효과 없음.

capitalize

각 단어의 첫 번째 조판 글자 단위가 소문자인 경우 titlecase로 만든다; 다른 문자는 영향을 받지 않는다.

uppercase

모든 글자를 대문자로 만든다.

lowercase

모든 글자를 소문자로 만든다.

full-width

모든 조판 문자 단위를 full-width 형태로 만든다. 어떤 문자에 대응하는 full-width 형태가 없으면, 그대로 둔다. 이 값은 일반적으로 라틴 글자와 숫자를 표의 문자처럼 조판하는 데 사용된다.

full-size-kana

모든 작은 가나 문자를 이에 해당하는 full-size 가나로 변환한다. 이 값은 일반적으로 루비 주석 텍스트에 사용되며, 작성자가 루비에 일반적으로 사용되는 작은 글꼴 크기에서의 가독성 문제를 보완하기 위해 모든 작은 가나가 큰 가나처럼 그려지기를 원할 때 쓰인다.

math-auto

MathML Core § 4.2 math-auto 변환을 참조하라.

abbr:lang(ja) { text-transform: full-width; }

참고: text-transform의 목적은 문서의 의미론에 영향을 주지 않으면서 표현상의 대소문자 변환을 가능하게 하는 것이다. 특히 text-transform 대소문자 작업은 손실이 있으며, 텍스트의 의미를 왜곡할 수 있다는 점에 유의하라. 접근성 인터페이스가 사용자에게 렌더링된 텍스트의 겉보기 대소문자를 전달하고자 할 수는 있지만, 변환된 텍스트가 문서의 기반 의미를 정확히 나타낸다고 신뢰할 수는 없다.

section > p:first-of-type::first-line {
  text-transform: uppercase;
}

rt { font-size: 50%; text-transform: full-size-kana; }
:is(h1, h2, h3, h4) rt { text-transform: none; /* unset for large text*/ }

<ruby>十<rt>じゅう</ruby>

2.1.1. 매핑 규칙

capitalize의 경우, “단어“를 구성하는 것이 무엇인지는 UA에 따라 다르다; 그러한 단어 경계를 결정하기 위해 [UAX29]가 제안되지만 (필수는 아니다). Out-of-flow 박스와 인라인 박스 경계는 text-transform 단어 경계를 도입해서는 안 되며 그러한 단어 경계를 결정할 때 무시되어야 한다.

참고: 작성자는 capitalize가 언어별 제목 표기 관례 (예: 영어에서 관사를 건너뛰는 것)를 따른다고 의존할 수 없다.

UA는 Unicode 문자의 전체 대소문자 매핑을 사용해야 하며, 여기에는 The Unicode Standard의 Default Case Algorithms 절에서 정의한 모든 조건부 대소문자 규칙이 포함된다. [UNICODE] 요소의 콘텐츠 언어가 문서 언어의 규칙에 따라 알려져 있는 경우에만, 적절한 언어별 규칙도 적용되어야 한다. 여기에는 최소한, 이에 한정되지는 않지만, Unicode의 SpecialCasing.txt에 있는 언어별 규칙이 포함된다.

full-width 및 half-width 형태의 정의는 Unicode Standard Annex #11: East Asian Width에서 확인할 수 있다. [UAX11] full-width 형태로의 매핑은 Unicode Standard Annex #44: Unicode Character Database의 Decomposition_Mapping에서 <wide> 또는 <narrow> 태그가 있는 코드 포인트를 취하여 정의된다. [UAX44] <narrow> 태그의 경우, 매핑은 코드 포인트에서 분해 (<narrow> 태그를 뺀 것)로 향하며, <wide> 태그의 경우, 매핑은 분해 (<wide> 태그를 뺀 것)에서 원래 코드 포인트로 되돌아간다.

작은 가나에서 full-size 가나로의 매핑은 부록 G: 작은 가나 매핑에서 정의된다.

2.2. 단어 사이 확장: word-space-transform 속성

일부 언어와 문자 체계는 서로 다른 구분 문자를 사용하거나, 때로는 가시적인 문자를 전혀 사용하지 않는 등 단어를 구분하는 대안적인 방식을 가진다. 이 속성은 작성자가 마크업을 변경할 필요 없이 한 스타일에서 다른 스타일로 렌더링을 변경할 수 있게 한다.

none

이 속성은 효과가 없다.

space

이 요소의 자식 text 안에 있는 확장 가능한 구분자가 U+0020 SPACE로 대체된다.

ideographic-space

이 요소의 자식 text 안에 있는 확장 가능한 구분자가 U+3000 IDEOGRAPHIC SPACE로 대체된다.

auto-phrase

콘텐츠 언어가 알려져 있고 사용자 에이전트가 이 언어에 대한 언어 분석을 지원하는 경우, 사용자 에이전트는 구 경계를 감지해야 한다. 단어 구분 문자, 기타 공백 구분자, 또는 U+200B ZERO WIDTH SPACE 문자가 이미 그 경계에 발생하지 않는 경우, UA는 가상 확장 가능 구분자를 삽입해야 한다.

이 값이 생략되었거나, 또는 콘텐츠 언어가 알려지지 않았거나, 또는 사용자 에이전트가 그 언어에 대한 구 경계 감지를 지원하지 않는 경우, 가상 확장 가능 구분자는 없다.

이 속성의 목적상, 확장 가능한 구분자는 다음 중 하나이다:

• U+200B ZERO WIDTH SPACE 문자

• wbr 요소

• 가상 확장 가능 구분자

가상 확장 가능 구분자는 원본 문서에 달리 존재하지 않는 확장 가능한 구분자를 나타내는 텍스트 내의 UA가 감지한 구문 경계이다. 이 속성을 위한 것 외에는 아무런 효과가 없다.

사용자 에이전트는 (중간의 모든 인라인 박스 경계와, 관련 margin/border/padding을 무시하고) 강제 줄 나누기 바로 앞이나 뒤에 오는 확장 가능한 구분자를 대체해서는 안 된다.

참고: 가상 확장 가능 구분자는 인라인 박스 경계에 참여하는 가장 바깥쪽 요소에 배치되므로, 어떤 것이 인라인 박스의 경계와 일치할 때 그 부모 박스가 used value 로 word-space-transform: none을 가지면, 그 특정 가상 확장 가능 구분자는 확장되지 않는다. 그것은 부모 박스에 배치될 것이기 때문이다.

text-transform처럼, 이 속성도 스타일링 목적만을 위해 텍스트를 변환한다. 이는 기반 콘텐츠에는 영향을 주지 않으며, 일반 텍스트 복사 및 붙여넣기 작업의 콘텐츠에 영향을 주어서는 안 된다.

<p>むかしむかし、<wbr>あるところに、<wbr>おじいさんと<wbr>おばあさんが<wbr>すんでいました。

p {
  word-space-transform: ideographic-space;
}

p {
  word-break: keep-all;
  word-space-transform: ideographic-space;
}

<p>らいしゅう<wbr>の<wbr>じゅぎょう<wbr>に<wbr class=p>たいこ<wbr>と<wbr>ばち<wbr>を<wbr class=p>もって<wbr>きて<wbr>ください。

p wbr.p {
  word-space-transform: ideographic-space;
}

p wbr {
  word-space-transform: ideographic-space;
}

p {
  word-break: keep-all;
}
p wbr.p {
  word-space-transform: ideographic-space;
}

p {
  word-break: keep-all;
}
p wbr {
  word-space-transform: ideographic-space;
}

2.3. 작업 순서

여러 변환을 적용해야 하는 경우, 다음 순서로 적용된다:

1. word-space-transform
2. capitalize, uppercase, 및 lowercase
3. full-width
4. full-size-kana

단어 공백 변환과 텍스트 변환은 § 4.3.1 1단계: 병합과 변환 이후, 하지만 § 4.3.2 2단계: 잘라내기와 배치 이전에 발생한다. 이는 예를 들어 full-width가 보존된 공백 내부의 공백(U+0020)만 U+3000 IDEOGRAPHIC SPACE로 변환한다는 뜻이다.

참고: 부록 A: 텍스트 처리 작업 순서에서 정의한 바와 같이, 변환은 줄 나누기 및 기타 서식 작업에 영향을 준다.

3. 공백과 줄바꿈: white-space 속성

이 속성은 white-space-collapse, text-wrap-mode, 그리고 white-space-trim의 단축 속성이다. 이는 두 가지를 지정한다:

• 공백이 병합되는지 여부와 그 방식; 공백 처리 참조
• 줄이 강제되지 않은 소프트 줄바꿈 기회에서 줄바꿈될 수 있는지 여부; § 5 텍스트 줄바꿈 및 줄 나누기 참조

참고: 이 단축 속성은 상속되는 속성과 상속되지 않는 속성을 모두 결합한다. 이것이 문제라면 CSSWG에 알려 달라.

달리 명시되지 않는 한, 생략된 모든 longhand는 그 초기값으로 설정된다.

다음 표는 단축 속성의 특별 키워드 값이 동등한 longhand 값에 매핑되는 규범적 매핑을 제공한다.

참고: 경우에 따라, 보존된 공백 및 기타 공백 구분자는 줄 끝에 있을 때 hang될 수 있으며; 이는 내재 크기 산정을 위해 그것들이 측정되는지 여부에 영향을 줄 수 있다.

다음 정보 제공 표는 다양한 white-space 값의 동작을 요약한다:

4. 공백 처리 및 제어 문자

문서의 원본 텍스트에는 최종 렌더링과 관련이 없는 서식이 포함되어 있는 경우가 많다: 예를 들어, 편집을 쉽게 하기 위해 원본을 구간으로 나누거나 (줄), 원본 코드를 들여쓰기하기 위해 공백 문자 예컨대 탭과 공백을 추가하는 경우이다. CSS 공백 처리는 작성자가 이러한 서식의 해석을 제어할 수 있게 한다: 문서를 렌더링할 때 이를 보존할지, 아니면 병합하여 없앨지를 말이다. CSS의 공백 처리 (white-space-collapse 및 white-space-trim 속성으로 제어됨)는 공백 문자를 렌더링을 위해서만 해석한다: 이는 기반 문서 데이터에는 영향을 주지 않는다.

참고: 문서 언어에 따라, 구간은 특정 newline 시퀀스 (예: line feed 또는 CRLF 쌍)로 구분될 수도 있고, 또는 SGML RECORD-START 및 RECORD-END 토큰 같은 다른 메커니즘으로 구분될 수도 있다.

CSS 처리를 위해, 각 문서 언어가 정의한 “segment break” 또는 “newline sequence”—​또는 정의된 것이 없으면 텍스트의 각 line feed (U+000A)—​는 세그먼트 나누기로 처리되며, 이는 이후 white-space 속성에 지정된 대로 렌더링을 위해 해석된다.

HTML의 경우, newlines는 DOM에서 표현되기 위해 line feed 문자(U+000A)로 정규화되므로, HTML 문서가 DOM 트리로 표현될 때 각 line feed(U+000A)는 세그먼트 나누기로 처리된다. [HTML] [DOM]

참고: 대부분의 일반적인 CSS 구현에서, HTML은 직접 스타일링되지 않는다. 대신 DOM 트리로 처리되고, 그 다음 스타일링된다. HTML과 달리, DOM은 carriage return(U+000D)에 특별한 의미를 부여하지 않으므로, 그것들은 세그먼트 나누기로 처리되지 않는다. HTML 파싱이 아닌 수단으로 carriage return(U+000D)이 DOM에 삽입되면, 이후 아래에 정의된 대로 처리된다.

참고: 문서 파서는 세그먼트 나누기를 정규화할 뿐만 아니라, 다른 공백 문자를 병합하거나 마크업 규칙에 따라 공백을 다른 방식으로 처리할 수도 있다. CSS 처리는 파싱 단계 이후에 일어나므로, 스타일링을 위해 이러한 문자를 복원하는 것은 불가능하다. 따라서 아래에 지정된 동작 중 일부는 이러한 제한의 영향을 받을 수 있으며 사용자 에이전트에 따라 달라질 수 있다.

참고: 전적으로 병합 가능한 공백으로만 이루어진 익명 블록은 렌더링 트리에서 제거된다. 따라서 블록 수준 요소를 둘러싼 그러한 공백은 병합되어 사라진다. CSS 2 § 9.2.2.1 Anonymous inline boxes를 참조하라. [CSS2]

제어 문자(Unicode 범주 Cc)—​탭(U+0009), line feed(U+000A), carriage return(U+000D) 및 세그먼트 나누기를 형성하는 시퀀스는 제외—​는 보이는 글리프로 렌더링되어야 하며, 글꼴에서 찾은 글리프가 보이지 않는 경우 UA가 이를 합성해야 하고, 그 외에는 Other Symbols(So) 일반 범주와 Common script의 다른 문자처럼 처리되어야 한다. UA는 제어 문자에 대해 특별히 글꼴이 제공하는 글리프를 사용할 수도 있고, Control Pictures 블록의 해당 기호에 제공되는 글리프로 대체할 수도 있으며, 그 코드 포인트 값을 시각적으로 표현한 것을 생성하거나, 적절한 보이는 글리프를 제공하기 위해 다른 방법을 사용할 수도 있다. Unicode에서 요구하는 바와 같이, 지원되지 않는 Default_ignorable 문자는 텍스트 렌더링에서 무시되어야 한다. [UNICODE]

Carriage return(U+000D)은 모든 면에서 공백(U+0020)과 동일하게 처리된다.

참고: HTML 문서의 경우, 원본 코드에 존재하는 carriage return은 파싱 단계에서 line feed로 변환된다 (HTML § 13.2.3.5 Preprocessing the input stream 및 Infra의 normalize newlines 정의를 참조) 따라서 CSS에는 U+000D CARRIAGE RETURN으로 나타나지 않는다. [HTML] [INFRA]) 그러나 이 문자는 escape sequence(
)를 사용해 인코딩되면 보존되며—​위 규칙을 관찰할 수 있다.

4.1. 공백 병합: white-space-collapse 속성

이 절은 아직 논의 중이며 향후 초안에서 변경될 수 있다.

이 속성은 공백이 병합되는지 여부와 그 방식을 지정한다. 값은 다음 의미를 가지며, 공백 처리 규칙에 따라 해석되어야 한다:

collapse

이 값은 사용자 에이전트가 공백의 연속을 하나의 문자로 (또는 일부 경우에는 문자 없음으로) 병합하도록 지시한다.

preserve

이 값은 사용자 에이전트가 공백의 연속을 병합하지 못하게 한다. line feed와 같은 세그먼트 나누기는 강제 줄 나누기로 보존된다.

preserve-breaks

collapse와 같이, 이 값은 연속된 공백 문자를 병합하지만, 원본의 세그먼트 나누기는 강제 줄 나누기로 보존한다.

preserve-spaces

이 값은 사용자 에이전트가 공백의 연속을 병합하지 못하게 하며, 탭과 세그먼트 나누기를 공백으로 변환한다. (이 값은 SVG에서 xml:space="preserve"의 동작을 나타내기 위한 것이다.)

break-spaces

동작은 preserve와 동일하지만, 다음 점이 다르다:

• 보존된 공백 또는 기타 공백 구분자의 모든 연속은 줄 끝을 포함하여 항상 공간을 차지한다.
• 소프트 줄바꿈 기회는 모든 보존된 공백 문자 뒤와 모든 기타 공백 구분자 뒤에 존재한다 (인접한 공백 사이를 포함).

참고: 이 값은 공백으로 인한 오버플로가 절대 발생하지 않음을 보장하지 않는다: 예를 들어, 줄 길이가 너무 짧아서 단일 공백 문자조차 맞지 않는 경우 오버플로는 피할 수 없다.

discard

이 값은 사용자 에이전트가 요소 안의 모든 공백을 “버리도록” 지시한다.

이것은 줄 나누기 기회를 보존하는가, 아니면 그렇지 않은가? 별도의 "hide" 값이 필요한가? 줄 나누기 기회를 보존한다면, word-space-transform 값으로 대체되어야 하는가?

공백 처리로 인해 제거되거나 병합되지 않은 공백을 보존된 공백이라고 한다.

@namespace m "http://www.w3.org/1998/Math/MathML";
m|* {
  white-space-collapse: discard;
}
m|mi, m|mn, m|mo, m|ms, m|mtext {
  white-space-trim: discard-inner;
}

4.2. 공백 잘라내기: white-space-trim 속성

이 속성은 작성자가 박스의 시작과 끝에서 잘라내기 동작을 지정할 수 있게 한다. 값은 다음 의미를 가진다:

discard-before

이 값은 UA가 요소 시작 바로 앞의 모든 병합 가능한 공백을 병합하도록 지시한다.

discard-after

이 값은 UA가 요소 끝 바로 뒤의 모든 병합 가능한 공백을 병합하도록 지시한다.

discard-inner

블록 컨테이너의 경우 이 값은 UA가 요소 안의 첫 번째 비공백 문자 이전에 있는 마지막 세그먼트 나누기까지 포함하여 요소 시작 부분의 모든 공백을 버리도록 지시하며, 또한 요소 안의 마지막 비공백 문자 이후 첫 번째 세그먼트 나누기부터 시작하여 요소 끝 부분의 모든 공백을 버리도록 지시한다. 다른 요소의 경우 이 값은 UA가 요소의 시작과 끝에 있는 모든 공백을 버리도록 지시한다.

참고: 문서 공백을 white-space-trim으로 버리면 텍스트에서 소프트 줄바꿈 기회가 발생하는 위치가 바뀔 수 있다.

dt { display: inline; }
dt + dt:before { content: ", "; white-space-trim: discard-before; }

pre { white-space: pre; white-space-trim: discard-inner; }

<pre>

  some
preformatted

  text

</pre>

<pre>  some
preformatted

  text</pre>

  some
preformatted

  text

span { white-space: normal; white-space-trim: discard-inner; }

start[<span>

  some
inline
  text

</span>]end

start[<span>  some
inline
  text</span>]end

start[some inline text]end

white-space-trim을 위한 공백 처리는 § 4.3.1 1단계: 병합과 변환 이전에 일어난다.

4.3. 공백 처리 규칙

달리 지정되지 않는 한, CSS의 공백 처리는 문서 공백 문자에만 영향을 준다: 공백 (U+0020), 탭 (U+0009), 및 세그먼트 나누기.

참고: 문서 공백으로 간주되는 문자 집합 (문서 콘텐츠의 일부)과 구문적 공백으로 간주되는 문자 집합 (CSS 구문의 일부)이 반드시 동일한 것은 아니다. 그러나 둘 다 공백(U+0020), 탭(U+0009), line feed(U+000A)를 포함하므로 대부분의 작성자는 차이를 알아차리지 못할 것이다.

공백(U+0020) 및 no-break space(U+00A0) 외에도, Unicode는 여러 추가 공백 구분자 문자를 정의한다. [UNICODE] 이 명세에서는 공백(U+0020) 및 no-break space(U+00A0)를 제외한 Unicode 일반 범주 Zs의 모든 문자를 통칭하여 기타 공백 구분자라고 한다.

4.3.1. 1단계: 병합과 변환

참고: white-space-trim은 이 단계 이전에 고려된다.

인라인 서식 맥락 안의 각 인라인 (익명 인라인 포함; CSS 2 § 9.2.2.1 Anonymous inline boxes [CSS2] 참조)에서, 공백 문자는 줄 나누기 및 bidi 재정렬 이전에 다음과 같이 처리되며, bidi 서식 문자 (Bidi_Control 속성을 가진 문자 [UAX9])는 없는 것처럼 무시한다:

• white-space-collapse가 collapse 또는 preserve-breaks로 설정된 경우, 공백 문자는 병합 가능한 것으로 간주되며 다음 단계를 수행하여 처리된다:
  1. 세그먼트 나누기 바로 앞이나 뒤에 있는 병합 가능한 공백 및 탭의 모든 연속은 제거된다.
  2. 병합 가능한 세그먼트 나누기는 세그먼트 나누기 변환 규칙에 따라 렌더링을 위해 변환된다.
  3. 모든 병합 가능한 탭은 병합 가능한 공백(U+0020)으로 변환된다.
  4. 다른 병합 가능한 공백 바로 뒤에 오는 모든 병합 가능한 공백—​그 공백을 포함하는 인라인의 경계 밖에 있는 것이라도, 두 공백이 같은 인라인 서식 맥락 안에 있다면—​은 advance width가 0이 되도록 병합된다. (보이지 않지만, 소프트 줄바꿈 기회가 있다면 이를 유지한다.)
• white-space-collapse가 preserve-spaces로 설정된 경우, 각 탭 및 세그먼트 나누기는 공백으로 변환된다.
• white-space-collapse가 preserve 또는 preserve-spaces로 설정된 경우, 공백의 모든 연속은 non-breaking space의 연속처럼 처리된다. 단, 공백 및/또는 탭의 각 최대 연속 끝에는 소프트 줄바꿈 기회가 존재한다. break-spaces의 경우, 모든 공백 및 모든 탭 뒤에 소프트 줄바꿈 기회가 존재한다.

<ltr>A <rtl> B </rtl> C</ltr>

A  BC

4.3.2. 2단계: 잘라내기와 배치

그 다음, 전체 블록이 렌더링된다. 인라인은 bidi 재정렬을 고려하여 배치되며, text-wrap-mode 및 text-wrap-style 속성이 지정한 대로 줄바꿈된다. 각 줄이 배치될 때,

1. 줄의 시작 부분에 있는 병합 가능한 공백의 연속은 제거된다.
2. 탭 크기가 0이면, 보존된 탭은 렌더링되지 않는다. 그렇지 않으면, 각 보존된 탭은 다음 글리프의 시작 가장자리가 다음 탭 정지점에 맞춰지도록 하는 수평 이동으로 렌더링된다. 이 거리가 0.5ch보다 작으면, 그 다음 탭 정지점이 대신 사용된다. 탭 정지점은 보존된 탭의 가장 가까운 블록 컨테이너 조상에서 시작 콘텐츠 가장자리로부터 탭 크기의 배수인 지점에 위치한다. 탭 크기는 tab-size 속성에 의해 주어진다.

   참고: tabulation(U+0009)이 bidi와 상호작용하는 방식에 대한 Unicode 규칙을 참조하라. [UAX9]

3. 줄 끝에 있는 병합 가능한 공백의 연속은 제거되며, white-space-collapse 속성이 collapse 또는 preserve-breaks인 모든 후행 U+1680   OGHAM SPACE MARK도 함께 제거된다.

   참고: Unicode Bidirectional Algorithm 규칙 L1로 인해, bidi 재정렬 이전에 줄 끝에 위치한 병합 가능한 공백의 연속은 재정렬 후에도 줄 끝에 있게 된다. [UAX9] [CSS-WRITING-MODES-4]

4. (bidi 재정렬 [CSS-WRITING-MODES-4] 이후) 줄 끝에 공백, 기타 공백 구분자, 및/또는 보존된 탭의 연속이 남아 있다면:
   • white-space-collapse가 collapse 또는 preserve-breaks이면, UA는 이 연속을 (무조건적으로) 행잉해야 한다.
   • white-space-collapse가 preserve이고 text-wrap-mode가 nowrap이 아니면, UA는 이 연속을 (무조건적으로) 행잉해야 한다. 단, 그 연속 뒤에 강제 줄 나누기가 오는 경우에는 그 대신 그 연속을 조건부로 행잉해야 한다. 또한 다른 경우라면 오버플로될 문자들의 advance width를 시각적으로 병합할 수도 있다.

     참고: 공백을 병합하는 대신 행잉하면 사용자가 텍스트를 선택하거나 편집할 때 공백을 볼 수 있다.

   • white-space-collapse가 break-spaces로 설정된 경우, 공백, 탭, 및 기타 공백 구분자는 다른 보이는 문자와 동일하게 처리된다: 이들은 행잉될 수도 없고 advance width가 병합될 수도 없다.

     참고: 따라서 그러한 문자들은 공간을 차지하며, 사용 가능한 공간과 적용 가능한 줄 나누기 제어에 따라 오버플로되거나 줄바꿈을 유발한다.

   white-space-collapse: preserve-spaces의 경우 여기서 무엇이 일어나야 하는가?

p {
  white-space: pre-wrap;
  width: 5ch;
  border: solid 1px;
  font-family: monospace;
  text-align: center;
}

<p> 0 </p>

p {
  white-space: pre-wrap;
  width: 3ch;
  border: solid 1px;
  font-family: monospace;
}

<p> 0 0 0 0 </p>

p {
  white-space: pre-wrap;
  width: 3ch;
  border: solid 1px;
  font-family: monospace;
}

<p>0 0 0 0 </p>

4.3.3. 세그먼트 나누기 변환 규칙

white-space-collapse가 collapse가 아닌 경우, 세그먼트 나누기는 병합 가능하지 않다. collapse 또는 (이를 공백으로 변환하는) preserve-spaces 이외의 값에서는, 세그먼트 나누기가 대신 보존된 line feed (U+000A)로 변환된다.

white-space-collapse가 collapse인 경우, 세그먼트 나누기는 병합 가능하며, 다음과 같이 병합된다:

1. 먼저, 다른 병합 가능한 세그먼트 나누기 바로 뒤에 오는 모든 병합 가능한 세그먼트 나누기는 제거된다.
2. 그런 다음 남아 있는 모든 세그먼트 나누기는 나누기 앞뒤의 맥락에 따라 공백(U+0020)으로 변환되거나 제거된다. 이 단계에서 이 작업의 규칙은 UA가 정의한다.

   이를 레벨 4에서 정의해야 하는가?

   참고: 공백 처리 규칙은 이 맥락이 평가되기 전에 세그먼트 나누기 주변의 모든 탭 및 공백을 이미 제거했다.

Here is an English paragraph
that is broken into multiple lines
in the source code so that it can
be more easily read and edited
in a text editor.

這個段落是那麼長，
在一行寫不行。最好
用三行寫。

참고: 역사적으로 HTML과 CSS는 세그먼트 나누기를 무조건 공백으로 변환해 왔으며, 이로 인해 중국어 같은 언어로 작성된 콘텐츠는 원본 안에서 줄을 나눌 수 없었다. 따라서 UA 휴리스틱은 그러한 언어에 대한 지원을 개선하려고 노력하면서도 세그먼트 나누기를 버리는 위치에 대해 보수적일 필요가 있다.

4.4. 탭 문자 크기: tab-size 속성

이 속성은 보존된 탭 문자(U+0009)를 렌더링하는 데 사용되는 탭 크기를 결정한다. <number>는 보존된 탭의 가장 가까운 블록 컨테이너 조상에서 공백 문자(U+0020)의 advance width의 배수로 그 측정값을 나타내며, 여기에는 관련 letter-spacing 및 word-spacing이 포함된다. 음수 값은 허용되지 않는다.

5. 텍스트 줄바꿈

인라인 수준 콘텐츠가 줄로 배치될 때, 이는 줄 박스 사이에서 나뉜다. 그러한 나누기를 줄 나누기라고 한다. 명시적 줄 나누기 제어 (예: 보존된 newline 문자)로 인해 줄이 나뉘거나, 블록의 시작 또는 끝으로 인해 줄이 나뉘는 경우, 이는 강제 줄 나누기이다. 콘텐츠 줄바꿈으로 인해 줄이 나뉘는 경우 (즉, UA가 콘텐츠를 측정값 안에 맞추기 위해 강제되지 않은 줄 나누기를 생성하는 경우), 이는 소프트 줄바꿈 나누기이다. 인라인 수준 콘텐츠를 줄로 나누는 과정을 줄 나누기라고 한다.

줄바꿈은 허용된 나누기 지점에서만 수행되며, 이를 소프트 줄바꿈 기회라고 한다. 줄바꿈이 활성화된 경우(white-space 참조), UA는 존재하는 경우 소프트 줄바꿈 기회에서 줄을 줄바꿈하여 줄에서 오버플로되는 콘텐츠의 양을 최소화해야 한다. 유효한 소프트 줄바꿈 기회는 콘텐츠 언어와 문자 체계, 그리고 이를 제어하는 CSS 속성에 따라 달라진다. § 6 줄 나누기와 단어 경계를 참조하라.

텍스트가 어디에서 줄바꿈될 수 있는지는 줄 나누기 규칙과 제어에 의해 제어되며; 줄바꿈이 허용되는지 여부와 한 줄 안의 여러 소프트 줄바꿈 기회가 어떻게 우선순위화되는지는 text-wrap-mode, text-wrap-style, wrap-before, wrap-after, 및 wrap-inside 속성에 의해 제어된다.

5.1. 줄바꿈 여부 결정: text-wrap-mode 속성

이 속성은 인라인 수준 콘텐츠가 강제되지 않은 소프트 줄바꿈 기회에서 줄바꿈되는지 여부를 지정한다.

참고: 이 속성은 longhand이며, white-space와 text-wrap 둘 모두의 longhand이다.

가능한 값:

wrap

적용 중인 줄 나누기 규칙에 의해 결정되는 허용된 소프트 줄바꿈 기회에서 줄이 줄바꿈될 수 있으며, 이는 인라인 축 오버플로를 최소화하기 위한 것이다.

참고: 소프트 줄바꿈 기회에 대한 규칙과 제약에 관한 자세한 내용은 § 6.5 줄 나누기 세부 사항을 참조하라.

nowrap

줄은 강제 줄 나누기에서만 나뉜다; 블록 컨테이너 안에 맞지 않는 콘텐츠는 그 밖으로 오버플로된다.

text-wrap-mode 값과 관계없이, 보존된 세그먼트 나누기, 그리고 BK, CR, LF, NL 줄 나누기 클래스를 가진 모든 Unicode 문자는 강제 줄 나누기로 처리되어야 한다. [UAX14]

참고: 이러한 강제 줄 나누기의 bidi 관련 의미는 Unicode Bidirectional Algorithm에 의해 정의된다. [UAX9]

5.2. 박스 내부 나누기 제어: wrap-inside 속성

auto

적용 중인 줄 나누기 규칙에 의해 결정되는 허용된 나누기 지점에서, 박스 내부의 줄이 나뉠 수 있다.

avoid

박스 내부의 줄 나누기는 억제된다: UA는 해당 줄에 다른 유효한 나누기 지점이 없을 때에만 박스 내부에서 나눌 수 있다. 텍스트가 나뉘는 경우, 줄 나누기 제한은 auto와 동일하게 준수된다.

avoid가 적용된 박스가 중첩되어 있고 UA가 이 박스들 안에서 반드시 나누어야 하는 경우, 안쪽 박스 안의 나누기를 사용하기 전에 바깥쪽 박스에서의 나누기가 사용되어야 한다.

5.2.1. footer를 표시할 때 'wrap-inside: avoid'를 사용하는 예

footer { wrap-inside: avoid; }
venue { wrap-inside: avoid; }
date { wrap-inside: avoid; }
place { wrap-inside: avoid; }

<footer>
<venue>27th Internationalization and Unicode Conference</venue>
&#8226; <date>April 7, 2005</date> &#8226;
<place>Berlin, Germany</place>
</footer>

27th Internationalization and Unicode Conference •
April 7, 2005 • Berlin, Germany

27th Internationalization and Unicode
Conference • April 7, 2005 •
Berlin, Germany

27th Internationalization and Unicode Conference • April
7, 2005 • Berlin, Germany

5.3. 박스 사이 나누기 제어: wrap-before/wrap-after 속성

이 속성들은 줄 나누기 (및 flex line 나누기 [CSS3-FLEXBOX])에서 나누기 기회에 대한 수정을 지정한다. 가능한 값:

auto

적용 중인 줄 나누기 규칙에 의해 결정되는 허용된 나누기 지점에서, 박스 앞과 뒤의 줄이 나뉠 수 있다.

avoid

박스 바로 앞/뒤의 줄 나누기는 억제된다: UA는 해당 줄에 다른 유효한 나누기 지점이 없을 때에만 그곳에서 나눌 수 있다. 텍스트가 나뉘는 경우, 줄 나누기 제한은 auto와 동일하게 준수된다.

avoid-line

avoid와 같지만, 줄 나누기에만 적용된다.

avoid-flex

avoid와 같지만, flex line 나누기에만 적용된다.

line

박스가 인라인 수준 박스인 경우, 박스 바로 앞/뒤에 줄 나누기를 강제한다.

flex

박스가 여러 줄 flex 컨테이너 안의 flex item인 경우, 박스 바로 앞/뒤에 flex line 나누기를 강제한다.

인라인 수준 박스의 강제 줄 나누기는 모든 부모 인라인 박스를 통해 위로 전파되며, 이는 같은 fragmentation context 안에서 블록 수준 박스의 강제 나누기가 모든 부모 블록 박스를 통해 위로 전파되는 방식과 같다. [CSS3-BREAK]

5.4. 줄바꿈 방식 선택: text-wrap-style 속성

CSSWG는 avoid-orphans에 대해 더 나은 이름을 찾고 있다.

줄바꿈이 허용되는 경우 (text-wrap-mode 참조), 이 속성은 줄바꿈을 위한 여러 접근 방식 중 하나를 선택하며, 속도, 품질과 레이아웃 스타일, 또는 안정성 사이에서 절충한다. 이 속성은 어떤 소프트 줄바꿈 기회가 존재하는지를 바꾸지는 않지만, 사용자 에이전트가 그중 무엇을 선택하는지를 바꾼다. 가능한 값:

auto

어느 소프트 줄바꿈 기회에서 나눌지 선택하는 정확한 알고리즘은 UA가 정의한다. 알고리즘은 나누기 결정을 내릴 때 여러 줄을 고려할 수 있다. UA는 최상의 레이아웃보다 속도에 편향될 수 있다. UA는 balance처럼 모든 줄(마지막 줄 포함)을 균등하게 만들려고 시도해서는 안 된다. 이 값은 UA가 선호하는(또는 가장 Web 호환적인) 줄바꿈 알고리즘을 선택한다.

balance

auto보다 더 나은 균형이 가능하다면, 줄 나누기는 각 줄 박스에 남는 (빈) 공간의 균형을 맞추도록 선택된다. 이는 text-wrap가 auto로 설정되었을 때 블록이 포함했을 줄 박스 수를 변경하지 않아야 하며—​5줄 이하인 경우에는 변경해서는 안 된다.

참고: 한 줄에 함께 나타나는 콘텐츠가 바뀌기 때문에 줄 박스의 높이는 그럼에도 바뀔 수 있다.

고려할 남은 공간은 float와 인라인 콘텐츠를 배치한 후, 텍스트 양쪽 맞춤으로 인한 조정 전의 남은 공간이다. 줄 박스는 각 줄 박스에 남은 공간의 평균 inline-size로부터의 표준편차가 블록 전체에서 줄어들 때 균형을 이룬다 (강제 줄 나누기로 끝나는 줄 포함).

강제 줄 나누기로 분리된 줄 그룹은 별도로 처리된다. 요소가 line-clamp의 영향을 받는 경우, 먼저 클램핑 효과가 적용되고, 그 다음 남은 줄이 균형 조정된다.

정확한 알고리즘은 UA가 정의한다.

균형을 맞출 줄이 10줄을 초과하는 경우, UA는 이 값을 auto로 처리할 수 있다.

stable

텍스트 편집 시 커서 앞의 콘텐츠가 안정적으로 유지되도록, 나누기 결정을 내릴 때 이후 줄의 콘텐츠는 고려하지 않아야 함을 지정한다; 그 외에는 auto와 동등하다,

pretty

UA가 속도보다 더 나은 레이아웃에 편향되어야 함을 지정하며, 나누기 결정을 내릴 때 여러 줄을 고려할 것으로 기대된다. 그 외에는 auto와 동등하다.

사용자 에이전트는 다른 것들 중에서도 avoid-orphans와 유사하게 지나치게 짧은 마지막 줄을 피하려고 시도할 수 있지만, 그 외의 방식으로도 레이아웃을 개선해야 한다. 정확한 개선의 집합은 사용자 에이전트에 따라 달라지며, 다음과 같은 것들을 포함할 수 있다: 줄 길이 간 변동 줄이기; typographic rivers 피하기; 서로 다른 종류의 소프트 줄바꿈 기회, 하이픈 넣기 기회, 또는 양쪽 맞춤 기회에 우선순위 부여; 너무 많은 연속 줄에서 하이픈 넣기를 피하기…

필요한 계산은 비용이 클 수 있으며, 특히 많은 양의 텍스트에 적용될 때 그렇다. 작성자는 text-wrap-style: pretty를 사용할 때 성능에 미치는 영향을 평가하고, 가장 중요한 곳에 선택적으로 사용할 것을 권장한다.

avoid-orphans

UA가 지나치게 짧은 마지막 줄을 피해야 함을 지정하며, 나누기 결정을 내릴 때 둘 이상의 줄을 고려할 것으로 기대된다 (예를 들어, 이전 줄을 너무 짧게 만들어 orphan을 "수정"하는 일을 피하기 위해). 사용자 에이전트는 마지막 줄을 개선하는 것이 이전 줄(들)을 상당히 불균형하게 만드는 경우 개선하지 않기로 결정할 수 있다. 사용자 에이전트는 그러한 개선이 상당한 성능 비용을 초래한다면 auto를 넘어서는 레이아웃의 다른 측면을 개선하려고 시도해서는 안 된다.

참고: 서구 조판에서 “orphan”은 단락의 마지막 줄에 단어 하나만 있는 것을 가리킬 수 있다. 그러나 모든 언어나 문자 체계가 단어 경계에서 줄바꿈되는 것은 아니며, 그렇게 되는 언어에서도, 마지막 줄에 몇 개의 매우 짧은 단어만 있는 것은 여전히 바람직하지 않을 수 있다. 특히 사용 가능한 인라인 공간이 긴 경우 그렇다. 따라서 이 명세는 줄이 단어 하나로만 구성된 경우에만 너무 짧다고 엄격히 정의하지 않으며, 무엇이 지나치게 짧은지는 사용자 에이전트가 판단하게 한다.

참고: fragmentation에 대한 제어와 “orphans”의 다른 조판적 의미에 대해서는 orphans 속성도 참조하라.

예를 들어, 주어진 줄 길이에서는 다음 텍스트가 마지막 줄에 단어 하나만 있게 줄바꿈되며, 이는 너무 짧다고 판단될 수 있다.

ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα
πολλὰ πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον
ἔπερσεν.

text-wrap-style: avoid-orphans를 적용하면 대신 다음과 같은 결과가 나올 수 있으며, 이는 논쟁의 여지는 있지만 더 보기 좋다:

ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς
μάλα πολλὰ πλάγχθη, ἐπεὶ Τροίης ἱερὸν
πτολίεθρον ἔπερσεν.

그러나 다음 조각은 더 까다롭다:

Circumnavigating
the Mississippi
river

마지막 줄을 덜 짧게 만들기 위해 이전 줄을 더 이르게 줄바꿈하려고 시도하면 다음과 같은 결과가 된다:

Circumnavigating
the
Mississippi river

마지막 줄이 실제로 더 이상 짧지 않게 되지만, 끝에서 두 번째 줄은 보기 좋지 않다. 이러한 경우, 사용자 에이전트는 text-wrap-style: avoid-orphans가 설정되어 있음에도 첫 번째 렌더링을 선호할 것으로 기대된다.

참고: auto 값은 일반적으로 Web 브라우저의 빠른 레거시 줄 나누기에 매핑되며, 이는 지금까지 종종 최적이 아닌 결과를 내는 first-fit/greedy 알고리즘을 사용해 왔다. UA는 이 기본값으로 더 나은 줄 나누기 알고리즘을 실험할 수 있지만, 최적의 결과는 종종 더 많은 시간이 걸리므로, pretty와 avoid-orphans는 더 나은 결과를 위해 더 많은 시간을 들이는 opt-in으로 제공된다. 두 값 모두 본문 텍스트를 위한 것이며, 여기서 마지막 줄은 평균 줄보다 약간 더 짧을 것으로 기대된다. 하지만 avoid-orphans는 성능을 유지하면서 지나치게 짧은 마지막 줄을 피하는 것을 목표로 하고, pretty는 더 나은 레이아웃을 추구하기 위해 더 많은 속도를 희생할 수 있다; balance 값은 제목과 캡션을 위한 것이며, 여기서는 길이가 같은 텍스트 줄이 선호되는 경향이 있다; 그리고 stable은 편집 가능하거나 편집 가능으로 전환될 가능성이 있는 섹션을 위한 것이다.

5.5. 결합된 줄바꿈 제어: text-wrap 단축 속성

이 속성은 text-wrap-mode와 text-wrap-style 속성의 단축 속성이다. 생략된 모든 longhand는 그 초기값으로 설정된다.

6. 줄 나누기와 단어 경계

대부분의 문자 체계에서는, 하이픈 넣기가 없을 때 소프트 줄바꿈 기회가 보통 단어 경계에서만 발생한다. 그러한 많은 체계(라틴 알파벳으로 쓰인 영어 등)는 단어를 명시적으로 구분하기 위해 공백이나 문장부호를 사용하며, 소프트 줄바꿈 기회는 이러한 문자로 식별될 수 있다.

그러나 태국어, 라오어, 크메르어와 같은 문자 체계는 단어를 구분하기 위해 공백이나 문장부호를 사용하지 않는다. zero width space(U+200B)를 이러한 문자 체계에서 명시적 단어 구분자로 사용할 수는 있지만, 이 관행은 흔하지 않다. 그 결과, 이러한 텍스트에서 소프트 줄바꿈 기회를 올바르게 식별하려면 어휘 자원이 필요하다.

다른 일부 문자 체계에서는, 특히 자바 문자와 발리 문자 같은 브라흐미계 문자에서, 소프트 줄바꿈 기회가 단어 경계가 아니라 정서법적 음절 경계를 기반으로 한다. 정서법적 음절 나누기는 콘텐츠 언어에 의존하지 않고 어휘 자원을 요구하지도 않지만, 그럼에도 나누기 기회를 찾기 위해 텍스트 분석을 요구한다.

중국어(및 일본어, 이 문자, 때로는 한국어도 포함)와 같은 다른 체계에서는, 각 음절이 하나의 조판 글자 단위에 대응하는 경향이 있으므로, 줄 나누기 관례는 특정 문자 조합 사이를 제외한 어디에서나 줄이 나뉠 수 있게 한다. 또한 이러한 제한의 엄격도 수준은 조판 스타일에 따라 달라진다.

CSS가 소프트 줄바꿈 기회가 발생하는 위치를 완전히 정의하지는 않지만, 일반적인 변형을 구분하기 위한 몇 가지 제어가 제공된다:

• line-break 속성은 줄 나누기 제한에 대해 다양한 “엄격도” 수준을 선택할 수 있게 한다.
• word-break 속성은 어떤 유형의 글자가 나눌 수 없는 “단어”를 형성하도록 함께 묶이는지를 제어하여, CJK 문자가 비-CJK 텍스트처럼 동작하거나 그 반대로 동작하게 하며, 동남아시아 언어에서 단어 감지를 제어할 수 있게 하거나, 단어를 구로 그룹화할 수 있게 한다…
• hyphens 속성은 하이픈을 사용하는 문자 체계에서 자동 하이픈 넣기가 단어를 나눌 수 있는지 여부를 제어한다.
• overflow-wrap 속성은 그렇지 않으면 오버플로될 나눌 수 없는 문자열 안의 어디에서든 UA가 나누기를 취할 수 있게 한다.

참고: Unicode Standard Annex #14: Unicode Line Breaking Algorithm은 Unicode의 모든 문자 체계에 대한 줄 나누기의 기준 동작을 정의하며, 이는 추가로 조정될 것으로 기대된다. [UAX14] 줄 나누기 관례에 대한 자세한 내용은 일본어의 경우 Requirements for Japanese Text Layout [JLREQ] 및 Formatting Rules for Japanese Documents [JIS4051]에서, 중국어의 경우 Requirements for Chinese Text Layout [CLREQ] 및 General Rules for Punctuation [ZHMARK]에서 확인할 수 있다. 추가 언어에 대한 더 많은 정보를 포함하는 국제화 작업 그룹의 Language Enablement Index도 참조하라. [TYPOGRAPHY] 추가로 적절한 참고문헌에 대한 안내는 매우 감사히 받겠다.

6.1. 글자에 대한 나누기 규칙: word-break 속성

이 속성은 “단어” 사이와 내부의 소프트 줄바꿈 기회를 지정한다. 즉, 텍스트 줄을 나누는 것이 “normal”이고 허용되는 위치를 지정한다. 이는 글자 사이의 나누기에 초점을 맞추며, 공백 및 기타 공백 구분자에 의해 소프트 줄바꿈 기회가 생성되는지 여부와 그 방식을 정의하지 않으며 (auto-phrase가 일부를 억제할 수는 있음), 문장부호 주변도 정의하지 않는다. (문장부호와 작은 가나에 영향을 주는 제어는 line-break를 참조하라.)

특히, word-break는 인접한 조판 글자 단위 사이에 소프트 줄바꿈 기회가 일반적으로 존재하는지 여부를 제어한다. 여기서 NU, AL, AI, 또는 ID Unicode 줄 나누기 클래스에 속하는 글자가 아닌 letter 조판 문자 단위도 이 목적에 한해서 조판 글자 단위로 처리한다. [UAX14]

예를 들어, 일부 CJK 조판 스타일에서는, 영어 단어가 공백이나 하이픈 넣기 지점에서만이 아니라 임의의 두 글자 사이에서 나뉘는 것이 허용된다; 이는 word-break:break-all로 활성화할 수 있다.

또 다른 예로, 한국어에는 두 가지 줄 나누기 스타일이 있다: 임의의 두 한국어 음절 사이(word-break: normal) 또는 영어처럼 주로 공백에서(word-break: keep-all).

각 줄의 마지막에 한글이 올 때 줄 나눔 기
준을 “글자” 또는 “어절” 단위로 한다.

각 줄의 마지막에 한글이 올 때 줄 나눔
기준을 “글자” 또는 “어절” 단위로 한다.

에티오피아 문자도 마찬가지로 두 가지 줄 나누기 스타일이 있다. 단어 구분자에서만 나누거나(word-break: normal), 또는 단어 내부의 글자 사이에서도 나누기를 허용한다(word-break: break-all).

ተወልዱ፡ኵሉ፡ሰብእ፡ግዑዛን፡ወዕሩያን፡
በማዕረግ፡ወብሕግ።ቦሙ፡ኅሊና፡ወዐቅል፡
ወይትጌበሩ፡አሐዱ፡ምስለ፡አሀዱ፡
በመንፈሰ፡እኍና።

ተወልዱ፡ኵሉ፡ሰብእ፡ግዑዛን፡ወዕሩያን፡በማ
ዕረግ፡ወብሕግ።ቦሙ፡ኅሊና፡ወዐቅል፡ወይትጌ
በሩ፡አሐዱ፡ምስለ፡አሀዱ፡በመንፈሰ፡እኍና።

참고: 오버플로가 발생하는 경우에만 추가 나누기 기회를 활성화하려면, overflow-wrap를 참조하라.

값은 다음 의미를 가진다:

normal

단어는 위에서 설명한 대로 관례적인 규칙에 따라 나뉜다. 흔히 두 가지 다른 동작을 보이는 한국어는 연속된 임의의 두 Hangul/Hanja 사이에서 나누기를 허용한다. 에티오피아 문자의 경우에도 두 가지 다른 동작을 보이지만, 그러한 단어 내부 나누기는 허용되지 않는다.

일부 문자 체계는 관례적으로 기대되는 소프트 줄바꿈 기회를 얻기 위해 특정 처리가 필요하며, 이는 § 6.1.1 분석적 단어 나누기에 설명되어 있다.

break-all

“단어” 내부에서 나누기가 허용된다: 구체적으로, normal에 대해 허용되는 소프트 줄바꿈 기회에 더하여, 모든 조판 글자 단위 (및 NU (“numeric”), AL (“alphabetic”), 또는 SA (“Southeast Asian”) 줄 나누기 클래스 [UAX14]로 해석되는 모든 조판 문자 단위)는 줄 나누기의 목적상 ID (“ideographic characters”)로 처리된다. 하이픈 넣기는 적용되지 않는다.

참고: 이 값은 문장부호 문자 주변에 소프트 줄바꿈 기회가 있는지 여부에는 영향을 주지 않는다. 어디에서나 나누기를 허용하려면 line-break: anywhere를 참조하라.

참고: 이 옵션은 에티오피아 문자의 다른 일반적인 동작을 활성화한다. 또한 텍스트가 주로 CJK 문자로 이루어져 있고 짧은 비-CJK 발췌만 포함된 맥락에서, 각 줄에 텍스트가 더 잘 분산되기를 원할 때 자주 사용된다.

keep-all

“단어” 내부에서 나누기가 금지된다: 조판 글자 단위 사이의 암시적 소프트 줄바꿈 기회 (또는 NU, AL, AI, 또는 ID Unicode 줄 나누기 클래스 [UAX14]에 속하는 다른 조판 문자 단위 사이의 암시적 기회)는 억제된다. 즉, 그러한 문자 쌍 사이의 나누기는 (line-break 설정 중 anywhere 이외의 설정과 관계없이) 금지되며, § 6.1.1.1 어휘적 단어 나누기로 인해 기회가 존재하는 경우는 예외이다. 그 외에는 이 옵션은 normal과 동등하다. 이 스타일에서는 CJK 문자 시퀀스가 나뉘지 않는다.

참고: 이것은 한국어의 다른 일반적인 동작 (단어 사이에 공백을 사용함)이며, CJK 조각이 공백을 구분자로 사용하는 다른 언어 안에 섞인 혼합 문자 체계 텍스트에도 유용하다.

manual

normal과 동일하게 동작하지만, § 6.1.1.1 어휘적 단어 나누기를 수행해서는 안 된다. 구체적으로, [UAX14]에서 클래스 SA를 가진 조판 문자 단위는 클래스 AL을 가진 것처럼 처리되어야 한다. (즉, line-break 값이 anywhere가 아니라고 가정하면, 그러한 문자 쌍 사이에는 소프트 줄바꿈 기회가 없다).

참고: 이 값은 발리어 같은 언어에서 단어 내부의 음절 기반 소프트 줄바꿈 기회에는 영향을 주지 않는다. (그러한 문자 체계에 대한 논의는 § 6.1.1.2 정서법적 나누기를 참조하라.)

또는, 이 값은 normal이 아니라 keep-all을 기반으로 할 수도 있다. 또 다른 변형은 이 동작을 keep-all과 병합하는 것이다.

참고: 일부 동남아시아 언어는 사용자 에이전트에 의해 흔히 잘못 감지된다. word-break: normal에서는 그 결과 UA가 줄바꿈 기회를 찾기 위해 부적절한 언어별 논리를 적용하고, 이를 부적절한 위치에 배치할 수 있다.

예를 들어, 태국어 이외의 많은 언어가 태국 문자로 쓰이며, 이를 태국어인 것처럼 줄 나누기하면 일반적으로 부적절하고—​혼란스러울 수 있는—​결과가 나온다.

이런 일이 발생하면, 이 값은 작성자가 word-break: normal에 대해 사용자 에이전트에 내장된 단어 경계 감지를 끌 수 있게 하여, 줄바꿈 기회를 나타내기 위해 텍스트를 수동으로 마크업하고 합리적인 결과를 얻을 수 있게 한다.

이 값을 사용하는 작성자는 동남아시아 언어의 단어 경계를 수동으로 표시해야 하며, 이를 위해 wbr 또는 U+200B를 사용해야 한다. 그렇지 않으면 소프트 줄바꿈 기회가 없으며 텍스트가 오버플로될 수 있다.

auto-phrase

normal과 동일하게 동작하지만, 이 값은 사용자 에이전트가 언어별 콘텐츠 분석을 수행하여 자연스러운 구(여러 단어로 이루어진)를 함께 유지하는 것에 우선순위를 두도록 지시한다.

요소의 콘텐츠 언어가 알려지지 않았거나, 사용자 에이전트가 그 특정 언어에 대해 구 경계를 감지하는 방법을 모르는 경우, 이 값은 normal처럼 동작해야 한다. 그렇지 않으면, 사용자 에이전트는 구 경계를 감지하고 각 구 내부의 소프트 줄바꿈 기회를 억제해야 한다.

콘텐츠 언어와 구 경계 감지 지원 여부와 관계없이, 하이픈 넣기 기회는 hyphens: none이 지정된 것처럼 억제된다.

참고: 한 언어를 위해 설계된 단어 경계 감지 시스템이 그 언어의 일부 또는 모든 방언에 적합한지는 어느 정도 주관적이며, 이 명세는 이를 사용자 에이전트의 재량에 맡긴다. 감지 시스템이 특정 방언의 모든 미묘한 차이를 처리할 수 없더라도, 단어 경계를 대부분의 경우 올바르게 인식한다면 지원한다고 주장하는 것이 합리적일 수 있다. 그러나 사용자 에이전트가 대부분의 단어 경계를 감지하지 못하거나 오류율이 높은 언어에 대해 지원한다고 주장한다면, 작성자와 사용자에게 해가 될 것이다.

사용자 에이전트가 광범위한 중국어 집합에는 적합하지 않은 광둥어용 단어 경계 감지 시스템을 가지고 있다면, auto-phrase는 lang=yue, lang=zh-yue, 또는 lang=zh-HK로 표시된 콘텐츠에는 효과가 있어야 하지만, lang=zh 또는 lang=zh-Hant에는 그렇지 않아야 한다.

그러나 사용자 에이전트가 중국어 전반에 적합한 일반 단어 경계 감지 시스템을 지원한다면, auto-phrase는 넓은 lang=zh 특성으로 표시된 콘텐츠뿐 아니라, lang=zh-yue, lang=zh-Hant-HK, lang=zh-Hans-SG, 또는 lang=zh-hak 같은 더 구체적인 콘텐츠에도 효과가 있어야 한다.

특정 범주의 글자와 같은 방식으로 줄 나누기되는 기호는 그 글자들과 같은 방식으로 영향을 받는다.

这是一些汉字 and some Latin و کمی خط عربی และตัวอย่างการเขียนภาษาไทย በጽሑፍ፡ማራዘሙን፡አንዳንድ፡

<h1>
窓ぎわの<wbr>トットちゃん
</h1>

h1 {
  word-break: normal;
}

窓ぎわのトッ
トちゃん

<h1>
窓ぎわの<wbr>トットちゃん
</h1>

h1 {
  word-break: keep-all;
}

窓ぎわの
トットちゃん

<h1 lang=ja>
窓ぎわのトットちゃん
</h1>

h1 {
  word-break: auto-phrase;
}

窓ぎわの
トットちゃん

사용자 에이전트는 이 속성의 어떤 값에 대한 응답으로도 다음과 같은 소프트 줄바꿈 기회를 억제해서는 안 된다:

• wbr HTML 요소 또는 U+200B ZERO WIDTH SPACE에 의해 도입된 것

• line-break 속성에 의해 요구되는 것

• atomic inline을 둘러싼 것

word-break의 효과는 내재 크기를 계산할 때 고려된다.

레거시 콘텐츠와의 호환성을 위해, word-break 속성은 더 이상 권장되지 않는 break-word 키워드도 지원한다. 지정된 경우, 이는 word-break: normal 및 overflow-wrap: anywhere와 같은 효과를 가지며, overflow-wrap 속성의 실제 값과는 무관하다.

6.1.1. 분석적 단어 나누기

6.1.1.1. 어휘적 단어 나누기

동남아시아 언어에 대해 기대되는 normal 동작을 제공하려면, [UAX14]에서 줄 나누기 클래스 SA를 가진 조판 문자 단위는 클래스 AL을 가진 것처럼 처리되어야 한다. 그러나 사용자 에이전트는 추가로 그러한 문자들의 연속 콘텐츠를 분석하여 단어 경계를 감지하고, 각 경계를 소프트 줄바꿈 기회로 처리해야 한다.

클래스 SA 문자를 사용하는 문자 체계로 다양한 언어가 쓰일 수 있으므로, 콘텐츠 언어가 알려진 경우, 사용자 에이전트는 이 정보를 사용하여 분석을 조정해야 한다.

6.1.1.2. 정서법적 나누기

발리 문자와 같이 정서법적 음절을 기반으로 줄 나누기를 사용하는 문자 체계의 경우, UA는 소프트 줄바꿈 기회를 삽입할 올바른 지점을 찾기 위해 콘텐츠를 분석해야 한다.

참고: 작성 시점에는, Unicode가 이 분석을 수행하는 방법을 정의하지 않으며, 이러한 문자 체계의 모든 문자를 줄 나누기 클래스 AL로 처리한다. 그러나, 그 문제를 해결하기 위한 제안이 이루어졌다. 최종적인 것은 아니지만, 참고할 정보로 유용할 수 있다. [L2-22-080R]

6.1.1.3. 대체 나누기

예상치 못한 오버플로를 피하기 위해, 사용자 에이전트가 줄 나누기에 필요한 어휘적 또는 정서법적 분석을 이를 필요로 하는 콘텐츠 언어에 대해 수행할 수 없는 경우—​예를 들어 클래스 SA 문자로 쓰인 언어에 대한 사전이 없기 때문에—​그 문자 체계의 조판 글자 단위 쌍 사이에 소프트 줄바꿈 기회가 있다고 가정해야 한다.

참고: 이 조항은 UA가 특정 텍스트 연속에서 단어 경계를 찾지 못했다는 이유만으로 발동되는 것은 아니다; 그 텍스트 연속은 실제로 하나의 나눌 수 없는 단어일 수 있다. 예를 들어, 사용자 에이전트가 크메르어의 단어 경계를 결정하는 방법을 모르는 경우, 텍스트 연속이 크메르 문자(U+1780부터 U+17FF까지)로 구성되어 있을 때 적용된다.

6.1.2. 구 기반 줄 나누기에 대한 사용자 선호 표현

사용자 에이전트는 사용자 선호에 응답하여 auto-phrase에 설명된 언어별 콘텐츠 분석을 활성화할 수 있다. 이러한 동작을 가진 사용자 에이전트는 word-break의 선언값을 user origin에서 auto-phrase로 설정함으로써 이를 수행해야 한다.

참고: 이는 작성자가 getComputedStyle()를 호출하여 이 기능이 활성화되었는지 여부를 감지하거나, 적절한 경우 author origin에서 이를 재정의할 수 있게 한다.

6.2. 줄 나누기 엄격도: line-break 속성

이 속성은 요소 안에 적용되는 줄 나누기 규칙의 엄격도를 지정한다: 특히 줄바꿈이 문장부호 및 기호와 어떻게 상호작용하는지를 지정한다. 값은 다음 의미를 가진다:

auto

UA가 사용할 줄 나누기 제한 집합을 결정하며, 줄의 길이에 따라 제한을 달리할 수 있다; 예를 들어, 짧은 줄에는 덜 제한적인 줄 나누기 규칙 집합을 사용한다.

loose

가장 제한이 적은 줄 나누기 규칙 집합을 사용하여 텍스트를 나눈다. 일반적으로 신문과 같은 짧은 줄에 사용된다.

normal

가장 일반적인 줄 나누기 규칙 집합을 사용하여 텍스트를 나눈다.

strict

가장 엄격한 줄 나누기 규칙 집합을 사용하여 텍스트를 나눈다.

anywhere

모든 조판 문자 단위 주변에 소프트 줄바꿈 기회가 있다. 여기에는 모든 문장부호 문자, 보존된 공백, 또는 단어 중간도 포함되며, 줄 나누기에 대한 모든 금지를 무시한다. 여기에는 GL, WJ, 또는 ZWJ 줄 나누기 클래스를 가진 문자에 의해 도입된 금지나 word-break 속성에 의해 요구되는 금지도 포함된다. [UAX14] 서로 다른 줄바꿈 기회는 우선순위가 매겨져서는 안 된다. 하이픈 넣기는 적용되지 않는다.

참고: 이 값은 터미널에서 흔히 보이는 줄 나누기 규칙을 유발한다.

참고: anywhere는 white-space가 break-spaces로 설정된 경우에만 줄 끝의 보존된 공백이 다음 줄로 줄바꿈될 수 있게 한다. 다른 경우에는:

• 줄 끝/시작의 보존된 공백이 버려진다 (normal, pre-line)
• 줄바꿈이 완전히 금지된다(nowrap, pre)
• 보존된 공백이 행잉된다(pre-wrap).

보존된 공백에 효과가 있는 경우, white-space: break-spaces에서는 공백 시퀀스의 첫 번째 공백 앞에서도 나누기를 허용한다. 이는 break-spaces 자체만으로는 허용되지 않는다.

CSS는 텍스트 줄바꿈 규칙에서 네 가지 엄격도 수준을 구분한다. loose, normal, 및 strict 각각에 대해 적용되는 정확한 규칙 집합은 UA에 달려 있으며 언어 관례를 따라야 한다. 그러나 이 세 키워드에 대해, 이 명세는 다음을 요구한다:

• 다음 나누기는 normal 및 loose 줄 나누기에서 writing system이 중국어 또는 일본어인 경우 허용되며, 그 외에는 금지된다:
  • 특정 CJK 하이픈 유사 문자 앞의 나누기:
    〜 U+301C, ゠ U+30A0
• 다음 나누기는 앞의 문자가 Unicode 줄 나누기 클래스 ID [UAX14]에 속하는 경우 loose 줄 나누기에서 허용되며, (앞의 문자가 word-break: break-all로 인해 ID로 처리되는 경우 포함) 그 외에는 금지된다:
  • 하이픈 앞의 나누기:
    ‐ U+2010, – U+2013
• 다음 나누기는 normal 및 strict 줄 나누기에서는 금지되고 loose에서는 허용된다:
  • 일본어 작은 가나 또는 Katakana-Hiragana prolonged sound mark 앞의 나누기, 즉 Unicode 줄 나누기 클래스 CJ의 문자. [UAX14]
  • 반복 기호 앞의 나누기:
    々 U+3005, 〻 U+303B, ゝ U+309D, ゞ U+309E, ヽ U+30FD, ヾ U+30FE
  • 분리할 수 없는 문자 사이의 나누기 (예: ‥ U+2025, … U+2026), 즉 Unicode 줄 나누기 클래스 IN의 문자. [UAX14]
• 다음 나누기는 writing system이 중국어 또는 일본어인 경우 loose에서 허용되며 그 외에는 금지된다:
  • 특정 가운데 문장부호 앞의 나누기:
    ・ U+30FB, ： U+FF1A, ； U+FF1B, ･ U+FF65, ‼ U+203C, ⁇ U+2047, ⁈ U+2048, ⁉ U+2049, ！ U+FF01, ？ U+FF1F
  • 접미사 앞의 나누기:
    Unicode 줄 나누기 클래스 PO를 가진 문자 [UAX14] 및 East Asian Width 속성 [UAX11] Ambiguous, Fullwidth, 또는 Wide.
  • 접두사 뒤의 나누기:
    Unicode 줄 나누기 클래스 PR을 가진 문자 [UAX14] 및 East Asian Width 속성 [UAX11] Ambiguous, Fullwidth, 또는 Wide.

참고: 위에 나열된 요구사항은 CJK 텍스트에서만 구분을 만든다. 위 규칙들만 일치하고 추가 규칙이 없는 구현에서는, writing system이 중국어 또는 일본어로 태그되지 않는 한 line-break는 CJK 코드 포인트에만 영향을 줄 것이다. 향후 레벨은 다른 문자 체계와 언어에 대해 그 요구사항이 알려짐에 따라 추가적인 특정 규칙을 더할 수 있다.

참고: CSSWG는 향후 명세 판에서 고급 출판 요구사항을 충족하기 위해 줄 나누기에 대한 더 세밀한 제어가 필요할 수 있음을 인정한다.

6.3. 하이픈 넣기: 단어 내부의 형태론적 나누기

6.3.1. 하이픈 넣기 제어: hyphens 속성

하이픈 넣기는 단락의 레이아웃을 개선하기 위해 일반적으로 나누기가 허용되지 않는 곳에서 단어를 제어하여 분할하는 것이며, 보통 음절 또는 형태소 경계에서 단어를 나누고 종종 그 분할을 시각적으로 표시한다 (대개 하이픈, U+2010을 삽입). 어떤 경우에는 하이픈 넣기가 단어의 철자를 바꿀 수도 있다. 어쨌든 하이픈 넣기는 렌더링 효과일 뿐이다: 이는 기반 문서 콘텐츠나 텍스트 선택 또는 검색에 영향을 주어서는 안 된다.

하이픈 넣기 관행은 언어마다 다르며, 줄 나누기 앞에 하이픈을 삽입하는 것뿐 아니라, 나누기 뒤에 하이픈을 삽입하거나(또는 둘 다), U+2010과 다른 문자를 삽입하거나, 단어의 철자를 바꾸는 것도 포함될 수 있다.

언어	나뉘지 않은 형태	앞	뒤
영어	Unbroken	Un‐	broken
네덜란드어	cafeetje	café‐	tje
헝가리어	Összeg	Ösz‐	szeg
중국어(만다린)	tú’àn	tú‐	àn
	àizēng‐fēnmíng	àizēng‐	‐fēnmíng
위구르어
크리어

하이픈 넣기는 줄이 유효한 하이픈 넣기 기회에서 나뉠 때 발생하며, 이는 하이픈 넣기가 허용되는 단어 내부에 존재하는 소프트 줄바꿈 기회의 한 종류이다. CSS에서 하이픈 넣기 기회는 hyphens 속성으로 제어된다. CSS Text Level 3은 하이픈 넣기의 정확한 규칙을 정의하지 않는다; 그러나 UA는 나누기 지점 선택을 최적화하고 언어에 적합한 하이픈 넣기 지점을 선택할 것을 강하게 권장한다.

참고: U+002D - HYPHEN-MINUS 문자나 U+2010 ‐ HYPHEN 문자에 의해 도입되는 소프트 줄바꿈 기회는 하이픈 넣기 기회가 아니다. 줄바꿈 시 분할의 시각적 표시가 생성되지 않기 때문이다: 이 문자들은 해당 지점에서 줄이 나뉘든 아니든 보인다.

하이픈 넣기 기회는 min-content 내재 크기를 계산할 때 고려된다.

참고: 이는 표가 포함 블록을 오버플로하는 대신 그 내용을 하이픈 넣기할 수 있게 하며, 독일어처럼 긴 단어가 많은 언어에서 특히 중요하다.

이 속성은 하이픈 넣기가 텍스트 줄 안에서 더 많은 소프트 줄바꿈 기회를 만들 수 있는지 여부를 제어한다. 값은 다음 의미를 가진다:

none

단어 내부의 문자가 하이픈 넣기 기회를 명시적으로 정의하더라도, 단어는 하이픈 넣기되지 않는다.

참고: 이는 U+002D - HYPHEN-MINUS 또는 U+2010 ‐ HYPHEN처럼 항상 보이는 문자에 의해 도입된 기존 소프트 줄바꿈 기회를 억제하지 않는다.

manual

단어 내부에 하이픈 넣기 기회를 명시적으로 제안하는 문자가 있는 곳에서만 단어가 하이픈 넣기된다. UA는 적절한 언어별 하이픈 넣기 문자(들)를 사용해야 하며, 같은 지점에서의 자동 하이픈 넣기와 마찬가지로 적절한 철자 변경을 적용해야 한다.

Unicode에서 U+00AD는 조건부 “soft hyphen”이고 U+2010은 무조건 하이픈이다. Unicode Standard Annex #14는 Unicode 줄 나누기에서 soft hyphen의 역할을 설명한다. [UAX14] HTML에서 &shy;는 하이픈 넣기 기회를 제안하는 soft hyphen 문자를 나타낸다.

ex­ample

auto

단어는 조건부 하이픈에 의해 명시적으로 표시된 기회에 더하여, 언어에 적합한 하이픈 넣기 자원이 자동으로 결정한 하이픈 넣기 기회에서 나뉠 수 있다. 단어가 조건부 하이픈 (&shy; 또는 U+00AD SOFT HYPHEN)을 포함하는 경우, 단어 안의 다른 자동 하이픈 넣기 기회는 조건부 하이픈(들)을 우선하여 무시되어야 한다. 그러나 그러한 기회에서 나눈 뒤에도 그 단어의 일부가 한 줄에 맞기에는 여전히 너무 길다면, 자동 하이픈 넣기 기회를 사용할 수 있다.

올바른 자동 하이픈 넣기에는 나뉘는 텍스트의 언어에 적합한 하이픈 넣기 자원이 필요하다. 따라서 UA는 콘텐츠 언어가 알려져 있고 적절한 하이픈 넣기 자원을 가진 텍스트에 대해서만 자동 하이픈 넣기를 해야 한다.

UA는 특정 단어를 자동 하이픈 넣기에서 제외하기 위해 언어에 맞춘 휴리스틱을 사용할 수 있다. 예를 들어, UA는 특정 대문자화 및 문장부호 패턴에 일치하는 단어를 제외하여 고유명사에서의 하이픈 넣기를 피하려고 할 수 있다. 이러한 휴리스틱은 이 명세에서 정의하지 않는다. (이러한 휴리스틱은 언어마다 달라질 필요가 있음에 유의하라: 예를 들어 영어와 독일어는 대문자화 관례가 매우 다르다.)

hyphens 속성의 목적상, 무엇이 “단어”를 구성하는지는 UA에 따라 다르다. 그러나 단어 경계를 결정할 때 인라인 요소 경계와 out-of-flow 요소는 무시되어야 한다.

조건부 하이픈 문자 (예: U+00AD SOFT HYPHEN)가 만든 하이픈 넣기 기회에서 하이픈 넣기로 인해 표시되는 모든 글리프는 그 문자로 표현되며 그 문자에 적용된 속성에 따라 스타일링된다.

참고: 아랍 문자와 같은 셰이핑 문자 체계가 하이픈 넣기로 인해 단어 내부에서 나뉠 수 있는 경우에도, 문자는 단어가 나뉘지 않은 것처럼 계속 셰이핑된다.

예를 들어, 위구르어 단어 “داميدى”가 하이픈 넣기된다면, 다음처럼 보인다 다음이 아니라 .

6.3.2. 하이픈: hyphenate-character 속성

이 속성은 하이픈 넣기된 단어의 부분들 사이에 표시되는 문자열을 지정한다. 값은 다음 의미를 가진다:

auto

사용자 에이전트가 콘텐츠 언어의 조판 관례를 기반으로 적절한 문자열을 찾아야 함을 지정하며, 이는 하이픈 넣기 사전과 같은 출처에서 올 수도 있다.

<string>

하이픈 넣기 시 하이픈 넣기 나누기 지점에 나타나는 문자열을 지정한다. (이 문자열의 위치는 영향을 받지 않는다: UA는 콘텐츠 언어의 조판 관례에 따라 문자열을 삽입해야 하며, 기본값은 하이픈 넣기 나누기 바로 앞이다.) UA는 used value를 제한된 수의 조판 문자 단위로 잘라낼 수 있다; 하지만 조판 문자 단위의 일부만 잘라내서는 안 된다.

참고: 빈 문자열 ""을 지정하는 것은 유효하며, UA가 보이는 하이픈 넣기 문자를 삽입하지 않고 하이픈 넣기 기회에서 나누도록 한다.

[lang]:lang(ojs) { hyphenate-character: "᐀" /* CANADIAN SYLLABICS HYPHEN (U+1400) */ }

참고: 자동 하이픈 넣기에 의해 발생한 하이픈과 soft hyphen에 의해 발생한 하이픈은 모두 hyphenate-character에 따라 렌더링된다.

6.3.3. 하이픈 넣기 크기 제한: hyphenate-limit-zone 속성

hyphenate-limit-zone이 좋은 이름인가? 의견/제안이 있는가?

이 속성은 하이픈 넣기가 유발되기 전에 줄 박스에 남을 수 있는 최대 빈 공간의 양 (양쪽 맞춤 이전)을 지정하며, 이는 다음 줄의 단어 일부를 현재 줄로 끌어올리기 위한 것이다.

6.3.4. 하이픈 넣기 문자 제한: hyphenate-limit-chars 속성

이 속성은 하이픈 넣기된 단어의 최소 문자 수를 지정한다. 단어가 단어 전체 / 하이픈 앞 / 하이픈 뒤의 필수 최소 문자 수를 충족하지 않으면, 그 단어는 하이픈 넣기되어서는 안 된다. 비간격 결합 표식(Unicode General Category Mn)과 단어 내부 문장부호(Unicode General Category P*)는 최소값 계산에 포함되지 않는다.

세 값이 지정된 경우, 첫 번째 값은 단어 전체 문자 수의 필수 최소값, 두 번째 값은 하이픈 넣기 지점 앞 문자 수의 최소값, 세 번째 값은 하이픈 넣기 지점 뒤 문자 수의 최소값이다. 세 번째 값이 빠지면 두 번째 값과 같다. 두 번째 값이 빠지면 auto가 된다. auto 값은 UA가 현재 레이아웃에 맞게 조정되는 값을 선택함을 의미한다.

참고: UA가 더 나은 값을 계산할 수 없는 한, auto는 앞과 뒤에 대해 2, 단어 전체에 대해 5를 의미하는 것이 제안된다.

p { hyphenate-limit-chars: auto 3; }

6.3.5. 하이픈 넣기 줄 제한: hyphenate-limit-lines 및 hyphenate-limit-last 속성

이 속성은 요소 안에서 연속적으로 하이픈 넣기될 수 있는 줄의 최대 수를 나타낸다. no-limit 값은 제한이 없음을 의미한다.

어떤 경우에는 사용자 에이전트가 지정된 값을 준수하지 못할 수 있다. (overflow-wrap 참조.) 그러한 긴급 나누기로 도입된 하이픈 넣기가 가까운 하이픈 넣기 지점에 영향을 주는지는 정의되지 않는다.

이 속성은 요소, 열, 페이지 및 spread 끝에서의 하이픈 넣기 동작을 나타낸다. spread는 독자에게 동시에 보이는 두 페이지의 집합이다. 값은 다음 의미를 가진다:

none

제한이 부과되지 않는다.

always

요소의 마지막 전체 줄, 또는 요소 내부의 column, page, spread 나누기 앞 마지막 줄은 하이픈 넣기되어서는 안 된다.

column

요소 내부의 column, page, spread 나누기 앞 마지막 줄은 하이픈 넣기되어서는 안 된다.

page

요소 내부의 page 또는 spread 나누기 앞 마지막 줄은 하이픈 넣기되어서는 안 된다.

spread

요소 내부의 spread 나누기 앞 마지막 줄은 하이픈 넣기되어서는 안 된다.

p { hyphenate-limit-last: always }
div.chapter {	hyphenate-limit-last: spread }

This is just a
simple example
to show Antarc-
tica.

This is just a
simple example
to        show
Antarctica.

6.4. 오버플로 줄바꿈: overflow-wrap (word-wrap) 속성

이 속성은 그렇지 않으면 나눌 수 없는 문자열이 줄 박스 안에 맞기에는 너무 길 때, 오버플로를 방지하기 위해 UA가 줄 내부의 원래 허용되지 않는 지점에서 나눌 수 있는지 여부를 지정한다. 이는 white-space가 줄바꿈을 허용할 때에만 효과가 있다. 가능한 값:

normal

줄은 허용된 나누기 지점에서만 나뉠 수 있다. 그러나 줄에 달리 허용 가능한 나누기 지점이 없는 경우, word-break: keep-all에 의해 도입된 제한은 word-break: normal과 일치하도록 완화될 수 있다.

또한 줄에 달리 허용 가능한 나누기 지점이 없는 경우, word-break: auto-phrase에 의해 도입된 제한도 완화된다:

• 특정 구 내부의 소프트 줄바꿈 기회를 억제하는 것이 그 구를 달리 빈 줄에 배치하더라도 오버플로되게 한다면, 사용자 에이전트는 그 구 내부에서 normal과 동일한 소프트 줄바꿈 기회로 되돌아가야 한다.
• 그것으로도 오버플로를 방지하기에 충분하지 않다면, 오버플로될 각 줄 안에서는 하이픈 넣기 기회의 억제도 포기되어야 한다.
• 중간 조치로, 사용자 에이전트는 여러 수준의 구를 감지하여, 더 긴 구가 오버플로를 유발할 때 더 짧은 구(가능하면 개별 단어까지)를 선택할 수도 있다.

word-break: keep-all 및 word-break: auto-phrase에 의해 도입된 제한을 완화하여 얻은 소프트 줄바꿈 기회는 min-content 내재 크기를 계산할 때 고려되지 않는다.

anywhere

그렇지 않으면 나눌 수 없는 문자 시퀀스는 줄에 달리 허용 가능한 나누기 지점이 없는 경우 임의의 지점에서 나뉠 수 있다. 셰이핑 문자는 여전히 단어가 나뉘지 않은 것처럼 셰이핑되며, 자소 클러스터는 하나의 단위로 함께 유지되어야 한다. 나누기 지점에 하이픈 넣기 문자는 삽입되지 않는다. anywhere에 의해 도입된 소프트 줄바꿈 기회는 min-content 내재 크기를 계산할 때 고려된다.

word-break: auto-phrase의 경우, 이러한 추가 소프트 줄바꿈 기회는 overflow-wrap: normal에서 설명한 대로 word-break: auto-phrase에 의해 도입된 제한을 완화하는 것으로도 오버플로를 방지하기에 충분하지 않은 경우에만 도입된다.

break-word

anywhere와 같지만, break-word에 의해 도입된 소프트 줄바꿈 기회는 min-content 내재 크기를 계산할 때 고려되지 않는다.

overflow-wrap에 none 값을 추가하여, overflow-wrap: normal이 허용하는 keep-all 및 auto-phrase 제한 완화를 opt out할 필요가 있는가?

레거시 이유로, UA는 word-wrap을 overflow-wrap 속성의 레거시 이름 별칭으로 처리해야 한다.

6.5. 줄 나누기 세부 사항

줄 나누기를 결정할 때:

• 줄 나누기와 양방향 텍스트의 상호작용은 CSS Writing Modes 4 § 2.4 Applying the Bidirectional Reordering Algorithm 및 Unicode Bidirectional Algorithm (특히 UAX9§3.4 Reordering Resolved Levels)에 의해 정의된다. [CSS-WRITING-MODES-4] [UAX9]
• 보존된 세그먼트 나누기, 그리고—​white-space 값과 관계없이—​BK 및 NL 줄 나누기 클래스를 가진 모든 Unicode 문자는 강제 줄 나누기로 처리되어야 한다. [UAX14]

  참고: 이러한 강제 줄 나누기의 bidi 관련 의미는 Unicode Bidirectional Algorithm에 의해 정의된다. [UAX9]

• 명시적으로 달리 정의된 경우를 제외하고 (예: line-break: anywhere 또는 overflow-wrap: anywhere) CM, 및 SG, WJ, ZW, GL, ZWJ Unicode 줄 나누기 클래스에 대해 정의된 줄 나누기 동작은 준수되어야 한다. [UAX14]
• CSS는 조판 문자 단위 내부의 소프트 줄바꿈 기회를 절대 허용하지 않는다. 따라서 CM 및 SG Unicode 줄 나누기 클래스는 항상 준수되어야 한다. [UAX14]
• 이를 사용하는 문자 체계에서 단어 구분자 이외의 문장부호에서 줄바꿈을 허용하는 UA는 나누기 지점에 우선순위를 두는 것이 좋다. (예를 들어, 슬래시 뒤 나누기가 공백보다 낮은 우선순위를 받는다면, 시퀀스 “check /etc”는 "/"와 "e" 사이에서 절대 나뉘지 않는다.) 그러한 어색한 나누기를 피하도록 주의하는 한, 단어 구분자가 아닌 적절한 문장부호에서 나누기를 허용하는 것이 권장되며, 특히 좁은 측정값에서 더 고르게 보이는 여백을 만들기 때문이다. UA는 우선순위를 할당할 때 포함 블록의 너비, 텍스트의 언어, line-break 값, 및 기타 요소를 사용할 수 있다: CSS는 소프트 줄바꿈 기회의 우선순위를 정의하지 않는다. 그러나 word-break: break-all이 지정된 경우 단어 구분자의 우선순위 지정은 기대되지 않는다 (이 값은 단어 구분자에서 나누는 것에 기반하지 않는 줄 나누기 동작을 명시적으로 요청하기 때문)—​그리고 line-break: anywhere에서는 금지된다.
• Out-of-flow 박스와 인라인 박스 경계는 흐름 안에 강제 줄 나누기나 소프트 줄바꿈 기회를 도입하지 않는다.
• Web 호환성을 위해 각 replaced element 또는 다른 atomic inline의 앞뒤에는 U+00A0 NO-BREAK SPACE를 포함하여 보통 이를 억제할 문자와 인접하더라도 소프트 줄바꿈 기회가 있다. 그러나 U+00A0 NO-BREAK SPACE를 제외하면, atomic inline과 Unicode GL, WJ, ZWJ 줄 나누기 클래스에 속하는 인접 문자 사이에는 소프트 줄바꿈 기회가 없어야 한다. [UAX14]
• 줄 나누기에서 사라지는 문자 (예: U+0020 SPACE)가 만든 소프트 줄바꿈 기회의 경우, 해당 문자를 직접 포함하는 박스의 속성이 그 기회에서의 줄 나누기를 제어한다. 두 문자 또는 atomic inline 사이의 경계로 정의된 소프트 줄바꿈 기회의 경우, 두 문자의 가장 가까운 공통 조상에 있는 white-space 속성이 나누기를 제어한다; 그러한 경계에서 소프트 줄바꿈 기회의 결정을 어떤 요소의 line-break, word-break, 및 overflow-wrap 속성이 제어하는지는 이 레벨에서 정의되지 않는다.
• 박스의 첫 번째 문자 앞 또는 마지막 문자 뒤의 소프트 줄바꿈 기회의 경우, 나누기는 박스를 콘텐츠 가장자리와 콘텐츠 사이에서 나누는 것이 아니라 박스 바로 앞/뒤에서 (그 margin edge에서) 발생한다.
• Ruby 안/주변의 줄 나누기는 CSS Ruby Annotation Layout 1 § 3.4 Breaking Across Lines에서 정의된다. [CSS-RUBY-1]
• 아랍 문자와 같은 셰이핑 문자 체계가 단어 내부의 강제되지 않은 소프트 줄바꿈 기회에서 줄바꿈될 때 (예: word-break: break-all, line-break: anywhere, overflow-wrap: break-word, overflow-wrap: anywhere, 또는 하이픈 넣기로 인한 나누기), 문자는 여전히 (결합 형태가 선택되어) 단어가 여전히 온전한 것처럼 셰이핑되어야 한다.
  예를 들어, 단어 “نوشتن”이 “ش”와 “ت” 사이에서 나뉘는 경우, “ش”는 여전히 초성형(“ﺷ”)을 취하고, “ت”는 중성형(“ﺘ”)을 취한다—​즉 “نوش | تن”이 아니라 “ﻧﻮﺷ | ﺘﻦ”처럼 형성된다.

7. 정렬과 양쪽 맞춤

정렬과 양쪽 맞춤은 인라인 콘텐츠가 줄 박스 안에서 어떻게 분배되는지를 제어한다.

7.1. 텍스트 정렬: text-align 단축 속성

이 단축 속성은 text-align-all 및 text-align-last 속성을 설정하며, 콘텐츠가 줄 박스를 완전히 채우지 않을 때 블록의 인라인 수준 콘텐츠가 인라인 축을 따라 어떻게 정렬되는지를 설명한다. justify-all 또는 match-parent 이외의 값은 text-align-all에 할당되고 text-align-last를 auto로 재설정한다.

값은 다음 의미를 가진다:

start

인라인 수준 콘텐츠는 줄 박스의 start 가장자리에 정렬된다.

end

인라인 수준 콘텐츠는 줄 박스의 end 가장자리에 정렬된다.

left

인라인 수준 콘텐츠는 줄 박스의 line-left 가장자리에 정렬된다. (세로 쓰기 모드에서는, writing-mode에 따라 이는 물리적 위쪽 또는 아래쪽 중 하나일 수 있다.) [CSS-WRITING-MODES-4]

right

인라인 수준 콘텐츠는 줄 박스의 line-right 가장자리에 정렬된다. (세로 쓰기 모드에서는, writing-mode에 따라 이는 물리적 위쪽 또는 아래쪽 중 하나일 수 있다.) [CSS-WRITING-MODES-4]

center

인라인 수준 콘텐츠는 줄 박스 안에서 가운데 정렬된다.

<string>

문자열은 단일 문자여야 한다; 그렇지 않으면 선언은 유효하지 않으며 무시되어야 한다. 표 셀에 적용될 때, 셀의 내용이 그 주변으로 정렬될 정렬 문자를 지정한다. 자세한 내용과 이 값이 키워드와 어떻게 결합되는지는 아래를 참조하라.

justify

줄 박스를 정확히 채우기 위해 text-justify 속성이 지정한 방식에 따라 텍스트가 양쪽 맞춤된다. text-align-last에 의해 달리 지정되지 않는 한, 강제 줄 나누기 앞의 마지막 줄은 start 정렬된다.

justify-all

text-align-all과 text-align-last를 모두 justify로 설정하여, 마지막 줄도 양쪽 맞춤하도록 강제한다.

match-parent

이 값은 inherit와 동일하게 동작하지만 (부모의 계산값으로 계산됨), start 또는 end의 상속값은 부모의 direction 값에 대해 해석되어, left 또는 right 중 하나의 계산값이 된다. 루트 요소에 지정되면 start로 계산된다.

text-align 단축 속성에 지정되면, text-align-all과 text-align-last를 모두 match-parent로 설정한다.

텍스트 블록은 줄 박스의 스택이다. 이 속성은 각 줄 박스 안의 인라인 수준 박스가 줄 박스의 시작쪽과 끝쪽에 대해 어떻게 정렬되는지를 지정한다. 정렬은 viewport 또는 포함 블록에 대한 것이 아니다.

justify의 경우, UA는 텍스트를 조정하여 어떤 인라인 박스든 늘리거나 줄일 수 있다. (text-justify 참조.) 요소의 공백이 병합 가능하지 않다면, UA는 양쪽 맞춤을 위해 그 텍스트를 조정할 필요가 없으며, 대신 그 텍스트에 양쪽 맞춤 기회가 없는 것으로 처리할 수 있다. UA가 텍스트를 조정하기로 선택한 경우, 공백 처리 규칙이 요구하는 대로 탭 정지점이 계속 맞춰지도록 보장해야 한다.

(양쪽 맞춤이 있다면 그 이후에) 줄 박스의 인라인 내용이 그 안에 맞기에는 너무 길다면, 내용은 start 정렬된다: 맞지 않는 모든 콘텐츠는 줄 박스의 end 가장자리로 오버플로된다.

줄 박스의 start 및 end 가장자리를 결정하는 방법에 대한 자세한 내용은 § 9.3 양방향성과 줄 박스를 참조하라.

7.2. 표 열에서의 문자 기반 정렬

열 안의 여러 셀이 정렬 문자를 지정한 경우, 그 열의 각 해당 셀의 정렬 문자는 단일 열-평행 축을 따라 가운데에 맞춰지고 열 안의 나머지 텍스트는 그에 따라 이동된다. (문자열이 각 셀마다 같을 필요는 없지만, 보통은 같다는 점에 유의하라.)

이것은 정렬 문자의 중심들이 정렬되어야 한다는 뜻인가? 그것이 말하는 바가 명확하지 않지만, 서로 다른 정렬 문자 발생이 서로 다른 글꼴 안에 있을 때 무슨 일이 일어나는지를 설명하려면, 그것(또는 다른 동작)이 명시되어야 한다. (더 나아가, 이것이 의도된 동작인가? 아마 고려해야 할 가장 중요한 사용 사례는 굵은 텍스트와 보통 텍스트의 차이이며, 이는 폭이 조금만 다르다.) [피드백] [2016-02-02 10:00 AM 대면 회의 의사록]

TD { text-align: "." center }

<TABLE>
<COL width="40">
<TR> <TH>Long distance calls
<TR> <TD> $1.30
<TR> <TD> $2.50
<TR> <TD> $10.80
<TR> <TD> $111.01
<TR> <TD> $85.
<TR> <TD> N/A
<TR> <TD> $.05
<TR> <TD> $.06
</TABLE>

+---------------------+
| Long distance calls |
+---------------------+
|         $1.30       |
|         $2.50       |
|        $10.80       |
|       $111.01       |
|        $85.         |
|        N/A          |
|          $.05       |
|          $.06       |
+---------------------+

키워드 값은 <string> 값과 함께 지정될 수 있으며; 주어지지 않으면 기본값은 right이다. 이 값은 다음 경우에 사용된다:

• 문자 기반 정렬이 표 셀이 아닌 박스에 적용될 때.
• 텍스트가 여러 줄로 줄바꿈될 때(강제되지 않은 나누기 지점에서).
• 문자 정렬된 셀이 둘 이상의 열에 걸칠 때. 이 경우 키워드 정렬 값은 어느 열의 축에 맞출지를 결정하는 데 사용된다: left의 경우 가장 왼쪽 열, right 및 center의 경우 가장 오른쪽 열, start의 경우 가장 start 쪽 열, end의 경우 가장 end 쪽 열.
• 열이 충분히 넓어서 문자 정렬만으로는 문자 정렬된 내용의 위치가 결정되지 않을 때. 이 경우 지정된 정렬 문자를 가진 열의 첫 번째 셀의 키워드 정렬이 문자 정렬된 내용의 위치를 이동시켜, 열 너비를 바꾸지 않는 범위에서 키워드 정렬과 일치하도록 하는 데 사용된다. center의 경우, UA는 정렬된 내용을 그 극단을 사용하여 가운데 정렬하거나, 정렬 축 자체를(가능한 한) 가운데 정렬하거나, 또는 다른 방식으로 (예: 축의 양쪽에 있는 셀 내용 범위의 가중 평균을 취함으로써) 정렬된 내용을 시각적으로 가운데 정렬할 수 있다.

참고: 문자 기반 정렬에서는 기본적으로 오른쪽 정렬이 사용된다. 숫자 체계는 오른쪽에서 왼쪽으로 쓰는 문자 체계에서도 거의 모두 왼쪽에서 오른쪽으로 쓰이며, 문자 기반 정렬의 주요 사용 사례가 숫자 정렬이기 때문이다.

정렬 문자가 텍스트에 둘 이상 나타나면, 첫 번째 인스턴스가 정렬에 사용된다. 정렬 문자가 셀 안에 전혀 나타나지 않으면, 문자열은 정렬 문자가 내용의 끝에 삽입된 것처럼 정렬된다.

이는 정렬 문자를 찾기 위해 검색되는 텍스트가 무엇인지 명시해야 한다. 셀을 containing block으로 가지는 in-flow 텍스트만인가? 아니면 셀이 형성한 block formatting context 안의 모든 in-flow descendant 안의 텍스트도 고려되는가? 그렇다면 그것은 그 text-align 속성이 셀의 것과 일관되는 동안에만 고려되는가? (정렬 문자에서 일관되는가, 아니면 완전히 일관되는가?)

정렬 문자가 셀 내용의 끝에 삽입된 것처럼 정렬하는 이 동작은, 문자 중심 정렬과 결합될 때, 열의 어느 줄에도 정렬 문자가 없거나, 더 중요하게는 어떤 줄에는 정렬 문자가 있지만 열이 max-content 너비로 배치되지 않은 경우, <string> 텍스트 정렬이 적용된 줄의 end 쪽에 빈틈을 만들 것이다. 이는 아마 바람직하지 않다.

정렬 문자가 내용의 끝에 삽입될 때, 어떤 글꼴이 사용되는가? (특히 정렬 문자가 descendant block 안에 있을 수 있다면, 그 블록의 글꼴인가, 아니면 표 셀의 글꼴인가? 또는 삽입이 인라인 안의 강제 나누기 위치라면, 인라인의 글꼴을 사용하는가, 아니면 블록이나 셀의 글꼴을 사용하는가?)

문자 기반 정렬은 표 셀 너비 계산 이전에 발생하므로, auto 너비 계산은 정렬을 위한 충분한 공간을 남길 수 있다. 열에 걸치는 셀이 너비 계산 이전 또는 이후에 정렬에 참여하는지는 정의되지 않는다. 셀 내용에 대한 너비 제약이 열 전체의 완전한 정렬을 방해한다면, 결과 정렬은 정의되지 않는다.

이는 문자 정렬이 (표 열 및 표 열 안에 있을 수 있는 모든 콘텐츠의) min-content 및 max-content 내재 너비에 어떻게 영향을 주는지에 대한 형식적 정의를 가져야 한다. Max-content 내재 너비는 세 숫자로 나뉘어야 한다(정렬 문자의 중심이 정렬된다고 가정): 하나는 정렬 문자가 없는 너비, 하나는 정렬 문자 중심의 inline-start 쪽 너비, 하나는 정렬 문자 중심의 inline-end 쪽 너비이다. 이는 max-content 너비에 대해 강제 나누기 사이의 모든 텍스트 세그먼트를 기반으로 작동한다. Min-content 너비의 경우, 그 안에 선택적 나누기가 있는 강제 나누기 사이의 텍스트 세그먼트는 명확히 정렬 문자가 없는 너비에만 기여해야 한다. 그러나 모든 min-content 너비가 이런 방식으로 작동해야 하는지, 아니면 선택적 나누기가 없는 강제 나누기 사이의 세그먼트 (그리고 아마 실제로 정렬 문자를 포함하는 세그먼트만)가 대신 정렬 문자 start 쪽 및 end 쪽 min-content 너비에 기여해야 하는지는 덜 명확하다; 이 선택은 표의 min-content 크기 산정이 가장 좁은 합리적 크기를 의미하는 것과 더 많은 경우에 정렬 문자를 존중하는 것 사이의 절충이다. 또 다른 옵션은 선택적 나누기의 줄 나누기가 허용되는지 여부를 어떤 동작을 사용할지에 대한 제어로 삼는 것일 수 있다.

<string> 값을 가진 열에 걸치는 셀의 text-align에 대한 내재 너비 기여를 형식적으로 정의하는 것은 열에 걸치지 않는 셀의 내재 너비 기여에 대해 내려진 결정을 복잡하지만(비록 직접적이지만) 확장하는 것이며; 이것도 형식적으로 정의되어야 한다. 기여는 결국 (정렬에 사용되는) start 쪽 또는 end 쪽 열의 분할된 내재 너비에, 그리고 다른 span된 열의 정렬 문자 없는 내재 너비에 이루어진다.

7.3. 기본 텍스트 정렬: text-align-all 속성

text-align 단축 속성의 이 longhand는 text-align-last의 non-auto 값에 의해 재정의되는 마지막 줄을 제외하고, 블록 컨테이너 안의 인라인 콘텐츠의 모든 줄에 대한 인라인 정렬을 지정한다. 값에 대한 전체 설명은 text-align을 참조하라.

작성자는 이 속성 대신 text-align 단축 속성을 사용해야 한다.

7.4. 마지막 줄 정렬: text-align-last 속성

이 속성은 블록의 마지막 줄 또는 강제 줄 나누기 바로 앞의 줄이 어떻게 정렬되는지를 설명한다.

auto가 지정되면, 영향을 받는 줄의 콘텐츠는 text-align-all에 따라 정렬된다. 단, text-align-all이 justify로 설정된 경우에는, start 정렬된다. 다른 모든 값은 text-align에서 설명한 대로 해석된다.

7.5. 양쪽 맞춤 방식: text-justify 속성

이 속성은 줄의 정렬이 justify로 설정될 때 사용되는 양쪽 맞춤 방식을 선택한다 (text-align 참조). 이 속성은 텍스트에 적용되지만, 블록 컨테이너에서 그 인라인 수준 콘텐츠를 포함하는 루트 인라인 박스로 상속된다. 이는 다음 값을 가진다:

auto

UA는 성능과 충분한 표시 품질 사이의 균형에 기반하여 따를 양쪽 맞춤 알고리즘을 결정한다. 양쪽 맞춤 규칙은 writing system과 언어에 따라 다르므로, UA는 가능하면 텍스트에 적합한 양쪽 맞춤 알고리즘을 사용해야 한다.

예를 들어, UA는 기본적으로 모든 writing system을 위한 단순한 보편적 절충안인 양쪽 맞춤 방식을 사용할 수 있다—​예를 들어 주로 단어 구분자와 CJK 조판 글자 단위 사이를 확장하고, 보조적으로는 동남아시아 조판 글자 단위 사이를 확장하는 방식이다. 그러고 나서, 단락의 콘텐츠 언어가 알려진 경우에는, 더 언어 맞춤형 양쪽 맞춤 동작을 선택할 수 있다. 예를 들어 일본어에는 Requirements for Japanese Text Layout를 따르고 [JLREQ], 아랍어에는 필기체 확장을 사용하고, 독일어에는 inter-word를 사용하는 식이다.

none

양쪽 맞춤은 비활성화된다: 텍스트 안에 양쪽 맞춤 기회가 없다.

참고: 이 값은 가독성 향상이나 접근성 목적을 위해 사용자 스타일시트에서 사용하는 것을 의도한다.

inter-word

양쪽 맞춤은 단어 구분자에서만 간격을 조정한다 (사실상 줄의 used word-spacing을 변화시킴). 이 동작은 영어나 한국어처럼 공백을 사용하여 단어를 구분하는 언어에서 일반적이다.

inter-character

양쪽 맞춤은 인접한 조판 문자 단위의 각 쌍 사이에서 간격을 조정한다 (사실상 줄의 used letter-spacing을 변화시킴). 이 값은 일본어 같은 동아시아 체계에서 때때로 사용된다.

레거시 이유로, UA는 대체 키워드 distribute도 지원해야 하며, 이는 inter-character로 계산되어야 하고, 따라서 정확히 동일한 의미와 동작을 가진다. UA는 이를 레거시 값 별칭으로 처리할 수 있다.

ruby

양쪽 맞춤은 auto와 같이 간격을 조정하되, 다음은 예외이다:

• 단어 구분자에서는 양쪽 맞춤 기회가 비활성화된다.

• Bopomofo 문자 사이에서는 양쪽 맞춤 기회가 비활성화된다.

참고: 이 값은 ruby 주석에서 사용되어, 합리적인 기본 정렬을 제공하기 위한 것이다. [CSS-RUBY-1]을 참조하라.

no-compress

양쪽 맞춤은 text-spacing-trim 또는 text-autospace가 제어하는 간격을 압축해서는 안 된다. (이 값이 지정되지 않은 경우, 양쪽 맞춤 과정은 그 간격이 줄의 시작이나 끝에 있는 경우를 제외하고 그러한 간격을 줄일 수 있다.)

참고: 압축 규칙의 예는 일본어의 경우 [JLREQ]의 3.8 Line Adjustment에 제시되어 있다.

이 키워드는 이전에 text-spacing의 일부였다; 이제 여기에 있으므로 더 구체적으로 이름을 바꿀 필요가 있을 수 있다. 예컨대 U+0020도 압축될 수 없다는 뜻으로 보이기 때문이다. [Issue #7079]

최적의 양쪽 맞춤은 언어에 민감하므로, 작성자는 최상의 결과를 위해 자신의 콘텐츠에 올바른 언어 태그를 지정해야 한다.

참고: 이 CSS 레벨의 지침은 완전한 양쪽 맞춤 알고리즘을 설명하지 않는다. 이는 완전한 알고리즘이 충족해야 하는 최소 요구사항 집합일 뿐이다. 요구사항 집합을 제한하면 UA가 자신의 필요와 품질, 속도, 복잡도 사이의 원하는 균형을 충족하는 양쪽 맞춤 알고리즘을 선택할 여지를 갖게 된다.

7.5.1. 텍스트 확장과 압축

텍스트를 양쪽 맞춤할 때, 사용자 에이전트는 줄 콘텐츠의 끝과 그 줄 박스의 가장자리 사이에 남은 공간을 가져와, 그 공간을 콘텐츠 전체에 분배하여 콘텐츠가 줄 박스를 정확히 채우도록 한다. 사용자 에이전트는 대안적으로 음의 공간을 분배하여, 정상 간격 조건에서라면 맞지 않을 더 많은 콘텐츠를 줄에 넣을 수도 있다.

양쪽 맞춤 기회는 양쪽 맞춤 알고리즘이 텍스트 내 간격을 변경할 수 있는 지점이다. 양쪽 맞춤 기회는 (단어 구분자 같은) 단일 조판 문자 단위에 의해 제공될 수도 있고, 두 조판 문자 단위의 병치에 의해 제공될 수도 있다. 소프트 줄바꿈 기회에 대한 제어와 마찬가지로, 조판 문자 단위가 양쪽 맞춤 기회를 제공하는지 여부는 그 부모의 text-justify 값에 의해 제어된다; 마찬가지로, 두 연속된 조판 문자 단위 사이에 양쪽 맞춤 기회가 존재하는지 여부는 그들의 가장 가까운 공통 조상의 text-justify 값에 의해 결정된다.

양쪽 맞춤에 의해 분배되는 공간은 letter-spacing 또는 word-spacing 속성이 정의하는 간격에 추가되는 것이다. 그러한 추가 공간이 단어 구분자 양쪽 맞춤 기회에 분배될 때, 이는 word-spacing에 대한 것과 동일한 규칙에 따라 적용된다. 마찬가지로, 공간이 두 조판 문자 단위 사이의 양쪽 맞춤 기회에 분배될 때, letter-spacing에 대한 것과 동일한 규칙에 따라 적용되어야 한다.

양쪽 맞춤 알고리즘은 양쪽 맞춤 기회를 서로 다른 우선순위 수준으로 나눌 수 있다. 주어진 수준 안의 모든 양쪽 맞춤 기회는 어떤 조판 문자 단위가 그 기회를 만들었는지와 관계없이 같은 우선순위로 확장되거나 압축된다. 예를 들어, 두 한자 사이의 양쪽 맞춤 기회와 두 라틴 글자 사이의 양쪽 맞춤 기회가 같은 수준으로 정의되어 있다면 (inter-character 양쪽 맞춤 스타일에서 그러하듯), 그들은 서로 다른 조판 문자 단위에서 비롯되었다는 이유로 다르게 취급되지 않는다. 이 레벨에서는 줄 안에서 양쪽 맞춤 기회에 공간을 분배할 때 다른 요소들 (예: 글꼴 크기, letter-spacing, 글리프 모양, 줄 안의 위치 등)이 영향을 줄 수 있는지 또는 어떻게 영향을 주는지는 정의되지 않는다.

UA는 어떤 방식에서든 텍스트 양쪽 맞춤을 돕기 위해 선택적 합자를 활성화하거나 깨거나, 대체 글리프 또는 글리프 압축 같은 다른 글꼴 기능을 사용할 수 있다. 이 동작은 이 CSS 레벨에서 제어되지 않는다. 그러나 UA는 필수 합자를 깨거나, 복잡한 문자 체계를 올바르게 셰이핑하는 데 필요한 기능을 비활성화해서는 안 된다.

줄 안에 양쪽 맞춤 기회가 존재하고, 텍스트 정렬이 그 줄에 대해 완전한 양쪽 맞춤 (justify)을 지정한다면, 그 줄은 양쪽 맞춤되어야 한다.

7.5.2. 기호와 문장부호 처리

양쪽 맞춤 기회를 결정할 때, Unicode Symbols (S*) 및 Punctuation (P*) 클래스의 조판 문자 단위는 일반적으로 같은 스크립트의 조판 글자 단위와 동일하게 취급된다 (또는, 문자의 script 속성이 Common이라면, 지배적 스크립트의 조판 글자 단위로 취급된다).

그러나 조판 전통상 기호와 문장부호의 양쪽 맞춤을 제어하는 추가 규칙이 있을 수 있다. 따라서 UA는 기호 및 문장부호와 관련된 양쪽 맞춤 기회를 처리하기 위해 특정 문자를 재할당하거나 추가적인 우선순위 수준을 도입할 수 있다.

7.5.3. 확장할 수 없는 텍스트

줄의 인라인 내용을 줄 박스의 전체 너비까지 늘릴 수 없다면, 그 내용은 text-align-last 속성이 지정한 대로 정렬되어야 한다. (text-align-last가 justify이면, center와 같이 정렬되어야 한다.)

7.5.4. 필기체 문자 체계

양쪽 맞춤은 아랍어와 같은 필기체 문자 체계의 결합된 조판 글자 단위 사이에 간격을 도입해서는 안 된다. 가능하다면, UA는 그러한 조판 글자 단위의 run 내부의 양쪽 맞춤 기회에 분배된 공간을 그 run을 위한 어떤 형태의 필기체 확장으로 변환할 수 있다. 그렇지 않으면 필기체 문자 체계 안의 조판 글자 단위 쌍 사이에는 (그들이 결합하는지 여부와 관계없이) 양쪽 맞춤 기회가 존재하지 않는다고 가정해야 한다.

다음은 허용되지 않는 양쪽 맞춤의 예이다:

일부 글꼴 디자인은 양쪽 맞춤을 위해 tatweel 문자를 사용할 수 있도록 한다. tatweel 기반 양쪽 맞춤을 수행하는 UA는 그 사용 규칙을 올바르게 처리해야 한다. tatweel 문자의 올바른 삽입은 문맥, 관련된 글자 조합, 단어 안의 위치, 그리고 줄 안에서 단어의 위치에 따라 달라진다는 점에 유의하라.

7.5.5. auto 양쪽 맞춤을 위한 최소 요구사항

auto 양쪽 맞춤에 대해, 이 명세는 모든 양쪽 맞춤 기회가 무엇인지, 그것들이 어떻게 우선순위화되는지, 또는 여러 수준의 양쪽 맞춤 기회가 언제 어떻게 상호작용하는지를 정의하지 않는다. 그러나 다음을 요구한다:

• 콘텐츠 언어의 조판 전통이나 인접한 기호/문장부호에 의해 반대되는 경우가 아니라면, 다음 각각은 양쪽 맞춤 기회를 제공한다:
  • 단어 구분자
  • 모든 block scripts의 조판 문자 단위와 다른 모든 조판 문자 단위 사이의 경계
  • 모든 clustered scripts의 조판 문자 단위와 다른 모든 조판 문자 단위 사이의 경계
• 모든 block scripts에 속하는 모든 letter는 동일하게 취급되고, 모든 clustered scripts에 속하는 모든 letter도 동일하게 취급된다. 예를 들어, 한자 글자 뒤에 또 다른 한자 글자가 오는 경우의 양쪽 맞춤 기회와, 한자 글자 뒤에 한글 글자가 오는 경우의 양쪽 맞춤 기회 사이에는 구분이 없다.

텍스트 양쪽 맞춤에 대한 추가 정보는 writing system 및 언어별로 색인화되어 있고 W3C 국제화 작업 그룹이 관리하는 “Approaches to Full Justification”에서 찾을 수 있다(또는 제출할 수 있다). [JUSTIFY]

7.6. 컨테이너 안에서 텍스트 블록 정렬: text-group-align 속성

이 속성은 텍스트 정렬을 유지하면서 줄 박스의 내용을 그룹으로 정렬한다.

그룹 정렬은 남은 공간이 가장 짧은 줄 박스를 찾고, 그 공간만큼을 줄 박스의 한쪽 또는 양쪽에 padding으로 추가하여 그 내용에 사용할 수 있는 공간의 양을 줄인 다음; 텍스트 정렬을 남은 공간 안에서 그 내용에 적용함으로써 수행된다. 같은 block formatting context 안의 모든 descendant in-flow 줄 박스는 가장 짧은 남은 공간을 찾을 때와 padding을 추가할 때 모두 고려된다; 독립 서식 맥락을 형성하는 descendant의 내용은 건너뛴다.

이 속성의 변형은 상속되며, 각 블록 컨테이너에 개별적으로 적용되고, 그 블록의 직접 자식인 줄 박스에만 영향을 준다. 이는 덜 유용하지만, 아마 구현하기는 더 쉬울 것이다.

같은 블록 컨테이너에서 비롯된 float도 같은 양만큼 어떻게든 함께 이동시키면 더 보기 좋게 맞춰질 것이며, 이는 특히 CJK 레이아웃에서 가치가 있을 것이다. 그것이 정확히 어떻게 동작하는지, 그리고 조상 요소에서 침범해 오는 float와 어떻게 상호작용하는지는 독자에게 연습 문제로 남긴다.

값은 다음 의미를 가진다:

none

텍스트 정렬은 정상적으로 일어난다: 그룹 정렬은 수행되지 않는다.

start

인라인 수준 콘텐츠는 각 줄 박스의 inline end 쪽에 padding을 넣음으로써, 그룹 정렬되어 inline start 쪽에 맞춰진다.

end

인라인 수준 콘텐츠는 각 줄 박스의 inline start 쪽에 padding을 넣음으로써, 그룹 정렬되어 inline end 쪽에 맞춰진다.

left

인라인 수준 콘텐츠는 각 줄 박스의 line-right 쪽에 padding을 넣음으로써, 그룹 정렬되어 line-left 쪽에 맞춰진다.

right

인라인 수준 콘텐츠는 각 줄 박스의 line-left 쪽에 padding을 넣음으로써, 그룹 정렬되어 line-right 쪽에 맞춰진다.

center

인라인 수준 콘텐츠는 각 줄 박스의 양쪽에 padding을 넣고, 간격을 양쪽에 절반씩 배분함으로써, 가운데에 그룹 정렬된다.

8. 간격

CSS는 word-spacing, letter-spacing, 및 line-padding 속성을 통해 일반 텍스트 간격을 제어할 수 있게 하며, 이들은 각각 단어 구분자 주변, 조판 문자 단위 사이, 또는 줄의 시작/끝에 추가 공간을 지정한다. 또한 text-spacing-trim 속성을 통해 문맥적 간격 제어를 제공하며, 이는 CJK 문장부호의 문맥적 전각/반각 설정을 허용한다; 그리고 text-autospace 속성은 문자 체계가 바뀌는 지점이나 문장부호 주변에 추가 공간을 자동 삽입할 수 있게 한다.

8.1. 단어 간격: word-spacing 속성

이 속성은 “단어” 사이의 추가 간격을 지정한다. 값은 아래 정의된 대로 해석된다:

normal

추가 간격이 적용되지 않는다. 0으로 계산된다.

<length-percentage>

글꼴이 정의한 고유 단어 간 간격에 추가되는 여분의 간격을 지정한다.

참고: 백분율은 그대로 상속되며, 현재 요소의 used font-size에 대해 해석된다 (따라서 적용되는 텍스트의 크기에 상대적인 크기를 나타낸다). 이는 절대 길이로서, 상속된 요소의 계산된 font-size에 대해 해석되는 em 단위와 다르다.

추가 간격은 공백 처리 규칙이 적용된 뒤 텍스트에 남아 있는 각 단어 구분자에 적용되며, 조판 전통이 달리 지시하지 않는 한 문자 양쪽에 절반씩 적용되어야 한다. 값은 음수일 수 있지만, 구현에 따라 제한이 있을 수 있다.

단어 구분자 문자는 주된 목적과 일반적 사용이 단어를 구분하는 것인 조판 문자 단위이다. Unicode에서는 (완전한 정의는 아니지만) space (U+0020), no-break space (U+00A0), Ethiopic word space (U+1361), Aegean word separators (U+10100,U+10101), Ugaritic word divider (U+1039F), 및 Phoenician word separator (U+1091F)를 포함한다. [UNICODE]

참고: 일반적인 문장부호나 고정폭 공백(예: U+3000 및 U+2000부터 U+200A까지)은 단어 구분자 문자로 간주되지 않는다. 이들은 단어를 구분하는 일이 자주 있더라도, 그 주된 목적이 단어를 구분하는 것이 아니기 때문이다.

단어 구분자 문자가 없거나, 단어를 구분하는 문자가 advance width가 0인 경우 (예: U+200B ZERO WIDTH SPACE), 사용자 에이전트는 단어 사이에 추가 간격을 만들지 말아야 한다.

8.2. 자간 조정: letter-spacing 속성

이 속성은 인접한 조판 문자 단위 사이의 추가 간격 (일반적으로 tracking이라고 함)을 지정한다. Letter-spacing은 bidi 재정렬 이후에 적용되며, kerning 및 word-spacing에 추가된다. [CSS-WRITING-MODES-4] [CSS-FONTS-3] 적용 중인 양쪽 맞춤 규칙에 따라, 사용자 에이전트는 텍스트를 양쪽 맞춤하기 위해 조판 문자 단위 사이의 공간을 더 늘리거나 줄일 수 있다.

값은 다음 의미를 가진다:

normal

추가 간격이 적용되지 않는다. 0으로 계산된다.

<length-percentage>

조판 문자 단위 사이의 추가 간격을 지정한다. 값은 음수일 수 있지만, 구현에 따라 제한이 있을 수 있다.

참고: 백분율은 그대로 상속되며, 현재 요소의 used font-size에 대해 해석된다 (따라서 적용되는 텍스트의 크기에 상대적인 크기를 나타낸다). 이는 절대 길이로서, 상속된 요소의 계산된 font-size에 대해 해석되는 em 단위와 다르다.

레거시 이유로, 0의 계산된 letter-spacing은 resolved value (getComputedStyle() 반환값)로 normal을 산출한다.

letter-spacing의 목적상, atomic inline (이미지 및 인라인 블록 등)의 각 연속 run은 하나의 조판 문자 단위로 처리된다.

Letter-spacing은 줄의 시작에 적용되어서는 안 된다. 줄의 끝에 letter-spacing이 적용되는지는 이 레벨에서 정의되지 않는다.

p { letter-spacing: 1em; }

<p>abc</p>

두 조판 문자 단위 사이의 letter spacing은 사실상 두 조판 문자 단위를 포함하는 가장 안쪽 요소에 “속한다”: (bidi 재정렬 이후) 인접한 두 조판 문자 단위 사이의 총 letter spacing은 두 조판 문자 단위 사이의 경계를 포함하는 가장 안쪽 요소에 의해 지정되고 그 안에서 렌더링된다. 그러나 UA는 대신 요소 경계의 letter-spacing을 그 포함 요소에 관련된 letter-spacing 값을 사용하여 어느 한쪽 조판 문자 단위에 붙일 수 있다.

참고: 이 보조 동작은 Web 호환성 문제로 인해 이 레벨에서 허용된다.

p { letter-spacing: 1em; }

<p>a<span>bb</span>c</p>

p    { letter-spacing: 1em; }
span { letter-spacing: 2em; }

<p>a<span>bb</span>c</p>

p    { letter-spacing: 1em; }
span { letter-spacing: 2em; }

<p>a<span>b</span>c</p>

p    { letter-spacing: 1em; }
span { letter-spacing: 2em; }

<!-- abc followed by Hebrew letters alef (א), bet (ב) and gimel (ג) -->
<!-- Reordering will display these in reverse order. -->
<p>ab<span>cא</span>בג</p>

Letter spacing은 보이지 않는 zero-width 서식 문자 (예: Unicode Cf 범주의 문자)를 무시한다. 간격은 그러한 문자가 문서에 존재하지 않는 것처럼 추가되어야 한다.

두 문자 사이의 유효 간격이 0이 아닌 경우 (양쪽 맞춤 또는 letter-spacing의 non-zero 값 때문), 사용자 에이전트는 선택적 합자, 즉 근본적으로 올바른 글리프 셰이핑을 위해 필수라고 정의되지 않은 합자를 적용하지 않는 것이 좋다. 그러나 저수준 font-feature-settings 속성을 통해 지정된 합자 및 기타 글꼴 기능은 이 규칙보다 우선한다. CSS Fonts Module Level 3 § feature-precedence를 참조하라.

참고: OpenType에서 필수 합자는 rlig 기능과 관련될 것으로 기대된다. 따라서 다른 모든 합자는 선택적이라고 간주된다. 그러나 어떤 경우에는, UA 또는 플랫폼 휴리스틱이 깨진 글꼴을 처리하기 위해 추가 합자를 적용한다; 이 명세는 그러한 예외적 처리를 정의하거나 재정의하지 않는다.

8.2.1. 필기체 문자 체계

가능하다면, UA는 그러한 글자들의 run에 분배될 총 추가 공간을 그 run의 동등한 총 확장(또는 압축)을 낳는 어떤 형태의 필기체 확장 (또는 음의 tracking 값의 경우 압축)으로 변환함으로써, 필기체 문자 체계에 letter spacing을 적용할 수 있다. 그렇지 않고, UA가 필기체 문자 체계의 텍스트를 필기체 연결을 깨지 않고 확장할 수 없다면, 그 문자 체계의 어떤 조판 글자 단위 쌍 사이에도 간격을 전혀 적용해서는 안 된다 (letter-spacing의 목적상 각 단어를 하나의 조판 글자 단위로 처리하는 효과). 두 경우 모두 그러한 글자 사이의 유효 간격은 0이 된다; 그러나 전자는 텍스트가 늘어나는 느낌을 보존한다.

아래는 아랍어 텍스트의 간격을 벌리는 것에 대한 적절한 예와 부적절한 예이다.

	—	원본 텍스트
	BAD	각 글자 사이에 공간을 균등하게 분배. 이것이 필기체 연결을 끊는다는 점에 주목하라!
	OK	조판상 적절한 필기체 확장으로 ∑letter-spacing을 분배. 결과 텍스트는 앞의 균등 간격 예와 같은 길이이다.
	OK	아랍어 글자 사이의 letter-spacing 억제. 그럼에도 letter-spacing은 비아랍어 문자(예: 공백)에는 적용된다는 점에 주목하라.
	BAD	결합되지 않은 글자 사이에만 letter-spacing 적용. 이는 조판 색을 왜곡하고 단어 경계를 흐리게 한다.

참고: 텍스트의 올바른 필기체 확장 또는 압축은 문자 체계, 서체, 언어, 단어 안의 위치, 줄 안의 위치, 구현 복잡도, 글꼴 기능, 및 서예적 선호에 따라 달라질 수 있으며, 특정 경우에는 전혀 가능하지 않을 수도 있다. 이는 짧아지는 합자, 장식형 변형, 문맥형, U+0640 ـ ARABIC TATWEEL 같은 확장 글리프, 또는 기타 미세 조판의 사용을 포함할 수 있다. 이러한 효과에 대한 규칙을 정의하는 것은 CSS의 범위를 벗어난다. 작성자는 상호운용되지 않는 결과를 받아들일 준비가 되어 있지 않다면 필기체 문자 체계에 letter-spacing을 적용하지 말아야 한다.

8.3. 줄 시작/끝 padding: line-padding 속성

letter-spacing이 조판 문자 단위 사이의 간격을 조정하고 줄의 시작이나 끝에는 적용되지 않는 반면, 이 속성은 줄의 시작/끝에서만 간격을 조정한다. 추가 간격은 줄 박스의 시작/끝에 있는 가장 안쪽 인라인 박스에 의해서만 적용되며, 그 인라인 박스의 콘텐츠 가장자리와 인접한 인라인 수준 콘텐츠 (텍스트 또는 atomic inline) 사이에 삽입된다. 이 추가 공간은 양쪽 맞춤 기회가 아니다.

p    { line-padding: 0.5em; line-height: 1; text-align: center }
span { background: black; color: white; }
em   { background: green; color: white; }

<p><span>Here is <em>some text</em></span>

Here is some
text

8.4. 자동 문맥 간격: text-autospace 속성

문자 클래스 기반 규칙 집합을 사용하여 같은 인라인 서식 맥락 안에서 같은 줄에 있는 인접 문자 사이의 간격을 제어하며, 문자 체계 사이의 간격과 문장부호 주변 간격을 자동으로 제어할 수 있게 한다.

값은 다음과 같이 정의된다:

<autospace> = no-autospace |
              [ ideograph-alpha || ideograph-numeric || punctuation ]
              || [ insert | replace ]

normal

ideograph-alpha ideograph-numeric와 같은 동작.

no-autospace

자동 공백을 삽입하지 않는다.

insert

어떤 종류의 공백 문자(Unicode 일반 범주 Z)도 이미 존재하지 않는 경우, 지정된 간격이 자동으로 삽입된다.

insert도 replace도 지정되지 않은 경우, 동작은 insert와 같다.

replace

해당 지점에 이미 공백 (U+0020)이 있더라도, 지정된 간격이 자동으로 삽입된다; 추가로, 그 공백 (U+0020)은 제거된다. 다른 유형의 공백 문자(Unicode 일반 범주 Z)는 insert와 마찬가지로 자동 간격을 억제한다.

참고: 이는 적절한 간격 대신 입력하기 쉬운 U+0020을 사용하는 텍스트를 교정하기 위한 것이다.

ideograph-alpha

표의문자 run과 비표의문자 글자 run 사이에 추가 간격을 만든다. § 8.4.1 문자 체계 간 간격을 참조하라.

ideograph-numeric

표의문자 run과 비표의문자 숫자 run 사이에 추가 간격을 만든다. § 8.4.1 문자 체계 간 간격을 참조하라.

punctuation

언어별 조판 관례가 요구하는 대로 문장부호 주변에 추가적인 줄바꿈 불가능 간격을 만든다.

이 레벨에서는 요소의 콘텐츠 언어가 프랑스어인 경우, 프랑스어 조판 지침이 요구하는 위치에 narrow no-break space (U+202F)와 no-break space (U+00A0)가 삽입된다. 그 밖의 경우 이 값은 효과가 없다. 그러나 향후 명세에서 다른 언어에 대한 자동 간격 동작이 추가될 수 있다.

auto

사용자 에이전트가 조판상 높은 품질의 간격 값 집합을 선택한다. 서로 다른 플랫폼에서 실행되는 서로 다른 사용자 에이전트는 서로 다른 값을 선택할 수 있다.

참고: 이러한 간격 값은 OS 플랫폼 관례와 일치할 수도 있고 일치하지 않을 수도 있다.

이 속성은 word-spacing 및 letter-spacing 속성과 가산적이다. 즉, letter-spacing 설정이 기여하는 간격의 양(있는 경우)은 text-autospace가 만든 간격에 더해진다. word-spacing에도 동일하게 적용된다.

요소 경계에서 문자 사이에 도입되는 추가 간격의 양은 그 경계를 포함하는 가장 안쪽 요소에 의해 결정되고 그 안에서 렌더링된다.

8.4.1. 문자 체계 간 간격

ideograph-alpha 및 ideograph-numeric 값은 특정 문자 클래스 사이의 경계에 간격을 도입한다. 이들은 같은 줄에서 직접 인접할 때, 즉 중간에 non-zero margin, border, 또는 padding이 없고 중간 문자(예: 따옴표나 공백)도 없는 경우이다. 이러한 키워드가 도입하는 공간의 양은 CJK advance measure의 1/8, 즉 used value인 font-size가 그 computed value와 같다면 0.125ic이다.

참고: 간격 관례는 다양하지만, 값은 일반적으로 1/4ic부터 1/8ic만큼 작은 값까지의 범위에 있으며, 금속 활자 제한 때문에 역사적 맥락에서는 1/4ic가 더 일반적이고 비례 조판에서는 1/6ic 또는 더 얇은 값이 더 일반적이다. 이러한 공간은 기본적으로 (초기값 normal을 통해) 삽입되므로, CSS는 간섭을 보수적으로 하기 위해 1/8ic를 사용한다. 이 모듈의 향후 레벨에서는 간격의 양에 대한 제어를 도입할 수 있다.

8.5. CJK 문장부호 간격: text-spacing-trim 속성

문자 클래스 기반 규칙 집합을 사용하여 같은 인라인 서식 맥락 안에서 같은 줄에 있는 CJK 문장부호 문자 주변의 간격을 제어하며, 줄 안에서의 위치와 이웃 문자에 기반하여 이들을 반각 또는 전각으로 설정할 수 있게 한다.

값은 다음과 같이 정의된다:

<spacing-trim> = space-all | normal | space-first | trim-start | trim-both | trim-all

space-all

모든 전각 문장부호 문자는 전각 글리프(간격 있음)로 설정된다.

normal

전각 여는 문장부호를 각 줄의 시작에서 전각 글리프(간격 있음)로 설정한다; 전각 닫는 문장부호를 각 줄의 끝에서 양쪽 맞춤 이전에 그렇지 않으면 맞지 않는 경우 반각 글리프(붙임)로 설정하고, 그렇지 않으면 그 문장부호를 전각 글리프로 설정한다; 그리고 아래에 설명된 대로 문장부호 글리프 사이의 간격을 병합한다.

trim-both

전각 여는 문장부호를 각 줄의 시작에서 반각 글리프(붙임)로 설정한다; 전각 닫는 문장부호를 각 줄의 끝에서 반각 글리프(붙임)로 설정한다; 그리고 아래에 설명된 대로 문장부호 글리프 사이의 간격을 병합한다.

space-first

전각 여는 문장부호를 블록 컨테이너의 첫 줄과 강제 줄 나누기 뒤의 각 줄에서 전각 글리프(간격 있음)로 설정한다. 그 밖에는 normal과 같다.

이 값은 호환성 요구사항 때문에 존재한다.

이 값은 일부 기존 중국어 및 일본어 콘텐츠의 서식 지정을 관리하기 위해 존재한다. 조판상으로는 trim-both가 적절했을 콘텐츠이지만, 해당 콘텐츠는 이미 첫 줄이 space-all처럼 설정될 것을 기대하도록 작성되어 있기 때문이다.

구체적으로, UA 전반에서 신뢰할 수 있는 hanging-punctuation 지원이 부족하기 때문에, 기존 콘텐츠(특히 ePub 콘텐츠)는 text-indent 대신 U+3000 ideographic space를 사용하지만, 단락이 들여쓰기 안에 매달리기를 원하는 문장부호로 시작하는 경우에는 hanging punctuation 효과를 만들기 위해 이를 생략한다. 따라서 첫 줄에 trim-both를 사용하면 그러한 콘텐츠에서 실질적인 들여쓰기를 잘라내어 그 줄이 새 단락의 첫 줄이라는 구분을 흐리게 된다.

이처럼 들여쓰기에 ideographic space를 사용하는 조판 관행은 (항상은 아니지만 때때로) HTML과 CSS가 제공하는 콘텐츠와 스타일의 분리에 반한다는 점에 유의하라. 문서의 텍스트 콘텐츠를 조정하는 대신 hanging-punctuation 및 text-indent를 사용해 단락 서식을 제어하면 문서 소스에서 텍스트의 실제 의미를 보존하고, 스타일시트 설계자가 콘텐츠를 변경할 필요 없이 다양한 간격/들여쓰기 스타일 사이를 자유롭게 전환할 수 있다. 예시는 § 8.5.3 CSS에서의 일본어 단락 시작 관례를 참조하라.

추가로, 줄 끝에서의 동작은 trim-both가 아니라 normal 및 trim-start 값과 정렬된다. 즉, 양쪽 맞춤 이전에 그렇지 않으면 맞지 않는 경우에만 글리프를 잘라낸다. 더 적은 경우에 조판을 개선하지만, 이는 space-all의 레거시 동작에 더 가까워 호환성 우려를 줄인다.

trim-start

전각 여는 문장부호를 각 줄의 시작에서 반각 글리프(붙임)로 설정한다. 그 밖에는 normal과 같다.

trim-all

전각 여는 문장부호, 전각 닫는 문장부호, 그리고 전각 가운데점 문장부호를 줄 안의 위치나 인접 문자와 관계없이 반각 글리프로 설정한다.

auto

사용자 에이전트가 조판상 높은 품질의 간격 값 집합을 선택한다. 서로 다른 플랫폼에서 실행되는 서로 다른 사용자 에이전트는 서로 다른 값을 선택할 수 있다.

참고: 이러한 간격 값은 OS 플랫폼 관례와 일치할 수도 있고 일치하지 않을 수도 있다.

auto가 필요한가? 작성자가 첫 줄의 시작에서 플랫폼 의존 동작을 선택하는 것은 이상할 것이며, 그 밖에는 trim-both를 사용해야 한다.

8.5.1. 전각 문장부호 병합

일반적으로 전각 문자는 표준 한자 문자(예: 水 U+6C34)와 같은 advance width를 가진 글리프를 갖는다. 그러나 많은 전각 문장부호 글리프는 전각 디자인 공간의 일부만 차지한다. 따라서 이러한 문장부호가 항상 전각으로 설정되는 것은 아니다. text-spacing-trim의 여러 값은 작성자가 이러한 문자를 언제 반각(일반적으로 표의문자의 절반 폭)으로 설정하고 언제 전각으로 설정할지를 제어할 수 있게 한다.

지정된 대로 텍스트를 설정하기 위해, UA는 다음 중 하나를 수행해야 한다

• 글리프가 전각으로 주어졌지만 반각으로 설정되어야 하는 경우, 글리프의 빈 절반을 잘라내거나(kern),
• 글리프가 반각으로 주어졌지만 전각으로 설정되어야 하는 경우, 글리프에 공간을 추가한다.

UA는 특정 글리프의 필요한 잘라내기를 수행하기 위해 글꼴이 구현한 경우 OpenType halt 및 vhal 기능을 사용할 수 있다. UA는 hwid 기능을 사용하거나 그 밖의 방식으로 반각 형태를 대체해서는 안 된다. 반각 글리프로 전환하면 글리프 모양이 바뀔 수 있으며, 여기서는 허용되지 않기 때문이다.

일부 글꼴은 전각 문장부호 문자에 비례 글리프를 사용한다. 글꼴에서 전각과 반각 글리프 모양을 구분하는 지원이 없다면 (예: 글꼴 기능을 통해), 그러한 비례 글리프에 대해서는 주어진 advance width가 동시에 전각이자 반각으로 간주된다: UA는 이러한 글리프에 공간을 추가하거나 제거해서는 안 된다.

참고: 표준 한자 문자의 advance width는 반대 writing mode에 대한 OpenType ideo 및 idtp 기준선 같은 글꼴 메트릭에서 결정하거나, 水 U+6C34 같은 한자 문자의 advance width를 취하여 결정할 수 있다. (일부 글꼴은 문자가 정사각형이 아니도록 압축되어 있으므로 반대 writing mode를 사용해야 한다.) OpenType 메트릭에 대한 자세한 내용은 OpenType 명세에서 확인할 수 있다. 水 U+6C34, 卜 U+535C, 一 U+4E00이 모두 같은 advance width를 갖지 않는 경우, 해당 글꼴은 비례 표의문자를 가지고 있으며 전각 advance width를 글리프 측정으로 신뢰성 있게 결정할 수 없음에 유의하라.

일부 글꼴은 빈 공간이 너무 작아 잘라낼(kern) 수 없는 전각 문장부호 문자를 가지고 있다. UA는 글리프 bounding box, 글리프 메트릭, 또는 글꼴 기능을 통해 잘라내기(kerning)가 글리프 잘림, 충돌, 또는 과도한 kerning을 유발할 수 있다고 판단하는 경우 잘라내지(kern) 않기로 선택할 수 있다.

text-spacing-trim이 trim-all이면, UA는 그러한 전각 글리프와 일반적으로 연관된 공간을 그것들이 나타나는 문맥과 관계없이 병합해야 한다. 그렇지 않으면, text-spacing-trim이 space-all로 설정된 경우 (또는 글꼴이 비례 전각 문장부호 글리프를 가진 경우)가 아니라면, UA는 그러한 전각 글리프와 일반적으로 연관된 공간을 줄에서 인접하게 배치될 때 다음과 같이 병합해야 한다:

• 이전 문자가 다음 중 하나인 경우 전각 여는 문장부호를 반각으로 설정한다:

  • 전각 여는 문장부호

  • 전각 가운데점 문장부호

  • ideographic space (U+3000)

  • 동등하거나 더 큰 font-size의 전각 닫는 문장부호

  • Unicode 일반 범주 Ps에 속하는 문자

  그렇지 않으면 전각으로 설정한다.

• 다음 문자가 다음 중 하나인 경우 전각 닫는 문장부호를 반각으로 설정한다:

  • 전각 닫는 문장부호

  • 전각 가운데점 문장부호

  • ideographic space (U+3000)

  • 더 큰 font-size의 전각 여는 문장부호

  • Unicode 일반 범주 Pe에 속하는 문자

  그렇지 않으면 전각으로 설정한다.

8.5.2. 텍스트 간격 문자 클래스

이 속성의 맥락에서는 다음 정의가 적용된다:

클래스와 Unicode 코드 포인트는 검토 중이며, Unicode의 더 최근 추가 사항을 수용하려면 적어도 일부 변경이 필요하다. [Issue #9503]

표의문자

기본 문자가 아래에 나열된 모든 조판 문자 단위 [CSS-TEXT-3]를 포함한다:

• U+3041부터 U+30FF 범위의 모든 문자. 단, Unicode Punctuation [P*] 일반 범주에 속하는 문자는 제외한다.
• CJK Strokes (U+31C0부터 U+31EF까지).
• Katakana Phonetic Extensions (U+31F0부터 U+31FF까지).
• Han script 속성을 가진 모든 문자.

비표의문자 글자

Unicode Letters [L*] 및 Mark [M*] 일반 범주에 속하는 모든 조판 문자 단위를 포함한다. 단, 다음 조건 중 하나를 충족하는 경우는 제외한다:

• 표의문자로 정의되어 있다.
• [UAX11]에 의해 East Asian Fullwidth (F)로 분류된다.
• text-orientation 속성 또는 text-combine-upright 속성을 사용한 세로 텍스트 흐름에서 upright이다.

비표의문자 숫자

Unicode Decimal Digit Number [Nd] 일반 범주에 속하는 모든 조판 문자 단위를 포함한다. 단, 다음 조건 중 하나를 충족하는 경우는 제외한다:

• [UAX11]에 의해 East Asian Fullwidth (F)로 분류된다.
• text-orientation 속성 또는 text-combine-upright 속성을 사용한 세로 텍스트 흐름에서 upright이다.

전각 여는 문장부호

CJK Symbols and Punctuation 블록(U+3000–U+303F)에 속하거나 [UAX11]에 의해 East Asian Fullwidth (F)로 분류되는 모든 여는 문장부호 문자(Unicode category Ps)를 포함한다. LEFT SINGLE QUOTATION MARK (U+2018) 및 LEFT DOUBLE QUOTATION MARK (U+201C)도 포함한다. 잘라낼 때, 왼쪽(가로 텍스트의 경우) 또는 위쪽(세로 텍스트의 경우) 절반이 kern된다.

전각 닫는 문장부호

CJK Symbols and Punctuation 블록(U+3000–U+303F)에 속하거나 [UAX11]에 의해 East Asian Fullwidth (F)로 분류되는 모든 닫는 문장부호 문자(Unicode category Pe)를 포함한다. RIGHT SINGLE QUOTATION MARK (U+2019) 및 RIGHT DOUBLE QUOTATION MARK (U+201D)도 포함한다. 전각 콜론 문장부호 및/또는 전각 점 문장부호도 포함할 수 있다 (아래 참조). 잘라낼 때, 오른쪽(가로 텍스트의 경우) 또는 아래쪽(세로 텍스트의 경우) 절반이 kern된다.

전각 가운데점 문장부호

MIDDLE DOT (U+00B7), HYPHENATION POINT (U+2027), 및 KATAKANA MIDDLE DOT (U+30FB)을 포함한다. 전각 콜론 문장부호 및/또는 전각 점 문장부호도 포함할 수 있다 (아래 참조).

전각 콜론 문장부호

FULLWIDTH COLON (U+FF1A) 및 FULLWIDTH SEMICOLON (U+FF1B)을 포함한다.

전각 점 문장부호

다음을 포함한다: IDEOGRAPHIC COMMA (U+3001), IDEOGRAPHIC FULL STOP (U+3002), FULLWIDTH COMMA (U+FF0C), FULLWIDTH FULL STOP (U+FF0E).

전각 콜론 문장부호와 전각 점 문장부호를 전각 닫는 문장부호로 간주할지, 아니면 전각 가운데점 문장부호로 간주할지는 문장부호가 글리프 박스 안의 어디에 그려지는지에 달려 있다. 문장부호가 가운데에 있으면, 가운데점 문장부호로 간주해야 한다. 문장부호가 한쪽(가로 텍스트에서는 왼쪽, 세로 텍스트에서는 위쪽)에 그려지고 따라서 다른 절반이 비어 있다면, 그 문장부호는 닫는 문장부호로 간주하고 그에 따라 잘라내야 한다.

UA는 전각 콜론 문장부호와 전각 점 문장부호를 적절한 대로 전각 닫는 문장부호 범주 또는 전각 가운데점 문장부호 범주 중 하나로 분류해야 한다. UA는 이러한 분류를 결정하기 위해 언어 관례와 writing mode(가로 vs. 세로), 및/또는 글꼴 정보에 의존할 수 있다. UA는 적절한 경우 임의의 범주에 추가 문자를 더할 수도 있다.

8.5.3. CSS에서의 일본어 단락 시작 관례

일본어에는 여는 괄호 처리 방식으로 구분되는 세 가지 일반적인 시작 가장자리 조판 방식이 있다.

줄 머리에서 여는 괄호의 배치 [JLREQ]

p { margin: 1em 0; }이라는 UA 스타일시트를 가정하면, CSS는 다음 규칙으로 일본어 조판 스타일을 구현할 수 있다:

• 들여쓰기와 딱 맞고, 다른 줄과도 딱 맞는 괄호(첫 번째 방식):

  p { /* Flush alignment */
    margin: 0;
    text-indent: 1em;
    text-spacing-trim: trim-both;
  }
  

• 모든 줄에서 전각 간격을 보존하는 괄호(두 번째 방식):

  p { /* Fullwidth alignment */
    margin: 0;
    text-indent: 1em;
    text-spacing-trim: space-all;
  }
  

• 들여쓰기 안에 매달리고, 다른 줄과는 딱 맞는 괄호(세 번째 방식):

  p { /* Hanging alignment */
    margin: 0;
    text-indent: 1em;
    text-spacing-trim: trim-both;
    hanging-punctuation: first;
  }
  

8.6. 문자 클래스 간격 단축 속성: text-spacing 속성

이 속성은 단일 선언에서 text-spacing-trim과 text-autospace를 설정하기 위한 단축 속성이다. 값은 다음과 같이 정의된다:

none

모든 text-spacing 기능을 끈다: text-spacing-trim을 space-all로 설정하고, text-autospace를 no-autospace로 설정한다.

auto

text-spacing-trim과 text-autospace를 모두 auto로 설정한다.

<spacing-trim>

text-spacing-trim을 지정된 값으로 설정한다. <autospace> 값이 주어지지 않으면, text-autospace는 그 초기값으로 설정된다.

<autospace>

text-autospace를 지정된 값으로 설정한다. <spacing-trim> 값이 주어지지 않으면, text-spacing-trim은 그 초기값으로 설정된다.

참고: normal은 text-spacing-trim과 text-autospace 둘 모두의 초기값이므로, text-spacing: normal은 둘 모두를 초기값으로 재설정한다.

8.7. 요소 경계를 가로지르는 셰이핑

두 조판 문자 단위를 분리하는 경계를 가진 박스에 대해 다음 중 하나라도 참이면, 인라인 박스 경계에서 텍스트 셰이핑은 반드시 끊겨야 한다:

• 인라인 축에서 두 조판 문자 단위를 분리하는 margin/border/padding 중 어느 것이든 non-zero이다.
• vertical-align이 baseline이 아니다.
• 경계가 bidi isolation boundary이다.

서식에 실질적인 변화가 없거나, 글리프에 영향을 주지 않는 서식 변경만 있는 경우 (예: text decoration 적용), 인라인 박스 경계를 가로지르는 텍스트 셰이핑은 끊겨서는 안 된다.

그 밖의 경우에도, 글꼴 기술의 한계를 고려할 때 해당 경우에 합리적이고 가능하다면, 인라인 박스 경계를 가로지르는 텍스트 셰이핑은 끊기지 않는 것이 좋다.

9. 가장자리 효과

가장자리 효과는 블록 안의 다른 줄에 대한 줄의 들여쓰기(text-indent)와 줄의 시작 및 끝 가장자리에서 콘텐츠를 측정하는 방식(hanging-punctuation)을 제어한다.

9.1. 첫 줄 들여쓰기: text-indent 속성

이 속성은 블록 안의 인라인 콘텐츠 줄에 적용되는 들여쓰기를 지정한다. 들여쓰기는 줄 박스의 start 가장자리에 적용되는 margin으로 취급된다.

each-line 및/또는 hanging 키워드에 의해 달리 지정되지 않는 한, 요소의 첫 번째 서식 지정된 줄인 줄만 영향을 받는다. [CSS-PSEUDO-4] 예를 들어, 익명 블록 박스의 첫 줄은 그것이 부모 요소의 첫 번째 자식인 경우에만 영향을 받는다.

값은 다음 의미를 가진다:

<length>

들여쓰기의 양을 절대 길이로 제공한다.

<percentage>

들여쓰기의 양을 블록 컨테이너 자신의 논리적 너비에 대한 백분율로 제공한다.

백분율은 내재 크기 기여를 계산할 목적에서는 0으로 취급되어야 하지만, 레이아웃을 수행할 때에는 항상 정상적으로 해석된다.

참고: 이는 요소가 오버플로되게 할 수 있다. 백분율 들여쓰기와 내재 크기 산정을 함께 사용하는 것은 권장되지 않는다.

each-line

들여쓰기는 각 블록 컨테이너의 첫 줄과 강제 줄 나누기 뒤의 각 줄에 영향을 준다 (하지만 소프트 줄바꿈 뒤의 줄에는 영향을 주지 않는다).

hanging

영향을 받는 줄을 반전한다.

     Since CSS1 it has been possible to
indent the first line of a block element
5em by setting the 'text-indent' property 
to '5em'.

In CSS3 we can instead indent all other
     lines of the block element by 5em
     by setting the 'text-indent' property
     to 'hanging 5em'.

   For example, in the middle of
this paragraph is an equation,
which is centered:
             x + y = z
The first line after the equation
is flush (else it would look like
we started a new paragraph).

In a short line of text
There need be no wrapping,
But when we go on and on and on  
   and on,
Sometimes a soft break
Can help us stay on the page.

참고: text-indent 속성은 상속되므로, 블록 요소에 지정되면 descendant inline-block 요소에도 영향을 준다. 이런 이유로, display: inline-block로 지정된 요소에는 text-indent: 0을 지정하는 것이 흔히 현명하다.

9.2. 행잉 글리프

줄의 시작 또는 끝 가장자리에 있는 글리프가 행잉될 때, 이는 fit, 정렬, 또는 양쪽 맞춤을 위해 줄의 콘텐츠를 측정할 때 고려되지 않는다. 줄의 정렬/양쪽 맞춤에 따라, 이로 인해 해당 mark가 줄 박스 밖에 배치될 수 있다. 행잉 글리프는 내재 크기 (min-content size 및 max-content size)와 이로부터 파생된 모든 크기를 계산할 때도 고려되지 않는다. (이 측정과 kerning의 상호작용은 현재 UA가 정의한다; CSSWG는 이 지점에 대한 조언을 환영한다.)

행잉 글리프는 여전히 그 부모 인라인 박스 안에 포함되며 텍스트 양쪽 맞춤에도 여전히 참여한다: 다만 줄에 얼마나 많은 콘텐츠가 맞는지, 양쪽 맞춤을 위해 줄의 콘텐츠를 얼마나 확장 또는 압축해야 하는지, 또는 텍스트 정렬을 위해 줄 박스 안에서 콘텐츠를 어떻게 배치할지를 결정할 때 그 character advance가 측정되지 않을 뿐이다. 실제로 행잉 글리프의 character advance는 영향을 받는 부모 인라인 박스의 해당 가장자리에 추가적인 음수 margin으로 재해석된다; 줄은 그 밖에는 평소처럼 배치된다. 오버플로되는 행잉 글리프는 불필요한 스크롤바 생성을 피하기 위해 일반적으로 ink overflow로 간주되는 것이 좋지만, 콘텐츠가 편집 가능하거나 이를 scrollable overflow로 취급하는 것이 사용자에게 유용한 다른 상황에서는 UA가 이를 scrollable overflow로 취급할 수 있다. [CSS-OVERFLOW-3]

어떤 경우에는 줄 끝의 글리프가 조건부로 행잉될 수 있다: 이는 양쪽 맞춤 이전에 그 줄에 그렇지 않으면 맞지 않는 경우에만 행잉된다. 이는 fit을 위해 줄의 콘텐츠를 측정할 때 고려되지 않는다; 그러나 맞지 않는 부분은 행잉되는 것으로 간주된다. 조건부로 행잉되는 글리프는 min-content sizes와 이로부터 파생된 모든 크기를 계산할 때는 고려되지 않지만, max-content sizes와 이로부터 파생된 모든 크기에는 고려된다.

행잉 가능한 글리프와 줄의 가장자리 사이에 non-zero 인라인 축 border 또는 padding이 있으면 그 글리프는 행잉될 수 없다. 예를 들어, end padding이 있는 인라인 박스 끝의 마침표는 줄의 끝 가장자리에서 행잉되지 않는다.

여러 인접 글리프가 함께 행잉될 수 있지만, 얼마나 많이 행잉될 수 있는지에 대한 구체적인 제한이 지정될 수 있다 (예: 줄의 각 가장자리에서 문장부호 문자는 최대 하나만 행잉될 수 있다).

9.2.1. 행잉 문장부호: hanging-punctuation 속성

이 속성은 문장부호가 있는 경우, 그것이 텍스트 줄의 시작 또는 끝에서 행잉되어 줄 박스 밖(또는 들여쓰기 안)에 배치될 수 있는지를 결정한다.

참고: 블록 컨테이너에 충분한 padding이 없으면, hanging-punctuation은 오버플로를 유발할 수 있다.

값은 다음 의미를 가진다:

none

어떤 문장부호 문자도 행잉되게 하지 않는다.

first

요소의 첫 번째 서식 지정된 줄 시작에 있는 여는 괄호, 따옴표, 또는 ideographic space가 행잉된다. 이는 Unicode 범주 Ps, Pf, Pi의 모든 문자와 ASCII 따옴표 U+0027 ' APOSTROPHE 및 U+0022 " QUOTATION MARK, 그리고 IDEOGRAPHIC SPACE U+3000에 적용된다.

last

요소의 마지막 서식 지정된 줄 끝에 있는 닫는 괄호 또는 따옴표가 행잉된다. 이는 Unicode 범주 Pe, Pf, Pi의 모든 문자와 ASCII 따옴표 U+0027 ' APOSTROPHE 및 U+0022 " QUOTATION MARK에 적용된다.

force-end

줄 끝의 stop 또는 comma가 행잉된다.

allow-end

줄 끝의 stop 또는 comma가 조건부로 행잉된다.

줄의 각 가장자리에는 문장부호 문자 하나만 행잉될 수 있다.

Stops and commas 중 행잉될 수 있는 것은 다음을 포함한다:

UA는 적절한 경우 다른 문자를 포함할 수 있다.

참고: CSS Working Group은 다른 문자를 포함하는 UA가 그러한 추가 사항을 작업 그룹에 알려주기를 바란다.

allow-end 및 force-end는 동아시아에서 사용되는 행잉 문장부호의 두 변형이다.

p {
  text-align: justify;
  hanging-punctuation: allow-end;
}

p {
  text-align: justify;
  hanging-punctuation: force-end;
}

allow-end의 경우 첫 줄 끝의 문장부호는 행잉되지 않는다. 행잉 없이도 맞기 때문이다. 그러나 force-end가 사용되면, 강제로 행잉된다. 양쪽 맞춤은 행잉 문장부호 없이 줄을 측정한다. 따라서 줄이 확장될 때, 문장부호는 줄 밖으로 밀려난다.

9.3. 양방향성과 줄 박스

줄 박스의 start 및 end 쪽은 줄 박스의 인라인 기본 방향에 의해 결정된다. 보통은 일치하지만, 줄 박스의 인라인 기본 방향은 containing block 또는 bidi paragraph의 인라인 기본 방향과 구별된다. 줄 박스의 인라인 기본 방향은 text-align-all, text-align-last, text-indent, 그리고 hanging-punctuation—​즉 그 가장자리에 대한 콘텐츠의 위치와 정렬—​에 영향을 준다. 이는 인라인 콘텐츠의 서식 지정이나 순서에는 영향을 주지 않는다 (이는 Unicode Bidirectional Algorithm에 의해 제어되며, CSS Writing Modes가 적용한다 [UAX9] [CSS-WRITING-MODES-4]).

대부분의 경우, 줄 박스의 인라인 기본 방향은 그 containing block의 계산된 direction에 의해 주어진다. 그러나, 그 containing block에 unicode-bidi: plaintext가 있는 경우 [CSS-WRITING-MODES-4]:

• bidi paragraph가 줄 박스가 속하는 것 (즉, 줄 박스가 콘텐츠를 담는 bidi paragraph)이고 강한 방향성을 가지는 경우, 줄 박스의 인라인 기본 방향은 그 방향이다.
• 줄 박스가 비어 있거나 (즉 atomic inline이나 newline 문자를 제외한 문자를 포함하지 않음) 또는 그 밖의 이유로 강한 방향성이 없다면 (약한 문자 또는 중립 문자만 포함한다면), 그 인라인 기본 방향은 앞선 줄 박스(있는 경우)에서 가져오거나, 이것이 containing block의 첫 번째 줄 박스라면, containing block의 direction 속성에서 가져온다. (이로 인해 콘텐츠는 LTR 기본 방향을 가지지만 줄 박스는 RTL일 수 있다.)

<block style="unicode-bidi: plaintext">
français
فارسی
français
فارسی
français
فارسی
</block>

<para style="display: block; direction: rtl; unicode-bidi:plaintext">
“<quote style="unicode-bidi:plaintext">שלום!</quote>”, they said.
</para>

<textarea style="direction: rtl; unicode-bidi:plaintext">

Hello!

</textarea>

부록 A: 텍스트 처리 작업 순서

이 부록은 규범적이다.

다음 목록은 텍스트 작업의 순서를 정의한다. (결과 레이아웃이 동일한 한, 구현이 이 순서에 얽매이는 것은 아니다.)

1. § 4.2 공백 잘라내기: white-space-trim 속성
2. 공백 처리 파트 I (pre-wrapping)
3. § 2.2 단어 사이 확장: word-space-transform 속성 및 텍스트 변환
4. 텍스트 결합 [CSS-WRITING-MODES-4]
5. 텍스트 방향 설정 [CSS-WRITING-MODES-4]
6. 각 줄에 다음을 적용하면서 텍스트 줄바꿈:

   1. 들여쓰기

   2. 양방향 재정렬 [CSS2] / [CSS-WRITING-MODES-4]

   3. 공백 처리 파트 II

   4. line-padding, letter-spacing, word-spacing, 및 text-spacing

   5. 글꼴/글리프 선택과 위치 지정 [CSS-FONTS-3]

   6. 행잉 문장부호

   참고: 이러한 작업은 한 줄에 얼마나 많은 텍스트가 맞는지에 영향을 줄 수 있으며, 따라서 다시 줄바꿈으로 돌아갈 수 있다.

7. 양쪽 맞춤 (이는 글리프 선택 및/또는 텍스트 줄바꿈에 영향을 주어 그 단계로 되돌아갈 수 있음)
8. 텍스트 정렬
9. 텍스트 그룹 정렬

부록 B: Plaintext로 변환

이 부록은 plaintext 복사-붙여넣기 작업의 목적에 대해 규범적이다.

CSS로 렌더링된 문서가 plaintext 형식으로 변환될 때, 다음이 기대된다:

• text-transform 속성은 효과가 없다.
• white-space-trim 및 § 4.3.1 Phase I: Collapsing and Transformation이 적용되며, block의 시작 또는 강제 줄 나누기 바로 뒤에 있는 병합 가능한 공백의 모든 시퀀스가 제거된다.

부록 C: 기본 UA 스타일시트

이 부록은 정보 제공용이며, UA 개발자가 HTML용 기본 스타일시트를 구현하는 데 도움을 주기 위한 것이다. 그러나 UA 개발자는 적절한 경우 이를 자유롭게 무시하거나 수정할 수 있다.

/* make option elements align together */
option { text-align: match-parent; }

/* do not allow white space to collapse in textarea */
textarea { white-space-collapse: preserve !important; }

/* preserve character grid in preformatted text */
pre, code, kbd, samp, tt, listing, xmp, plaintext { text-spacing: none; }

/* Avoid hanging punctuation inheriting into preformatted blocks */
pre { hanging-punctuation: none; }

부록 D: 문자 체계와 간격

이 부록은 규범적이다.

조판 동작은 언어에 따라 어느 정도 달라지지만, writing system에 따라 크게 달라진다. 이 부록은 Unicode 6.0의 몇 가지 일반적인 script를 그 양쪽 맞춤 및 간격 동작에 따라 분류한다. 범주 설명은 기술적이며 규정적이지 않다; 결정 요인은 양쪽 맞춤 기회의 우선순위화이다.

block scripts

CJK 및 확장적으로 모든 Wide 문자 (East Asian Width 참조 [UAX11]). 다음 Unicode scripts가 포함된다: Bopomofo, Han, Hangul, Hiragana, Katakana, 및 Yi. East Asian Width property가 Wide 및 Fullwidth인 문자도 포함되지만, Ambiguous 문자는 writing system이 Chinese, Korean, 또는 Japanese인 경우에만 포함된다.

clustered scripts

Clustered scripts는 이산적 단위를 가지며 단어 경계에서만 나뉘지만, 보이는 단어 구분자를 사용하지 않는다. 이들은 공백을 늘리는 것을 우선하지만, 양쪽 맞춤을 위해 문자 사이 간격을 편안하게 허용한다. clustered scripts에는 다음 Unicode scripts가 포함되지만 이에 한정되지는 않는다: Khmer, Lao, Myanmar, New Tai Lue, Tai Le, Tai Tham, Tai Viet, Thai

cursive scripts

Cursive scripts는 양쪽 맞춤이나 letter-spacing을 위해 글자 사이에 틈을 허용하지 않는다. 다음 Unicode scripts가 포함된다: Arabic, Hanifi Rohingya, Mandaic, Mongolian, N’Ko, Phags Pa, Syriac

참고: 기준선 연결자를 가진 Indic scripts (예: Devanagari 및 Gujarati)는 cursive scripts로 간주되지 않으며, 조판 문자 단위 사이에 그러한 틈을 허용한다. Indic Layout Requirements를 참조하라. [ILREQ]

사용자 에이전트는 Unicode 지원을 업데이트함에 따라 향후 Unicode 버전에서 아직 인코딩되지 않은 cursive scripts를 처리하기 위해 이 목록을 업데이트해야 하며, CSSWG에 이 명세를 그에 맞게 업데이트해 달라고 요청하는 것이 권장된다.

부록 E: 문자와 속성

이 부록은 규범적이다.

Unicode는 CSS 조판에서 참조되는 네 가지 코드 포인트 수준 속성을 정의한다:

East Asian width property

Unicode Standard Annex #11 [UAX11]에 정의되어 있으며, Unicode Character Database [UAX44]에서 East_Asian_Width 속성으로 제공된다.

general category

Unicode Standard Annex #44 [UAX44]에 정의되어 있으며, Unicode Character Database [UAX44]에서 General_Category 속성으로 제공된다.

script property

Unicode Standard Annex #24 [UAX24]에 정의되어 있으며, Unicode Character Database [UAX44]에서 Script 속성으로 제공된다. (UA는 이 매핑에 ScriptExtensions.txt 할당을 모두 포함해야 한다.)

Vertical Orientation

Unicode Standard Annex #50 [UAX50]에 Unicode Character Database [UAX44]의 Vertical_Orientation 속성으로 정의되어 있다.

Unicode는 개별 코드 포인트의 속성을 정의하지만, 때로는 조판 문자 단위의 속성을 결정해야 한다. CSS Text의 목적상, 조판 문자 단위의 속성은 첫 번째 grapheme cluster의 기본 문자에 의해 주어진다—​다만 두 경우는 예외이다:

• Common script의 Enclosing Mark (Me)로 형성된 Grapheme clusters는 Common script의 Other Symbols (So)로 간주된다. 이들은 replacement character (U+FFFD)와 동일한 Unicode 속성을 가진다고 가정된다.
• Space Separator (Zs)를 기본으로 형성된 Grapheme clusters는 Modifier Symbols (Sk)로 간주된다. 이들은 기본 문자와 동일한 East Asian Width property를 가진다고 가정되지만, 그 밖의 속성은 시퀀스의 첫 번째 결합 문자에서 가져온다.

부록 F: 콘텐츠 Writing System 식별

이 부록은 규범적이다.

대부분의 언어에는 선호되는 writing system이 있지만, 일부 언어에는 여러 writing system이 있으며, 대부분은 하나 이상의 외래 writing system으로도 전사될 수 있다. 흔한 예로, 대부분의 언어에는 적어도 하나의 라틴 전사 방식이 있으며, 따라서 Latin writing system으로 쓰일 수 있다. 전사된 텍스트는 보통 그 writing system의 조판 관례를 따른다: 예를 들어 일본어 “romaji”와 중국어 Pinyin은 라틴 글자와 단어 공백을 사용하며, 그에 따라 Latin 줄 나누기 및 양쪽 맞춤 관행을 따른다. 또 다른 예로, 역사적 표의문자 한국어 (ko-Hani)는 단어 공백을 사용하지 않으므로, 현대 한국어가 아니라 중국어와 유사하게 조판되어야 한다.

HTML 또는 document language에서 content language를 선언하기 위해 BCP47 태그를 사용하는 경우, 작성자는 script subtag를 사용하여 비전형적 writing system의 사용을 모호하지 않게 하거나 나타낼 수 있다. [BCP47] 예를 들어, 본래 이를 사용하지 않는 언어에 대해 Latin writing system 사용을 나타내려면, -Latn script subtag를 추가할 수 있다. 예: 일본어 romaji의 경우 ja-Latn. 다른 writing system을 위한 다른 subtag도 존재하며, ISO의 Code for the Representation of Names of Scripts와 ISO15924 script tag registry를 참조하라. [ISO15924]

그러나 BCP47 script subtag는 단일 writing system과 강하게 연관된 언어에는 보통 사용되지 않으며 (실제로 권장되지 않으며), 대신 다른 것이 지정되지 않은 경우 해당 writing system이 암시되는 것으로 기대된다. [BCP47] IANA는 이 목적을 위해 language subtag registry의 Suppress-Script 필드를 통해 여러 언어의 가장 일반적인 writing system 데이터베이스를 유지한다.

참고: 언어 태그 지정에 대한 더 많은 조언은 Internationalization Working Group의 “Language tags in HTML and XML” 및 “Choosing a Language Tag”에서 찾을 수 있다.

writing system이 명시적으로 표시되지 않은 경우, UA는 줄 나누기나 양쪽 맞춤 같은 언어 민감 조판 동작에 대해 선언된 content language의 가장 일반적인 writing system을 가정해야 한다. 그러나 작성자가 명시적으로 다른 writing system을 선언한 경우, UA는 그 writing system을 가정해서는 안 된다. UA가 특정 언어와 writing system 조합에 대한 언어별 지식을 가지고 있지 않다면, 선언된 writing system의 조판 관례를 사용해야 하며 (필요하다면 다른 언어의 관례를 가정), 선언된 언어가 가정된 writing system 안에서 가지는 관례를 사용해서는 안 된다. 이는 선언된 writing system에는 부적절할 수 있기 때문이다.

언어와 그 가장 일반적인 writing system 사이의 전체 대응 관계는 이 문서의 범위를 벗어난다. 그러나 사용자 에이전트는 적어도 다음을 가정해야 한다:

• content language가 중국어이고 writing system이 지정되지 않았거나, 임의의 content language에 대해 writing system이 Hant, Hans, Hani, Hanb, 또는 Bopo ISO script codes 중 하나로 지정되어 있다면, 그 writing system은 Chinese이다.
• content language가 일본어이고 writing system이 지정되지 않았거나, 임의의 content language에 대해 writing system이 Jpan, Hrkt, Hira, 또는 Kana ISO script codes 중 하나로 지정되어 있다면, 그 writing system은 Japanese이다.
• content language가 한국어이고 writing system이 지정되지 않았거나, 임의의 content language에 대해 writing system이 Kore, Hang, 또는 Jamo ISO script codes 중 하나로 지정되어 있다면, 그 writing system은 Korean이다.
• writing system은 content language 자체가 알 수 없거나, 알 수 없는 writing system을 명시적으로 나타내는 경우에만 unknown으로 간주된다.

  참고: content language가 선언되어 있을 때 writing system 정보가 단순히 생략된 것은 writing system이 unknown이 아니라 암시된다는 뜻이다.

부록 G: 작은 Kana 매핑

이 부록은 규범적이다.

부록 H: 단어와 구 감지

이 부록은 규범적이다.

이 명세의 몇몇 작업은 자동화된 단어 경계 감지 또는 구 경계 감지에 의존한다.

두 작업은 비슷하다: 사용자 에이전트는 텍스트에 대한 언어 분석을 수행하여 언어별로 의미 있는 문자 시퀀스를 식별한다. 둘의 차이는 대상이 되는 텍스트 단위가 다르다는 것뿐이다: 단어 또는 구.

넓은 의미에서는 쉽게 이해되지만, 단어와 구라는 두 개념은 정확하게 정의하기 어렵고, 특히 여러 언어에 걸쳐 작동하도록 정의하기는 더 어렵다. 그럼에도 이 맥락에서는:

• 단어는 하나 이상의 문자 또는 음절로 구성될 수 있는 인식 가능한 의미 단위이다.

  참고: 이 개념에 대한 논의는 What is a word?를 참조하라.

• 구는 하나 또는 여러 단어가 함께 서서 개념적 또는 문법적 단위를 이루는 짧은 묶음이며, 절이나 문장의 구성 요소를 형성한다.

  참고: 이는 영어에서 여기 사용된 의미의 phrase가 아니라 sentence를 뜻하는 프랑스어 단어 phrase와 혼동해서는 안 된다. 일본어에서는 文節이라는 개념에 해당한다.

  구는 관사와 전치사 또는 후치사를 가진 명사, phrasal verb, 복합 동사 시제 등이 될 수 있다…

감지된 각 단어 또는 구의 시작 및 끝 위치를 단어 경계 또는 구 경계라고 한다. 단어 및 구 경계 자체는 관찰 가능하지 않지만, word-space-transform 또는 word-break 같은 속성은 그 위치에서 보이는 효과를 유발할 수 있다.

단어나 구를 감지하고 그 경계를 배치하는 구체적인 알고리즘은 UA 의존적이며, 다양한 요소 또는 접근 방식을 고려할 수 있다. 예를 들면 사전 기반 어휘 분석, 문장부호 또는 다른 구분 문자 식별, 형태론적 분석, 기계 학습 방법 등이다…

그럼에도 다음 제약은 반드시 준수되어야 한다:

• 사용자 에이전트는 단일 조판 문자 단위를 구성하는 문자 사이에 단어 또는 구 경계를 배치해서는 안 된다.
• 사용자 에이전트는 줄 나누기 클래스 GL, WJ, 또는 ZWJ를 가진 문자에 인접하여 단어 또는 구 경계를 배치해서는 안 된다; 그러한 문자로 두 개의 후보 단어나 구가 분리되어 있는 경우, 이들은 하나로 취급되어야 한다. [UAX14]
• 단어 또는 구 바로 뒤에 다음 문자 중 하나 이상이 오는 경우, 사용자 에이전트는 그것들이 앞선 단어 또는 구의 일부라고 반드시 간주해야 한다:
  • word-separator 문자
  • 기타 공백 구분자
  • U+200B ZERO WIDTH SPACE 문자

• 문장부호는 그 자체로 구가 아니다: 이는 인접한 언어적 단어 또는 구의 관련된 쪽에 붙어야 한다. 예를 들어, 괄호 및 따옴표 같은 둘러싸는 문장부호는 그것들이 둘러싸는 구의 일부이다; 쉼표와 세미콜론은 앞선 구에 접미된다; U+00BF INVERTED QUESTION MARK는 뒤따르는 단어에 붙는다; 등.

  그러나 smiley, kaomoji, 또는 Perl snippet 같은 비관습적인 문장부호 사용은 사용자 에이전트가 이 원칙에서 벗어날 필요가 있게 만들 수 있다.

• 단어 또는 구 경계를 결정할 때 인라인 박스 경계와 out-of-flow 요소는 무시되어야 한다. 그러나, 단어 또는 구 경계가 하나 이상의 인라인 박스 경계와 같은 위치에서 발견된다면, 단어 또는 구 경계는 이 인라인 박스 경계에 참여하는 가장 바깥 요소에 삽입되어야 한다.
  다음 예에서, 빨간색 “|”는 사용자 에이전트가 단어 경계를 감지할 때 이를 배치하기에 합리적인 위치를 나타낸다:

  กรุงเทพ|คือ|สวยงาม

  그 문장에 일부 인라인 마크업이 포함되어 있었다면, 다음 예는 단어 경계를 배치할 올바른 위치를 보여준다:

  กรุงเทพ|คือ|<em>สวยงาม</em>

  다음 예는 잘못된 위치를 보여준다:

  กรุงเทพ|คือ<em>|สวยงาม</em>

  다음은 더 인위적인 상황에서의 올바른 위치를 보여준다:

  กรุงเทพ|<b><u>คือ</u>|<em>สวยงาม</em></b>

Privacy Considerations

이 명세는 사용자가 설치한 하이픈 넣기 및 줄 나누기 사전을 노출한다.

Security Considerations

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

감사의 말

이 명세는 다음 사람들의 도움 없이는 가능하지 않았을 것이다: Addison Phillips, Aharon Lanin, Alan Stearns, Ambrose Li, Arnold Schrijver, Arye Gittelman, Ayman Aldahleh, Ben Errez, Bert Bos, Chris Lilley, Chris Pratley, Chris Thrasher, Chris Wilson, Dave Hyatt, David Baron, Emilio Cobos Álvarez, Eric LeVine, Etan Wexler, Frank Tang, Håkon Wium Lie, IM Mincheol, Ian Hickson, James Clark, Javier Fernandez, John Daggett, Jonathan Kew, Ken Lunde, Laurie Anna Edlund, Marcin Sawicki, Martin Dürst, Martin Heijdra, Masafumi Yabe, Masayasu Ishikawa, Michael Jochimsen, Michel Suignard, Mike Bemford, Myles Maxfield, Nat McCully, Paul Nelson, Pierre-Anthony Lemieux, Rahul Sonnad, Randy Edmunds, Richard Ishida, Shinyu Murakami, Stephen Deach, Steve Zilles, Takao Suzuki, Tantek Çelik, Xidorn Quan, Yaniv Feinberg.

변경사항

이 초안은 [CSS-TEXT-3]와 동기화되어 유지된다. CSS Text 3 § 변경사항을 참조하라.
Level 4에 특화된 변경사항은 아래에 나열되어 있다.

2024년 5월 29일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• avoid-orphans를 text-wrap-style에 추가했다. (Issue 10837)

• 기본 UA 스타일시트에서 text-spacing: none이 할당되는 요소 목록에 listing, xmp, 및 plaintext를 추가했다. (Issue 13369)

2024년 2월 19일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• text-spacing-trim 값 trim-auto의 이름을 trim-both로 바꾸었다. (Issue 10161)

• 많은 수의 줄이 있는 경우에 대해 text-wrap-style: balance에서 줄을 변경하지 말아야 한다는 요구사항을 완화했다. (Issue 10186)

• text-wrap-style: balance와 line-clamp의 상호작용을 정의했다 (Issue 9310)

• text-transform에 math-auto 값을 추가했다. (Issue 5386)

2023년 10월 20일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• text-spacing-trim: space-first 정의에서 실수로 삭제된 “and each line after a forced line break”를 복원했다. (Issue 9532)

• text-spacing-trim의 초기값을 normal로 만들었다. (Issue 9511)

• space-first의 줄 끝 동작을 변경했다. (Issue 9736)

• space-first가 줄 나누기 뒤에도 적용된다. (Issue 9532)

• 전각 문장부호 병합의 세부 사항을 명확히 했다. (Issue 9225)

• 사용자 에이전트 스타일 규칙으로 pre가 기본적으로 hanging-punctuation을 상속하지 못하게 했다. (Issue 9689)

2023년 3월 29일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• text-wrap 속성을 두 새 속성 text-wrap-mode 및 text-wrap-style의 단축 속성으로 재구성하고, text-wrap가 아니라 text-wrap-mode를 white-space 속성의 longhand로 만들었다.

• 부록 G: 작은 Kana 매핑을 Unicode 15.0으로 업데이트했다. (Issue 8442)

• word-break: auto-phrase word-break: manual 기능을 (이전의 독립적인 word-boundary-detection 속성 시도에서) 다시 설계하고, word-space-transform에 auto-phrase 값을 추가했다 (더 이상 word-boundary-detection에 의존할 수 없기 때문). 그리고 관련 지원 메커니즘을 업데이트했다.

• word-boundary-expansion의 이름을 word-space-transform으로 바꾸었다

• text-spacing-trim에 trim-all을 추가했다. (Issue 8482)

• NBSP 이외의 non-tailorable Unicode 줄 나누기 제어가 atomic inline에 대한 우리의 규칙보다 우선한다. (Issue 8972)

2023년 3월 1일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• white-space를 여러 longhand로 변환하는 작업을 다음으로 완료했다

  • white-space-collapse에 break-spaces를 추가하여 모든 단축 속성 값을 longhand로 표현할 수 있게 함 (Issue 8256)

  • 모든 longhand 키워드를 white-space 단축 속성에 통합

  • 그에 따라 설명 업데이트

• text-space-collapse 및 text-space-trim의 이름을 white-space-collapse 및 white-space-trim으로 바꾸었다. (Issue 8273)

2022년 12월 31일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• text-spacing을 다음 방식으로 다시 설계했다:

  • 유용하지 않은 키워드 조합 제거 (Issues 4246, 8288)

  • space-first를 초기값으로 만듦 (Issue 2462)

  • longhand로 분리 (Issues 4246, 7183, 8288)

  • 각 기능을 “off”할 수 있도록 보장. (Issues 6950, 8288)

  • 소스의 잘못된 공백 문자를 대체할 수 있는 키워드 추가. (Issues 318, 7183, 8263)

  • plaintext에서 유래한 소스 텍스트 관행을 보정하기 위해 hanging-punctuation이 선행 ideographic space를 행잉할 수 있게 함. (Issue 2462)

  • no-compress를 text-justify로 옮김. 이는 간격보다 양쪽 맞춤을 더 많이 제어하기 때문이다. (Issue 7079)

• text-spacing에서 평가되는 문맥적 문자를 Pe 및 Ps 범주의 문자까지 확장했다. (Issue 6091)

• text-space-collapse의 이름을 다시 white-space-collapse로 바꾸었다. (Issue 8273)

2022년 5월 5일 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• ruby 값을 text-justify에 추가했다. (Issue 771 Issue 779)
• text-spacing: normal이 allow-end 대신 trim-end를 사용하도록 전환했다. (Issue 7055)
• text-spacing: normal이 ideograph-alpha 및 ideograph-numeric도 적용하도록 전환하고, monospace 컨텍스트에서는 이를 제외하도록 UA 기본 스타일시트를 업데이트했으며, non-zero margin/border/padding이 공백 삽입을 억제한다고 지정하고, 삽입되는 공간의 양을 0.125ic로 정의했다. (Issue 6950)
• text-align: match-parent가 구현 단순화를 위해 root element에서 start로 계산되도록 정의했다. (Issue 6542)
• distribute 키워드가 레거시 값 별칭이 되거나, 단순히 inter-character로 계산될 수 있도록 허용했다; 이는 어떤 방식이든 하위 호환성에서는 구분이 중요하지 않으므로 UA가 더 쉬운 쪽을 사용할 수 있게 한다. (Issue 7322)
• white-space-trim의 trim-inner 값을 다른 값들과의 일관성을 위해 discard-inner로 이름 바꾸었다. (Issue 448)

2019년 Working Draft 이후의 중요한 변경사항은 다음을 포함한다:

• [CSS-TEXT-3]의 전체 텍스트 통합.
• word-spacing 및 letter-spacing에 현재 font-size에 상대적인 크기를 나타내기 위해 백분율을 추가. (Issue 2165)
• textarea의 공백이 병합되지 않도록 하는 UA 규칙 제안. (Issue 6309)

Level 3 이후 추가사항

Level 4의 새로운 기능:

• 줄 나누기 중 함께 유지할 구를 자동으로 결정하기 위한 word-break: auto-phrase

• 단어 구분자를 변환하기 위한 word-space-transform

• white-space 속성을 여러 longhand로 분리:

  • white-space-collapse 및 그 preserve-spaces 및 discard 값

  • 요소 경계의 초과 공백을 잘라내기 위한 white-space-trim

  • 줄바꿈이 발생할지 여부를 제어하기 위한 text-wrap-mode

• text-wrap-style 및 그 balance, stable, 그리고 pretty 값

• 줄바꿈을 피하거나 강제하기 위한 wrap-before, wrap-after, 및 wrap-inside (페이지네이션의 break-* 속성과 유사)

• 하이픈 넣기 문자를 명시적으로 제어하기 위한 hyphenate-character

• 자동 하이픈 넣기를 더 잘 제어하기 위한 hyphenate-limit-zone, hyphenate-limit-chars, hyphenate-limit-lines, hyphenate-limit-last

• 예를 들어 소수점에 맞춰 정렬하기 위한 <string> 값의 text-align

• text-align로 내용이 정렬된 줄 박스 집합을 그룹 정렬하기 위한 text-group-align

• 줄의 시작/끝에서 인라인 박스 내부에 공간을 삽입하기 위한 line-padding

• 문장부호 및 script 변경 주변의 자동 간격을 위한 text-spacing