CSS 텍스트 모듈 레벨 3

W3C 후보 권고안 초안,

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/CRD-css-text-3-20260608/
최신 게시 버전:
https://www.w3.org/TR/css-text-3/
편집자 초안:
https://drafts.csswg.org/css-text-3/
이전 버전:
이력:
https://www.w3.org/standards/history/css-text-3/
구현 보고서:
https://test.csswg.org/harness/results/css-text-3_dev/grouped/
테스트 모음:
http://test.csswg.org/suites/css3-text/nightly-unstable/
https://wpt.fyi/results/css/css-text/
피드백:
CSSWG 이슈 저장소
편집자:
Elika J. Etemad / fantasai (Apple)
(초청 전문가)
Florian Rivoal (초청 전문가)
이 명세에 대한 수정 제안:
GitHub 편집기
테스트 커버리지 분석:
https://drafts.csswg.org/css-text-3/test-coverage

초록

이 CSS 모듈은 텍스트 조작을 위한 속성을 정의하고 그 처리 모델을 명시한다. 줄 나누기, 양쪽 맞춤과 정렬, 공백 처리, 텍스트 변환을 다룬다.

CSS는 구조화된 문서 (HTML 및 XML 등) 의 렌더링을 화면, 종이 등에 설명하기 위한 언어이다.

이 문서의 상태

이 절은 발행 당시 이 문서의 상태를 설명한다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 찾을 수 있다.

이 문서는 CSS Working Group에서 권고안 트랙을 사용하여 후보 권고안 초안으로 발행했다. 후보 권고안으로 발행되었다고 해서 W3C와 그 회원들이 이를 보증한다는 뜻은 아니다. 후보 권고안 초안은 워킹 그룹이 이후 후보 권고안 스냅샷에 포함하려는 이전 후보 권고안의 변경 사항을 통합한다.

이 문서는 초안 문서이며 언제든지 다른 문서로 갱신되거나, 대체되거나, 폐기될 수 있다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않다.

피드백은 GitHub에 이슈를 제출하여 보내는 것이 좋으며(권장), 제목에 “css-text”라는 명세 코드를 다음과 같이 포함해야 한다: “[css-text] …의견 요약…”. 모든 이슈와 의견은 보관된다. 또는 피드백을 (보관된) 공개 메일링 리스트 www-style@w3.org로 보낼 수 있다.

이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받는다.

이 문서는 W3C Patent Policy에 따라 운영되는 그룹이 작성했다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 특허 공개의 공개 목록을 유지하며, 이 페이지에는 특허 공개 방법에 대한 지침도 포함되어 있다. 개인이 Essential Claim(s)을 포함한다고 판단하는 특허에 대해 실제 지식을 가지고 있는 경우, 그 개인은 W3C Patent Policy의 6절에 따라 해당 정보를 공개해야 한다.

다음 기능들은 위험 상태이며, CR 기간 중 제외될 수 있다:

“위험 상태”는 W3C Process의 전문 용어이며, 해당 기능이 반드시 제외되거나 지연될 위험에 처해 있음을 의미하지는 않는다. 이는 WG가 해당 기능을 적시에 상호운용 가능하게 구현하는 데 어려움이 있을 수 있다고 판단한다는 뜻이며, 이렇게 표시하면 필요한 경우 제안 권고안 단계로 전환할 때 해당 기능이 포함되지 않은 새 후보 권고안을 먼저 발행하지 않고도 WG가 그 기능을 제외할 수 있다.

1. 소개

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

참고: 글꼴 선택은 CSS Fonts Module에서 다룬다. [CSS-FONTS-3]

밑줄, 강조 표시, 그리고 그림자와 같은 텍스트 장식 기능은 (이전에는 이 모듈의 일부였지만) CSS Text Decoration Module에서 다룬다. [CSS-TEXT-DECOR-3]

양방향세로 텍스트는 CSS Writing Modes Module에서 다룬다. [CSS-WRITING-MODES-4].

전 세계 다양한 언어와 문자 체계의 조판 요구사항에 대한 자세한 정보는 Internationalization Working GroupLanguage Enablement Index에서 찾을 수 있다. [TYPOGRAPHY]

1.1. 모듈 상호작용

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

아래에 정의된 용어 외에도, 이 명세에서 사용되는 다른 용어와 개념은 Cascading Style Sheets Level 2CSS Writing Modes Module에 정의되어 있다. [CSS2] and [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 속성을 사용하여 콘텐츠 언어를 선언할 수 있다. HTMLHTML 요소의 콘텐츠 언어를 결정하는 규칙XML 1.0XML 요소의 콘텐츠 언어를 결정하는 규칙을 보라. [HTML] [XML10]

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

참고: 일부 언어에는 둘 이상의 문자 체계 전통이 있으며, 다른 경우에는 언어가 외래 문자 체계로 전사될 수 있다. 저자는 그러한 경우를 하위 태그로 표시하여 UA가 적절히 조정할 수 있도록 해야 한다.

예를 들어, 한국어(ko)는 한글(-Hang), 한자(-Hani), 또는 그 조합(-Kore)으로 쓸 수 있다. 한자로만 쓰인 역사 문서는 단어 공백을 사용하지 않으며 현대 한국어보다 현대 중국어와 더 비슷하게 조판된다. 다시 말해, 조판 목적에서는 ko-Haniko(ko-Kore)보다 zh-Hant와 더 비슷하게 동작한다.

또 다른 예로, 일본어(ja)는 일반적으로 히라가나(-Hira), 가타카나(-Kana), 한자(-Hani)의 조합(-Japn)으로 쓰인다. 그러나 언어 학습 교재와 같은 특수한 목적에서는 라틴 문자(-Latn)로 “로마자 표기”될 수도 있으며, 이 경우 일본어보다 영어와 더 비슷하게 조판되어야 한다.

세 번째 예로, 현대 몽골어는 두 가지 문자로 쓰인다: 키릴 문자(-Cyrl, 몽골에서 공식 사용) 와 몽골 문자(-Mong, 중국의 일부인 내몽골에서 더 흔함). 이들은 매우 다른 서식 요구사항을 가지며, 키릴 문자는 라틴 및 그리스 문자와 비슷하게 동작하고, 몽골 문자는 아랍 및 중국 문자 관례 모두에서 유래한다.

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 일반 범주 중 하나에 속하는 조판 문자 단위이다. 조판 문자 단위의 유니코드 속성을 결정하는 방법은 부록 E: 문자와 속성을 보라.

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

1.5. 텍스트 처리

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

텍스트 처리 (예: 공백 처리, 텍스트 변환, 줄 나누기 등)를 위한 인접성 결정의 목적상, 그리고 따라서 일반적으로 이 명세 안에서는, 개재하는 인라인 박스 경계와 흐름 밖 요소는 무시되어야 한다. 그러나 텍스트 셰이핑과 관련해서는 § 7.3 요소 경계를 가로지르는 셰이핑을 보라.

2. 텍스트 변환

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

이름: text-transform
값: none | [capitalize | uppercase | lowercase ] || full-width || full-size-kana
초기값: none
적용 대상: text
상속: yes
백분율: n/a
계산값: specified keyword
정규 순서: n/a
애니메이션 유형: discrete

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

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

값은 다음 의미를 가진다:

none
효과 없음.
capitalize
각 단어의 첫 번째 조판 글자 단위가 소문자인 경우 제목식 대문자로 만든다; 다른 문자는 영향을 받지 않는다.
uppercase
모든 글자를 대문자로 만든다.
lowercase
모든 글자를 소문자로 만든다.
full-width
모든 조판 문자 단위전각 형태로 만든다. 문자에 대응하는 전각 형태가 없으면, 그대로 둔다. 이 값은 일반적으로 라틴 문자와 숫자를 표의 문자처럼 조판하는 데 사용된다.
full-size-kana
모든 작은 가나 문자를 대응하는 전체 크기 가나로 변환한다. 이 값은 일반적으로 루비 주석 텍스트에 사용되며, 저자는 루비에서 일반적으로 사용되는 작은 글꼴 크기의 가독성 문제를 보완하기 위해 모든 작은 가나를 큰 가나로 그리기를 원할 수 있다.
다음 예는 일본어 텍스트의 약어에 사용된 ASCII 문자를 전각 변형으로 변환하여, 그것들이 표의 문자처럼 배치되고 줄 나누기되도록 한다:
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*/ }

이렇게 하면 작은 활자 크기에서 그러한 글자를 더 쉽게 볼 수 있지만, 이 변환은 텍스트를 왜곡한다는 점에 유의하라: 독자는 적절한 위치에서 작은 가나를 마음속으로 대체해야 한다—​마치 모든 “U”가 “V”처럼 보이는 라틴어 비문을 읽는 것과 다르지 않다.

예를 들어, 다음 원본에 text-transform: full-size-kana가 적용되면, 주석은 주석이 달린 “十”의 올바른 읽기와 의미인 “じゅう”(jū, “열”) 대신, “じゆう”(jiyū, “자유”)로 읽히게 된다.

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

2.1.1. 매핑 규칙

capitalize의 경우, 무엇이 “단어“를 구성하는지는 UA에 의존한다; [UAX29]는 그러한 단어 경계를 결정하는 데 권장되지만 필수는 아니다. 흐름 밖 박스인라인 박스 경계는 text-transform 단어 경계를 도입해서는 안 되며, 그러한 단어 경계를 결정할 때 무시되어야 한다.

참고: 저자는 capitalize가 언어별 제목식 대문자 규칙 (예: 영어에서 관사 건너뛰기)을 따를 것이라고 의존할 수 없다.

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

예를 들어, 터키어에는 두 가지 “i”가 있다. 하나는 점이 있는 “İ”와 “i”이고, 하나는 점이 없는 “I”와 “ı”이다. 따라서 “I”와 “i” 사이의 일반적인 대소문자 매핑은 영어에는 존재하지 않는, 각각의 점 없는/점 있는 대응 문자로 가는 다른 매핑 집합으로 대체된다. 이 매핑은 콘텐츠 언어가 현대 라틴 기반 문자 체계로 쓰인 터키어 (또는 터키어 대소문자 규칙을 사용하는 다른 튀르크어)인 경우에만 적용되어야 하며; 다른 언어에서는 “I”와 “i”의 일반적인 매핑이 요구된다. 따라서 이 규칙은 Unicode의 SpecialCasing.txt 파일에 조건부로 정의되어 있다.

전각반각 형태의 정의는 Unicode Standard Annex #11: East Asian Width에서 찾을 수 있다. [UAX11] 전각 형태로의 매핑은 Unicode Standard Annex #44: Unicode Character DatabaseDecomposition_Mapping<wide> 또는 <narrow> 태그가 있는 코드 포인트를 취하여 정의된다. [UAX44] <narrow> 태그의 경우, 매핑은 코드 포인트에서 분해값 (<narrow> 태그 제외)으로 이루어지며, <wide> 태그의 경우, 매핑은 분해값 (<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보존된 공백 안에서만 공백(U+0020)을 U+3000 IDEOGRAPHIC SPACE로 변환함을 의미한다.

참고: 부록 A: 텍스트 처리 작업 순서에 정의된 대로, 텍스트를 변환하면 줄 나누기와 기타 서식 작업에 영향을 준다.

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

이름: white-space
값: normal | pre | nowrap | pre-wrap | break-spaces | pre-line
초기값: normal
적용 대상: text
상속: yes
백분율: n/a
계산값: specified keyword
정규 순서: n/a
애니메이션 유형: discrete

이 속성은 두 가지를 지정한다:

값은 다음 의미를 가지며, 공백 처리줄 나누기 규칙에 따라 해석되어야 한다:

normal
이 값은 사용자 에이전트가 공백 시퀀스를 하나의 문자로 (또는 일부 경우에는 아무 문자도 없이) 축소하도록 지시한다. 줄은 현재 적용되는 줄 나누기 규칙에 따라 결정되는 허용된 소프트 줄바꿈 기회에서 줄바꿈될 수 있으며, 이는 인라인 축 넘침을 최소화하기 위함이다.
pre
이 값은 사용자 에이전트가 공백 시퀀스를 축소하지 못하게 한다. 줄 바꿈 문자와 같은 세그먼트 나누기강제 줄 나누기로 보존된다. 줄은 강제 줄 나누기에서만 나뉜다; 블록 컨테이너 안에 맞지 않는 콘텐츠는 넘친다.
nowrap
normal과 마찬가지로, 이 값은 공백을 축소한다; 그러나 pre와 마찬가지로, 줄바꿈을 허용하지 않는다.
pre-wrap
pre와 마찬가지로, 이 값은 공백을 보존한다; 그러나 normal과 마찬가지로, 줄바꿈을 허용한다.
break-spaces
동작은 pre-wrap과 동일하지만, 다음은 예외이다:

참고: 이 값은 공백 때문에 절대 넘침이 발생하지 않는다는 것을 보장하지 않는다: 예를 들어, 줄 길이가 너무 짧아 공백 문자 하나조차 맞지 않는 경우, 넘침은 피할 수 없다.

pre-line
normal과 마찬가지로, 이 값은 연속된 공백 문자를 축소하고 줄바꿈을 허용하지만, 원본의 세그먼트 나누기강제 줄 나누기로 보존한다.

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

참고: 일부 경우, 보존된 공백기타 공백 구분자는 줄 끝에 있을 때 행잉될 수 있다; 이는 내재적 크기 조정에서 측정되는지 여부에 영향을 줄 수 있다.

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

새 줄 공백과 탭 텍스트 줄바꿈 줄 끝 공백 줄 끝 기타 공백 구분자
normal 축소 축소 줄바꿈 제거 행잉
pre 보존 보존 줄바꿈 없음 보존 줄바꿈 없음
nowrap 축소 축소 줄바꿈 없음 제거 행잉
pre-wrap 보존 보존 줄바꿈 행잉 행잉
break-spaces 보존 보존 줄바꿈 줄바꿈 줄바꿈
pre-line 보존 축소 줄바꿈 제거 행잉

공백이 어떻게 축소되는지에 대한 자세한 내용은 공백 처리 규칙을 보라.

줄바꿈 동작에 대한 자세한 내용은 줄 나누기를 보라.

4. 공백 처리 및 제어 문자

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

참고: 문서 언어에 따라, 세그먼트는 특정 개행 시퀀스 (예: 줄 바꿈 문자 또는 CRLF 쌍)로 분리되거나, SGML RECORD-STARTRECORD-END 토큰 같은 다른 메커니즘으로 구분될 수 있다.

CSS 처리의 경우, 각 문서 언어에서 정의된 “세그먼트 나누기” 또는 “개행 시퀀스”—​또는 정의된 것이 없으면 텍스트의 각 줄 바꿈 문자 (U+000A)—​는 세그먼트 나누기로 취급되며, 이후 white-space 속성이 지정한 대로 렌더링을 위해 해석된다.

HTML의 경우, 개행은 DOM에서 표현하기 위해 줄 바꿈 문자(U+000A)로 정규화되므로, HTML 문서가 DOM 트리로 표현될 때 각 줄 바꿈 문자(U+000A)는 세그먼트 나누기로 취급된다. [HTML] [DOM]

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

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

참고: 전적으로 축소 가능한 공백으로 구성된 익명 블록은 렌더링 트리에서 제거된다. 따라서 블록 수준 요소 주변의 그러한 공백은 축소되어 제거된다. CSS 2 § 9.2.2.1 익명 인라인 박스를 보라. [CSS2]

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

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

참고: HTML 문서의 경우, 원본 코드에 있는 캐리지 리턴은 파싱 단계에서 줄 바꿈 문자로 변환되므로 (HTML § 13.2.3.5 입력 스트림 전처리개행 정규화의 정의를 Infra에서 보라), CSS에는 U+000D CARRIAGE RETURN으로 나타나지 않는다. [HTML] [INFRA]) 그러나 이 문자는 이스케이프 시퀀스(&#x0d;)를 사용해 인코딩된 경우에는 보존되며—​위 규칙이 관찰 가능하다.

4.1. 공백 처리 규칙

달리 지정된 경우를 제외하면, CSS의 공백 처리는 문서 공백 문자에만 영향을 준다: 공백 (U+0020), (U+0009), 그리고 세그먼트 나누기.

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

공백(U+0020) 및 줄 바꿈 없는 공백(U+00A0) 외에도, Unicode는 여러 추가 공백 구분자 문자를 정의한다. [UNICODE] 이 명세에서는 Unicode 일반 범주 Zs에 속하는 모든 문자 중 공백(U+0020) 및 줄 바꿈 없는 공백(U+00A0)을 제외한 문자를 통틀어 기타 공백 구분자라고 한다.

4.1.1. 1단계: 축소와 변환

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

다음 예는 공백 축소와 양방향성의 상호작용을 보여준다. 다음 마크업 조각을 고려하라. 특히 공백에 주목하라 (강조와 식별을 위해 서로 다른 배경과 테두리를 사용함):
<ltr>A <rtl> B </rtl> C</ltr>

여기서 <ltr> 요소는 왼쪽에서 오른쪽으로의 임베딩을 나타내고, <rtl> 요소는 오른쪽에서 왼쪽으로의 임베딩을 나타낸다. white-space 속성이 normal로 설정되면, 공백 처리 모델은 다음 결과를 만든다:

그 결과 두 개의 공백이 남는다. 하나는 왼쪽에서 오른쪽으로의 임베딩 레벨에서 A 뒤에 있고, 하나는 오른쪽에서 왼쪽으로의 임베딩 레벨에서 B 뒤에 있다. 그런 다음 텍스트는 Unicode 양방향 알고리즘에 따라 정렬되며, 최종 결과는 다음과 같다:

A  BC

A와 B 사이에는 두 개의 공백이 있고, B와 C 사이에는 공백이 없다는 점에 유의하라. 이는 여는 태그와 닫는 태그 바로 안쪽에만 공백을 두는 대신 요소 바깥쪽에 공백을 배치하고, 실용적인 경우에는 명시적 임베딩 레벨 대신 암시적 양방향성에 의존함으로써 피하는 것이 좋다.

4.1.2. 2단계: 제거와 위치 지정

그런 다음 전체 블록이 렌더링된다. 인라인은 양방향 재정렬을 고려하고, white-space 속성으로 지정된 대로 줄바꿈하면서 배치된다. 각 줄이 배치될 때,

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

    참고: 탭 문자(U+0009)가 양방향 처리와 상호작용하는 방식에 대한 Unicode 규칙을 보라. [UAX9]

  3. 줄 끝에 있는 축소 가능한 공백 시퀀스는 제거되며, 또한 white-space 속성이 normal, nowrap, 또는 pre-line인 뒤따르는 U+1680   OGHAM SPACE MARK도 제거된다.

    참고: Unicode Bidirectional Algorithm 규칙 L1 때문에, 양방향 재정렬 이전에 줄 끝에 위치한 축소 가능한 공백 시퀀스는 재정렬 이후에도 줄 끝에 있게 된다. [UAX9] [CSS-WRITING-MODES-4]

  4. 양방향 재정렬 이후 줄 끝에 공백, 기타 공백 구분자, 및/또는 보존된 의 시퀀스가 여전히 남아 있다면 ([CSS-WRITING-MODES-4]):
    • white-spacenormal, nowrap, 또는 pre-line으로 설정된 경우, UA는 이 시퀀스를 (무조건) 행잉해야 한다.
    • white-spacepre-wrap로 설정된 경우, UA는 이 시퀀스를 (무조건) 행잉해야 한다. 단, 이 시퀀스 뒤에 강제 줄 나누기가 오는 경우에는, 대신 그 시퀀스를 조건부로 행잉해야 한다. 또한 그렇지 않으면 넘칠 수 있는 문자들의 선행 폭을 시각적으로 축소할 수 있다.

      참고: 공백을 축소하지 않고 행잉하면, 사용자가 텍스트를 선택하거나 편집할 때 공백을 볼 수 있다.

    • white-spacebreak-spaces로 설정된 경우, 공백, , 그리고 기타 공백 구분자는 다른 보이는 문자와 동일하게 취급된다: 이들은 행잉될 수 없고 선행 폭이 축소될 수도 없다.

      참고: 따라서 그러한 문자는 공간을 차지하며, 사용 가능한 공간과 적용 가능한 줄 나누기 제어에 따라 넘치거나 줄바꿈을 유발한다.

이 예는 강제 나누기가 있는 줄 끝의 공백을 조건부로 행잉하는 것이 줄 시작과 대칭을 이룬다는 것을 보여준다. 공백을 시각화하는 데 도움이 되도록 밑줄을 추가했다.
p {
  white-space: pre-wrap;
  width: 5ch;
  border: solid 1px;
  font-family: monospace;
  text-align: center;
}
<p> 0 </p>

위 예제는 다음과 같이 렌더링된다:

0

마지막 공백은 강제 줄 나누기 앞에 있으며 넘치지 않으므로, 행잉되지 않고, 가운데 정렬은 예상대로 동작한다.

이 예는 강제 나누기가 없는 줄 끝에서 행잉되는 공백과, 강제 나누기가 있는 줄 끝에서 이를 조건부로 행잉하는 것의 차이를 보여준다. 공백을 시각화하는 데 도움이 되도록 밑줄을 추가했다.
p {
  white-space: pre-wrap;
  width: 3ch;
  border: solid 1px;
  font-family: monospace;
}
<p> 0 0 0 0 </p>

위 예제는 다음과 같이 렌더링된다:

0
0 0
0

p { text-align: right; } 가 추가되면, 결과는 다음과 같다:

0
0 0
0

강제 나누기가 없는 줄 끝의 보존된 공백은 반드시 행잉되어야 하므로, 텍스트 정렬 중 나머지 줄을 배치할 때 고려되지 않는다. 끝쪽으로 정렬할 때, 이는 그러한 공백이 넘칠 수 있으며, 줄의 나머지 콘텐츠가 줄 가장자리에 맞닿는 것을 방해하지 않는다는 뜻이다. 반면, 강제 나누기가 있는 줄 끝의 보존된 공백은 조건부로 행잉된다. 이 예에서 마지막 줄 끝의 공백은 넘치지 않으므로, 행잉되지 않으며 따라서 텍스트 정렬 중 고려된다.

다음 예에서는, 어떤 줄에도 줄 끝 공백을 맞출 충분한 공간이 없으므로, 모든 줄에서 공백이 행잉된다: 강제 나누기가 없는 줄의 공백은 반드시 행잉되어야 하기 때문이고, 강제 나누기가 있는 줄의 공백도 조건부로 행잉되며 넘치기 때문이다. 공백을 시각화하는 데 도움이 되도록 밑줄을 추가했다.
p {
  white-space: pre-wrap;
  width: 3ch;
  border: solid 1px;
  font-family: monospace;
}
<p>0 0 0 0 </p>
0 0
0 0

마지막 줄은 마지막 0 앞에서 줄바꿈되지 않는다. 조건부로 행잉되는 문자는 줄의 콘텐츠가 맞는지 측정할 때 고려되지 않기 때문이다.

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

white-spacepre, pre-wrap, break-spaces, 또는 pre-line이면, 세그먼트 나누기축소 가능하지 않으며, 대신 보존된 줄 바꿈 문자(U+000A)로 변환된다.

white-space의 다른 값에 대해서는, 세그먼트 나누기축소 가능하며, 다음과 같이 축소된다:

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

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

세그먼트 나누기 변환 규칙 (및 일반적인 공백 축소)의 목적은 문서 원본 코드를 더 쉽게 다룰 수 있도록 세그먼트로 나뉜 텍스트를 “다시 이어 붙이는” 것이다. 영어와 한국어처럼 단어 구분자를 사용하는 언어에서는, 줄을 “다시 이어 붙이려면” 두 줄을 공백으로 연결해야 한다.
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.

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.2. 탭 문자 크기: tab-size 속성

이름: tab-size
값: <number [0,∞]> | <length [0,∞]>
초기값: 8
적용 대상: text
상속: yes
백분율: n/a
계산값: 지정된 숫자 또는 절대 길이
정규 순서: n/a
애니메이션 유형: 계산값 유형에 따름

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

5. 줄 나누기와 단어 경계

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

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

대부분의 문자 체계에서는, 하이픈 넣기가 없는 경우 소프트 줄바꿈 기회가 단어 경계에서만 발생한다. 이러한 체계 중 많은 것들(예: 라틴 알파벳을 사용하는 영어)은 공백이나 문장부호를 사용하여 명시적으로 단어를 분리하며, 이러한 문자로 소프트 줄바꿈 기회를 식별할 수 있다.

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

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

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

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

참고: 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]에서 찾을 수 있다. 또한 추가 언어에 대한 더 많은 정보를 포함하는 Internationalization Working GroupLanguage Enablement Index도 보라. [TYPOGRAPHY] 추가로 적절한 참고문헌에 대한 안내가 있다면 매우 감사하겠다.

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

이름: word-break
값: normal | keep-all | break-all | break-word
초기값: normal
적용 대상: text
상속: yes
백분율: n/a
계산값: specified keyword
정규 순서: n/a
애니메이션 유형: discrete

이 속성은 글자 사이의 소프트 줄바꿈 기회, 즉 텍스트 줄을 나누는 것이 “정상”이고 허용되는 위치를 지정한다. 구체적으로는 인접한 조판 글자 단위 사이에 소프트 줄바꿈 기회가 일반적으로 존재하는지를 제어하며, 글자가 아닌 조판 문자 단위NU, AL, AI, 또는 ID Unicode 줄 나누기 클래스에 속하는 것들을 이 목적에 대해서만 조판 글자 단위로 취급한다. [UAX14] 이는 공백 (및 기타 공백 구분자)과 문장부호 주변에서 생성되는 소프트 줄바꿈 기회를 관장하는 규칙에는 영향을 주지 않는다. (문장부호와 작은 가나에 영향을 주는 제어는 line-break를 보라.)

예를 들어, CJK 조판의 일부 스타일에서는, 영어 단어가 공백이나 하이픈 넣기 지점에서만 나뉘는 대신 임의의 두 글자 사이에서 나뉘도록 허용된다; 이는 word-break:break-all로 활성화할 수 있다.
일본어 텍스트 안에 영어가 포함된 조각.
			          단어 'caption'이 두 줄에 걸쳐 'capt'와 'ion'으로 나뉘어 있다.
일본어에 포함된 영어 텍스트가 단어 안의 임의 지점에서 나뉘는 예.

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

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

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

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

참고: 넘침이 있는 경우에만 추가 나누기 기회를 활성화하려면, overflow-wrap를 보라.

값은 다음 의미를 가진다:

normal
단어는 위에서 설명한 대로 관례적인 규칙에 따라 나뉜다. 일반적으로 두 가지 다른 동작을 보이는 한국어는 연속된 임의의 두 한글/한자 사이에서 나누기를 허용한다. 역시 두 가지 다른 동작을 보이는 에티오피아 문자의 경우, 단어 내부에서 그러한 나누기는 허용되지 않는다.
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]에 속하는 다른 조판 문자 단위) 사이의 암시적 소프트 줄바꿈 기회는 억제된다. 즉, 사전 기반 나누기 때문에 기회가 존재하는 경우를 제외하고, 그러한 문자 쌍 사이의 나누기는 금지된다 (anywhere 이외의 line-break 설정과 관계없이). 그 밖의 경우 이 옵션은 normal과 동일하다. 이 스타일에서는 CJK 문자 시퀀스가 나뉘지 않는다.

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

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

다음은 혼합 문자 예제 텍스트이다:
这是一些汉字 and some Latin و کمی خط عربی และตัวอย่างการเขียนภาษาไทย በጽሑፍ፡ማራዘሙን፡አንዳንድ፡

나누기 지점은 다음과 같이 결정된다(‘·’로 표시):

word-break: normal
这·是·一·些·汉·字·and·some·Latin·و·کمی·خط·عربی·และ·ตัวอย่าง·การเขียน·ภาษาไทย·በጽሑፍ፡·ማራዘሙን፡·አንዳንድ፡
word-break: break-all
这·是·一·些·汉·字·a·n·d·s·o·m·e·L·a·t·i·n·و·ﮐ·ﻤ·ﻰ·ﺧ·ﻁ·ﻋ·ﺮ·ﺑ·ﻰ·แ·ล·ะ·ตั·ว·อ·ย่·า·ง·ก·า·ร·เ·ขี·ย·น·ภ·า·ษ·า·ไ·ท·ย·በ·ጽ·ሑ·ፍ፡·ማ·ራ·ዘ·ሙ·ን፡·አ·ን·ዳ·ን·ድ፡
word-break: keep-all
这是一些汉字·and·some·Latin·و·کمی·خط·عربی·และ·ตัวอย่าง·การเขียน·ภาษาไทย·በጽሑፍ፡·ማራዘሙን፡·አንዳንድ፡

일본어는 일반적으로 단어 내부의 음절 사이에서 줄 나누기를 허용하도록 조판된다. 그러나 때때로 이러한 줄바꿈 기회를 억제하고 특정 문장 조각의 끝에서만 줄바꿈을 허용하는 것이 선호된다. 이는 제목과 표 또는 그림 캡션처럼 매우 짧은 텍스트 조각에서 가장 흔히 사용된다.

이는 허용된 줄바꿈 지점을 wbr 또는 U+200B ZERO WIDTH SPACE로 표시하고, word-break: keep-all을 사용해 다른 지점들을 억제함으로써 달성할 수 있다.

예를 들어, 다음 마크업은 word-break 속성 값에 따라 아래 렌더링 중 하나를 만들 수 있다:

<h1>窓ぎわの<wbr>トットちゃん</h1>
h1 { word-break: normal } h1 { word-break: keep-all }
예상 렌더링
窓ぎわのトットちゃ
ん
窓ぎわの
トットちゃん
브라우저에서의 결과 窓ぎわのトットちゃん 窓ぎわのトットちゃん

레거시 콘텐츠와의 호환성을 위해, word-break 속성은 폐기된 break-word 키워드도 지원한다. 이것이 지정되면, word-break: normaloverflow-wrap: anywhere와 같은 효과를 가지며, overflow-wrap 속성의 실제 값과 관계없다.

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

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

이름: line-break
값: auto | loose | normal | strict | anywhere
초기값: auto
적용 대상: text
상속: yes
백분율: n/a
계산값: 지정된 키워드
정규 순서: n/a
애니메이션 유형: discrete

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

auto
UA가 사용할 줄 나누기 제한 집합을 결정하며, 줄의 길이에 따라 제한을 달리할 수 있다; 예를 들어 짧은 줄에는 덜 제한적인 줄 나누기 규칙 집합을 사용할 수 있다.
loose
가장 제한이 적은 줄 나누기 규칙 집합을 사용하여 텍스트를 나눈다. 일반적으로 신문과 같은 짧은 줄에 사용된다.
normal
가장 일반적인 줄 나누기 규칙 집합을 사용하여 텍스트를 나눈다.
strict
가장 엄격한 줄 나누기 규칙 집합을 사용하여 텍스트를 나눈다.
anywhere
모든 조판 문자 단위 주변에 소프트 줄바꿈 기회가 존재한다. 여기에는 모든 문장부호 문자 주변, 보존된 공백 주변, 또는 단어 중간도 포함되며, 줄 나누기에 대한 어떤 금지도 무시한다. 여기에는 GL, WJ, 또는 ZWJ 줄 나누기 클래스를 가진 문자에 의해 도입된 금지나 word-break 속성이 명령한 금지도 포함된다. [UAX14] 서로 다른 줄바꿈 기회에는 우선순위를 두어서는 안 된다. 하이픈 넣기는 적용되지 않는다.

참고: 이 값은 터미널에서 일반적으로 보이는 줄 나누기 규칙을 유발한다.

참고: anywhere보존된 공백이 줄 끝에 있을 때 white-spacebreak-spaces로 설정된 경우에만 다음 줄로 줄바꿈되도록 허용한다. 다른 경우에는 다음과 같기 때문이다:

보존된 공백에 영향을 주는 경우, white-space: break-spaces와 함께 사용하면, 시퀀스의 첫 번째 공백 앞에서 나누는 것을 허용한다. 이는 break-spaces만으로는 허용되지 않는다.

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

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

UA는 strict/normal/loose 모드 사이에 추가적인 구분을 더할 수 있으므로, 이러한 값들은 다른 문자 체계에서도 차이를 보일 수 있다. 예를 들어, 충분히 고급의 태국어 처리 능력을 가진 UA는 태국어 줄 나누기에서 서로 다른 엄격도 수준을 이 키워드들에 매핑하도록 선택할 수 있다. 예를 들어 strict 모드에서는 복합어 내부의 나누기를 허용하지 않고 (예: ตัวอย่างการเขียนภาษาไทย를 ตัวอย่าง·การเขียน·ภาษาไทย처럼 나눔), loose에서는 더 많은 나누기를 허용할 수 있다 (ตัวอย่าง·การ·เขียน·ภาษา·ไทย).

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

참고: 사용자 에이전트는 줄 나누기 구현의 시작점으로 [UAX14]를 참조할 수 있지만, 기존 구현과의 최대 상호운용성을 위해 다음과 같은 편차가 바람직할 수 있다:

5.3. 하이픈 넣기: 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
위구르어  [독립형 DAL + 독립형 ALEF + 초성 MEEM +
					          중성 YEH  + 종성 DAL +
					          독립형 ALEF MAKSURA] [독립형 DAL + 독립형 ALEF + 초성 MEEM +
					          종성 YEH + 하이픈 ] [ 독립형 DAL + 독립형 ALEF MAKSURA]
크리어 [ᑲᓯᑕᓂᐘᓂᓂᐠ]
					          (CANADIAN SYLLABICS KA +
					          CANADIAN SYLLABICS SI +
					          CANADIAN SYLLABICS TA +
					          CANADIAN SYLLABICS NI +
					          CANADIAN SYLLABICS WEST-CREE WA +
					          CANADIAN SYLLABICS NI +
					          CANADIAN SYLLABICS NI +
					          CANADIAN SYLLABICS FINAL GRAVE) [ᑲᓯᑕᓂ᐀]
					          (CANADIAN SYLLABICS KA +
					          CANADIAN SYLLABICS SI +
					          CANADIAN SYLLABICS TA +
					          CANADIAN SYLLABICS NI +
					          CANADIAN SYLLABICS HYPHEN) [ᐘᓂᓂᐠ]
					          (CANADIAN SYLLABICS WEST-CREE WA +
					          CANADIAN SYLLABICS NI +
					          CANADIAN SYLLABICS NI +
					          CANADIAN SYLLABICS FINAL GRAVE)

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

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

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

참고: 이는 표가 포함 블록을 넘치는 대신 콘텐츠에 하이픈을 넣을 수 있게 하며, 독일어처럼 긴 단어가 많은 언어에서 특히 중요하다.

이름: hyphens
값: none | manual | auto
초기값: manual
적용 대상: text
상속: yes
백분율: n/a
계산값: 지정된 키워드
정규 순서: n/a
애니메이션 유형: discrete

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

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

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

manual
단어 안에 하이픈 넣기 기회를 명시적으로 제안하는 문자가 있는 곳에서만 단어에 하이픈을 넣는다. UA는 적절한 언어별 하이픈 넣기 문자를 사용해야 하며, 같은 지점에서 자동 하이픈 넣기를 할 때와 마찬가지로 적절한 철자 변경을 적용해야 한다.
Unicode에서 U+00AD는 조건부 "소프트 하이픈"이고 U+2010은 무조건 하이픈이다. Unicode Standard Annex #14는 Unicode 줄 나누기에서 소프트 하이픈의 역할을 설명한다. [UAX14] HTML에서 &shy;는 하이픈 넣기 기회를 제안하는 소프트 하이픈 문자를 나타낸다.
ex&shy;ample
auto
단어는 조건부 하이픈으로 명시적으로 표시된 기회에 더해, 언어에 적합한 하이픈 넣기 자원이 자동으로 결정한 하이픈 넣기 기회에서 나뉠 수 있다. 단어에 조건부 하이픈 (&shy; 또는 U+00AD SOFT HYPHEN)이 포함되어 있으면, 단어 내부 다른 곳의 자동 하이픈 넣기 기회는 조건부 하이픈을 우선하기 위해 무시되어야 한다. 그러나 그러한 기회에서 나누더라도 그 단어의 일부가 여전히 한 줄에 맞기에는 너무 길다면, 자동 하이픈 넣기 기회를 사용할 수 있다.

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

작성자는 올바른 자동 하이픈 넣기를 얻기 위해 콘텐츠의 언어를 올바르게 태그 지정해야 한다 (예: HTML lang 속성 또는 XML xml:lang 속성 사용).

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

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

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

참고: 아랍어 같은 셰이핑 문자 체계가 하이픈 넣기 때문에 단어 안에서 나뉘도록 허용될 때, 문자는 여전히 단어가 나뉘지 않은 것처럼 셰이핑된다.

예를 들어, 위구르어 단어 “داميدى”에 하이픈 넣기가 적용되면, 다음과 같이 표시되어야 하며 [독립형 DAL + 독립형 ALEF + 초성 MEEM +
		          중성 YEH + 하이픈 + 줄 나누기 + 종성 DAL +
		          독립형 ALEF MAKSURA] 다음과 같이 표시되어서는 안 된다 [독립형 DAL + 독립형 ALEF + 초성 MEEM +
		          종성 YEH + 하이픈 + 줄 나누기 + 독립형 DAL +
		          독립형 ALEF MAKSURA] .

5.4. 넘침 줄바꿈: overflow-wrap (word-wrap) 속성

이름: overflow-wrap
값: normal | break-word | anywhere
초기값: normal
적용 대상: text
상속: yes
백분율: n/a
계산값: 지정된 키워드
정규 순서: n/a
애니메이션 유형: discrete

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

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

레거시 이유로, UA는 word-wrapoverflow-wrap 속성의 레거시 이름 별칭으로 취급해야 한다.

5.5. 줄 나누기 세부사항

줄 나누기를 결정할 때:

6. 정렬과 양쪽 맞춤

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

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

이름: text-align
값: start | end | left | right | center | justify | match-parent | justify-all
초기값: start
적용 대상: 블록 컨테이너
상속: yes
백분율: 개별 속성 참조
계산값: 개별 속성 참조
애니메이션 유형: discrete
정규 순서: n/a

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

값은 다음 의미를 가진다:

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-alltext-align-last 모두를 justify로 설정하여, 마지막 줄도 양쪽 맞춤되도록 강제한다.
match-parent
이 값은 inherit과 동일하게 동작한다 (부모의 계산값으로 계산됨). 다만 start 또는 end라는 상속된 값은 부모의 direction 값에 대해 해석되어, left 또는 right 중 하나의 계산값이 된다. 루트 요소에 지정된 경우에는 start로 계산된다.

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

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

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

(양쪽 맞춤이 있다면 그 이후) 라인 박스의 인라인 콘텐츠가 너무 길어 그 안에 맞지 않으면, 그 콘텐츠는 start 정렬된다: 맞지 않는 모든 콘텐츠는 라인 박스의 가장자리 밖으로 넘친다.

라인 박스의 시작 가장자리를 결정하는 방법에 대한 자세한 내용은 § 8.3 양방향성과 라인 박스를 보라.

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

이름: text-align-all
값: start | end | left | right | center | justify | match-parent
초기값: start
적용 대상: 블록 컨테이너
상속: yes
백분율: n/a
계산값: 지정된 키워드. 단 match-parent는 위에 정의된 대로 계산됨
정규 순서: n/a
애니메이션 유형: discrete

text-align 단축 속성의 이 롱핸드는 text-align-lastauto가 아닌 값으로 덮어쓴 마지막 줄을 제외하고, 블록 컨테이너 안의 인라인 콘텐츠 모든 줄의 인라인 정렬을 지정한다. 값에 대한 전체 설명은 text-align을 보라.

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

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

이름: text-align-last
값: auto | start | end | left | right | center | justify | match-parent
초기값: auto
적용 대상: 블록 컨테이너
상속: yes
백분율: n/a
계산값: 지정된 키워드. 단 match-parent는 위에 정의된 대로 계산됨
정규 순서: n/a
애니메이션 유형: discrete

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

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

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

이름: text-justify
값: auto | none | inter-word | inter-character
초기값: auto
적용 대상: text
상속: yes
백분율: n/a
계산값: 지정된 키워드(distribute 레거시 값 제외)
정규 순서: n/a
애니메이션 유형: discrete

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

auto
UA는 성능과 적절한 표현 품질 사이의 균형에 따라 따를 양쪽 맞춤 알고리즘을 결정한다. 양쪽 맞춤 규칙은 문자 체계언어에 따라 다르므로, UA는 가능한 경우 텍스트에 적합한 양쪽 맞춤 알고리즘을 사용해야 한다.
예를 들어, UA는 기본적으로 모든 문자 체계에 대한 단순한 범용 절충 양쪽 맞춤 방식을 사용할 수 있다—​예컨대 주로 단어 구분자와 CJK 조판 글자 단위 사이를 확장하고, 부차적으로 동남아시아 조판 글자 단위 사이를 확장하는 방식이다. 그런 다음 문단의 콘텐츠 언어가 알려진 경우에는, 더 언어 맞춤형인 양쪽 맞춤 동작을 선택할 수 있다. 예를 들어 일본어에는 Requirements for Japanese Text Layout [JLREQ]을 따르고, 아랍어에는 필기체 늘이기를 사용하며, 독일어에는 inter-word를 사용하는 식이다.

압축된 형태와 장식적 형태의 조합 덕분에
				          두 줄의 서예적 아랍어가 함께 끝난다

Tasmeem으로 렌더링된, 필기체 방식으로 양쪽 맞춤된 아랍어 텍스트의 예. 영어처럼, 아랍어도 단어 사이의 간격을 조정하여 양쪽 맞춤할 수 있지만, 대부분의 스타일에서는 글자꼴 자체를 서예적으로 늘이거나 압축하여 양쪽 맞춤할 수도 있다. 이 예에서, 위쪽 텍스트는 늘어난(kashida) 형태와 장식적 형태를 사용하여 줄을 채우도록 확장되며, 아래쪽 줄은 ت와 م 사이의 문자에 대해 쌓인 조합을 사용하여 약간 압축된다. 전통적 서예 기법을 사용함으로써, 조판자는 흐름과 색을 보존하면서 줄을 양쪽 맞춤할 수 있으며, 매우 높은 품질의 양쪽 맞춤 효과를 제공한다. 그러나 이는 본질적으로 매우 문자 체계별인 효과이다.
추가 공간이 일부는 공백에, 일부는 CJK 및 태국어 글자 사이에 배분된다.
text-justify: auto가 적용된 혼합 문자 텍스트: 이 해석은 범용 절충 양쪽 맞춤 방식을 사용하여, 공백뿐 아니라 CJK 및 동남아시아 글자 사이도 확장한다. 이는 단어 구분자 및/또는 CJK 문자가 있는 줄에는 inter-word + inter-ideograph 간격을 효과적으로 사용하고, 그렇지 않은 줄이나 공백이 너무 많이 늘어나는 줄에는 inter-cluster 동작으로 폴백한다.
none
양쪽 맞춤이 비활성화된다: 텍스트 안에는 양쪽 맞춤 기회가 없다.
추가 공간이 삽입되지 않는다.
text-justify: none이 적용된 혼합 문자 텍스트

참고: 이 값은 사용자 스타일시트에서 가독성을 개선하거나 접근성 목적을 위해 사용하도록 의도되었다.

inter-word
양쪽 맞춤은 단어 구분자에서만 간격을 조정한다 (실질적으로 해당 줄에서 사용되는 word-spacing을 변화시킨다). 이 동작은 영어나 한국어처럼 공백을 사용하여 단어를 구분하는 언어에서 일반적이다.
추가 공간이 주로 공백에 균등하게 분배된다.
text-justify: inter-word가 적용된 혼합 문자 텍스트
inter-character
양쪽 맞춤은 인접한 각 조판 문자 단위 쌍 사이의 간격을 조정한다 (실질적으로 해당 줄에서 사용되는 letter-spacing을 변화시킨다). 이 값은 일본어 같은 동아시아 체계에서 때때로 사용된다.
추가 공간이 모든 문자 체계의 공백과 글자 사이 지점에
				          균등하게 분배된다.
text-justify: inter-character가 적용된 혼합 문자 텍스트

레거시 이유로, UA는 대체 키워드 distribute도 지원해야 하며, 이는 inter-character로 계산되어 정확히 같은 의미와 동작을 가져야 한다. UA는 이를 레거시 값 별칭으로 취급할 수 있다.

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

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

6.4.1. 텍스트 확장과 압축

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

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

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

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

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

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

6.4.2. 기호와 문장부호 처리

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

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

예를 들어, 전통적으로 연속된 U+2014 — EM DASH, U+2015 ― HORIZONTAL BAR, U+2026 … HORIZONTAL ELLIPSIS, 또는 U+2025 ‥ TWO DOT LEADER 문자 사이에는 양쪽 맞춤 기회가 없다 [JLREQ]; 따라서 UA는 이러한 문자를 “never” 우선순위 수준에 할당할 수 있다. 또 다른 예로, 특정 전각 문장부호 문자 (예: U+301A 〚 LEFT WHITE SQUARE BRACKET)는 일본어에서 내부에 양쪽 맞춤 기회를 포함하는 것으로 간주된다. 따라서 UA는 이러한 문자를 표의 문자 사이의 기회보다 더 높은 우선순위 수준에 할당할 수 있다.

6.4.3. 확장할 수 없는 텍스트

줄의 인라인 콘텐츠를 라인 박스의 전체 너비까지 늘릴 수 없으면, 해당 콘텐츠는 text-align-last 속성이 지정한 대로 정렬되어야 한다. (text-align-lastjustify이면, center처럼 정렬되어야 한다.)

6.4.4. 필기체 문자

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

다음은 허용되지 않는 양쪽 맞춤의 예이다:
모든 아랍어 글자 쌍 사이에 틈 추가
결합되지 않은 모든 아랍어 글자 쌍 사이에 틈 추가

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

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

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

텍스트 양쪽 맞춤에 대한 자세한 정보는 “Approaches to Full Justification”에서 찾거나 제출할 수 있으며, 이는 문자 체계와 언어별로 색인화되어 있고 W3C Internationalization Working Group이 유지 관리한다. [JUSTIFY]

7. 간격

CSS는 word-spacingletter-spacing 속성을 통해 텍스트 간격을 제어할 수 있게 한다. 이 속성들은 각각 단어 구분자 주변 또는 조판 문자 단위 사이의 추가 공간을 지정한다.

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

이름: word-spacing
값: normal | <length>
초기값: normal
적용 대상: text
상속: yes
백분율: N/A
계산값: 절대 길이
정규 순서: n/a
애니메이션 유형: 계산값 유형에 따름

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

normal
추가 간격이 적용되지 않는다. 0으로 계산된다.
<length>
글꼴이 정의하는 고유한 단어 간 간격에 더하여 추가 간격을 지정한다.

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

단어 구분자 문자는 주된 목적과 일반적 사용이 단어를 분리하는 데 있는 조판 문자 단위이다. Unicode에서는 여기에 공백(U+0020), 줄 바꿈 없는 공백(U+00A0), 에티오피아 단어 공백(U+1361), 에게해 단어 구분자(U+10100,U+10101), 우가리트어 단어 구분자(U+1039F), 그리고 페니키아어 단어 구분자(U+1091F)가 포함된다(하지만 이것이 전부로 정의되는 것은 아니다). [UNICODE]

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

단어 구분자 문자가 없거나, 단어를 분리하는 문자의 선행 폭이 0인 경우 (예: U+200B ZERO WIDTH SPACE) 사용자 에이전트는 단어 사이에 추가 간격을 만들어서는 안 된다.

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

이름: letter-spacing
값: normal | <length>
초기값: normal
적용 대상: 인라인 박스 및 text
상속: yes
백분율: n/a
계산값: 절대 길이
정규 순서: n/a
애니메이션 유형: 계산값 유형에 따름

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

값은 다음 의미를 가진다:

normal
추가 간격이 적용되지 않는다. 0으로 계산된다.
<length>
조판 문자 단위 사이의 추가 간격을 지정한다. 값은 음수일 수 있지만, 구현에 따라 제한이 있을 수 있다.

레거시 이유로, 0으로 계산된 letter-spacing해결값 (getComputedStyle() 반환값)으로 normal을 산출한다.

letter-spacing의 목적상, 원자적 인라인 (이미지 및 인라인 블록 등)의 각 연속 런은 하나의 조판 문자 단위로 취급된다.

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

줄의 시작이나 끝에 letter-spacing이 적용되지 않으면, 텍스트는 항상 블록의 가장자리에 딱 맞게 들어간다.
p { letter-spacing: 1em; }
<p>abc</p>

a b c

a b c

따라서 UA는 줄의 오른쪽 또는 뒤쪽 가장자리에 letter spacing을 덧붙이는 것을 정말 피해야 한다 [RFC6919]:

a b c 

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

참고: 이 보조 동작은 웹 호환성 문제 때문에 이 레벨에서 허용된다.

인라인 박스는 그 요소 안에 완전히 포함된 문자들 사이의 letter spacing만 포함할 것으로 기대된다. 따라서 요소의 오른쪽 또는 뒤쪽 가장자리의 letter spacing은 제외된다:
p { letter-spacing: 1em; }
<p>a<span>bb</span>c</p>

a b b c

a b b c

따라서 letter-spacing의 주어진 값은 그 값이 지정된 요소 안에 완전히 포함된 문자들 사이의 간격에만 영향을 줄 것으로 기대된다:

p    { letter-spacing: 1em; }
span { letter-spacing: 2em; }
<p>a<span>bb</span>c</p>

a b  b c

이는 더 나아가, 단일 문자만 포함하는 요소에 letter-spacing을 적용해도 렌더링 결과에는 영향을 주지 않음을 뜻한다:

p    { letter-spacing: 1em; }
span { letter-spacing: 2em; }
<p>a<span>b</span>c</p>

a b c

letter spacing은 RTL 재정렬 이후 삽입되므로, 아래 내부 span에 적용된 letter spacing 역시 효과가 없다. 재정렬 이후 "c"가 "א" 옆에 놓이지 않기 때문이다:

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></span>בג</p>

a b c א ב ג

Letter spacing은 보이지 않는 제로 폭 서식 문자 (Unicode Cf 범주의 문자 등)를 무시한다. 그러한 문자가 문서에 없는 것처럼 간격을 추가해야 한다.

예를 들어 A&#x200B;B에 적용된 letter-spacing은 요소 경계가 어디에 있든 AB와 동일하다.

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

예를 들어 “filial”이라는 단어에 letter spacing이 적용되면, “fi” 합자는 사용해서는 안 된다. 이는 텍스트의 균등한 간격을 방해하기 때문이다.
filial vs filial

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

7.2.1. 필기체 문자

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

아래는 아랍어 텍스트에 간격을 적용하는 적절한 예와 부적절한 예이다.
원본 텍스트
나쁨 각 글자 사이에 공간을 균등하게 분배. 이것이 필기체 결합을 끊는다는 점에 유의하라!
좋음 letter-spacing을 조판상 적절한 필기체 늘이기로 분배. 그 결과 텍스트는 앞의 균등 간격 예와 같은 길이가 된다.
좋음 아랍어 글자 사이의 letter-spacing 억제. 그럼에도 letter-spacing은 아랍어가 아닌 문자(예: 공백)에는 적용됨에 유의하라.
나쁨 결합되지 않은 글자 사이에만 letter-spacing 적용. 이는 조판 색을 왜곡하고 단어 경계를 흐린다.

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

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

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

서식에 효과적인 변화가 없거나, 유일한 서식 변화가 글리프에 영향을 주지 않는 경우 (텍스트 장식 적용처럼), 텍스트 셰이핑은 인라인 박스 경계를 가로질러 끊어져서는 안 된다.

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

경계를 가로지르는 합리적이고 가능한 셰이핑의 예는 아랍어 셰이핑이다: 많은 시스템에서 이는 글꼴 엔진이 수행하며, 글꼴이 잠재적으로 매우 정교한 문맥 셰이핑을 가진 변형 글리프를 제공할 수 있게 한다. 글꼴 엔진에 문맥을 제공하는 API가 없는 한 글꼴 변경을 가로질러 이 시스템에 의존하는 것은 일반적으로 불가능하지만, 엔진이 예를 들어 제로 폭 결합자(U+200D) 또는 제로 폭 비결합자(U+200C)를 적절히 사용하여 초성/중성/종성/독립형 글리프의 올바른 선택을 유도함으로써 이 한계를 우회하는 것은 간단하며 따라서 상당히 합리적이다.

경계를 가로지르는 가능하지만 합리적이지는 않은 셰이핑의 예는 양쪽 20자 문맥에 민감하여 글리프를 선택하는 글꼴을 처리하는 것이다: 해당 문자열 앞 및 뒤의 모든 텍스트를, 서식 변화가 있는 여러 인라인 경계를 지나서까지 전달하는 것은 복잡하다. UA가 그러한 경우를 처리할 수는 있지만, 이는 현대 문자 체계에서 일반적이거나 근본적으로 요구되는 것이 아니므로 필수는 아니다.

경계를 가로지르는 불가능한 셰이핑의 예는 “and”라는 단어 중간에서 글꼴 굵기가 바뀌는 경우로, 그 글꼴에서는 해당 단어의 세 글자 모두가 앰퍼샌드 글리프(“&”)로 대체되는 합자를 이룬다.

8. 가장자리 효과

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

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

이름: text-indent
값: [ <length-percentage> ] && hanging? && each-line?
초기값: 0
적용 대상: 블록 컨테이너
상속: yes
백분율: 블록 컨테이너 자신의 인라인 축 내부 크기를 참조
계산값: 계산된 <length-percentage> 값 및 지정된 모든 키워드
정규 순서: 문법 기준
애니메이션 유형: 계산값 유형에 따름

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

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

값은 다음 의미를 가진다:

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

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

참고: 이는 요소가 넘치게 만들 수 있다. 백분율 들여쓰기와 내재적 크기 조정을 함께 사용하는 것은 권장되지 않는다.

each-line
들여쓰기는 각 블록 컨테이너의 첫 줄과 강제 줄 나누기 뒤의 각 줄에 영향을 준다 (하지만 소프트 줄바꿈 나누기 뒤의 줄에는 영향을 주지 않는다).
hanging
어떤 줄이 영향을 받는지를 반전한다.

왼쪽에서 오른쪽으로 쓰는 텍스트에서 float가 없고, text-alignstart이며 text-indent5em이라면, 텍스트의 첫 줄은 블록 안쪽으로 5em 들어간 지점에서 시작한다:

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

hanging 키워드를 추가하면, 첫 줄은 가장자리에 맞춰 시작하지만, 다른 줄은 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'.
text-indent 속성은 “첫 번째 서식 지정된 줄”에만 영향을 주므로, 강제 나누기 뒤의 줄은 들여쓰기되지 않는다.
   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).

그러나 때때로(시나 코드에서처럼), 줄바꿈될 만큼 긴 각 줄을 들여쓰기하는 것이 적절하다. 다음 예에서 text-indent에는 3em hanging each-line 값이 주어져, 시의 세 번째 줄이 블록의 오른쪽 경계에서 소프트 줄바꿈될 때 내어쓰기를 만든다:

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 요소에 영향을 준다. 이 때문에 display: inline-block으로 지정된 요소에는 text-indent: 0을 지정하는 것이 대체로 현명하다.

8.2. 행잉 글리프

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

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

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

행잉될 수 있는 글리프와 줄 가장자리 사이에 0이 아닌 인라인 축 테두리 또는 패딩이 있으면 그 글리프는 행잉되지 않는다. 예를 들어 끝 패딩이 있는 인라인 박스 끝의 마침표는 줄의 끝 가장자리에서 행잉되지 않는다.

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

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

이름: hanging-punctuation
값: none | [ first || [ force-end | allow-end ] || last ]
초기값: none
적용 대상: text
상속: yes
백분율: n/a
계산값: 지정된 키워드
정규 순서: 문법 기준
애니메이션 유형: discrete

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

참고: 블록 컨테이너에 충분한 패딩이 없으면, hanging-punctuation이 넘침을 유발할 수 있다.

값은 다음 의미를 가진다:

none
어떤 문장부호 문자도 행잉되게 하지 않는다.
first
요소의 첫 번째 서식 지정된 줄 시작에 있는 여는 괄호, 따옴표, 또는 표의 문자 공백이 행잉된다. 이는 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
줄 끝의 마침표류 또는 쉼표행잉된다.
allow-end
줄 끝의 마침표류 또는 쉼표조건부로 행잉된다.

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

마침표류 및 쉼표행잉이 허용되는 것은 다음을 포함한다:

U+002C , COMMA
U+002E . FULL STOP
U+060C ، ARABIC COMMA
U+06D4 ۔ ARABIC FULL STOP
U+3001 IDEOGRAPHIC COMMA
U+3002 IDEOGRAPHIC FULL STOP
U+FF0C FULLWIDTH COMMA
U+FF0E FULLWIDTH FULL STOP
U+FE50 SMALL COMMA
U+FE51 SMALL IDEOGRAPHIC COMMA
U+FE52 SMALL FULL STOP
U+FF61 HALFWIDTH IDEOGRAPHIC FULL STOP
U+FF64 HALFWIDTH IDEOGRAPHIC COMMA

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

참고: CSS Working Group은 다른 문자를 포함하는 UA가 그러한 추가 사항을 워킹 그룹에 알려주면 감사할 것이다.

allow-endforce-end는 동아시아에서 사용되는 행잉 문장부호의 두 변형이다.
hanging-punctuation: allow-end
p {
  text-align: justify;
  hanging-punctuation: allow-end;
}
hanging-punctuation: force-end
p {
  text-align: justify;
  hanging-punctuation: force-end;
}

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

8.3. 양방향성과 라인 박스

라인 박스의 시작 쪽은 라인 박스의 인라인 기본 방향에 의해 결정된다. 보통은 일치하지만, 라인 박스인라인 기본 방향포함 블록 또는 양방향 문단인라인 기본 방향과는 구별된다. 라인 박스인라인 기본 방향text-align-all, text-align-last, text-indent, 및 hanging-punctuation—​즉 가장자리에 대한 콘텐츠의 위치와 정렬—​에 영향을 준다. 이는 인라인 콘텐츠의 서식 지정이나 순서에는 영향을 주지 않는다 (이는 Unicode Bidirectional AlgorithmCSS Writing Modes에 의해 적용되는 방식으로 제어된다 [UAX9] [CSS-WRITING-MODES-4]).

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

다음 예에서, <block>이 시작 정렬된 사전 서식 블록 (display: block; white-space: pre; text-align: start)이라고 가정하면, 한 줄 걸러 오른쪽 정렬된다:
<block style="unicode-bidi: plaintext">
français
فارسی
français
فارسی
français
فارسی
</block>
중립 문자(문장부호 등)와 격리된 런은 plaintext 양방향 문단의 인라인 기본 방향을 찾을 때 건너뛰어지므로, 다음 예의 라인 박스는 첫 번째 강한 문자 ‘h’가 지시하는 대로 왼쪽에서 오른쪽이 된다 (따라서 text-align: start가 주어지면 왼쪽 정렬된다):
<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>

unicode-bidi: plaintext 때문에, “Hello!”는 LTR로 조판된다 (즉 느낌표가 오른쪽에 위치한다) 그리고 왼쪽 정렬되며, 포함 블록의 RTL direction을 무시한다. 이로 인해 그 뒤의 빈 줄도 LTR이 되며, 이는 그 줄의 캐럿이 왼쪽 가장자리에 나타나야 함을 뜻한다. 그러나 비어 있는 첫 줄은 오른쪽 정렬된다: 앞선 줄이 없으므로, 포함 블록의 RTL 방향을 가정하기 때문이다.

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

이 부록은 규범적이다.

다음 목록은 텍스트 작업의 순서를 정의한다. (구현은 결과 레이아웃이 동일한 한 이 순서에 구속되지 않는다.)

  1. 공백 처리 1부(줄바꿈 전)
  2. 텍스트 변환
  3. 텍스트 결합 [CSS-WRITING-MODES-4]
  4. 텍스트 방향 지정 [CSS-WRITING-MODES-4]
  5. 줄마다 다음을 적용하면서 텍스트 줄바꿈:
  6. 양쪽 맞춤 (이는 글리프 선택 및/또는 텍스트 줄바꿈에 영향을 줄 수 있어, 그 단계로 되돌아갈 수 있다)
  7. 텍스트 정렬

부록 B: 일반 텍스트로 변환

이 부록은 일반 텍스트 복사-붙여넣기 작업의 목적상 규범적이다.

CSS로 렌더링된 문서가 일반 텍스트 형식으로 변환될 때, 다음이 기대된다:

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

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

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

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

부록 D: 문자 체계와 간격

이 부록은 규범적이다.

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

블록 문자
CJK 및 확장하여 모든 Wide 문자 (East Asian Width [UAX11] 참조). 다음 Unicode 스크립트가 포함된다: Bopomofo, Han, Hangul, Hiragana, Katakana, and Yi. East Asian Width 속성의 문자 중 WideFullwidth도 포함되지만, 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

참고: 기준선 연결이 있는 인도계 문자 (예: Devanagari 및 Gujarati)는 필기체 문자로 간주되지 않으며, 조판 문자 단위 사이의 그러한 틈을 허용한다. Indic Layout Requirements를 보라. [ILREQ]

사용자 에이전트는 Unicode 지원을 갱신할 때 향후 Unicode 버전에서 아직 인코딩되지 않은 필기체 문자를 처리하도록 이 목록을 갱신해야 하며, CSSWG에 이 명세도 그에 맞게 갱신하도록 요청하는 것이 권장된다.

부록 E: 문자와 속성

이 부록은 규범적이다.

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

East Asian width 속성
Unicode Standard Annex #11 [UAX11]에 정의되며, Unicode Character Database [UAX44]에서 East_Asian_Width 속성으로 제공된다.
일반 범주
Unicode Standard Annex #44 [UAX44]에 정의되며, Unicode Character Database [UAX44]에서 General_Category 속성으로 제공된다.
script 속성
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의 목적상, 조판 문자 단위의 속성은 그 첫 번째 그래핌 클러스터의 기본 문자에 의해 주어진다—​두 경우는 예외이다:

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

이 부록은 규범적이다.

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

HTML 또는 문서 언어콘텐츠 언어를 선언하기 위해 언어 식별에 BCP47 태그를 사용하는 모든 언어에서, 작성자는 script 하위 태그를 사용하여 비전형적인 문자 체계의 사용을 명확히 하거나 표시할 수 있다. [BCP47] 예를 들어, 본래 라틴 문자를 사용하지 않는 언어에 대해 라틴 문자 체계의 사용을 표시하려면 -Latn script 하위 태그를 추가할 수 있다. 예: 일본어 로마자 표기의 ja-Latn. 다른 문자 체계에는 다른 하위 태그가 존재하며, ISO의 Code for the Representation of Names of ScriptsISO15924 script tag registry를 보라. [ISO15924]

script 하위 태그가 있는 BCP47 태그 사용의 일반적/역사적 예:
zh-Latn
라틴 전사로 쓰인 중국어.
ko-Hani
한자(중국 표의문자)로 쓰인 한국어.
tr-Arab
아랍 문자로 쓰인 터키어.
mn-Cyrl
키릴 문자로 쓰인 몽골어.
mn-Mong
전통 몽골 문자로 쓰인 몽골어.

그러나 BCP47 script 하위 태그는 단일 문자 체계와 강하게 연결된 언어에는 일반적으로 사용되지 않으며 (사실 권장되지도 않는다); 대신 다른 것이 지정되지 않으면 그 문자 체계가 암시되는 것으로 기대된다. [BCP47] IANA는 이를 위해 language subtag registrySuppress-Script 필드를 통해 여러 언어의 가장 일반적인 문자 체계 데이터베이스를 유지한다.

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

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

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

부록 G: 작은 가나 매핑

이 부록은 규범적이다.

작은 가나에서 전체 크기 가나로의 매핑
작은 전체 크기
ぁ U+3041 あ U+3042
ぃ U+3043 い U+3044
ぅ U+3045 う U+3046
ぇ U+3047 え U+3048
ぉ U+3049 お U+304A
ゕ U+3095 か U+304B
ゖ U+3096 け U+3051
𛄲 U+1B132 こ U+3053
っ U+3063 つ U+3064
ゃ U+3083 や U+3084
ゅ U+3085 ゆ U+3086
ょ U+3087 よ U+3088
ゎ U+308E わ U+308F
𛅐 U+1B150 ゐ U+3090
𛅑 U+1B151 ゑ U+3091
𛅒 U+1B152 を U+3092
ァ U+30A1 ア U+30A2
ィ U+30A3 イ U+30A4
ゥ U+30A5 ウ U+30A6
ェ U+30A7 エ U+30A8
ォ U+30A9 オ U+30AA
ヵ U+30F5 カ U+30AB
ㇰ U+31F0 ク U+30AF
ヶ U+30F6 ケ U+30B1
𛅕 U+1B155 コ U+30B3
ㇱ U+31F1 シ U+30B7
ㇲ U+31F2 ス U+30B9
ッ U+30C3 ツ U+30C4
ㇳ U+31F3 ト U+30C8
ㇴ U+31F4 ヌ U+30CC
ㇵ U+31F5 ハ U+30CF
ㇶ U+31F6 ヒ U+30D2
ㇷ U+31F7 フ U+30D5
ㇸ U+31F8 ヘ U+30D8
ㇹ U+31F9 ホ U+30DB
ㇺ U+31FA ム U+30E0
ャ U+30E3 ヤ U+30E4
ュ U+30E5 ユ U+30E6
ョ U+30E7 ヨ U+30E8
ㇻ U+31FB ラ U+30E9
ㇼ U+31FC リ U+30EA
ㇽ U+31FD ル U+30EB
ㇾ U+31FE レ U+30EC
ㇿ U+31FF ロ U+30ED
ヮ U+30EE ワ U+30EF
𛅤 U+1B164 ヰ U+30F0
𛅥 U+1B165 ヱ U+30F1
𛅦 U+1B166 ヲ U+30F2
𛅧 U+1B167 ン U+30F3
ァ U+FF67 ア U+FF71
ィ U+FF68 イ U+FF72
ゥ U+FF69 ウ U+FF73
ェ U+FF6A エ U+FF74
ォ U+FF6B オ U+FF75
ッ U+FF6F ツ U+FF82
ャ U+FF6C ヤ U+FF94
ュ U+FF6D ユ U+FF95
ョ U+FF6E ヨ U+FF96

개인정보 보호 고려사항

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

보안 고려사항

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

감사의 말

이 명세는 다음 사람들의 도움 없이는 가능하지 않았을 것이다: 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.

변경 사항

최근 변경 사항

다음 변경 사항은 2024년 9월 후보 권고안 초안 이후에 이루어졌다:

다음 규범적 변경 사항은 2023년 9월 후보 권고안 초안 이후에 이루어졌다:

다음 규범적 변경 사항은 2023년 2월 후보 권고안 초안 이후에 이루어졌다.

다음 규범적 변경 사항은 2020년 12월 후보 권고안 이후에 이루어졌다.

그 밖에도 몇 가지 사소한 편집상 수정이 있었다.

이전 변경 사항

또한 해당 후보 권고안 이전의 2020년 및 2019년 작업 초안을 다루는 이전 변경 사항 목록과, 2013년부터 2020년 사이의 모든 의견을 다루는 의견 처리 결과도 보라.

적합성

문서 규칙

적합성 요구사항은 설명적 주장과 RFC 2119 용어의 조합으로 표현된다. 이 문서의 규범적 부분에서 핵심어 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”은 RFC 2119에 설명된 대로 해석되어야 한다. 그러나 가독성을 위해, 이 명세에서는 이 단어들이 모두 대문자로 나타나지는 않는다.

명시적으로 비규범적이라고 표시된 절, 예제, 참고를 제외하고 이 명세의 모든 텍스트는 규범적이다. [RFC2119]

이 명세의 예제는 “예를 들어”라는 말로 소개되거나 다음과 같이 class="example"으로 규범적 텍스트와 분리된다:

이것은 정보 제공용 예제의 예이다.

정보 제공용 참고는 “참고”라는 말로 시작하며 다음과 같이 class="note"로 규범적 텍스트와 분리된다:

참고, 이것은 정보 제공용 참고이다.

권고문은 특별한 주의를 환기하도록 스타일링된 규범적 절이며 다음과 같이 <strong class="advisement">으로 다른 규범적 텍스트와 분리된다: UA는 접근 가능한 대안을 제공해야 한다.

적합성 클래스

이 명세에 대한 적합성은 세 가지 적합성 클래스에 대해 정의된다:

스타일시트
CSS 스타일시트.
렌더러
스타일시트의 의미론을 해석하고 그것을 사용하는 문서를 렌더링하는 UA.
작성 도구
스타일시트를 작성하는 UA.

스타일시트는 이 모듈에서 정의된 구문을 사용하는 모든 문장이 일반 CSS 문법 및 이 모듈에서 정의된 각 기능의 개별 문법에 따라 유효하다면 이 명세에 적합하다.

렌더러는 적절한 명세에서 정의한 대로 스타일시트를 해석하는 것에 더해, 이 명세에서 정의한 모든 기능을 올바르게 파싱하고 그에 따라 문서를 렌더링함으로써 지원한다면 이 명세에 적합하다. 그러나 장치의 한계 때문에 UA가 문서를 올바르게 렌더링할 수 없다는 사실이 그 UA를 부적합하게 만들지는 않는다. (예를 들어, UA가 흑백 모니터에서 색을 렌더링할 필요는 없다.)

작성 도구는 이 모듈에서 설명된 대로 일반 CSS 문법과 이 모듈의 각 기능의 개별 문법에 따라 구문적으로 올바르고 스타일시트의 다른 모든 적합성 요구사항을 충족하는 스타일시트를 작성한다면 이 명세에 적합하다.

부분 구현

작성자가 전방 호환 파싱 규칙을 활용하여 폴백 값을 지정할 수 있도록, CSS 렌더러는 사용 가능한 수준의 지원이 없는 모든 @-규칙, 속성, 속성 값, 키워드, 및 기타 구문 구성물을 무효로 취급하고 (적절히 무시)해야 한다. 특히 사용자 에이전트는 하나의 다중 값 속성 선언 안에서 지원되지 않는 구성 값은 선택적으로 무시하고 지원되는 값은 존중해서는 안 된다: 어떤 값이든 무효로 간주되면(지원되지 않는 값은 그렇게 간주되어야 하므로), CSS는 전체 선언이 무시되어야 한다고 요구한다.

불안정 및 독점 기능의 구현

향후 안정적인 CSS 기능과의 충돌을 피하기 위해, CSSWG는 CSS의 불안정 기능 및 독점 확장 구현에 대해 모범 사례를 따를 것을 권장한다.

비실험적 구현

명세가 후보 권고안 단계에 도달하면, 비실험적 구현이 가능하며, 구현자는 명세에 따라 올바르게 구현되었음을 입증할 수 있는 모든 CR 수준 기능에 대해 접두사가 없는 구현을 배포해야 한다.

구현 전반에서 CSS의 상호운용성을 확립하고 유지하기 위해, CSS Working Group은 비실험적 CSS 렌더러가 CSS 기능의 접두사 없는 구현을 배포하기 전에 구현 보고서(필요한 경우 해당 구현 보고서에 사용된 테스트 케이스도)를 W3C에 제출할 것을 요청한다. W3C에 제출된 테스트 케이스는 CSS Working Group의 검토와 수정을 거친다.

테스트 케이스와 구현 보고서를 제출하는 방법에 대한 추가 정보는 CSS Working Group의 웹사이트 https://www.w3.org/Style/CSS/Test/에서 찾을 수 있다. 질문은 public-css-testsuite@w3.org 메일링 리스트로 보내야 한다.

CR 종료 기준

이 명세가 제안 권고안으로 진행되려면, 각 기능에 대해 적어도 두 개의 독립적이고 상호운용 가능한 구현이 있어야 한다. 각 기능은 서로 다른 제품 집합에 의해 구현될 수 있으며, 모든 기능이 단일 제품에 의해 구현되어야 한다는 요구사항은 없다. 이 기준의 목적상, 다음 용어를 정의한다:

독립적
각 구현은 서로 다른 당사자에 의해 개발되어야 하며, 다른 적격 구현에서 사용된 코드를 공유하거나, 재사용하거나, 그로부터 파생될 수 없다. 이 명세의 구현과 관련이 없는 코드 부분은 이 요구사항에서 제외된다.
상호운용 가능
공식 CSS 테스트 모음의 해당 테스트 케이스를 통과하거나, 구현이 웹 브라우저가 아닌 경우 동등한 테스트를 통과하는 것. 그러한 사용자 에이전트(UA)가 상호운용성을 주장하는 데 사용되려면, 테스트 모음의 모든 관련 테스트에 대해 동등한 테스트가 만들어져야 한다. 또한 그러한 UA가 상호운용성을 주장하는 데 사용되려면, 상호운용성의 목적상 같은 방식으로 그 동등한 테스트를 통과할 수 있는 하나 이상의 추가 UA가 있어야 한다. 동등한 테스트는 동료 검토를 위해 공개적으로 이용 가능해야 한다.
구현
다음에 해당하는 사용자 에이전트:
  1. 명세를 구현한다.
  2. 일반 대중이 이용할 수 있다. 구현은 출시 제품이거나 다른 공개적으로 이용 가능한 버전 (즉, 베타 버전, 미리보기 릴리스, 또는 "nightly build")일 수 있다. 출시되지 않은 제품 릴리스는 안정성을 입증하기 위해 최소 한 달 동안 해당 기능을 구현하고 있어야 한다.
  3. 실험적이지 않다(즉, 테스트 모음을 통과하기 위해 특별히 설계된 버전이며 앞으로의 정상 사용을 의도하지 않는 버전이 아니다).

이 명세는 적어도 6개월 동안 후보 권고안으로 남는다.

색인

이 명세에서 정의된 용어

참조로 정의된 용어

참고문헌

규범적 참고문헌

[CSS-BACKGROUNDS-3]
Elika Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 2024년 3월 11일. CRD. URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS-BOX-4]
Elika Etemad. CSS Box Model Module Level 4. 2024년 8월 4일. WD. URL: https://www.w3.org/TR/css-box-4/
[CSS-CASCADE-5]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 5. 2022년 1월 13일. CR. URL: https://www.w3.org/TR/css-cascade-5/
[CSS-DISPLAY-3]
Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 3. 2023년 3월 30일. CR. URL: https://www.w3.org/TR/css-display-3/
[CSS-DISPLAY-4]
Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 4. 2025년 11월 6일. WD. URL: https://www.w3.org/TR/css-display-4/
[CSS-FONTS-3]
John Daggett; Myles Maxfield; Chris Lilley. CSS Fonts Module Level 3. 2018년 9월 20일. REC. URL: https://www.w3.org/TR/css-fonts-3/
[CSS-FONTS-4]
Chris Lilley. CSS Fonts Module Level 4. 2026년 4월 22일. WD. URL: https://www.w3.org/TR/css-fonts-4/
[CSS-INLINE-3]
Elika Etemad. CSS Inline Layout Module Level 3. 2024년 12월 18일. WD. URL: https://www.w3.org/TR/css-inline-3/
[CSS-OVERFLOW-3]
Elika Etemad; Florian Rivoal. CSS Overflow Module Level 3. 2025년 10월 7일. WD. URL: https://www.w3.org/TR/css-overflow-3/
[CSS-PSEUDO-4]
Elika Etemad; Alan Stearns. CSS Pseudo-Elements Module Level 4. 2025년 6월 27일. WD. URL: https://www.w3.org/TR/css-pseudo-4/
[CSS-RUBY-1]
Elika Etemad; et al. CSS Ruby Annotation Layout Module Level 1. 2022년 12월 31일. WD. URL: https://www.w3.org/TR/css-ruby-1/
[CSS-SIZING-3]
Tab Atkins Jr.; Elika Etemad. CSS Box Sizing Module Level 3. 2021년 12월 17일. WD. URL: https://www.w3.org/TR/css-sizing-3/
[CSS-TEXT-4]
Elika Etemad; et al. CSS Text Module Level 4. 2024년 5월 29일. WD. URL: https://www.w3.org/TR/css-text-4/
[CSS-VALUES-3]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3. 2024년 3월 22일. CRD. URL: https://www.w3.org/TR/css-values-3/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 2024년 3월 12일. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS-WRITING-MODES-3]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 3. 2019년 12월 10일. REC. URL: https://www.w3.org/TR/css-writing-modes-3/
[CSS-WRITING-MODES-4]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 4. 2019년 7월 30일. CR. URL: https://www.w3.org/TR/css-writing-modes-4/
[CSS2]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 2011년 6월 7일. REC. URL: https://www.w3.org/TR/CSS2/
[CSSOM-1]
Daniel Glazman; Emilio Cobos Álvarez. CSS Object Model (CSSOM). 2021년 8월 26일. WD. URL: https://www.w3.org/TR/cssom-1/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997년 3월. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[UAX11]
Ken Lunde 小林剣. East Asian Width. 2025년 7월 24일. Unicode Standard Annex #11. URL: https://www.unicode.org/reports/tr11/tr11-44.html
[UAX14]
Robin Leroy. Unicode Line Breaking Algorithm. 2025년 9월 5일. Unicode Standard Annex #14. URL: https://www.unicode.org/reports/tr14/tr14-55.html
[UAX24]
Ken Whistler. Unicode Script Property. 2025년 7월 31일. Unicode Standard Annex #24. URL: https://www.unicode.org/reports/tr24/tr24-39.html
[UAX29]
Josh Hadley. Unicode Text Segmentation. 2025년 8월 17일. Unicode Standard Annex #29. URL: https://www.unicode.org/reports/tr29/tr29-47.html
[UAX44]
Ken Whistler. Unicode Character Database. 2025년 8월 27일. Unicode Standard Annex #44. URL: https://www.unicode.org/reports/tr44/tr44-36.html
[UAX50]
Ken Lunde 小林剣; Koji Ishii 石井宏治. Unicode Vertical Text Layout. 2025년 7월 24일. Unicode Standard Annex #50. URL: https://www.unicode.org/reports/tr50/tr50-33.html
[UAX9]
Manish Goregaokar मनीष गोरेगांवकर; Robin Leroy. Unicode Bidirectional Algorithm. 2025년 8월 13일. Unicode Standard Annex #9. URL: https://www.unicode.org/reports/tr9/tr9-51.html
[UNICODE]
The Unicode Standard. URL: https://www.unicode.org/versions/latest/

비규범적 참고문헌

[BCP47]
A. Phillips, Ed.; M. Davis, Ed.. Tags for Identifying Languages. 2009년 9월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[CLREQ]
Fuqiao Xue; Richard Ishida. Requirements for Chinese Text Layout - 中文排版需求. 2026년 5월 3일. DNOTE. URL: https://www.w3.org/TR/clreq/
[CSS-TEXT-DECOR-3]
Elika Etemad; Koji Ishii. CSS Text Decoration Module Level 3. 2022년 5월 5일. CRD. URL: https://www.w3.org/TR/css-text-decor-3/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[ILREQ]
Swaran Lata. Indic Layout Requirements. 2020년 5월 29일. WD. URL: https://www.w3.org/TR/ilreq/
[ISO15924]
Code for the representation of names of scripts.. 1998년. ISO 15924:1998. Draft International Standard.
[JIS4051]
Formatting rules for Japanese documents (日本語文書の組版方法).. 2004년. JIS X 4051:2004. 일본어.
[JLREQ]
Hiroyuki Chiba; et al. Requirements for Japanese Text Layout 日本語組版処理の要件(日本語版). 2020년 8월 11일. NOTE. URL: https://www.w3.org/TR/jlreq/
[JUSTIFY]
Elika Etemad; Richard Ishida. Approches to Full Justification. URL: https://www.w3.org/International/articles/typography/justification
[RFC6919]
R. Barnes; S. Kent; E. Rescorla. Further Key Words for Use in RFCs to Indicate Requirement Levels. 2013년 4월 1일. Experimental. URL: https://www.rfc-editor.org/rfc/rfc6919
[TYPOGRAPHY]
Richard Ishida. Language enablement index. 2024년 11월 15일. DNOTE. URL: https://www.w3.org/TR/typography/
[XML10]
Tim Bray; et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). 2008년 11월 26일. REC. URL: https://www.w3.org/TR/xml/
[ZHMARK]
General Rules for Punctuation (《标点符号用法》).. 2011년. GB/T 15834―2011. 중국어..

속성 색인

이름 초기값 적용 대상 상속 백분율 애니메이션 유형 정규 순서 계산값
hanging-punctuation none | [ first || [ force-end | allow-end ] || last ] none text yes n/a discrete 문법 기준 지정된 키워드
hyphens none | manual | auto manual text yes n/a discrete n/a 지정된 키워드
letter-spacing normal | <length> normal 인라인 박스 및 text yes n/a 계산값 유형에 따름 n/a 절대 길이
line-break auto | loose | normal | strict | anywhere auto text yes n/a discrete n/a 지정된 키워드
overflow-wrap normal | break-word | anywhere normal text yes n/a discrete n/a 지정된 키워드
tab-size <number [0,∞]> | <length [0,∞]> 8 text yes n/a 계산값 유형에 따름 n/a 지정된 숫자 또는 절대 길이
text-align start | end | left | right | center | justify | match-parent | justify-all start 블록 컨테이너 yes 개별 속성 참조 discrete n/a 개별 속성 참조
text-align-all start | end | left | right | center | justify | match-parent start 블록 컨테이너 yes n/a discrete n/a 지정된 키워드. 단 match-parent는 위에 정의된 대로 계산됨
text-align-last auto | start | end | left | right | center | justify | match-parent auto 블록 컨테이너 yes n/a discrete n/a 지정된 키워드. 단 match-parent는 위에 정의된 대로 계산됨
text-indent [ <length-percentage> ] && hanging? && each-line? 0 블록 컨테이너 yes 블록 컨테이너 자신의 인라인 축 내부 크기를 참조 계산값 유형에 따름 문법 기준 계산된 <length-percentage> 값 및 지정된 모든 키워드
text-justify auto | none | inter-word | inter-character auto text yes n/a discrete n/a 지정된 키워드(distribute 레거시 값 제외)
text-transform none | [capitalize | uppercase | lowercase ] || full-width || full-size-kana none text yes n/a discrete n/a 지정된 키워드
white-space normal | pre | nowrap | pre-wrap | break-spaces | pre-line normal text yes n/a discrete n/a 지정된 키워드
word-break normal | keep-all | break-all | break-word normal text yes n/a discrete n/a 지정된 키워드
word-spacing normal | <length> normal text yes N/A 계산값 유형에 따름 n/a 절대 길이