CSS 텍스트 모듈 레벨 3

1. 소개

이 모듈은 CSS의 조판 제어 기능을 설명합니다. 즉, 원본 텍스트를 서식이 적용되고 줄 바꿈된 텍스트로 변환하는 CSS 기능들을 다룹니다. 다양한 CSS 속성은 대소문자 변환, 공백 압축, 텍스트 줄 바꿈, 줄 바꿈 규칙 및 하이픈 처리, 정렬 및 양쪽 맞춤, 간격, 그리고 들여쓰기에 대한 제어를 제공합니다.

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

1.1. 모듈 상호작용

이 모듈은 CSS Text Decoration 모듈과 함께, Cascading Style Sheets Level 2 16장에서 정의된 텍스트 레벨 기능을 대체 및 확장합니다. [CSS-TEXT-DECOR-3] [CSS2]

아래에 정의된 용어 외에도, 이 명세에서 사용되는 다른 용어와 개념들은 Cascading Style Sheets Level 2 및 CSS Writing Modes 모듈에 정의되어 있습니다. [CSS2] 및 [CSS-WRITING-MODES-4].

1.2. 값 정의

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

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

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) 이들도 각각 문자로 간주될 수 있습니다.

컴퓨터 텍스트 인코딩의 기본 단위도 문자라 불리며, 인코딩에 따라 하나의 인코딩 문자가 전체 음절 단위의 문자(예: 한), 개별 음소 단위의 문자(예: ㅎ), 또는 더 작은 단위(예: ㅇ) 및 그에 변형을 주는 조합 기호(예: 발음 구별을 위한 추가 획)일 수 있습니다.

또한, 하나의 인코딩 문자는 데이터 스트림에서 하나 이상의 바이트로 표현될 수 있고, 프로그래밍 환경에서는 1 바이트가 문자라고 불리기도 합니다.

따라서 문자라는 용어는 기술적으로 정확해야 하는 경우에는 다소 모호할 수 있습니다.

텍스트 레이아웃에서는 조판 문자 단위를 텍스트의 기본 단위로 사용합니다. 텍스트 레이아웃 내에서도, 관련 문자 단위는 작업에 따라 달라집니다. 예를 들어 줄 바꿈 및 글자 간격 조정은 U+0E33 ำ 태국 문자 SARA AM이 포함된 태국어 문자 시퀀스를 다르게 분할할 수 있습니다; 또는 데바나가리와 같은 문자체계에서 결합 자음의 동작은 사용되는 글꼴에 따라 달라질 수 있습니다. 즉 조판 문자는 문자체계의 단위로, 라틴 알파벳(발음 구별 기호 포함), 한글 음절, 중국 한자, 미얀마 음절 클러스터 등 특정 조판 작업(줄 바꿈, 첫 글자 효과, 트래킹, 양쪽 맞춤, 수직 배열 등)에 대해 더 이상 분할되지 않는 단위를 의미합니다.

Unicode Standard Annex #29: Text Segmentation 에서는 그래프 클러스터라는 단위를 정의하는데, 이는 조판 문자와 유사합니다. [UAX29] UA는 확장 그래프 클러스터(레거시 그래프 클러스터가 아님)를 UAX29에서 정의한 대로 조판 문자 단위의 기준으로 사용해야 합니다. 하지만 UA는 조판 전통에 따라 필요한 경우 정의를 맞춤해야 하며, 기본 규칙이 항상 적합하거나 이상적이지 않으므로 작업에 따라 다르게 맞춤하는 것이 기대됩니다.

참고: 이러한 맞춤 규칙은 CSS의 범위에 포함되지 않습니다.

조판 글자 단위(또는 이 명세에서는 글자라 함) 는 조판 문자 단위 중 Letter 또는 Number 일반 카테고리에 속하는 것입니다. 조판 문자 단위의 Unicode 속성 결정 방법은 부록 E: 문자와 속성을 참고하세요.

요소 경계로 나뉜 조판 문자 단위의 렌더링 특성은 정의되어 있지 않습니다. 이상적으로는 각 구성 요소가 해당 요소의 속성에 맞는 서식 요구사항에 따라 렌더링되어야 하며, 전체 조판 문자 단위의 올바른 셰이핑 및 위치를 유지해야 합니다. 그러나 부분 간 서식 차이의 성격과 사용되는 글꼴 기술의 기능에 따라 항상 이것이 가능하지는 않습니다. 따라서 이러한 조판 문자 단위는 경계의 어느 한 쪽에 속한 것으로 렌더링되거나, 양쪽에 속한 것처럼 근접하게 렌더링될 수 있습니다. 저자는 그래프 클러스터 또는 합자(ligature)를 요소 경계로 나누면 일관되지 않거나 예상치 못한 결과가 발생할 수 있음을 유의해야 합니다.

1.5. 텍스트 처리

CSS는 유니코드에 기반합니다. [UNICODE] 유니코드를 지원하는 UA는 유니코드 코어 표준의 모든 규범적 요구사항을 따라야 하며, CSS에서 명시적으로 재정의된 경우를 제외하고는 예외가 없습니다. 유니코드가 아닌 텍스트 인코딩 모델을 기반으로 구현된 UA도 적절한 매핑과 유사한 동작을 가정하여 동일한 텍스트 처리 요구를 충족해야 합니다.

텍스트 처리(예: 공백 처리, 텍스트 변환, 줄 바꿈 등)의 인접성 판단을 위해, 그리고 이 명세 전반에서, inline box 경계 및 out-of-flow 요소는 무시해야 합니다. 텍스트 셰이핑과 관련해서는 § 7.3 요소 경계 셰이핑을 참고하세요.

2. 텍스트 변환

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

이 속성은 스타일링을 위해 텍스트를 변환합니다. 원본 콘텐츠에는 영향을 주지 않으며, 일반 텍스트 복사 & 붙여넣기 작업의 내용에도 영향을 주지 않아야 합니다.

저자는 text-transform을 의미론적 목적으로 사용해서는 안 됩니다; 올바른 대소문자 및 의미는 소스 문서의 텍스트와 마크업에 직접 인코딩되어야 합니다.

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

none

효과 없음.

capitalize

각 단어의 첫 번째 조판 글자 단위가 소문자일 경우 대문자(titlecase)로 변환합니다; 다른 문자는 변하지 않습니다.

uppercase

모든 글자를 대문자로 변환합니다.

lowercase

모든 글자를 소문자로 변환합니다.

full-width

모든 조판 문자 단위를 전각(full-width) 형태로 변환합니다. 해당 문자의 전각 형태가 없는 경우 그대로 둡니다. 이 값은 일반적으로 라틴 글자와 숫자를 한자처럼 조판할 때 사용됩니다.

full-size-kana

모든 소형 가나 문자를 해당하는 대형 가나로 변환합니다. 이 값은 주로 루비 주석 텍스트에서 사용되며, 저자가 작은 폰트 크기에서 가독성 문제를 보완하기 위해 모든 소형 가나를 대형 가나로 표시하고자 할 때 활용됩니다.

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; /* 큰 글자에는 해제 */ }

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

2.1.1. 매핑 규칙

capitalize의 경우, “단어”의 정의는 UA마다 다르며; [UAX29]를 단어 경계 판단에 권장하지만 필수는 아닙니다. out-of-flow 요소 및 인라인 요소 경계는 text-transform의 단어 경계를 만들면 안 되며, 단어 경계 판단 시 무시해야 합니다.

참고: 저자는 capitalize가 언어별 제목 대문자 규칙(예: 영어에서 관사 건너뛰기 등)을 따르는 것을 기대해서는 안 됩니다.

UA는 유니코드 문자에 대한 전체 대소문자 매핑(조건부 대소문자 규칙 포함)을 The Unicode Standard의 Default Case Algorithms 섹션에 정의된 대로 사용해야 합니다. [UNICODE] 요소의 콘텐츠 언어가, 문서 언어의 규칙에 따라 알려진 경우에는, 해당 언어별 규칙도 반드시 적용해야 합니다. 여기에 최소한 유니코드의 SpecialCasing.txt에 포함된 언어별 규칙이 포함됩니다.

전각(full-width) 및 반각(half-width) 형태의 정의는 Unicode Standard Annex #11: East Asian Width에서 확인할 수 있습니다. [UAX11] 전각 형태로의 매핑은 full-width 형태가 Decomposition_Mapping에 <wide> 또는 <narrow> 태그로 표시된 코드 포인트를 기반으로 정의됩니다. Unicode Standard Annex #44: Unicode Character Database [UAX44] <narrow> 태그의 경우 매핑은 코드 포인트에서 분해(decomposition, 태그 제외)로, <wide> 태그의 경우 매핑은 분해에서(태그 제외) 원래 코드 포인트로 이루어집니다.

소형 가나를 대형 가나로 매핑하는 규칙은 부록 G: 소형 가나 매핑에 정의되어 있습니다.

2.1.2. 변환 순서

여러 값을 지정하여 여러 변환을 적용해야 하는 경우, 다음 순서로 적용됩니다:

1. capitalize, uppercase, 그리고 lowercase
2. full-width
3. full-size-kana

텍스트 변환은 § 4.1.1 1단계: 압축 및 변환 이후, § 4.1.2 2단계: 트리밍 및 위치 지정 이전에 발생합니다. 즉, full-width는 preserved white space 내에서만 공백(U+0020)을 U+3000 한자 공백으로 변환합니다.

참고: 부록 A: 텍스트 처리 순서에서 정의한 대로, 텍스트 변환은 줄 바꿈 및 기타 서식 작업에 영향을 줍니다.

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

이 속성은 두 가지를 지정합니다:

• white space를 어떻게, 또는 어떤 방식으로 압축(collapse)할지
• 줄이 강제되지 않은 soft wrap 기회에서 줄 바꿈이 허용되는지 여부

값의 의미는 다음과 같으며, 공백 처리 규칙과 줄 바꿈 규칙에 따라 해석해야 합니다:

normal

이 값은 UA가 white space 시퀀스를 한 글자(또는 일부 경우에는 글자가 없는 상태)로 압축하도록 지시합니다. 줄은 허용된 soft wrap 기회에서 바뀔 수 있으며, 적용되는 줄 바꿈 규칙에 따라 inline 축 오버플로우를 최소화합니다.

pre

이 값은 UA가 white space 시퀀스를 압축하지 않도록 방지합니다. Segment break (줄바꿈 등)는 강제 줄 바꿈으로 유지됩니다. 줄은 강제 줄 바꿈에서만 바뀌며; 블록 컨테이너에 맞지 않는 내용은 오버플로우됩니다.

nowrap

normal과 유사하게 white space를 압축하지만, pre처럼 줄 바꿈을 허용하지 않습니다.

pre-wrap

pre처럼 white space를 유지하지만, normal처럼 줄 바꿈을 허용합니다.

break-spaces

동작은 pre-wrap과 동일하지만:

• 어떤 preserved white space 또는 other space separators 시퀀스는 항상 공간을 차지합니다, 줄 끝에서도 포함됩니다.
• 모든 preserved white space 문자 및 모든 other space separator(인접한 공백 사이 포함) 뒤에 soft wrap 기회가 존재합니다.

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

pre-line

normal처럼 연속된 white space 문자를 압축하고 줄 바꿈을 허용하지만, 소스의 segment break는 강제 줄 바꿈으로 유지합니다.

공백 처리로 인해 제거 또는 압축되지 않은 공백은 preserved white space라고 합니다.

참고: 어떤 경우에는 preserved white space와 other space separators가 줄 끝에서 hang될 수 있습니다; 이는 내재 크기 측정에 영향을 줄 수 있습니다.

다음 참고용 표는 다양한 white-space 값의 동작을 요약합니다:

공백 처리 규칙에서 white space 압축 방법의 세부사항을 확인하세요.

줄 바꿈에서 줄 바꿈 동작의 세부사항을 확인하세요.

4. 공백 처리 및 제어 문자

문서의 원본 텍스트에는 최종 렌더링과 관련 없는 서식이 포함되는 경우가 많습니다: 예를 들어, 편집 편의를 위해 원본을 여러 줄(segment)로 나누거나 소스 코드 들여쓰기를 위해 white space 문자로 탭과 공백을 추가하는 경우 등입니다. CSS의 공백 처리 기능을 통해 저자는 이러한 서식 해석을 제어할 수 있습니다: 렌더링 시 이를 유지하거나 압축할 수 있습니다. CSS에서의 공백 처리(white-space 속성으로 제어)는 white space 문자를 렌더링 목적에만 해석하며: 원본 문서 데이터에는 영향을 주지 않습니다.

참고: 문서 언어에 따라 구분자는 특정 줄 바꿈 시퀀스(줄 바꿈 문자, CRLF 등)일 수 있고, SGML RECORD-START, RECORD-END 토큰과 같은 다른 방식일 수도 있습니다.

CSS 처리 시, 각 문서 언어에서 정의한 "segment break" 또는 "newline sequence"—​정의가 없으면 각 줄 바꿈(U+000A)—​는 segment break로 처리되며, 이후 white-space 속성에서 지정한 대로 렌더링됩니다.

HTML의 경우, 줄 바꿈(newlines)은 정규화(normalized)되어 줄 바꿈 문자(U+000A)로 DOM에 표현됩니다. 따라서 HTML 문서가 DOM 트리로 표현될 때 각 줄 바꿈(U+000A)은 segment break로 처리됩니다. [HTML] [DOM]

참고: 대부분의 CSS 구현에서는 HTML이 직접 스타일링되지 않습니다. 대신 DOM 트리로 처리된 후 스타일링됩니다. HTML과 달리, DOM에서는 캐리지 리턴(U+000D)에 특별한 의미를 부여하지 않으므로, segment break로 처리되지 않습니다. HTML 파싱 이외의 방식으로 DOM에 캐리지 리턴(U+000D)이 삽입된 경우, 아래 정의에 따라 처리됩니다.

참고: 문서 파서는 segment break를 정규화할 뿐만 아니라, 다른 공백 문자를 압축하거나 마크업 규칙에 따라 공백을 처리할 수도 있습니다. CSS 처리 단계는 파싱 이후에 이루어지기 때문에 스타일링을 위해 해당 문자를 복원할 수 없습니다. 따라서 아래 명세된 일부 동작은 이러한 한계에 의해 영향을 받을 수 있으며 UA마다 다를 수 있습니다.

참고: collapsible white space만으로 구성된 익명 블록은 렌더링 트리에서 제거됩니다. 따라서 블록 수준 요소를 둘러싼 white space도 압축되어 사라집니다. CSS 2.1 § 9.2.2.1 익명 인라인 박스를 참고하세요. [CSS2]

제어 문자(Unicode category Cc)—​탭(U+0009), 줄 바꿈(U+000A), 캐리지 리턴(U+000D), 그리고 segment break를 구성하는 시퀀스를 제외하고—​는 UA가 글꼴에서 보이는 글리프를 찾지 못하는 경우 직접 합성해야 하며, 눈에 보이는 글리프로 렌더링되어야 하며, 그 외에는 Other Symbols(So) 일반 카테고리 및 Common 스크립트의 다른 문자처럼 처리되어야 합니다. UA는 제어 문자 전용 글꼴의 글리프, Control Pictures 블록의 해당 기호 글리프, 코드 포인트 값을 시각적으로 표시하거나 기타 적합한 방법으로 눈에 보이는 글리프를 제공할 수 있습니다. 유니코드 요구사항에 따라, 지원되지 않는 Default_ignorable 문자는 렌더링에서 무시해야 합니다. [UNICODE]

캐리지 리턴(U+000D)은 모든 면에서 공백(U+0020)과 동일하게 처리됩니다.

참고: HTML 문서의 경우, 소스 코드에 있는 캐리지 리턴은 파싱 단계에서 줄 바꿈으로 변환됩니다 (HTML § 13.2.3.5 입력 스트림 전처리 및 normalize newlines 정의(Infra)를 참고) 따라서 CSS에서는 U+000D CARRIAGE RETURN으로 나타나지 않습니다. [HTML] [INFRA]) 단, 이 문자는 escape 시퀀스(
)로 인코딩할 경우 보존되며, 위 규칙에 따라 관찰 가능합니다.

4.1. 공백 처리 규칙

별도로 명시된 경우를 제외하고, CSS의 공백 처리는 오직 문서 공백 문자에만 영향을 미칩니다: 스페이스(U+0020), 탭(U+0009), 그리고 세그먼트 분리입니다.

참고: 문서 공백으로 간주되는 문자 집합(문서 내용의 일부) 그리고 구문적 공백(CSS 문법의 일부)으로 간주되는 문자 집합은 반드시 동일하지 않습니다. 그러나 둘 다 스페이스(U+0020), 탭(U+0009), 줄 바꿈(U+000A)을 포함하므로 대부분의 저자는 차이를 느끼지 못할 것입니다.

스페이스(U+0020)와 non-breaking space(U+00A0) 외에도, 유니코드는 추가적인 공백 분리 문자들을 정의합니다. [UNICODE] 이 명세에서는 유니코드 일반 카테고리 Zs에 속하면서 스페이스(U+0020)와 non-breaking space(U+00A0)가 아닌 모든 문자를 기타 공백 분리자라 통칭합니다.

4.1.1. 1단계: 압축 및 변환

각 인라인(익명 인라인 포함; CSS 2.1 § 9.2.2.1 익명 인라인 박스 [CSS2] 참고) 인라인 포맷팅 컨텍스트 내에서, 공백 문자는 줄 바꿈 및 bidi 재정렬 이전에 다음과 같이 처리됩니다. bidi 서식 문자(Bidi_Control 속성 가진 문자 [UAX9]) 는 없는 것처럼 무시합니다:

• white-space 속성이 normal, nowrap, pre-line으로 설정된 경우, 공백 문자는 압축 가능 공백으로 간주되며, 다음의 단계로 처리됩니다:
  1. 압축 가능 스페이스와 탭이 세그먼트 분리 직전 또는 직후에 연속으로 있으면 삭제됩니다.
  2. 압축 가능 세그먼트 분리는 세그먼트 분리 변환 규칙에 따라 렌더링용으로 변환됩니다.
  3. 모든 압축 가능 탭은 압축 가능 스페이스(U+0020)로 변환됩니다.
  4. 압축 가능 스페이스가 바로 앞에 다른 압축 가능 스페이스가 있을 경우—​해당 스페이스가 포함 인라인의 경계를 넘어 있더라도, 두 스페이스가 동일 인라인 포맷팅 컨텍스트 내에 있으면—​너비가 0으로 압축됩니다. (보이지 않지만, soft wrap 기회는 유지됩니다.)
• white-space 속성이 pre, pre-wrap, break-spaces 중 하나로 설정된 경우, 모든 스페이스 시퀀스는 non-breaking space 시퀀스로 처리합니다. 단, pre-wrap에서는 soft wrap 기회가 스페이스 및/또는 탭 시퀀스 끝에 존재하며, break-spaces에서는 모든 스페이스 및 탭 뒤에 soft wrap 기회가 있습니다.

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

A  BC

4.1.2. 2단계: 트리밍 및 위치 지정

이후 전체 블록이 렌더링됩니다. 인라인은 bidi 재정렬을 고려하여 배치되고, 줄 바꿈은 white-space 속성에 따라 처리됩니다. 각 줄을 배치할 때,

1. 줄 시작에 압축 가능 스페이스 시퀀스가 있으면 제거됩니다.
2. 탭 크기가 0이면 preserved 탭은 렌더링되지 않습니다. 그렇지 않으면, 각 preserved 탭은 다음 글리프의 시작 가장자리를 다음 탭 스톱에 맞추는 수평 이동으로 렌더링됩니다. 이 거리가 0.5ch보다 짧으면 다음 탭 스톱이 사용됩니다. 탭 스톱은 탭 크기의 배수 지점에서 preserved 탭이 속한 가장 가까운 블록 컨테이너의 시작 가장자리로부터 측정됩니다. 탭 크기는 tab-size 속성으로 지정됩니다.

   참고: 유니코드 탭(U+0009)이 양방향성과 상호작용하는 규칙 참고. [UAX9]

3. 줄 끝에 압축 가능 스페이스 시퀀스와, white-space 속성이 normal, nowrap, pre-line인 경우의 마지막 U+1680   오검 공백 기호가 제거됩니다.

   참고: Unicode Bidirectional Algorithm L1 규칙에 따라, 줄 끝의 압축 가능 스페이스 시퀀스는 재정렬 전과 후 모두 줄 끝에 위치합니다. [UAX9] [CSS-WRITING-MODES-4]

4. 줄 끝에 공백, 기타 공백 분리자, preserved 탭 시퀀스가 남아 있다면(양방향성 재정렬 후 [CSS-WRITING-MODES-4]):
   • white-space 속성이 normal, nowrap, pre-line인 경우, UA는 해당 시퀀스를 행(hang)해야 합니다(무조건).
   • white-space 속성이 pre-wrap인 경우, UA는 해당 시퀀스를 무조건 행(hang)해야 하며, 단, 시퀀스 뒤에 강제 줄 바꿈이 있는 경우에는 조건부 행(hang)으로 처리해야 합니다. 필요한 경우 오버플로우가 발생하는 문자의 advance width를 시각적으로 압축할 수 있습니다.

     참고: 공백을 행(hang) 처리하면 텍스트 선택 또는 편집 시 사용자가 공백을 볼 수 있습니다.

   • white-space 속성이 break-spaces인 경우, 스페이스, 탭, 기타 공백 분리자는 다른 보이는 문자와 동일하게 처리됩니다: 행(hang) 되거나 advance width가 압축될 수 없습니다.

     참고: 이런 문자는 공간을 차지하며, 사용 가능한 공간 및 줄 바꿈 제어에 따라 오버플로우되거나 줄이 바뀔 수 있습니다.

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.1.3. 세그먼트 분리 변환 규칙

white-space가 pre, pre-wrap, break-spaces, 또는 pre-line인 경우, segment break는 압축 가능이 아니며, 대신 보존된 줄 바꿈(U+000A)으로 변환됩니다.

그 외 white-space 값에서는, segment break가 압축 가능으로 간주되어 아래와 같이 압축됩니다:

1. 먼저, 병합 가능한 구분 구간 줄바꿈이 다른 병합 가능한 구분 구간 줄바꿈 바로 뒤에 오면 제거됩니다.
2. 남아있는 segment break는 상황에 따라 스페이스(U+0020)로 변환되거나 삭제됩니다. 이 작업의 규칙은 현행 표준에서는 UA 정의입니다.

   참고: 공백 처리 규칙은 이미 이 컨텍스트 평가 전에 탭 및 스페이스를 segment break 주변에서 제거합니다.

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는 segment break를 조건 없이 스페이스로 변환해왔으며, 이로 인해 중국어처럼 소스 내에서 줄 바꿈이 필요한 언어의 콘텐츠 작성이 어려웠습니다. 따라서 UA 휴리스틱은 segment break를 어디서 버릴지 결정할 때 보수적이어야 하며, 이런 언어 지원을 개선하기 위한 노력과 균형이 필요합니다.

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

이 속성은 탭 크기를 결정하며, 이는 preserved 탭 문자(U+0009)를 렌더링할 때 사용됩니다. <number>는 가장 가까운 블록 컨테이너 조상에 있는 preserved 탭의 스페이스(U+0020) advance width의 배수로 측정합니다. letter-spacing 및 word-spacing도 포함됩니다. 음수 값은 허용되지 않습니다.

5. 줄 바꿈 및 단어 경계

인라인 레벨 콘텐츠가 줄로 레이아웃될 때, 줄 박스 사이에서 분리됩니다. 이러한 분리를 줄 바꿈(line break)이라 합니다. 명시적 줄 바꿈 제어(예: preserved 줄 바꿈 문자)로 인해 줄이 분리되거나, 블록의 시작 또는 끝에서 줄이 분리되는 경우, 이를 강제 줄 바꿈(forced line break)이라 합니다. 콘텐츠 줄 바꿈(wrapping)으로 인해 줄이 분리되면(UA가 콘텐츠를 칸 내에 맞추기 위해 비강제 줄 바꿈을 생성하는 경우), 이를 연성 줄 바꿈(soft wrap break)이라 합니다. 인라인 레벨 콘텐츠를 줄 단위로 분리하는 과정을 줄 바꿈 처리(line breaking)라 합니다.

줄 바꿈은 허용된 분리 지점에서만 수행되며, 이를 연성 줄 바꿈 기회(soft wrap opportunity)라고 합니다. 줄 바꿈이 활성화된 경우(white-space 참고), UA는 줄이 넘치는 콘텐츠를 최소화하기 위해 연성 줄 바꿈 기회에서 줄을 바꿔야 합니다(존재하는 경우).

대부분의 문자체계에서는, 하이픈 처리(hyphenation)가 없는 경우 연성 줄 바꿈 기회는 단어 경계에서만 발생합니다. 이런 시스템에서는 스페이스 또는 문장부호로 단어를 명시적으로 분리하며, 연성 줄 바꿈 기회를 이런 문자로 식별할 수 있습니다. 태국어, 라오어, 크메르어 같은 문자체계는 단어 분리에 스페이스나 문장부호를 사용하지 않습니다. 이런 문자체계에서는 zero width space(U+200B)를 명시적 단어 경계로 사용할 수 있지만, 일반적으로 그렇게 하지 않습니다. 따라서 이런 텍스트에서 연성 줄 바꿈 기회를 올바르게 식별하려면 어휘 자원이 필요합니다.

다른 일부 문자체계에서는 연성 줄 바꿈 기회가 단어 경계가 아니라 정서법적 음절 경계를 기준으로 합니다. 자와어, 발리어와 같은 시스템은 태국어, 라오어와 유사하게 줄 바꿈 기회를 찾으려면 텍스트 분석이 필요합니다. 중국어(및 일본어, 이이어, 때때로 한국어)의 경우 각 음절이 대개 하나의 조판 글자 단위에 대응하며, 줄 바꿈 규칙은 특정 문자 조합 사이를 제외하고는 어디서든 줄 바꿈을 허용합니다. 또한 이런 제한의 엄격성 수준은 조판 스타일에 따라 다릅니다.

CSS는 연성 줄 바꿈 기회가 어디서 발생하는지 완전히 정의하지는 않지만, 일반적인 변형을 구분할 수 있는 몇 가지 제어를 제공합니다:

• line-break 속성은 줄 바꿈 제한의 다양한 "엄격도" 수준을 선택할 수 있게 해줍니다.
• word-break 속성은 어떤 종류의 글자들이 끼리 뭉쳐져 분리 불가능한 "단어"를 구성할지 제어하며, CJK 문자가 비-CJK 텍스트처럼 동작하거나 그 반대가 되도록 만듭니다.
• hyphens 속성은 하이픈 처리가 가능한 문자체계에서 자동 하이픈으로 단어를 분리할 수 있는지 제어합니다.
• overflow-wrap 속성은 UA가 오버플로우될 수 있는 분리 불가능한 문자열에서 어디서든 줄을 바꿀 수 있게 해줍니다.

참고: Unicode Standard Annex #14: Unicode Line Breaking Algorithm은 유니코드의 모든 문자체계에 대한 줄 바꿈의 기본 동작을 정의하며, 추가 맞춤이 이루어질 것으로 예상됩니다. [UAX14] 줄 바꿈 관행에 대한 더 많은 정보는 일본어의 경우 일본어 조판 요구사항 [JLREQ] 및 일본어 문서 조판 방법 [JIS4051], 중국어의 경우 중국어 조판 요구사항 [CLREQ] 및 문장부호 일반 규칙 [ZHMARK] 참고. 국제화 작업 그룹의 언어 지원 인덱스도 참고하면 추가 언어에 관한 정보를 얻을 수 있습니다. [TYPOGRAPHY] 추가로 적합한 참고문헌에 대한 안내가 있다면 감사히 받겠습니다.

5.1. 줄 바꿈 상세

줄 바꿈을 결정할 때:

• 줄 바꿈 처리와 양방향 텍스트의 상호작용은 CSS Writing Modes 4 § 2.4 양방향 재정렬 알고리즘 적용하기 및 Unicode 양방향 알고리즘(특히 UAX9§3.4 Resolved Levels 재정렬)에서 정의됩니다. [CSS-WRITING-MODES-4] [UAX9]
• 보존된 세그먼트 분리와—​white-space 값에 관계없이—​BK, NL 줄 바꿈 클래스를 가진 모든 유니코드 문자는 강제 줄 바꿈으로 처리되어야 합니다. [UAX14]

  참고: 이런 강제 줄 바꿈의 양방향성 영향은 Unicode 양방향 알고리즘에서 정의됩니다. [UAX9]

• 명시적으로 다르게 정의된 경우를 제외하고 (예: line-break: anywhere 또는 overflow-wrap: anywhere 등) WJ, ZW, GL, ZWJ 유니코드 줄 바꿈 클래스의 줄 바꿈 동작을 반드시 준수해야 합니다. [UAX14]
• 줄 바꿈을 허용하는 문자체계에서 단어 구분자 이외의 문장부호에서 줄 바꿈을 허용하는 UA는 분리점 우선순위를 적용해야 합니다. (예: 슬래시 뒤에 줄 바꿈 우선순위가 스페이스보다 낮으면 “check /etc”에서 "/"와 "e" 사이에 줄 바꿈이 절대 발생하지 않음.) 이런 어색한 줄 바꿈을 피하도록 주의하면서, 단어 구분자 이외의 적절한 문장부호에서 줄 바꿈을 허용하면, 특히 좁은 칸에서 더 고른 여백이 가능합니다. UA는 컨테이닝 블록의 너비, 텍스트 언어, line-break 값 등 다양한 요소로 우선순위를 정할 수 있습니다: CSS는 soft wrap opportunities의 우선순위를 정의하지 않습니다. 단어 구분자 우선순위는, word-break: break-all 지정 시에는 적용되지 않으며 (단어 구분자에서 줄 바꿈하지 않는 동작을 명시적으로 요청하므로)—​line-break: anywhere에서는 금지됩니다.
• out-of-flow 요소 및 인라인 요소 경계는 흐름 내에서 강제 줄 바꿈 또는 soft wrap opportunity를 생성하지 않습니다.
• 웹 호환성을 위해, 치환 요소나 기타 atomic inline 앞뒤에는 soft wrap opportunity가 존재합니다. 이는 인접한 문자가 보통 줄 바꿈 기회를 억제하는 경우(예: U+00A0 NO-BREAK SPACE 포함)에도 해당됩니다. 단, U+00A0 NO-BREAK SPACE를 제외하고는, soft wrap opportunity는 atomic inlines와 인접한 문자 중 GL, WJ, ZWJ 줄 바꿈 클래스를 가진 문자 사이에는 없어야 합니다. [UAX14]
• 줄 바꿈 시 사라지는 문자(예: U+0020 SPACE)가 만든 soft wrap opportunity에서는 해당 문자를 직접 포함하는 박스의 속성이 줄 바꿈을 제어합니다. 두 문자 또는 atomic inline 사이 경계에서 정의된 soft wrap opportunity의 경우, 두 문자에 가장 가까운 공통 조상 요소의 white-space 속성이 줄 바꿈을 제어합니다; 어떤 요소의 line-break, word-break, overflow-wrap 속성이 이런 경계에서 soft wrap opportunity 결정에 영향을 주는지는 현행 표준에서는 정의되지 않았습니다.
• 박스의 첫 번째 또는 마지막 문자 앞뒤에 있는 soft wrap opportunity의 경우, 줄 바꿈은 바로 박스 앞/뒤(마진 가장자리)에서 발생하며, 박스 내부 콘텐츠와 가장자리 사이에서 박스를 분할하지 않습니다.
• Ruby의 줄 바꿈은 CSS Ruby Annotation Layout 1 § 3.4 줄 바꿈에서 정의됩니다. [CSS-RUBY-1]
• 예기치 않은 오버플로우를 방지하기 위해, UA가 줄 바꿈에 필요한 어휘적 또는 정서법적 분석을 수행할 수 없는 콘텐츠 언어에서는—​예를 들어 특정 언어에 대한 사전이 없을 경우—​해당 문자체계의 조판 글자 단위 쌍 사이에 soft wrap opportunity가 있다고 가정해야 합니다.

  참고: 이 조항은 UA가 특정 텍스트 런에서 단어 경계를 찾지 못한 경우에만 적용되는 것이 아니라, 해당 텍스트 런이 분리 불가능한 단어일 수도 있습니다. 예를 들어, UA가 크메르어 문자(U+1780~U+17FF)로 구성된 텍스트 런에서 단어 경계 결정 방법을 모르는 경우에 적용됩니다.

5.2. 글자 줄 바꿈 규칙: word-break 속성

이 속성은 글자 사이의 soft wrap opportunity를 지정합니다. 즉, 텍스트 줄을 "일반적으로" 그리고 허용 가능한 위치에서 줄 바꿈할 수 있게 합니다. 특히, 인접한 soft wrap opportunity가 조판 글자 단위 사이에 일반적으로 존재할지 제어하며, NU, AL, AI, ID 유니코드 줄 바꿈 클래스에 속하는 비-글자 조판 문자 단위도 이 목적에 한해 조판 글자 단위로 간주됩니다. [UAX14] 이 속성은 공백(및 기타 공백 분리자)와 문장부호 주변에서 생성되는 soft wrap opportunity에는 영향을 주지 않습니다. (문장부호 및 소형 가나에 대한 제어는 line-break 참조)

예를 들어, CJK 조판의 일부 스타일에서는 영어 단어가 스페이스나 하이픈 분리점이 아니라 모든 두 글자 사이에서 줄 바꿈될 수 있습니다; 이는 word-break:break-all로 활성화할 수 있습니다.

또 다른 예로 한국어에는 두 가지 줄 바꿈 스타일이 있습니다: 모든 한글 음절 사이에서 줄 바꿈(word-break: normal) 또는 영어처럼 주로 스페이스에서만 줄 바꿈(word-break: keep-all).

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

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

에티오피아 문자도 마찬가지로 두 가지 줄 바꿈 스타일이 있습니다: 단어 구분자에서만 줄 바꿈(word-break: normal) 또는 단어 내에서 글자 사이에서도 줄 바꿈 허용(word-break: break-all).

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

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

참고: 오버플로우가 발생할 때만 추가 줄 바꿈 기회를 허용하려면 overflow-wrap을 참고하세요.

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

normal

단어는 위에서 설명한 관례적 규칙에 따라 줄 바꿈됩니다. 두 가지 동작이 공존하는 한국어는 연속된 한글/한자 사이에서 줄 바꿈을 허용합니다. 역시 두 가지 동작이 공존하는 에티오피아 문자는 단어 내에서 줄 바꿈을 허용하지 않습니다.

break-all

“단어” 내에서도 줄 바꿈이 허용됩니다: 즉, soft wrap opportunity가 normal에서 허용된 것 외에도 조판 글자 단위(및 조판 문자 단위가 NU(숫자), AL(알파벳), SA(동남아시아) 줄 바꿈 클래스인 경우 [UAX14]) 는 줄 바꿈 목적으로 ID(표의 문자)로 취급됩니다. 하이픈 처리는 적용되지 않습니다.

참고: 이 값은 문장부호 주변의 soft wrap opportunity에는 영향을 주지 않습니다. 어디서든 줄 바꿈을 허용하려면 line-break: anywhere를 참고하세요.

참고: 이 옵션은 에티오피아 문자의 또 다른 동작을 활성화합니다. CJK 문자가 주로 등장하고 비CJK 텍스트가 짧게 삽입된 경우, 각 줄의 텍스트 분포를 개선하고자 할 때 자주 사용됩니다.

keep-all

“단어” 내에서는 줄 바꿈이 금지됩니다: 조판 글자 단위 (또는 조판 문자 단위가 NU, AL, AI, ID 줄 바꿈 클래스인 경우 [UAX14]) 사이의 암시적 soft wrap opportunity는 억제됩니다, 즉 이런 문자 쌍 사이에서는 줄 바꿈이 금지됩니다(line-break가 anywhere가 아닌 한). 사전 기반 줄 바꿈 기회가 있는 경우는 예외입니다. 그렇지 않으면 이 옵션은 normal과 동일합니다. 이 스타일에서는 CJK 문자 연속이 줄 바꿈되지 않습니다.

참고: 이것이 한국어의 또 다른 일반적 동작입니다 (단어 사이에 스페이스를 사용하는 경우), 그리고 CJK 조각이 다른 언어에 혼합된 경우에도 스페이스로 분리된 텍스트에 유용합니다.

특정 카테고리 글자와 동일하게 줄 바꿈하는 기호도 해당 글자와 동일하게 처리됩니다.

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

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

窓ぎわのトットちゃ
ん

窓ぎわの
トットちゃん

아랍어 등 셰이핑이 필요한 문자체계에서 break-all로 인해 단어 내 줄 바꿈이 허용될 때도 문자는 분리되지 않은 것처럼 셰이핑해야 합니다(§ 5.6 단어 내부 줄 바꿈 시 셰이핑 참고).

레거시 콘텐츠와 호환성을 위해, word-break 속성은 사용되지 않는 break-word 키워드도 지원합니다. 지정 시, 실제 word-break: normal 및 overflow-wrap: anywhere와 동일한 효과를 가지며, overflow-wrap 속성의 실제 값과 관계없이 동작합니다.

5.3. 줄 바꿈 엄격도: line-break 속성

이 속성은 요소 내에서 적용되는 줄 바꿈 규칙의 엄격도를 지정합니다: 특히 줄 바꿈이 문장부호 및 기호와 어떻게 상호작용하는지에 관한 것입니다. 값의 의미는 다음과 같습니다:

auto

UA가 사용할 줄 바꿈 제한 집합을 결정하며, 줄 길이에 따라 제한을 다르게 적용할 수 있습니다; 예: 짧은 줄에는 덜 엄격한 줄 바꿈 규칙을 사용할 수 있습니다.

loose

가장 제한이 적은 줄 바꿈 규칙 집합을 사용하여 텍스트를 분리합니다. 신문과 같은 짧은 줄에 주로 사용됩니다.

normal

가장 일반적인 줄 바꿈 규칙 집합을 사용하여 텍스트를 분리합니다.

strict

가장 엄격한 줄 바꿈 규칙 집합을 사용하여 텍스트를 분리합니다.

anywhere

모든 조판 문자 단위 주변에 soft wrap opportunity가 있으며, 모든 문장부호 문자나 preserved white spaces 주변, 단어 중간에서도 줄 바꿈이 가능합니다. 줄 바꿈을 금지하는 모든 규칙(예: GL, WJ, ZWJ 줄 바꿈 클래스나 word-break 속성에 의해 부여된 금지)도 무시합니다. [UAX14] 다양한 줄 바꿈 기회에 우선순위를 두면 안 됩니다. 하이픈 처리는 적용되지 않습니다.

참고: 이 값은 터미널에서 흔히 볼 수 있는 줄 바꿈 규칙을 트리거합니다.

참고: anywhere는 preserved white spaces가 줄 끝에 있을 때만 다음 줄로 줄 바꿈을 허용합니다. 이는 white-space가 break-spaces로 설정된 경우에만 해당합니다. 다른 경우에는:

• 줄 끝/시작의 preserved white space가 제거됨 (normal, pre-line)
• 줄 바꿈이 전체적으로 금지됨 (nowrap, pre)
• preserved white space는 hang 처리됨 (pre-wrap).

preserved white space에 실제로 영향이 있는 경우, white-space: break-spaces와 함께 사용하면 시퀀스의 첫 번째 스페이스 앞에서 줄 바꿈이 가능하며, break-spaces 자체만으로는 불가능합니다.

CSS는 텍스트 줄 바꿈 규칙의 엄격도를 네 단계로 구분합니다. 각 loose, normal, strict에 적용되는 정확한 규칙 집합은 UA에 따라 다르며 언어 관습을 따라야 합니다. 하지만 이 세 키워드에 대해, 이 명세는 다음을 요구합니다:

• 다음 줄 바꿈은 strict 줄 바꿈에서는 금지되고, normal 및 loose에서는 허용됩니다:
  • 일본어 소형 가나 또는 가타카나-히라가나 장음 기호 앞에서 줄 바꿈, 즉 유니코드 줄 바꿈 클래스 CJ의 문자. [UAX14]
• 다음 줄 바꿈은 normal 및 loose 줄 바꿈에서 문자체계가 중국어 또는 일본어인 경우에만 허용되며, 그렇지 않으면 금지됩니다:
  • 특정 CJK 하이픈류 문자 앞에서 줄 바꿈:
    〜 U+301C, ゠ U+30A0
• 다음 줄 바꿈은 loose 줄 바꿈에서만 허용되고, 앞 문자가 유니코드 줄 바꿈 클래스 ID에 속하는 경우 [UAX14](word-break: break-all로 인해 앞 문자가 ID로 처리되는 경우 포함), 그렇지 않으면 금지됨:
  • 하이픈 앞에서 줄 바꿈:
    ‐ U+2010, – U+2013
• 다음 줄 바꿈은 normal 및 strict 줄 바꿈에서는 금지되고, loose에서는 허용됨:
  • 반복 부호 앞에서 줄 바꿈:
    々 U+3005, 〻 U+303B, ゝ U+309D, ゞ U+309E, ヽ U+30FD, ヾ U+30FE
  • 분리 불가능한 문자 사이에서 줄 바꿈 (예: ‥ U+2025, … U+2026) 즉 유니코드 줄 바꿈 클래스 IN의 문자. [UAX14]
• 다음 줄 바꿈은 loose에서만 허용되고, 문자체계가 중국어 또는 일본어인 경우에만 허용되며, 그렇지 않으면 금지됨:
  • 특정 가운데 문장부호 앞에서 줄 바꿈:
    ・ U+30FB, ： U+FF1A, ； U+FF1B, ･ U+FF65, ‼ U+203C, ⁇ U+2047, ⁈ U+2048, ⁉ U+2049, ！ U+FF01, ？ U+FF1F
  • 접미사 앞에서 줄 바꿈:
    유니코드 줄 바꿈 클래스 PO [UAX14] 및 동아시아 너비 속성 [UAX11] Ambiguous, Fullwidth, Wide.
  • 접두사 뒤에서 줄 바꿈:
    유니코드 줄 바꿈 클래스 PR [UAX14] 및 동아시아 너비 속성 [UAX11] Ambiguous, Fullwidth, Wide.

참고: 위 요구사항은 CJK 텍스트 구분만 만듭니다. 위 규칙만을 구현하고 추가 규칙이 없는 경우, line-break는 문자체계가 중국어 또는 일본어로 태그된 경우를 제외하면 CJK 코드 포인트에만 영향을 줍니다. 향후 현행 표준에서는 다른 문자체계와 언어의 요구 사항이 알려지면 추가 구체적 규칙을 도입할 수 있습니다.

참고: CSSWG는 향후 현행 표준에서 고급 출판 요구를 만족하기 위해 줄 바꿈을 더 세밀하게 제어할 필요가 있음을 인식합니다.

5.4. 하이픈 처리: 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
위구르어
크리어

하이픈 처리는 줄이 유효한 하이픈 처리 기회에서 분리될 때 발생합니다. 이는 단어 내에서 하이픈 처리가 허용되는 위치에 존재하는 soft wrap opportunity의 한 유형입니다. CSS에서는 하이픈 처리 기회를 hyphens 속성으로 제어합니다. CSS Text Level 3에서는 하이픈 처리의 정확한 규칙을 정의하지 않지만, UA가 분리 위치 선택을 최적화하고 언어에 맞는 하이픈 처리 위치를 선택하도록 강력히 권장합니다.

참고: U+002D - HYPHEN-MINUS 문자 및 U+2010 ‐ HYPHEN 문자로 유발되는 soft wrap opportunity는 하이픈 처리 기회가 아닙니다. 줄 바꿈 시 분할의 시각적 표시가 생성되지 않기 때문입니다: 이 문자들은 해당 위치에서 줄 바꿈이 되든 아니든 항상 보입니다.

하이픈 처리 기회는 min-content 내재 크기 계산 시 고려됩니다.

참고: 이로 인해 테이블은 콘텐츠를 하이픈 처리하여, 포함 블록을 넘치지 않게 할 수 있으며, 독일어처럼 단어가 긴 언어에서는 특히 중요합니다.

이 속성은 한 줄의 텍스트 내에서 하이픈 처리로 더 많은 soft wrap opportunity를 만들 수 있는지 제어합니다. 값의 의미는 다음과 같습니다:

none

단어 내 명시적으로 하이픈 처리 기회가 정의되어 있어도 단어를 하이픈 처리하지 않습니다.

참고: U+002D - HYPHEN-MINUS 또는 U+2010 ‐ HYPHEN처럼 항상 보이는 문자로 유발된 기존 soft wrap opportunity는 억제하지 않습니다.

manual

단어 내에서 명시적으로 하이픈 처리 기회를 제안하는 문자가 있을 때만 하이픈 처리합니다. UA는 적절한 언어별 하이픈 문자(들)를 사용해야 하며, 자동 하이픈 처리와 동일한 위치에서는 적절한 철자 변환도 적용해야 합니다.

유니코드에서 U+00AD는 조건부 "소프트 하이픈"이고 U+2010은 무조건 하이픈입니다. Unicode Standard Annex #14에서 유니코드 줄 바꿈에서 소프트 하이픈의 역할을 설명합니다. [UAX14] HTML에서는 &shy;가 소프트 하이픈 문자에 해당하며, 하이픈 처리 기회를 제안합니다.

ex­ample

auto

언어에 맞는 하이픈 처리 리소스가 자동으로 결정한 하이픈 처리 기회 및 조건부 하이픈으로 명시된 위치에서 단어를 분리할 수 있습니다. 단어에 조건부 하이픈(&shy; 또는 U+00AD SOFT HYPHEN)이 포함된 경우, 그 밖의 자동 하이픈 처리 기회는 무시하고 조건부 하이픈만 우선 적용해야 합니다. 단, 조건부 하이픈 위치에서 분리해도 단어 일부가 한 줄에 들어가지 않을 경우, 자동 하이픈 처리 기회도 사용할 수 있습니다.

정확한 자동 하이픈 처리를 위해서는 분리되는 텍스트의 언어에 맞는 하이픈 처리 리소스가 필요합니다. UA는 콘텐츠 언어가 알려져 있고, 이에 맞는 하이픈 리소스가 있을 때만 자동 하이픈 처리를 해야 합니다.

UA는 언어별 휴리스틱을 사용해 특정 단어를 자동 하이픈 처리에서 제외할 수 있습니다. 예를 들어, UA는 특정 대문자 및 구두점 패턴에 맞는 단어를 제외함으로써 고유명사 하이픈 처리를 피할 수 있습니다. 이런 휴리스틱은 현행 표준에서는 정의되지 않았습니다. (이런 휴리스틱은 언어마다 다르게 설계해야 하며: 예를 들어 영어와 독일어는 대소문자 규칙이 매우 다릅니다.)

hyphens 속성에서 "단어"의 정의는 UA마다 다릅니다. 단, 인라인 요소 경계 및 out-of-flow 요소는 단어 경계 판단 시 무시해야 합니다.

조건부 하이픈 문자(U+00AD SOFT HYPHEN 등)로 생성된 하이픈 처리 기회에서 표시되는 모든 글리프는 해당 문자로 표현되며, 그 속성에 적용된 스타일에 따라 렌더링됩니다.

아랍어와 같이 셰이핑이 필요한 문자체계에서 하이픈 처리로 단어 내 줄 바꿈이 허용될 때도, 문자는 분리되지 않은 것처럼 셰이핑해야 합니다(§ 5.6 단어 내부 줄 바꿈 시 셰이핑 참고).

예를 들어, 위구르어 단어 “داميدى”가 하이픈 처리될 경우, 처럼 표시되어야 하며, 와 같이 표시되면 안 됩니다.

5.5. 오버플로우 줄 바꿈: overflow-wrap/word-wrap 속성

이 속성은 UA가 줄 내에서 원래 허용되지 않는 위치에서 오버플로우를 방지하기 위해 줄을 나눌 수 있는지 지정합니다. 즉, 본래 분리할 수 없는 문자열이 줄 박스에 들어가지 않을 때 적용됩니다. white-space가 줄 바꿈을 허용할 때만 동작합니다. 가능한 값:

normal

줄은 허용된 분리점에서만 분리될 수 있습니다. 단, word-break: keep-all로 인한 제한은 줄에 허용된 분리점이 없을 경우 word-break: normal로 완화될 수 있습니다.

anywhere

본래 분리할 수 없는 character 시퀀스도, 줄에 허용된 분리점이 없으면 임의 위치에서 분리할 수 있습니다. 셰이핑 문자는 단어가 분리되지 않은 것처럼 셰이핑되어야 하며, 그래프 클러스터는 하나의 단위로 유지되어야 합니다. 줄 바꿈 위치에 하이픈 문자는 삽입되지 않습니다. soft wrap opportunities 는 anywhere로 도입된 경우 min-content 내재 크기 계산 시 고려됩니다.

break-word

anywhere와 동일하지만, soft wrap opportunities 는 break-word로 도입된 경우 min-content 내재 크기 계산 시 고려되지 않습니다.

레거시 이유로, UA는 word-wrap을 레거시 이름 별칭으로 overflow-wrap과 동일하게 처리해야 합니다.

5.6. 단어 내부 줄 바꿈 시 셰이핑

아랍어 등 셰이핑이 필요한 문자체계에서 단어 내에서 줄 바꿈이 soft wrap opportunity에서 발생할 때 (word-break: break-all, line-break: anywhere, overflow-wrap: break-word, overflow-wrap: anywhere 등으로 인한 경우, 또는 하이픈 처리 시) 문자는 단어가 분리되지 않은 것처럼(연결 형태 선택) 셰이핑되어야 합니다.

6. 정렬 및 양쪽 맞춤

정렬 및 양쪽 맞춤은 인라인 콘텐츠가 줄 박스 내에서 어떻게 분포되는지 제어합니다.

6.1. 텍스트 정렬: text-align 약식 속성

이 약식 속성은 text-align-all 및 text-align-last 속성을 설정하며, 블록의 인라인 레벨 콘텐츠가 줄 축에서 어떻게 정렬되는지 지정합니다. 콘텐츠가 줄 박스를 완전히 채우지 않을 때 적용됩니다. justify-all 또는 match-parent 값이 아니라면, text-align-all에 할당되고, text-align-last는 auto로 초기화됩니다.

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

start

인라인 레벨 콘텐츠가 줄 박스의 시작 가장자리에 정렬됩니다.

end

인라인 레벨 콘텐츠가 줄 박스의 끝 가장자리에 정렬됩니다.

left

인라인 레벨 콘텐츠가 줄 박스의 line-left 가장자리에 정렬됩니다. (수직 쓰기 모드에서는 물리적 위 또는 아래가 될 수 있으며, writing-mode에 따라 다릅니다.) [CSS-WRITING-MODES-4]

right

인라인 레벨 콘텐츠가 줄 박스의 line-right 가장자리에 정렬됩니다. (수직 쓰기 모드에서는 물리적 위 또는 아래가 될 수 있으며, writing-mode에 따라 다릅니다.) [CSS-WRITING-MODES-4]

center

인라인 레벨 콘텐츠가 줄 박스 내에서 가운데 정렬됩니다.

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로 설정합니다.

텍스트 블록은 line box의 스택입니다. 이 속성은 각 line box 내 인라인 레벨 박스들이 줄 박스의 시작 및 끝 방향에 대해 어떻게 정렬되는지 지정합니다. 정렬은 뷰포트나 포함 블록 기준이 아닙니다.

justify의 경우, UA는 텍스트 조정을 통해 인라인 박스를 늘리거나 줄일 수 있습니다. (text-justify 참고.) 요소의 공백이 압축 가능이 아니면, UA는 양쪽 맞춤을 위해 텍스트를 조정할 필요가 없으며 대신 텍스트를 양쪽 맞춤 기회가 없는 것으로 처리할 수 있습니다. UA가 텍스트를 조정하기로 한 경우, 탭 스톱이 공백 처리 규칙에 따라 계속 정렬되도록 해야 합니다.

양쪽 맞춤 이후에도 line box의 인라인 콘텐츠가 너무 길어 들어가지 않을 경우, 콘텐츠는 시작 방향으로 정렬되며: 들어가지 않는 콘텐츠는 줄 박스의 끝 방향을 넘어 오버플로우됩니다.

§ 8.3 양방향성 및 줄 박스에서 줄 박스의 시작 및 끝 가장자리 결정 방법을 확인하세요.

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

이 속성은 text-align 약식 속성의 롱핸드이며, 블록 컨테이너의 인라인 콘텐츠 모든 줄의 인라인 정렬을 지정합니다. 단, 마지막 줄은 auto가 아닌 text-align-last 값으로 오버라이드되는 경우 제외합니다. 값의 전체 설명은 text-align을 참고하세요.

저자는 이 속성 대신 text-align 약식 속성을 사용할 것을 권장합니다.

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

이 속성은 블록의 마지막 줄 또는 강제 줄 바꿈 바로 앞의 줄이 어떻게 정렬되는지 설명합니다.

auto가 지정된 경우, 해당 줄의 콘텐츠는 text-align-all에 따라 정렬되며, text-align-all이 justify일 경우에는 start로 정렬됩니다. 그 외 모든 값은 text-align에 설명된 대로 해석됩니다.

6.4. 양쪽 맞춤 방법: text-justify 속성

이 속성은 줄 정렬이 justify로 설정된 경우 사용할 양쪽 맞춤 방법을 선택합니다(text-align 참고). 이 속성은 텍스트에 적용되며, 블록 컨테이너로부터 인라인 콘텐츠가 포함된 루트 인라인 박스로 상속됩니다. 다음 값을 가집니다:

auto

UA가 성능과 적절한 표현 품질의 균형에 따라 사용할 양쪽 맞춤 알고리즘을 결정합니다. 맞춤 규칙은 문자체계와 언어에 따라 달라지므로, UA는 가능한 경우 텍스트에 적합한 맞춤 알고리즘을 사용해야 합니다.

예를 들어, UA는 기본값으로 모든 문자체계에 보편적으로 적용 가능한 간단한 맞춤 방법을 사용할 수 있습니다—​예: 주로 단어 구분자와 CJK 조판 글자 단위 사이, 그리고 동남아시아 조판 글자 단위 사이도 확장함. 단락의 콘텐츠 언어가 알려진 경우, UA는 더 언어에 특화된 맞춤 동작을 선택할 수 있습니다. 예: 일본어는 일본어 조판 요구사항을 따르고 [JLREQ], 아랍어는 필기체 늘림을 사용하거나, 독일어는 inter-word를 사용하는 등.

none

양쪽 맞춤을 비활성화합니다: 텍스트 내에 양쪽 맞춤 기회가 없습니다.

참고: 이 값은 가독성 개선이나 접근성 목적의 사용자 스타일시트에서 사용됩니다.

inter-word

양쪽 맞춤은 단어 구분자 위치에서만 간격을 조정합니다 (실질적으로 word-spacing을 조정함). 이 방식은 영어, 한국어처럼 스페이스로 단어를 구분하는 언어에서 일반적입니다.

inter-character

양쪽 맞춤은 인접한 조판 문자 단위 쌍 사이 간격을 조정합니다(실질적으로 letter-spacing을 조정함). 이 값은 일본 등 동아시아 시스템에서 사용되는 경우가 있습니다.

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

최적의 양쪽 맞춤은 언어에 따라 달라지므로, 저자는 최상의 결과를 위해 콘텐츠의 언어 태그를 정확하게 작성해야 합니다.

참고: 현행 표준의 CSS 지침은 완전한 양쪽 맞춤 알고리즘을 설명하지 않습니다. 최소 요구사항 집합만을 명시하고 있으며, UA가 품질, 속도, 복잡성 균형에 맞는 알고리즘을 선택할 수 있도록 여지를 남겨둡니다.

6.4.1. 텍스트 확장 및 압축

텍스트를 양쪽 맞춤할 때, 사용자 에이전트는 한 줄의 콘텐츠 끝과 줄 박스 가장자리 사이에 남은 공간을 콘텐츠 전체에 분배하여 내용이 줄 박스를 정확히 채우도록 만듭니다. 사용자 에이전트는 대신 음수 공간을 분배하여, 보통 간격 조건에서 들어갈 수 있는 것보다 더 많은 콘텐츠를 한 줄에 넣을 수도 있습니다.

양쪽 맞춤 기회란 양쪽 맞춤 알고리즘이 텍스트 내 간격을 변경할 수 있는 지점을 의미합니다. 양쪽 맞춤 기회는 하나의 조판 문자 단위(예: 단어 구분자)에 의해 제공되거나, 두 조판 문자 단위의 인접에 의해 제공될 수 있습니다. soft wrap opportunity 제어와 마찬가지로, 조판 문자 단위가 양쪽 맞춤 기회를 제공하는지 여부는 부모의 text-justify 값에 의해 제어됩니다; 마찬가지로, 두 연속 조판 문자 단위 사이에 양쪽 맞춤 기회가 존재하는지는 가장 가까운 공통 조상의 text-justify 값에 따라 결정됩니다.

양쪽 맞춤으로 분배되는 공간은 letter-spacing 또는 word-spacing 속성으로 정의된 간격 이외에 추가로 분배되는 공간입니다. 이런 추가 공간이 단어 구분자 양쪽 맞춤 기회에 분배될 경우, word-spacing과 동일한 규칙으로 적용됩니다. 마찬가지로, 공간이 두 조판 문자 단위 사이 양쪽 맞춤 기회에 분배될 경우, letter-spacing과 동일한 규칙으로 적용되어야 합니다.

양쪽 맞춤 알고리즘은 양쪽 맞춤 기회를 여러 우선순위 레벨로 나눌 수 있습니다. 주어진 레벨 내 모든 양쪽 맞춤 기회는 어떤 조판 문자 단위에서 유래했든 동일한 우선순위로 확장/압축됩니다. 예를 들어, 두 한자 사이와 두 라틴 문자 사이 양쪽 맞춤 기회가 같은 레벨로 정의된 경우 (inter-character 양쪽 맞춤 스타일에서처럼), 서로 다른 조판 문자 단위에서 유래했다는 이유로 차별되지 않습니다. 이 현행 표준에서는 다른 요소(글꼴 크기, letter-spacing, 글리프 모양, 줄 내 위치 등)가 줄 내 양쪽 맞춤 기회에 공간 분배에 영향을 줄 수 있는지 여부는 정의되지 않았습니다.

UA는 선택적 합자를 활성화하거나, 대체 글리프 또는 글리프 압축 등 다른 글꼴 기능을 활용해 어떤 방법이든 텍스트 양쪽 맞춤을 도울 수 있습니다. 이런 동작은 현행 표준의 CSS에서 제어하지 않습니다. 단, UA는 반드시 필수 합자를 분리하거나, 복잡한 문자체계 셰이핑에 필수적인 기능을 비활성화해서는 안 됩니다.

한 줄에 양쪽 맞춤 기회가 존재하고, 텍스트 정렬이 해당 줄에 대해 전체 양쪽 맞춤(justify)을 지정하면, 반드시 양쪽 맞춤해야 합니다.

6.4.2. 기호 및 문장부호 처리

양쪽 맞춤 기회를 결정할 때, 유니코드 기호(S*) 및 문장부호(P*) 클래스에 속하는 조판 문자 단위는 일반적으로 해당 문자체계의 조판 글자 단위와 동일하게 취급됩니다. (해당 문자 스크립트 속성이 Common이라면, 지배적 문자체계의 조판 글자 단위로 취급됩니다.)

하지만, 조판 전통에 따라 기호 및 문장부호의 양쪽 맞춤에 추가 규칙이 있을 수 있습니다. 따라서 UA는 특정 문자를 재분류하거나, 기호 및 문장부호 관련 양쪽 맞춤 기회에 추가 우선순위 레벨을 도입할 수 있습니다.

6.4.3. 확장 불가 텍스트

한 줄의 인라인 콘텐츠가 줄 박스 전체 너비로 늘릴 수 없는 경우, text-align-last 속성에 지정된 대로 정렬되어야 합니다. (text-align-last가 justify인 경우, center처럼 정렬되어야 합니다.)

6.4.4. 필기체 문자체계

양쪽 맞춤은 필기체 문자체계(예: 아랍어)의 조판 글자 단위 사이에 공백을 생성해서는 안 됩니다. UA가 가능하다면, 해당 조판 글자 단위 런 내 양쪽 맞춤 기회에 분배된 공간을 필기체 늘림(예: kashida 등)으로 변환할 수 있습니다. 그렇지 않으면, 해당 필기체 문자체계의 조판 글자 단위 쌍 사이에는(연결 여부와 관계없이) 양쪽 맞춤 기회가 없는 것으로 간주해야 합니다.

다음은 허용되지 않는 양쪽 맞춤 예시입니다:

일부 글꼴 디자인은 tatweel 문자를 활용한 양쪽 맞춤을 허용합니다. tatweel 기반 양쪽 맞춤을 수행하는 UA는 해당 사용 규칙을 올바르게 처리해야 합니다. tatweel 문자 올바른 삽입은 문맥(글자 조합, 단어 내 위치, 줄 내 단어 위치 등)에 따라 결정됨에 유의해야 합니다.

6.4.5. auto 양쪽 맞춤의 최소 요구사항

auto 양쪽 맞춤에 대해서는, 이 명세는 모든 양쪽 맞춤 기회가 무엇인지, 어떻게 우선순위를 정하는지, 여러 레벨 양쪽 맞춤 기회가 언제 어떻게 상호작용하는지 정의하지 않습니다. 하지만 다음은 요구합니다:

• 콘텐츠 언어 또는 인접 기호/문장부호의 조판 전통에 위배되지 않는 한, 다음 각 항목은 양쪽 맞춤 기회를 제공합니다:
  • 단어 구분자
  • 블록 문자체계의 조판 문자 단위와 다른 조판 문자 단위 사이 경계
  • 클러스터 문자체계의 조판 문자 단위와 다른 조판 문자 단위 사이 경계
• 모든 블록 문자체계의 글자는 동일하게 취급되고, 모든 클러스터 문자체계의 글자도 동일하게 취급됩니다. 예를 들어, 한자 뒤에 또 다른 한자가 올 때와, 한자 뒤에 한글이 올 때의 양쪽 맞춤 기회 사이에 차별이 없습니다.

텍스트 양쪽 맞춤에 대한 추가 정보는 “Approaches to Full Justification”에서 확인할 수 있으며, 문자체계와 언어별로 인덱싱되어 있고, W3C 국제화 작업 그룹이 관리합니다. [JUSTIFY]

7. 간격

CSS는 텍스트 간격을 제어할 수 있도록 word-spacing 및 letter-spacing 속성을 제공합니다. 각각 단어 구분자 주위 또는 조판 문자 단위 사이에 추가 간격을 지정합니다.

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

이 속성은 “단어” 사이의 추가 간격을 지정합니다. 값의 해석은 아래와 같습니다:

normal

추가 간격이 적용되지 않습니다. 0으로 계산됩니다.

<length>

폰트에 정의된 내재적 단어 간격 이외에 추가 간격을 지정합니다.

추가 간격은 단어 구분자마다 적용되며, 공백 처리 규칙 적용 후 텍스트에 남아 있어야 합니다. 전통에 따라 달리 지정되지 않는 한, 해당 문자 양쪽에 반씩 적용하는 것이 바람직합니다. 값은 음수일 수 있지만, 구현에 따라 한계가 있을 수 있습니다.

단어 구분자는 조판 문자 단위 중 기본 목적이 단어 구분인 문자입니다. 유니코드에서는 (완전한 목록은 아님) 스페이스(U+0020), 노브레이크 스페이스(U+00A0), 에티오피아 단어 공백(U+1361), 에게 단어 구분자(U+10100,U+10101), 우가리트 단어 구분자(U+1039F), 페니키아 단어 구분자(U+1091F) 등이 포함됩니다. [UNICODE]

참고: 일반적인 문장부호나 고정폭 스페이스(U+3000 및 U+2000~U+200A 등)는 단어 구분자로 간주하지 않습니다. 이들 문자도 종종 단어를 구분하지만, 기본 목적이 단어 구분이 아니기 때문입니다.

단어 구분자가 없거나, 단어 구분 문자가 advance width가 0(U+200B ZERO WIDTH SPACE 등)인 경우, UA는 단어 사이에 추가 간격을 생성하면 안 됩니다.

7.2. 트래킹: letter-spacing 속성

이 속성은 인접한 조판 문자 단위 사이의 추가 간격(일반적으로 트래킹이라 부름)을 지정합니다. letter-spacing은 bidi 재정렬 이후 적용되며, 커닝 및 word-spacing과 별도로 추가됩니다. [CSS-WRITING-MODES-4] [CSS-FONTS-3] 양쪽 맞춤 규칙에 따라, UA는 조판 문자 단위 사이 간격을 추가로 늘리거나 줄일 수 있습니다(양쪽 맞춤 참고).

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

normal

추가 간격이 적용되지 않습니다. 0으로 계산됩니다.

<length>

조판 문자 단위 사이에 추가 간격을 지정합니다. 값은 음수일 수 있으며, 구현에 따라 한계가 있을 수 있습니다.

레거시 이유로, 계산된 letter-spacing이 0이면 resolved value(getComputedStyle() 반환값) 은 normal이 됩니다.

letter-spacing의 목적상, 연속된 atomic inlines(예: 이미지, 인라인 블록) 시퀀스는 하나의 조판 문자 단위로 취급합니다.

letter-spacing은 줄 시작에는 적용되지 않아야 합니다. 줄 끝에 적용되는지는 현행 표준에서 정의되지 않았습니다.

p { letter-spacing: 1em; }

<p>abc</p>

두 조판 문자 단위 사이의 letter-spacing은 해당 두 조판 문자 단위를 모두 포함한 가장 안쪽 요소에 “귀속”됩니다: 인접한 두 조판 문자 단위 사이의 총 letter-spacing(bidi 재정렬 후)은, 경계를 포함하는 가장 안쪽 요소에서 지정되고 렌더링됩니다. 단, UA는 대신 요소 경계에서 letter-spacing을 해당 요소의 letter-spacing 값에 따라 한쪽 문자에 붙일 수도 있습니다.

참고: 이 보조 동작은 웹 호환성 때문에 허용됩니다.

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 다음에 히브리어 문자 alef (א), bet (ב), gimel (ג) -->
<!-- 재정렬 후에는 역순으로 표시됨 -->
<p>ab<span>cא</span>בג</p>

letter-spacing은 보이지 않는 0폭 서식 문자(유니코드 Cf 카테고리 등)는 무시합니다. 해당 문자가 문서에 없는 것처럼 간격을 추가해야 합니다.

두 문자 사이의 유효 간격이 0이 아닐 경우 (양쪽 맞춤이나 letter-spacing 값 때문), UA는 필수적이지 않은 선택적 합자를 적용하면 안 됩니다. 즉, 올바른 글리프 셰이핑에 필수적이지 않은 합자는 금지입니다. 단, 저수준 font-feature-settings 속성으로 명시한 폰트 기능은 이 규칙보다 우선합니다. CSS Fonts Module Level 3 § feature-precedence 참고.

참고: OpenType에서 필수 합자는 rlig 기능에 할당되어야 합니다. 나머지 합자는 모두 선택적으로 간주됩니다. 다만 일부 경우 UA나 플랫폼 휴리스틱이 깨진 폰트 처리를 위해 추가 합자를 적용하는데, 이 명세는 그런 예외 처리까지 정의하거나 무시하지 않습니다.

7.2.1. 필기체 문자체계

UA가 가능하다면, 필기체 문자체계에 letter-spacing을 적용할 때, 해당 문자 런 전체에 분배할 추가 공간을 필기적으로 적합한 늘림(또는 음수 트래킹 값일 때 압축) 형태로 변환하여, 런 전체가 동일한 총 확장(또는 압축)이 되도록 할 수 있습니다. 반대로, UA가 필기체 문자체계 텍스트를 필기 연결을 끊지 않고 확장할 수 없다면, 해당 문자체계의 조판 글자 단위 쌍 사이에는 절대 간격을 넣으면 안 되며 (실질적으로 각 단어를 letter-spacing 목적상 하나의 조판 글자 단위로 간주), 두 경우 모두 이런 글자 사이의 실제 간격은 0이 됩니다; 단, 첫 번째 경우는 텍스트가 늘어난 느낌을 유지합니다.

아래는 아랍어 텍스트에 대한 적절/부적절 간격 조정 예시입니다.

	—	원본 텍스트
	BAD	각 글자 사이에 공간을 균등 분배. 필기 연결이 끊어짐!
	OK	∑letter-spacing을 필기적으로 적합한 늘림(kashida 등)으로 분배. 결과적 텍스트 길이는 이전의 균등 분배 예시와 동일.
	OK	아랍어 글자 사이에 letter-spacing을 억제함. 아랍어 이외의 문자(예: 공백)에는 여전히 letter-spacing이 적용됨.
	BAD	서로 연결되지 않은 글자 사이에만 letter-spacing 적용. 조판 색감이 왜곡되고 단어 경계가 모호해짐.

참고: 필기체 늘림/압축은 문자체계, 서체, 언어, 단어 내 위치, 줄 내 위치, 구현 복잡도, 폰트 기능, 서예적 선호도 등에 따라 달라질 수 있으며, 어떤 경우에는 불가능할 수도 있습니다. 줄임 합자, 스와시 변형, 맥락형, 늘림 글리프(U+0640 ـ ARABIC TATWEEL 등), 기타 마이크로타이포그래피 효과 등이 쓰일 수 있습니다. 이런 효과에 대한 규칙은 CSS의 범위를 벗어납니다. 저자는 필기체 문자체계에 letter-spacing을 적용할 경우, 상호운용성 없는 결과를 수용할 준비가 되어 있지 않다면 사용을 피해야 합니다.

7.3. 요소 경계 간 셰이핑

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

• 두 조판 문자 단위를 인라인 축에서 분리하는 margin/border/padding 이 0이 아니면.
• vertical-align이 baseline이 아니면.
• 그 경계가 bidi isolation 경계이면.

서식이 실질적으로 변경되지 않거나, 변경이 글리프에 영향을 주지 않는 경우(예: text decoration 적용), 텍스트 셰이핑은 절대 인라인 박스 경계에서 끊기면 안 됩니다.

그 밖의 경우에도, 폰트 기술의 한계를 감안할 때 합리적이고 가능한 경우라면, 텍스트 셰이핑은 인라인 박스 경계를 넘어 끊기지 않는 것이 바람직합니다.

8. 가장자리 효과

가장자리 효과는 블록 내 줄들의 들여쓰기(text-indent) 및 줄의 시작/끝 가장자리에서 콘텐츠 측정 방식(hanging-punctuation)을 제어합니다.

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

이 속성은 블록 내 인라인 콘텐츠 줄에 적용되는 들여쓰기를 지정합니다. 들여쓰기는 줄 박스의 시작 가장자리에 적용된 margin으로 처리됩니다.

each-line 및/또는 hanging 키워드로 별도로 지정하지 않는 한, 요소의 첫 번째 형식화된 줄에만 적용됩니다. [CSS-PSEUDO-4] 예를 들어, 익명 블록 박스의 첫 줄은 부모 요소의 첫 자식인 경우에만 영향을 받습니다.

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

<length>

들여쓰기 양을 절대 길이로 지정합니다.

<percentage>

들여쓰기 양을 블록 컨테이너의 논리적 너비의 백분율로 지정합니다.

백분율은 0으로 취급되어 내재 크기 기여도 계산에는 사용되지 않지만, 레이아웃 계산시에는 항상 정상적으로 해석됩니다.

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

each-line

들여쓰기는 각 블록 컨테이너의 첫 줄 및 강제 줄 바꿈 뒤의 각 줄에 적용(단, soft wrap break 뒤의 줄에는 적용되지 않음).

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 속성은 상속되므로, 블록 요소에 지정하면 하위 inline-block 요소에도 영향을 줍니다. 따라서 text-indent: 0을 display: inline-block에 지정하는 것이 현명한 경우가 많습니다.

8.2. 행잉 글리프

줄의 시작 또는 끝 가장자리에 있는 글리프가 행(hang) 처리되는 경우, 줄의 내용 적합성, 정렬, 또는 양쪽 맞춤 측정에서 고려되지 않습니다. 줄 정렬/양쪽 맞춤에 따라, 해당 기호가 줄 박스 밖에 위치할 수 있습니다. 행(hang) 처리된 글리프는 내재 크기(min-content 크기 및 max-content 크기)와 이로부터 파생된 모든 크기 계산에서도 고려되지 않습니다. (이 측정과 커닝의 상호작용은 현재 UA 정의이며, CSSWG가 조언을 환영합니다.)

행(hang) 처리된 글리프는 여전히 부모 인라인 박스 내부에 포함되어 있고, 텍스트 양쪽 맞춤에도 참여합니다: 해당 글리프 advance는 줄에 얼마나 내용이 들어가는지, 줄의 내용을 얼마만큼 확장/압축해야 하는지, 또는 텍스트 정렬을 위해 줄 박스 내에서 콘텐츠를 어떻게 배치할지 결정할 때 측정에 포함되지 않을 뿐입니다. 실질적으로 행(hang) 글리프의 advance는 부모 인라인 박스의 해당 가장자리에 추가 음수 margin으로 재해석되어, 나머지 줄 레이아웃은 정상적으로 진행됩니다. 오버플로우된 행잉 글리프는 보통 잉크 오버플로우로 처리해 불필요한 스크롤바 생성을 방지해야 하지만, UA는 콘텐츠가 편집 가능하거나, 스크롤 오버플로우가 사용자에게 유용한 다른 상황에서는 스크롤 오버플로우로 처리할 수 있습니다. [CSS-OVERFLOW-3]

경우에 따라, 줄 끝에 위치한 글리프가 조건부 행(hang)될 수 있습니다: 이는 양쪽 맞춤 이전에 줄에 들어갈 수 없을 때만 행(hang) 처리됩니다. 줄 내용 적합성 측정에서는 고려되지 않지만, 줄에 들어가지 않는 부분은 행(hang) 처리로 간주됩니다. 조건부 행(hang) 처리된 글리프는 min-content 크기 및 파생 크기 계산에는 포함되지 않지만, max-content 크기 및 파생 크기에는 포함됩니다.

행(hang) 처리 가능한 글리프와 줄 끝 사이에 0이 아닌 인라인 축 border나 padding이 있으면, 해당 글리프는 행(hang) 처리되지 않습니다. 예를 들어, 인라인 박스 끝에 끝 padding이 있는 마침표는 줄 끝에서 행(hang) 처리되지 않습니다.

여러 인접한 글리프가 함께 행(hang) 처리될 수 있지만, 몇 개까지 허용할지 구체적인 제한이 있을 수 있습니다 (예: 각 줄 가장자리에 최대 한 개의 문장부호만 행(hang) 처리 허용).

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

이 속성은 문장부호가 있는 경우, 해당 문장부호가 행(hang) 처리되어 줄 박스 밖(또는 들여쓰기 부분) 또는 텍스트 줄의 시작/끝에 위치할 수 있는지 결정합니다.

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

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

none

어떤 문장부호도 행(hang) 처리하지 않습니다.

first

요소의 첫 형식화된 줄 시작에 있는 여는 괄호, 인용부호, 또는 전각 공백은 행(hang) 처리됩니다. 해당 범위는 유니코드 Ps, Pf, Pi 카테고리, ASCII 인용부호 U+0027 ' 및 U+0022 " 그리고 전각 공백(U+3000)입니다.

last

요소의 마지막 형식화된 줄 끝에 있는 닫는 괄호 또는 인용부호는 행(hang) 처리됩니다. 해당 범위는 유니코드 Pe, Pf, Pi 카테고리, ASCII 인용부호 U+0027 ' 및 U+0022 "입니다.

force-end

줄 끝에 위치한 마침표 또는 콤마는 행(hang) 처리됩니다.

allow-end

줄 끝에 위치한 마침표 또는 콤마는 조건부 행(hang) 처리됩니다.

각 줄 가장자리에 최대 한 개의 문장부호만 행(hang) 처리될 수 있습니다.

행(hang) 처리 가능한 마침표 및 콤마는 다음을 포함합니다:

UA는 필요에 따라 다른 문자를 포함할 수 있습니다.

참고: UA가 다른 문자를 포함하는 경우 CSS 워킹 그룹에 알려주시면 감사하겠습니다.

allow-end와 force-end는 동아시아에서 사용되는 행잉 문장부호의 두 가지 변형입니다.

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

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

첫 줄 끝의 문장부호는 allow-end일 때 행(hang) 처리되지 않습니다. 줄에 충분히 들어가므로 행(hang) 처리 필요가 없습니다. 반면 force-end는 강제로 행(hang) 처리됩니다. 양쪽 맞춤 측정은 행잉 문장부호를 제외하고 줄을 측정합니다. 따라서 줄이 확장되면 문장부호가 줄 밖으로 밀려납니다.

8.3. 양방향성과 줄 박스

start 및 end 방향의 줄 박스 가장자리는 줄 박스의 인라인 기본 방향에 따라 결정됩니다. 보통 일치하지만, 인라인 기본 방향은 줄 박스와 포함 블록 또는 양방향 문단과는 구별됩니다. 줄 박스의 인라인 기본 방향은 text-align-all, text-align-last, text-indent, hanging-punctuation에 영향을 줍니다—즉, 줄 내용이 가장자리에 대해 어떻게 배치되는지에 영향을 줍니다. 인라인 콘텐츠의 서식이나 순서에는 영향을 주지 않습니다 (이는 Unicode 양방향 알고리즘 및 CSS Writing Modes에서 제어됨. [UAX9] [CSS-WRITING-MODES-4]).

대부분의 경우, 줄 박스의 인라인 기본 방향은 포함 블록의 계산된 direction 속성에 의해 결정됩니다. 그러나, 포함 블록에 unicode-bidi: plaintext가 지정되어 있으면 [CSS-WRITING-MODES-4]:

• 양방향 문단에 속한 줄 박스 (즉, 해당 줄 박스가 포함하는 문단의 콘텐츠) 에 강한 방향성이 있으면, 줄 박스의 인라인 기본 방향은 그 방향을 따릅니다.
• 줄 박스가 비어 있거나 (즉, atomic inlines나 개행 문자 이외의 문자가 없을 때) 또는 강한 방향성이 없으면(약한/중립 문자만 있으면), 인라인 기본 방향은 바로 이전 줄 박스(있는 경우)에서 가져오고, 만약 포함 블록의 첫 줄 박스라면, 포함 블록의 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. 공백 처리 1단계(줄 바꿈 전)
2. 텍스트 변환
3. 텍스트 결합 [CSS-WRITING-MODES-4]
4. 텍스트 방향 [CSS-WRITING-MODES-4]
5. 텍스트 줄 바꿈 (줄마다 적용, 동시에):

   • 들여쓰기

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

   • 공백 처리 2단계

   • 폰트/글리프 선택 및 배치 [CSS-FONTS-3]

   • letter-spacing 및 word-spacing

   • 행잉 문장부호

6. 양쪽 맞춤 (글리프 선택/텍스트 줄 바꿈에 영향을 줄 수 있음, 해당 단계로 다시 루프 가능)
7. 텍스트 정렬

부록 B: 플레인텍스트 변환

이 부록은 플레인텍스트 복사-붙여넣기 동작에 대해 규범적입니다.

CSS로 렌더링된 문서를 플레인텍스트 형식으로 변환할 때, 다음이 기대됩니다:

• text-transform 속성은 영향이 없습니다.
• § 4.1.1 1단계: 공백 압축 및 변환이 적용되며, 압축 가능한 공백이 블록 시작 또는 강제 줄 바꿈 직후에 있으면 제거됩니다.

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

이 부록은 정보 제공용입니다, HTML의 기본 스타일시트 구현을 돕기 위한 것이지만, UA 개발자는 자유롭게 무시하거나 적절히 수정할 수 있습니다.

/* option 요소들을 함께 정렬 */
option { text-align: match-parent; }

부록 D: 문자체계 및 간격

이 부록은 규범적입니다.

타이포그래피 동작은 언어에 따라 다소 다르지만, 문자체계에 따라 극적으로 달라집니다. 이 부록은 현행 표준에서 자주 쓰이는 일부 문자체계를 Unicode 6.0 기준으로 양쪽 맞춤/간격 동작에 따라 분류합니다. 카테고리 설명은 기술적 설명일 뿐, 규정적이지 않습니다; 결정 요인은 양쪽 맞춤 기회의 우선순위입니다.

블록 문자체계

CJK 및 확장된 Wide 문자 (동아시아 너비 [UAX11] 참고). 아래 Unicode 문자체계 포함: 보포모포(Bopomofo), 한자(Han), 한글(Hangul), 히라가나(Hiragana), 가타카나(Katakana), 이이(Yi). 동아시아 너비 속성이 Wide 또는 Fullwidth인 문자도 포함, 단 Ambiguous 문자는 문자체계가 중국어, 한국어, 일본어인 경우에만 포함됩니다.

클러스터 문자체계

클러스터 문자체계는 분리 단위가 있으며, 단어 경계에서만 줄 바꿈이 일어나며, 가시적인 단어 구분자를 사용하지 않습니다. 공간 확장을 우선하며, 양쪽 맞춤을 위해 문자 간 간격도 허용합니다. 클러스터 문자체계에는(제한되지 않음) 다음 Unicode 문자체계가 포함됩니다: 크메르(Khmer), 라오(Lao), 미얀마(Myanmar), 뉴타이루(New Tai Lue), 타이레(Tai Le), 타이탐(Tai Tham), 타이베트(Tai Viet), 태국(Thai)

필기체 문자체계

필기체 문자체계는 양쪽 맞춤이나 letter-spacing에 대해 글자 사이에 공백을 허용하지 않습니다. 아래 Unicode 문자체계 포함: 아랍어(Arabic), 하니피로힝야(Hanifi Rohingya), 만다이어(Mandaic), 몽골어(Mongolian), 은코(N’Ko), 파스파(Phags Pa), 시리아어(Syriac)

참고: 베이스라인 커넥터가 있는 인도 문자체계(데바나가리, 구자라티 등)는 필기체 문자체계로 간주되지 않으며, 조판 문자 단위 사이에 공백을 허용합니다. 인도 레이아웃 요구사항 참고. [ILREQ]

UA는 Unicode 지원이 업데이트될 때마다 아직 인코딩되지 않은 필기체 문자체계 처리도 반영하여 이 목록을 갱신해야 하며, CSSWG에 사양 업데이트를 요청하는 것이 권장됩니다.

부록 E: 문자 및 속성

이 부록은 규범적입니다.

유니코드는 CSS 조판에서 참조되는 4가지 코드 포인트 수준 속성을 정의합니다:

동아시아 너비 속성

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

일반 카테고리

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

스크립트 속성

Unicode Standard Annex #24 [UAX24]에서 정의되며, Unicode Character Database에서 Script 속성으로 제공됩니다. [UAX44]. (UA는 이 매핑에 ScriptExtensions.txt 할당도 포함해야 합니다.)

세로 방향 속성

Unicode Standard Annex #50 [UAX50]에서 정의되며, Unicode Character Database에서 Vertical_Orientation 속성으로 제공됩니다. [UAX44].

유니코드는 개별 코드 포인트의 속성을 정의하지만, 때로는 조판 문자 단위의 속성을 결정해야 할 때도 있습니다. CSS Text의 목적상, 조판 문자 단위의 속성은 첫 번째 그래페임 클러스터의 기본 문자에 의해 결정됩니다—단, 두 가지 예외가 있습니다:

• Enclosing Mark (Me)로 형성된 그래페임 클러스터(스크립트 Common)는 Common 스크립트의 기타 기호(So)로 간주됩니다. 이들은 대체 문자(U+FFFD)와 동일한 유니코드 속성을 가진 것으로 가정합니다.
• Space Separator (Zs)를 기본으로 하는 그래페임 클러스터는 Modifier Symbol(Sk)로 간주됩니다. 이들은 기본 문자와 동일한 동아시아 너비 속성을 갖지만, 그 외 속성은 시퀀스 내 첫 번째 결합 문자에서 가져옵니다.

부록 F: 콘텐츠 문자체계 식별

이 부록은 규범적입니다.

대부분의 언어는 선호 문자체계를 가지고 있지만, 일부는 여러 문자체계가 있고, 대부분은 하나 이상의 외래 문자체계로 전사될 수 있습니다. 예를 들어, 대부분의 언어는 최소한 하나의 라틴 전사체를 가지며, 라틴 문자체계로도 작성할 수 있습니다. 전사된 텍스트는 일반적으로 해당 문자체계의 타이포그래피 규칙을 따릅니다: 예를 들어 일본어 로마자(romaji)와 중국어 병음(Pinyin)은 라틴 문자와 단어 간 스페이스를 사용하며, 라틴식 줄 바꿈 및 양쪽 맞춤 규칙을 따릅니다. 또 다른 예로, 역사적 표의문 한글(ko-Hani)은 단어 간 스페이스를 사용하지 않으므로, 현대 한국어가 아니라 중국어와 유사하게 조판해야 합니다.

HTML이나 문서 언어에서 BCP47 태그로 언어를 식별하여 콘텐츠 언어를 선언할 때, 저자는 스크립트 서브태그로 비전형적 문자체계 사용을 명확히 하거나 표시할 수 있습니다. [BCP47] 예를 들어, 원래 해당 문자체계를 사용하지 않는 언어에서 라틴 문자체계를 사용함을 표시하려면 -Latn 스크립트 서브태그를 추가할 수 있습니다(예: 일본어 로마자는 ja-Latn). 다른 스크립트 태그도 있으며, ISO의 Code for the Representation of Names of Scripts 및 ISO15924 스크립트 태그 레지스트리 참고. [ISO15924]

단, BCP47 스크립트 서브태그는 한 문자체계와 강하게 연관된 언어에는 일반적으로 사용하지 않으며(권장되지도 않음), 그런 경우에는 별도 지정이 없으면 해당 문자체계가 암묵적으로 적용되는 것으로 간주합니다. [BCP47] IANA는 Suppress-Script 필드를 통해 언어 서브태그 레지스트리에서 각 언어의 대표 문자체계를 관리합니다.

참고: 언어 태그에 대한 추가 조언은 국제화 워킹 그룹의 “HTML과 XML의 언어 태그” 및 “언어 태그 선택”에서 찾을 수 있습니다.

문자체계가 명시적으로 지정되지 않은 경우, UA는 선언된 콘텐츠 언어의 대표 문자체계를 줄 바꿈, 양쪽 맞춤 등 언어 민감 타이포그래피 동작에 사용해야 합니다. 단, 저자가 명시적으로 다른 문자체계를 선언한 경우에는 그 문자체계를 적용해야 합니다. UA가 특정 언어/문자체계 조합에 대한 언어별 지식이 없을 경우, 해당 문자체계의 타이포그래피 규칙을 적용해야 하며 (필요시 다른 언어의 규칙을 참고), 선언된 언어의 암묵적 문자체계 규칙을 적용하면 안 됩니다. 이는 선언된 문자체계에 부적합합니다.

언어와 대표 문자체계의 전체 매핑은 이 문서 범위를 벗어납니다. 단, UA는 최소한 아래와 같아야 합니다:

• 콘텐츠 언어가 중국어이고 문자체계가 지정되지 않았거나, 또는 콘텐츠 언어가 무엇이든 문자체계에 아래 ISO 스크립트 코드 중 하나가 지정된 경우(Hant, Hans, Hani, Hanb, Bopo), 문자체계는 중국어 문자체계로 간주합니다.
• 콘텐츠 언어가 일본어이고 문자체계가 지정되지 않았거나, 또는 콘텐츠 언어가 무엇이든 문자체계에 아래 ISO 스크립트 코드 중 하나가 지정된 경우(Jpan, Hrkt, Hira, Kana), 문자체계는 일본어 문자체계로 간주합니다.
• 콘텐츠 언어가 한국어이고 문자체계가 지정되지 않았거나, 또는 콘텐츠 언어가 무엇이든 문자체계에 아래 ISO 스크립트 코드 중 하나가 지정된 경우(Kore, Hang, Jamo), 문자체계는 한국어 문자체계로 간주합니다.
• 문자체계는 알 수 없음으로 간주되는 경우는, 콘텐츠 언어 자체가 알 수 없거나, 문자체계가 명시적으로 알 수 없음으로 지정된 경우뿐입니다.

  참고: 문자체계 정보가 누락되었고 콘텐츠 언어가 선언된 경우, 문자체계는 암묵적으로 추정된 것이며, 알 수 없는 것이 아닙니다.

부록 G: 소형 가나 매핑

이 부록은 규범적입니다.

개인정보 보호 고찰

이 현행 표준은 사용자가 설치한 하이픈 처리 및 줄 바꿈 사전을 노출합니다.

보안 고찰

이 현행 표준은 새로운 보안 고찰을 도입하지 않습니다.

감사의 글

이 현행 표준은 아래 분들의 도움이 없었다면 가능하지 않았을 것입니다: 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, Rahul Sonnad, Richard Ishida, Shinyu Murakami, Stephen Deach, Steve Zilles, Takao Suzuki, Tantek Çelik, Xidorn Quan, Yaniv Feinberg.

변경 사항

최근 변경 사항

아래의 규범적 변경 사항은 2023년 9월 현행 표준 후보 권고안 이후에 이루어졌습니다:

• text-align-last의 계산 값 줄을 바로잡았습니다. (이슈 7331)

• 치환 요소 주변의 soft wrap opportunity를 명확히 했습니다. (이슈 9964)

  두 문자 사이 경계로 정의된 soft wrap opportunity에 대해 또는 atomic inlines , 두 문자 가장 가까운 공통 조상에 적용된 white-space 속성이 줄 바꿈을 제어합니다;

아래의 규범적 변경 사항은 2023년 2월 현행 표준 후보 권고안 이후 이루어졌습니다.

• 부록 G: 소형 가나 매핑을 Unicode 15.0에 맞춰 업데이트했습니다. (이슈 8442)

• NBSP 이외의 사용자 Tailor 불가능한 유니코드 줄 바꿈 컨트롤이 atomic inlines에 관한 규칙보다 우선하도록 했습니다. (이슈 8972)

  웹 호환성을 위해 각 치환 요소 또는 기타 atomic inline 앞뒤에 soft wrap opportunity가 있습니다, 인접한 문자가 일반적으로 suppress하는 경우에도 마찬가지입니다, 예를 들어 포함하여 U+00A0 NO-BREAK SPACE. 단, U+00A0 NO-BREAK SPACE를 제외하고는, soft wrap opportunity가 atomic inlines와 인접한 GL, WJ, ZWJ 줄 바꿈 클래스 문자 사이에는 없어야 합니다. [UAX14]

아래의 규범적 변경 사항은 2020년 12월 현행 표준 후보 권고안 이후 이루어졌습니다.

• hanging-punctuation: first가 U+300 전각 공백을 행(hang) 처리하도록 허용, 이는 플레인텍스트 들여쓰기 관행도 수용합니다. (이슈 2462)

  first

  여는 괄호 , 또는 인용부호 , 또는 전각 공백 요소의 첫 형식화된 줄 시작에 행(hang) 처리됩니다. 유니코드 Ps, Pf, Pi 카테고리 문자 및 ASCII 인용부호(U+0027 ', U+0022 ")와 전각 공백(U+3000)에 적용됩니다.

• distribute가 inter-character로 계산됨을 명확히 했고, distribute를 레거시 값 별칭으로 구현할 수 있도록 허용, 이는 일부 엔진에서 더 쉽고 호환성에도 영향이 없습니다. (이슈 6156, 이슈 7322)

• 언어별 하이픈 처리 규칙이 명시적 하이픈 처리 기회에도 적용됨을 명확히 했습니다. (이슈 5973)

  단어 내에 명시적으로 하이픈 처리 기회를 제시하는 문자가 있을 때만 하이픈 처리합니다. UA는 적절한 언어별 하이픈 문자를 사용해야 하며, 자동 하이픈과 동일한 위치에서는 적절한 철자 변환도 적용해야 합니다.

• match-parent가 루트 요소에서 start로 계산됨을 정의, 주된 쓰기 모드와 비교하지 않도록 함. (이슈 6542)

• text-transform에 관한 저자 조언을 규범적 권고로 변경. (이슈 8279)

  참고: text-transform 속성은 표시 레이어에만 영향을 주며, 의미적 목적의 올바른 대소문자는 소스 문서에 표현되어야 합니다.

  권고: 저자는 의미적 목적에 text-transform을 의존해서는 안 되며, 올바른 대소문자 및 의미는 반드시 소스 문서의 텍스트와 마크업에 인코딩해야 합니다.

이외에 몇 가지 사소한 편집적 수정이 있었습니다.

과거 변경 사항

2020년과 2019년 현행 표준 후보 권고안 이전의 Working Draft를 포함한 이전 변경사항 목록과 2013~2020년 모든 의견을 다루는 Disposition of Comments도 참고하세요.