1. 소개
이 모듈은 CSS의 조판 제어를 설명한다. 즉, 원본 텍스트를 서식이 지정되고 줄바꿈된 텍스트로 변환하는 것을 제어하는 CSS 기능을 말한다. 다양한 CSS 속성은 대소문자 변환, 공백 축소, 텍스트 줄바꿈, 줄 나누기 규칙 및 하이픈 넣기, 정렬과 양쪽 맞춤, 간격, 그리고 들여쓰기에 대한 제어를 제공한다.
밑줄, 강조 표시, 그리고 그림자와 같은 텍스트 장식 기능은 (이전에는 이 모듈의 일부였지만) CSS Text Decoration Module에서 다룬다. [CSS-TEXT-DECOR-3]
양방향 및 세로 텍스트는 CSS Writing Modes Module에서 다룬다. [CSS-WRITING-MODES-4].
전 세계 다양한 언어와 문자 체계의 조판 요구사항에 대한 자세한 정보는 Internationalization Working Group의 Language Enablement Index에서 찾을 수 있다. [TYPOGRAPHY]
1.1. 모듈 상호작용
이 모듈은 CSS Text Decoration Module과 함께, Cascading Style Sheets Level 2 16장에서 정의된 텍스트 수준 기능을 대체하고 확장한다. [CSS-TEXT-DECOR-3] [CSS2]
아래에 정의된 용어 외에도, 이 명세에서 사용되는 다른 용어와 개념은 Cascading Style Sheets Level 2와 CSS 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 속성을 사용하여
콘텐츠 언어를 선언할 수 있다.
HTML의
HTML 요소의 콘텐츠 언어를 결정하는 규칙과
XML 1.0의 XML 요소의 콘텐츠 언어를 결정하는
규칙을 보라.
[HTML]
[XML10]
요소가 속한다고 선언된 콘텐츠 언어는 그 요소에서 사용되는 해당 언어의 특정 문자 표기 형태도 식별하며, 이는 콘텐츠 문자 체계라고 한다. 문서 언어가 콘텐츠 언어를 식별하기 위해 제공하는 기능에 따라, 이 정보는 명시적일 수도 있고 암시적일 수도 있다. 규범적 부록 F: 콘텐츠 문자 체계 식별을 보라.
참고: 일부 언어에는 둘 이상의 문자 체계 전통이 있으며, 다른 경우에는 언어가 외래 문자 체계로 전사될 수 있다. 저자는 그러한 경우를 하위 태그로 표시하여 UA가 적절히 조정할 수 있도록 해야 한다.
ko)는
한글(-Hang),
한자(-Hani),
또는 그 조합(-Kore)으로 쓸 수 있다.
한자로만 쓰인 역사 문서는
단어 공백을 사용하지 않으며
현대 한국어보다 현대 중국어와 더 비슷하게 조판된다.
다시 말해, 조판 목적에서는 ko-Hani가
ko(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의 범위를 벗어난다.
- 미얀마 문자나 데바나가리 같은 일부 문자 체계에서는, 양쪽 맞춤과 줄 나누기 모두에 대한 조판 문자 단위가 전체 음절이며, 여기에는 둘 이상의 유니코드 그래핌 클러스터가 포함될 수 있다. [UAX29]
-
태국어나 라오어 같은 다른 문자 체계에서는,
줄 나누기의 경우 조판 문자가
유니코드의 기본 그래핌
클러스터와 일치하더라도,
자간 조정에서는 관련 단위가
유니코드 그래핌 클러스터보다 작으며,
간격을 삽입하기 전에 분해나 다른 대체가 필요할 수 있다.
[UAX29]
예를 들어, 태국어 단어 คำ (U+0E04 + U+0E33)에 적절히 자간을 적용하려면, U+0E33을 U+0E4D + U+0E32로 분해해야 하며, 그런 다음 추가 자간을 U+0E32 앞에 삽입한다: คํ า.
조금 더 복잡한 예는 น้ำ (U+0E19 + U+0E49 + U+0E33)이다. 이 경우 정상적인 태국어 셰이핑은 먼저 U+0E33을 U+0E4D + U+0E32로 분해한 뒤 U+0E4D와 U+0E49를 바꾸어 U+0E19 + U+0E4D + U+0E49 + U+0E32를 만든다. 이전과 마찬가지로 추가 자간은 U+0E32 앞에 삽입된다: นํ้ า.
- 세로 조판도 조정을 필요로 할 수 있다. 예를 들어, upright 텍스트를 조판할 때, 티베트 tsek 및 shad 표시는 독립적인 조판 문자 단위로 취급되지 않고, 앞선 그래핌 클러스터와 함께 유지된다. [CSS-WRITING-MODES-4]
조판 글자 단위 (또는 이 명세의 목적상 글자) 는 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
- 모든 작은 가나 문자를 대응하는 전체 크기 가나로 변환한다. 이 값은 일반적으로 루비 주석 텍스트에 사용되며, 저자는 루비에서 일반적으로 사용되는 작은 글꼴 크기의 가독성 문제를 보완하기 위해 모든 작은 가나를 큰 가나로 그리기를 원할 수 있다.
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 Standard의 Default Case Algorithms 절에 정의된 조건부 대소문자 규칙이 포함된다. [UNICODE] 요소의 콘텐츠 언어가, 문서 언어의 규칙에 따라, 알려져 있는 경우에만, 적절한 언어별 규칙도 적용해야 한다. 여기에는 최소한 Unicode의 SpecialCasing.txt에 있는 언어별 규칙이 포함되지만 이에 한정되지는 않는다.
전각
및 반각 형태의 정의는
Unicode Standard Annex #11:
East Asian Width에서 찾을 수 있다.
[UAX11]
전각 형태로의 매핑은
Unicode Standard Annex #44: Unicode
Character Database의
Decomposition_Mapping에
<wide>
또는 <narrow> 태그가 있는 코드 포인트를 취하여
정의된다.
[UAX44]
<narrow> 태그의 경우,
매핑은 코드 포인트에서 분해값
(<narrow> 태그 제외)으로 이루어지며,
<wide> 태그의 경우,
매핑은 분해값
(<wide> 태그 제외)에서
원래 코드 포인트로 되돌아가는 방식으로 이루어진다.
작은 가나에서 전체 크기 가나로의 매핑은 부록 G: 작은 가나 매핑에 정의되어 있다.
2.1.2. 작업 순서
여러 값이 지정되어 여러 변환을 적용해야 하는 경우, 다음 순서로 적용된다:
텍스트 변환은 § 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-START 및 RECORD-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])
그러나 이 문자는 이스케이프 시퀀스()를 사용해
인코딩된 경우에는 보존되며—위 규칙이 관찰 가능하다.
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])는 없는 것처럼
무시한다:
-
white-space가 normal, nowrap, 또는 pre-line으로 설정된 경우,
공백 문자는
축소 가능한 것으로 간주되며
다음 단계를 수행하여 처리된다:
- 세그먼트 나누기의 바로 앞이나 뒤에 있는 축소 가능한 공백 및 탭의 모든 시퀀스는 제거된다.
- 축소 가능한 세그먼트 나누기는 세그먼트 나누기 변환 규칙에 따라 렌더링을 위해 변환된다.
- 모든 축소 가능한 탭은 축소 가능한 공백(U+0020)으로 변환된다.
- 다른 축소 가능한 공백 바로 뒤에 오는 축소 가능한 공백—해당 공백을 포함하는 인라인의 경계 밖에 있는 공백이라도, 두 공백이 같은 인라인 서식 맥락 안에 있다면—은 선행 폭이 0이 되도록 축소된다. (보이지 않지만, 존재한다면 소프트 줄바꿈 기회는 유지한다.)
- white-space가 pre, pre-wrap, 또는 break-spaces로 설정된 경우, 공백의 모든 시퀀스는 줄 바꿈 없는 공백 시퀀스로 취급된다. 그러나 pre-wrap의 경우, 공백 및/또는 탭 시퀀스의 끝에 소프트 줄바꿈 기회가 존재하는 반면, break-spaces의 경우에는 모든 공백 및 모든 탭 뒤에 소프트 줄바꿈 기회가 존재한다.
<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 속성으로 지정된 대로 줄바꿈하면서 배치된다. 각 줄이 배치될 때,
- 줄 시작에 있는 축소 가능한 공백 시퀀스는 제거된다.
-
탭 크기가 0이면,
보존된
탭은 렌더링되지 않는다.
그렇지 않으면, 각 보존된 탭은
다음 글리프의 시작 가장자리를 다음 탭 정지점에 맞추는
수평 이동으로 렌더링된다.
이 거리가 0.5ch보다 작으면,
그 대신 다음 탭 정지점이 사용된다.
탭
정지점은
해당 보존된 탭의
가장 가까운 블록 컨테이너 조상에서
시작 콘텐츠 가장자리로부터
탭 크기의 배수인 지점에 위치한다.
탭 크기는 tab-size
속성으로 주어진다.
참고: 탭 문자(U+0009)가 양방향 처리와 상호작용하는 방식에 대한 Unicode 규칙을 보라. [UAX9]
-
줄 끝에 있는 축소
가능한 공백 시퀀스는 제거되며,
또한 white-space 속성이 normal, nowrap, 또는 pre-line인
뒤따르는 U+1680 OGHAM SPACE MARK도 제거된다.
참고: Unicode Bidirectional Algorithm 규칙 L1 때문에, 양방향 재정렬 이전에 줄 끝에 위치한 축소 가능한 공백 시퀀스는 재정렬 이후에도 줄 끝에 있게 된다. [UAX9] [CSS-WRITING-MODES-4]
-
양방향 재정렬 이후
줄 끝에
공백,
기타 공백
구분자,
및/또는 보존된
탭의 시퀀스가
여전히 남아 있다면
([CSS-WRITING-MODES-4]):
- white-space가 normal, nowrap, 또는 pre-line으로 설정된 경우, UA는 이 시퀀스를 (무조건) 행잉해야 한다.
-
white-space가 pre-wrap로
설정된 경우,
UA는 이 시퀀스를 (무조건) 행잉해야 한다.
단, 이 시퀀스 뒤에 강제
줄 나누기가 오는 경우에는,
대신 그 시퀀스를 조건부로 행잉해야 한다.
또한 그렇지 않으면 넘칠 수 있는 문자들의 선행 폭을
시각적으로 축소할 수 있다.
참고: 공백을 축소하지 않고 행잉하면, 사용자가 텍스트를 선택하거나 편집할 때 공백을 볼 수 있다.
-
white-space가 break-spaces로 설정된 경우,
공백, 탭, 그리고 기타 공백
구분자는
다른 보이는 문자와 동일하게 취급된다:
이들은 행잉될 수 없고
선행 폭이 축소될 수도 없다.
참고: 따라서 그러한 문자는 공간을 차지하며, 사용 가능한 공간과 적용 가능한 줄 나누기 제어에 따라 넘치거나 줄바꿈을 유발한다.
p {
white-space : pre-wrap;
width : 5 ch ;
border : solid 1 px ;
font-family : monospace;
text-align : center;
}
< p > 0</ p >
위 예제는 다음과 같이 렌더링된다:
마지막 공백은 강제 줄 나누기 앞에 있으며 넘치지 않으므로, 행잉되지 않고, 가운데 정렬은 예상대로 동작한다.
p {
white-space : pre-wrap;
width : 3 ch ;
border : solid 1 px ;
font-family : monospace;
}
< p > 0 0 0 0</ p >
위 예제는 다음과 같이 렌더링된다:
0 0
0
p
가 추가되면,
결과는 다음과 같다:
0 0
0
강제 나누기가 없는 줄 끝의 보존된 공백은 반드시 행잉되어야 하므로, 텍스트 정렬 중 나머지 줄을 배치할 때 고려되지 않는다. 끝쪽으로 정렬할 때, 이는 그러한 공백이 넘칠 수 있으며, 줄의 나머지 콘텐츠가 줄 가장자리에 맞닿는 것을 방해하지 않는다는 뜻이다. 반면, 강제 나누기가 있는 줄 끝의 보존된 공백은 조건부로 행잉된다. 이 예에서 마지막 줄 끝의 공백은 넘치지 않으므로, 행잉되지 않으며 따라서 텍스트 정렬 중 고려된다.
p {
white-space : pre-wrap;
width : 3 ch ;
border : solid 1 px ;
font-family : monospace;
}
< p > 0 0 0 0</ p >
0 0
마지막 줄은 마지막 0 앞에서 줄바꿈되지 않는다.
조건부로 행잉되는 문자는
줄의 콘텐츠가 맞는지 측정할 때 고려되지 않기 때문이다.
4.1.3. 세그먼트 나누기 변환 규칙
white-space가 pre, pre-wrap, break-spaces, 또는 pre-line이면, 세그먼트 나누기는 축소 가능하지 않으며, 대신 보존된 줄 바꿈 문자(U+000A)로 변환된다.
white-space의 다른 값에 대해서는, 세그먼트 나누기가 축소 가능하며, 다음과 같이 축소된다:
- 먼저, 다른 축소 가능한 세그먼트 나누기 바로 뒤에 오는 모든 축소 가능한 세그먼트 나누기는 제거된다.
- 그런 다음 남아 있는 모든 세그먼트 나누기는 나누기 전후의 문맥에 따라 공백(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-spacing 및 word-spacing도 포함한다. 음수 값은 허용되지 않는다.
5. 줄 나누기와 단어 경계
인라인 수준 콘텐츠가 줄 안에 배치될 때, 그것은 라인 박스 사이에서 나뉜다. 이러한 나누기를 줄 나누기라고 한다. 줄이 명시적 줄 나누기 제어 (예: 보존된 개행 문자) 때문에 나뉘거나, 블록의 시작 또는 끝 때문에 나뉘는 경우, 이는 강제 줄 나누기이다. 줄이 콘텐츠 줄바꿈 때문에 나뉘는 경우 (즉, UA가 콘텐츠를 측정값 안에 맞추기 위해 강제되지 않은 줄 나누기를 만드는 경우), 이는 소프트 줄바꿈 나누기이다. 인라인 수준 콘텐츠를 줄로 나누는 과정을 줄 나누기라고 한다.
줄바꿈은 허용된 나누기 지점에서만 수행되며, 이를 소프트 줄바꿈 기회라고 한다. 줄바꿈이 활성화되면(white-space 참조), UA는 소프트 줄바꿈 기회가 존재하는 경우 그 지점에서 줄을 줄바꿈하여 한 줄에서 넘치는 콘텐츠의 양을 최소화해야 한다. 유효한 소프트 줄바꿈 기회는 콘텐츠 언어와 문자 체계, 그리고 이를 제어하는 CSS 속성에 따라 달라진다.
대부분의 문자 체계에서는, 하이픈 넣기가 없는 경우 소프트 줄바꿈 기회가 단어 경계에서만 발생한다. 이러한 체계 중 많은 것들(예: 라틴 알파벳을 사용하는 영어)은 공백이나 문장부호를 사용하여 명시적으로 단어를 분리하며, 이러한 문자로 소프트 줄바꿈 기회를 식별할 수 있다.
그러나 태국어, 라오어, 크메르어 같은 문자 체계는 단어를 분리하기 위해 공백이나 문장부호를 사용하지 않는다. 이러한 문자 체계에서 제로 폭 공백(U+200B)을 명시적 단어 구분자로 사용할 수는 있지만, 이러한 관행은 일반적이지 않다. 그 결과, 그러한 텍스트에서 소프트 줄바꿈 기회를 올바르게 식별하려면 어휘 자원이 필요하다.
일부 다른 문자 체계, 특히 자바 문자와 발리 문자 같은 브라흐미계 문자에서는, 소프트 줄바꿈 기회가 단어 경계가 아니라 정서법적 음절 경계를 기반으로 한다. 정서법적 음절 나누기는 콘텐츠 언어에 의존하지 않고 어휘 자원을 필요로 하지 않지만, 나누기 기회를 찾기 위해서는 여전히 텍스트 분석이 필요하다.
중국어(그리고 일본어, 이 문자, 때로는 한국어도 포함) 같은 다른 문자 체계에서는, 각 음절이 하나의 조판 글자 단위에 대응하는 경향이 있으며, 따라서 줄 나누기 관례는 특정 문자 조합 사이를 제외하고 어디서든 줄이 나뉘도록 허용한다. 또한 이러한 제한의 엄격도 수준은 조판 스타일에 따라 달라진다.
CSS가 소프트 줄바꿈 기회가 발생하는 위치를 완전히 정의하지는 않지만, 일반적인 변형을 구분하기 위한 몇 가지 제어를 제공한다:
- line-break 속성은 줄 나누기 제한에 대한 다양한 “엄격도” 수준을 선택할 수 있게 한다.
- word-break 속성은 어떤 유형의 글자들이 끊을 수 없는 “단어”를 형성하도록 함께 묶이는지 제어하여, CJK 문자가 비 CJK 텍스트처럼 동작하거나 그 반대로 동작하게 한다.
- hyphens 속성은 하이픈 넣기를 사용하는 문자 체계에서 자동 하이픈 넣기가 단어를 나눌 수 있는지를 제어한다.
- overflow-wrap 속성은 그렇지 않으면 넘칠 수 있는 끊을 수 없는 문자열 안의 어디서든 UA가 나누기를 취할 수 있게 한다.
참고: Unicode Standard Annex #14: Unicode Line Breaking Algorithm은 Unicode의 모든 문자 체계에 대한 줄 나누기의 기준 동작을 정의하며, 이는 추가로 조정될 것으로 기대된다. [UAX14] 줄 나누기 관례에 대한 더 많은 정보는 일본어의 경우 Requirements for Japanese Text Layout [JLREQ] 및 Formatting Rules for Japanese Documents [JIS4051], 중국어의 경우 Requirements for Chinese Text Layout [CLREQ] 및 General Rules for Punctuation [ZHMARK]에서 찾을 수 있다. 또한 추가 언어에 대한 더 많은 정보를 포함하는 Internationalization Working Group의 Language 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를 보라.)
또 다른 예로, 한국어에는 두 가지 줄 나누기 스타일이 있다: 임의의 두 한국어 음절 사이(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, 또는IDUnicode 줄 나누기 클래스 [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·و·کمی·خط·عربی·และ·ตัวอย่าง·การเขียน·ภาษาไทย·በጽሑፍ፡·ማራዘሙን፡·አንዳንድ፡
레거시 콘텐츠와의 호환성을 위해, word-break 속성은 폐기된 break-word 키워드도 지원한다. 이것이 지정되면, word-break: normal 및 overflow-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-space가 break-spaces로 설정된 경우에만 다음 줄로 줄바꿈되도록 허용한다. 다른 경우에는 다음과 같기 때문이다:보존된 공백에 영향을 주는 경우, white-space: break-spaces와 함께 사용하면, 시퀀스의 첫 번째 공백 앞에서 나누는 것을 허용한다. 이는 break-spaces만으로는 허용되지 않는다.
CSS는 텍스트 줄바꿈 규칙에서 네 가지 엄격도 수준을 구분한다. loose, normal, 그리고 strict 각각에 대해 실제로 적용되는 정확한 규칙 집합은 UA가 결정하며 언어 관례를 따라야 한다. 그러나 이 세 키워드에 대해서, 이 명세는 다음을 요구한다:
-
다음 나누기는 normal
및 loose 줄 나누기에서,
문자 체계가
중국어
또는 일본어인
경우에 허용되며,
그 밖의 경우에는 금지된다:
-
특정 CJK 하이픈 유사 문자 앞의 나누기:
〜 U+301C, ゠ U+30A0
-
특정 CJK 하이픈 유사 문자 앞의 나누기:
-
다음 나누기는 선행 문자가 Unicode 줄 나누기 클래스
ID에 속하는 경우 [UAX14] (word-break: break-all 때문에 선행 문자가ID로 취급되는 경우 포함), loose 줄 나누기에서 허용되며, 그 밖의 경우에는 금지된다:-
하이픈 앞의 나누기:
‐ U+2010, – U+2013
-
하이픈 앞의 나누기:
- 다음 나누기는 normal 및 strict 줄 나누기에서는 금지되고 loose에서는 허용된다:
-
다음 나누기는 문자
체계가 중국어
또는 일본어인 경우
loose에서
허용되며,
그 밖의 경우에는 금지된다:
-
특정 가운데 문장부호 앞의 나누기:
・ U+30FB, : U+FF1A, ; U+FF1B, ・ U+FF65, ‼ U+203C, ⁇ U+2047, ⁈ U+2048, ⁉ U+2049, ! U+FF01, ? U+FF1F -
접미사 앞의 나누기:
Unicode 줄 나누기 클래스PO를 가진 문자 [UAX14] 및 East Asian Width 속성 [UAX11]Ambiguous,Fullwidth, 또는Wide. -
접두사 뒤의 나누기:
Unicode 줄 나누기 클래스PR를 가진 문자 [UAX14] 및 East Asian Width 속성 [UAX11]Ambiguous,Fullwidth, 또는Wide.
-
특정 가운데 문장부호 앞의 나누기:
참고: 위에 나열된 요구사항은 CJK 텍스트에서만 구분을 만든다. 위 규칙만 일치시키고 추가 규칙이 없는 구현에서는, 문자 체계가 중국어 또는 일본어로 태그 지정되지 않는 한 line-break는 CJK 코드 포인트에만 영향을 줄 것이다. 향후 레벨에서는 다른 문자 체계와 언어에 대해 요구사항이 알려짐에 따라 추가적인 구체적 규칙을 더할 수 있다.
참고: CSSWG는 명세의 향후 판에서 고급 출판 요구사항을 충족하기 위해 줄 나누기에 대한 더 세밀한 제어가 필요할 수 있음을 인식하고 있다.
-
U+0021(느낌표,
!)와 글자(Unicode 일반 범주L) 사이에 줄 나누기 기회를 도입하지 않기. 이는 “!important” 문자열에서 나누기가 발생하는 것을 방지한다. -
U+002F(빗금,
/)와 글자(Unicode 일반 범주L) 사이에 줄 나누기 기회를 도입하지 않기. 이는 “23/Jan/2024” 같은 날짜에서 나누기가 발생하는 것을 방지한다. -
U+007C(수직선,
|)와 글자(Unicode 일반 범주L) 사이에 줄 나누기 기회를 도입하지 않기. -
하이픈 앞의 코드 포인트가 글자나 숫자가 아닌 경우 (Unicode 일반 범주
L또는Nd), U+002D(하이픈-마이너스 `-`)와 숫자(Unicode 일반 범주Nd) 사이에 줄 나누기 기회를 도입하지 않기. 이는 “-13” 같은 숫자 앞의 마이너스 기호 뒤에서 나뉘는 것을 방지하면서, 긴 URL 등에 나타날 수 있는 “ABCD-1234” 및 “1234-5678”의 하이픈 뒤 나누기는 허용한다.
5.3. 하이픈 넣기: hyphens 속성
하이픈 넣기는 일반적으로 나누기가 허용되지 않는 위치에서 단어를 제어된 방식으로 분할하여 문단의 레이아웃을 개선하는 것이다. 보통 음절 또는 형태소 경계에서 단어를 나누고, 종종 시각적으로 그 분할을 표시한다 (보통 하이픈 U+2010을 삽입함). 어떤 경우에는 하이픈 넣기가 단어의 철자를 바꿀 수도 있다. 어쨌든 하이픈 넣기는 렌더링 효과일 뿐이다: 기본 문서 콘텐츠나 텍스트 선택 또는 검색에는 영향을 주어서는 안 된다.
| 언어 | 나뉘지 않음 | 앞 | 뒤 |
|---|---|---|---|
| 영어 | Unbroken | Un‐ | broken |
| 네덜란드어 | cafeetje | café‐ | tje |
| 헝가리어 | Összeg | Ösz‐ | szeg |
| 중국어 관화 | tú’àn | tú‐ | àn |
| àizēng‐fēnmíng | àizēng‐ | ‐fēnmíng | |
| 위구르어 |
|
|
|
| 크리어 |
|
|
|
하이픈 넣기는 줄이 유효한 하이픈 넣기 기회에서 나뉠 때 발생한다. 이는 하이픈 넣기가 허용되는 단어 내부에 존재하는 소프트 줄바꿈 기회의 한 유형이다. CSS에서 하이픈 넣기 기회는 hyphens 속성으로 제어된다. CSS Text Level 3은 하이픈 넣기의 정확한 규칙을 정의하지 않는다; 그러나 UA는 나누기 지점 선택을 최적화하고 언어에 적합한 하이픈 넣기 지점을 선택하도록 강력히 권장된다.
참고: U+002D - HYPHEN-MINUS 문자 또는 U+2010 ‐ HYPHEN 문자가 도입하는 소프트 줄바꿈 기회는 하이픈 넣기 기회가 아니다. 줄바꿈 시 분할의 시각적 표시가 생성되지 않기 때문이다: 이 문자들은 그 지점에서 줄이 줄바꿈되든 아니든 보인다.
하이픈 넣기 기회는 min-content 내재적 크기를 계산할 때 고려된다.
참고: 이는 표가 포함 블록을 넘치는 대신 콘텐츠에 하이픈을 넣을 수 있게 하며, 독일어처럼 긴 단어가 많은 언어에서 특히 중요하다.
| 이름: | 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에서 ­는 하이픈 넣기 기회를 제안하는 소프트 하이픈 문자를 나타낸다.
ex
­ ample - auto
- 단어는 조건부 하이픈으로 명시적으로 표시된 기회에 더해, 언어에 적합한 하이픈 넣기 자원이 자동으로 결정한 하이픈 넣기 기회에서 나뉠 수 있다. 단어에 조건부 하이픈 (­ 또는 U+00AD SOFT HYPHEN)이 포함되어 있으면, 단어 내부 다른 곳의 자동 하이픈 넣기 기회는 조건부 하이픈을 우선하기 위해 무시되어야 한다. 그러나 그러한 기회에서 나누더라도 그 단어의 일부가 여전히 한 줄에 맞기에는 너무 길다면, 자동 하이픈 넣기 기회를 사용할 수 있다.
올바른 자동 하이픈 넣기에는 나누려는 텍스트의 언어에 적합한 하이픈 넣기 자원이 필요하다. 따라서 UA는 콘텐츠 언어가 알려져 있고 적절한 하이픈 넣기 자원을 가진 텍스트에 대해서만 자동으로 하이픈을 넣어야 한다.
UA는 특정 단어를 자동 하이픈 넣기에서 제외하기 위해 언어에 맞춘 휴리스틱을 사용할 수 있다. 예를 들어, UA는 특정 대소문자 및 문장부호 패턴과 일치하는 단어를 제외하여 고유명사의 하이픈 넣기를 피하려고 할 수 있다. 그러한 휴리스틱은 이 명세에서 정의하지 않는다. (그러한 휴리스틱은 언어마다 달라질 필요가 있음에 유의하라: 예를 들어 영어와 독일어는 대소문자 관례가 매우 다르다.)
hyphens 속성의 목적상, 무엇이 “단어”를 구성하는지는 UA에 의존한다. 그러나 단어 경계를 결정할 때 인라인 요소 경계와 흐름 밖 요소는 무시되어야 한다.
조건부 하이픈 문자 (예: U+00AD SOFT HYPHEN)가 만든 하이픈 넣기 기회에서 하이픈 넣기 때문에 표시되는 모든 글리프는 그 문자로 표현되며 그 문자에 적용된 속성에 따라 스타일링된다.
참고: 아랍어 같은 셰이핑 문자 체계가 하이픈 넣기 때문에 단어 안에서 나뉘도록 허용될 때, 문자는 여전히 단어가 나뉘지 않은 것처럼 셰이핑된다.
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-wrap을 overflow-wrap 속성의 레거시 이름 별칭으로 취급해야 한다.
5.5. 줄 나누기 세부사항
줄 나누기를 결정할 때:
- 줄 나누기와 양방향 텍스트의 상호작용은 CSS Writing Modes 4 § 2.4 양방향 재정렬 알고리즘 적용 및 Unicode Bidirectional Algorithm (특히 UAX9§3.4 Reordering Resolved Levels)에 의해 정의된다. [CSS-WRITING-MODES-4] [UAX9]
-
보존된 세그먼트 나누기와,
white-space 값과 관계없이,
BK및NL줄 나누기 클래스를 가진 모든 Unicode 문자는 강제 줄 나누기로 취급되어야 한다. [UAX14]참고: 그러한 강제 줄 나누기의 양방향 관련 사항은 Unicode Bidirectional Algorithm에 의해 정의된다. [UAX9]
-
달리 명시적으로 정의된 경우
(예: line-break: anywhere 또는 overflow-wrap: anywhere)를 제외하고,
WJ,ZW,GL, 및ZWJUnicode 줄 나누기 클래스에 대해 정의된 줄 나누기 동작은 존중되어야 한다. [UAX14] -
CSS는 조판 문자 단위 내부의
소프트 줄바꿈
기회를
절대 허용하지 않는다.
따라서
CM및SGUnicode 줄 나누기 클래스는 항상 존중되어야 한다. [UAX14] - 이를 사용하는 문자 체계에서 단어 구분자가 아닌 문장부호에서도 줄바꿈을 허용하는 UA는 나누기 지점에 우선순위를 두어야 한다. (예를 들어, 빗금 뒤의 나누기가 공백보다 낮은 우선순위를 받는 경우, “check /etc” 시퀀스는 "/"와 "e" 사이에서 절대 나뉘지 않는다.) 그러한 어색한 나누기를 피하도록 주의하는 한, 단어 구분자가 아닌 적절한 문장부호에서 나누기를 허용하는 것이 권장된다. 특히 좁은 측정값에서 더 고르게 보이는 여백을 만들기 때문이다. UA는 우선순위를 부여할 때 포함 블록의 너비, 텍스트의 언어, line-break 값, 및 기타 요소를 사용할 수 있다: CSS는 소프트 줄바꿈 기회의 우선순위를 정의하지 않는다. 그러나 word-break: break-all이 지정된 경우에는 단어 구분자의 우선순위 지정이 기대되지 않는다 (이 값은 단어 구분자에서 나누는 것에 기반하지 않는 줄 나누기 동작을 명시적으로 요청하기 때문이다)—그리고 line-break: anywhere에서는 금지된다.
- 흐름 밖 박스 및 인라인 박스 경계는 흐름 안에 강제 줄 나누기 또는 소프트 줄바꿈 기회를 도입하지 않는다.
- 웹 호환성을 위해 각 대체 요소 또는 기타 원자적 인라인 앞뒤에는 소프트 줄바꿈 기회가 있다. 이는 U+00A0 NO-BREAK SPACE를 포함해, 일반적으로 그것들을 억제할 문자와 인접한 경우에도 마찬가지다. 그러나 U+00A0 NO-BREAK SPACE를 제외하면, 원자적 인라인과 Unicode GL, WJ, 또는 ZWJ 줄 나누기 클래스에 속하는 인접 문자 사이에는 소프트 줄바꿈 기회가 없어야 한다. [UAX14]
- 줄 나누기에서 사라지는 문자 (예: U+0020 SPACE)가 만든 소프트 줄바꿈 기회의 경우, 그 문자를 직접 포함하는 박스의 속성이 해당 기회에서의 줄 나누기를 제어한다. 두 문자 또는 원자적 인라인 사이의 경계로 정의되는 소프트 줄바꿈 기회의 경우, 두 문자에 가장 가까운 공통 조상의 white-space 속성이 나누기를 제어한다; 그러한 경계에서 소프트 줄바꿈 기회의 결정을 어떤 요소의 line-break, word-break, 및 overflow-wrap 속성이 제어하는지는 이 레벨에서 정의되지 않는다.
- 박스의 첫 문자 앞 또는 마지막 문자 뒤의 소프트 줄바꿈 기회의 경우, 나누기는 콘텐츠 가장자리와 콘텐츠 사이에서 박스를 나누는 것이 아니라, 박스 바로 앞/뒤 (그 여백 가장자리)에서 발생한다.
- 루비 안/주변의 줄 나누기는 CSS Ruby Annotation Layout 1 § 3.4 줄 사이에서 나누기에 정의되어 있다. [CSS-RUBY-1]
- 아랍어 같은 셰이핑 문자 체계가 단어 내부의 강제되지 않은 소프트 줄바꿈 기회에서 줄바꿈될 때 (예를 들어 word-break: break-all, line-break: anywhere, overflow-wrap: break-word, overflow-wrap: anywhere, 또는 하이픈 넣기 때문에 나누어지는 경우), 문자는 여전히 단어가 온전한 것처럼 셰이핑되어야 한다 (결합 형태가 선택되어야 한다).
-
예기치 않은 넘침을 피하기 위해,
사용자 에이전트가 줄 나누기에 필요한
어휘 또는 정서법 분석을 수행할 수 없는
콘텐츠 언어가 있는 경우—예를
들어 특정 언어에 대한
사전이 없어서—그 문자 체계의 조판 글자 단위 쌍 사이에
소프트 줄바꿈
기회가 있다고
가정해야 한다.
참고: 이 조항은 UA가 특정 텍스트 런에서 단어 경계를 찾지 못했다는 이유만으로 발동되지는 않는다; 그 텍스트 런은 하나의 끊을 수 없는 단어일 수도 있다. 예를 들어 텍스트 런이 크메르 문자(U+1780부터 U+17FF까지)로 구성되어 있고 사용자 에이전트가 크메르어에서 단어 경계를 결정하는 방법을 모르는 경우에 적용된다.
6. 정렬과 양쪽 맞춤
정렬과 양쪽 맞춤은 인라인 콘텐츠가 라인 박스 안에서 어떻게 분배되는지를 제어한다.
6.1. 텍스트 정렬: text-align 단축 속성
| 이름: | text-align |
|---|---|
| 값: | start | end | left | right | center | justify | match-parent | justify-all |
| 초기값: | start |
| 적용 대상: | 블록 컨테이너 |
| 상속: | yes |
| 백분율: | 개별 속성 참조 |
| 계산값: | 개별 속성 참조 |
| 애니메이션 유형: | discrete |
| 정규 순서: | n/a |
이 단축 속성은 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로 설정한다.
텍스트 블록은 라인 박스의 스택이다. 이 속성은 각 라인 박스 안의 인라인 수준 박스가 라인 박스의 시작 및 끝 쪽에 대해 어떻게 정렬되는지를 지정한다. 정렬은 뷰포트 또는 포함 블록에 대한 것이 아니다.
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-last의 auto가 아닌 값으로 덮어쓴 마지막 줄을 제외하고, 블록 컨테이너 안의 인라인 콘텐츠 모든 줄의 인라인 정렬을 지정한다. 값에 대한 전체 설명은 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-all이 justify로 설정된 경우에는 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) 형태와 장식적 형태를 사용하여 줄을 채우도록 확장되며, 아래쪽 줄은 ت와 م 사이의 문자에 대해 쌓인 조합을 사용하여 약간 압축된다. 전통적 서예 기법을 사용함으로써, 조판자는 흐름과 색을 보존하면서 줄을 양쪽 맞춤할 수 있으며, 매우 높은 품질의 양쪽 맞춤 효과를 제공한다. 그러나 이는 본질적으로 매우 문자 체계별인 효과이다.
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는 기호 및 문장부호와 관련된 양쪽 맞춤 기회를 처리하기 위해 특정 문자를 다시 할당하거나 추가적인 우선순위 수준을 도입할 수 있다.
6.4.3. 확장할 수 없는 텍스트
줄의 인라인 콘텐츠를 라인 박스의 전체 너비까지 늘릴 수 없으면, 해당 콘텐츠는 text-align-last 속성이 지정한 대로 정렬되어야 한다. (text-align-last가 justify이면, 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-spacing 및 letter-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이 적용되는지 여부는 이 레벨에서 정의되지 않는다.
p{ letter-spacing : 1 em ; }
< 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 값을 사용하여 한쪽 또는 다른 조판 문자 단위에 붙일 수 있다.
참고: 이 보조 동작은 웹 호환성 문제 때문에 이 레벨에서 허용된다.
p{ letter-spacing : 1 em ; }
< p > a< span > bb</ span > c</ p >
a b b c
a b b c
따라서 letter-spacing의 주어진 값은 그 값이 지정된 요소 안에 완전히 포함된 문자들 사이의 간격에만 영향을 줄 것으로 기대된다:
p{ letter-spacing : 1 em ; } span{ letter-spacing : 2 em ; }
< p > a< span > bb</ span > c</ p >
a b b c
이는 더 나아가, 단일 문자만 포함하는 요소에 letter-spacing을 적용해도 렌더링 결과에는 영향을 주지 않음을 뜻한다:
p{ letter-spacing : 1 em ; } span{ letter-spacing : 2 em ; }
< p > a< span > b</ span > c</ p >
a b c
letter spacing은 RTL 재정렬 이후 삽입되므로, 아래 내부 span에 적용된 letter spacing 역시 효과가 없다. 재정렬 이후 "c"가 "א" 옆에 놓이지 않기 때문이다:
p{ letter-spacing : 1 em ; } span{ letter-spacing : 2 em ; }
<!-- abc followed by Hebrew letters alef (א), bet (ב) and gimel (ג) --> <!-- Reordering will display these in reverse order. --> < p > ab< span > cא</ span > בג</ p >
a b c א ב ג
Letter spacing은 보이지 않는 제로 폭 서식 문자 (Unicode Cf 범주의 문자 등)를 무시한다. 그러한 문자가 문서에 없는 것처럼 간격을 추가해야 한다.
두 문자 사이의 유효 간격이 0이 아닌 경우 (양쪽 맞춤 때문이든 letter-spacing의 0이 아닌 값 때문이든), 사용자 에이전트는 선택적 합자, 즉 근본적으로 올바른 글리프 셰이핑에 필요하다고 정의되지 않은 합자를 적용하지 않는 것이 좋다. 그러나 저수준 font-feature-settings 속성을 통해 지정된 합자 및 기타 글꼴 기능은 이 규칙보다 우선한다. CSS Fonts Module Level 3 § feature-precedence를 보라.
참고: 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. 요소 경계를 가로지르는 셰이핑
두 조판 문자 단위를 분리하는 경계를 가진 어떤 박스에 대해서든 다음 중 하나가 참이면, 텍스트 셰이핑은 인라인 박스 경계에서 반드시 끊어져야 한다:
- 인라인 축에서 두 조판 문자 단위를 분리하는 margin/border/padding 중 어느 하나라도 0이 아니다.
- vertical-align이 baseline이 아니다.
- 그 경계가 양방향 격리 경계이다.
서식에 효과적인 변화가 없거나, 유일한 서식 변화가 글리프에 영향을 주지 않는 경우 (텍스트 장식 적용처럼), 텍스트 셰이핑은 인라인 박스 경계를 가로질러 끊어져서는 안 된다.
그 밖의 경우에는, 글꼴 기술의 한계를 고려할 때 그 경우에 합리적이고 가능하다면, 텍스트 셰이핑은 인라인 박스 경계를 가로질러 끊어지지 않는 것이 좋다.
경계를 가로지르는 가능하지만 합리적이지는 않은 셰이핑의 예는 양쪽 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-align이 start이며 text-indent가 5em이라면, 텍스트의 첫 줄은 블록 안쪽으로 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'.
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가 그러한 추가 사항을 워킹 그룹에 알려주면 감사할 것이다.
p{ text-align : justify; hanging-punctuation : allow-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 Algorithm이 CSS Writing Modes에 의해 적용되는 방식으로 제어된다 [UAX9] [CSS-WRITING-MODES-4]).
대부분의 경우, 라인 박스의 인라인 기본 방향은 그 포함 블록의 계산된 direction에 의해 주어진다. 그러나 그 포함 블록이 unicode-bidi: plaintext를 가진 경우 [CSS-WRITING-MODES-4]:
- 양방향 문단, 즉 라인 박스가 속한 (즉, 그 line box가 콘텐츠를 담고 있는 양방향 문단)이 강한 방향성을 가지면, 라인 박스의 인라인 기본 방향은 그 방향이다.
- 라인 박스가 비어 있거나 (즉 원자적 인라인 또는 개행 문자가 있다면 그것을 제외한 문자를 포함하지 않음), 또는 달리 강한 방향성을 가지지 않는 경우 (약한 문자나 중립 문자만 포함하는 경우), 그 인라인 기본 방향은 앞선 라인 박스(있는 경우)에서 가져오며, 이것이 포함 블록의 첫 번째 라인 박스라면 포함 블록의 direction 속성에서 가져온다. (이는 콘텐츠가 LTR 기본 방향을 가진 RTL 라인 박스를 만들 수 있다.)
<block>이 시작 정렬된 사전 서식 블록
(display: block; white-space: pre; text-align: start)이라고 가정하면,
한 줄 걸러 오른쪽 정렬된다:
< 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 >
unicode-bidi: plaintext 때문에, “Hello!”는 LTR로 조판된다 (즉 느낌표가 오른쪽에 위치한다) 그리고 왼쪽 정렬되며, 포함 블록의 RTL direction을 무시한다. 이로 인해 그 뒤의 빈 줄도 LTR이 되며, 이는 그 줄의 캐럿이 왼쪽 가장자리에 나타나야 함을 뜻한다. 그러나 비어 있는 첫 줄은 오른쪽 정렬된다: 앞선 줄이 없으므로, 포함 블록의 RTL 방향을 가정하기 때문이다.
부록 A: 텍스트 처리 작업 순서
이 부록은 규범적이다.
다음 목록은 텍스트 작업의 순서를 정의한다. (구현은 결과 레이아웃이 동일한 한 이 순서에 구속되지 않는다.)
- 공백 처리 1부(줄바꿈 전)
- 텍스트 변환
- 텍스트 결합 [CSS-WRITING-MODES-4]
- 텍스트 방향 지정 [CSS-WRITING-MODES-4]
- 줄마다 다음을 적용하면서 텍스트 줄바꿈:
- 양쪽 맞춤 (이는 글리프 선택 및/또는 텍스트 줄바꿈에 영향을 줄 수 있어, 그 단계로 되돌아갈 수 있다)
- 텍스트 정렬
부록 B: 일반 텍스트로 변환
이 부록은 일반 텍스트 복사-붙여넣기 작업의 목적상 규범적이다.
CSS로 렌더링된 문서가 일반 텍스트 형식으로 변환될 때, 다음이 기대된다:
- text-transform 속성은 아무 효과가 없다.
- § 4.1.1 1단계: 축소와 변환이 적용되고 블록의 시작이나 강제 줄 나누기 바로 뒤에 있는 축소 가능한 공백의 모든 시퀀스는 제거된다.
부록 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 속성의 문자 중
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
참고: 기준선 연결이 있는 인도계 문자 (예: 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의 목적상, 조판 문자 단위의 속성은 그 첫 번째 그래핌 클러스터의 기본 문자에 의해 주어진다—두 경우는 예외이다:
-
Common script의 Enclosing Mark
(
Me)로 형성된 그래핌 클러스터는 Common script의 Other Symbols (So)로 간주된다. 이는 replacement character(U+FFFD)와 같은 Unicode 속성을 가진 것으로 가정된다. -
Space Separator
(
Zs)를 기본 문자로 하여 형성된 그래핌 클러스터는 Modifier Symbols (Sk)로 간주된다. 이는 기본 문자와 같은 East Asian Width 속성을 가진 것으로 가정되지만, 다른 속성은 시퀀스의 첫 번째 결합 문자에서 가져온다.
부록 F: 콘텐츠 문자 체계 식별
이 부록은 규범적이다.
대부분의 언어에는 선호되는 문자 체계가 있지만,
일부 언어에는 여러 문자 체계가 있으며,
대부분은 하나 이상의 외래 문자 체계로도 전사될 수 있다.
흔한 예로, 대부분의 언어에는 적어도 하나의 라틴 문자 전사가 있으며,
따라서 라틴 문자 체계로 쓸 수 있다.
전사된 텍스트는 일반적으로 그 문자 체계의 조판 관례를 따른다:
예를 들어 일본어 “romaji”와 중국어 Pinyin은 라틴 글자와 단어 공백을 사용하며,
그에 따라 라틴 줄 나누기와 양쪽 맞춤 관행을 따른다.
또 다른 예로, 역사적 표의문자 한국어
(ko-Hani)는
단어 공백을 사용하지 않으므로,
현대 한국어보다 중국어와 비슷하게 조판되어야 한다.
HTML 또는 문서 언어 중
콘텐츠 언어를 선언하기 위해
언어 식별에 BCP47 태그를 사용하는 모든 언어에서,
작성자는 script 하위 태그를 사용하여
비전형적인 문자 체계의 사용을 명확히 하거나 표시할 수 있다.
[BCP47]
예를 들어, 본래 라틴 문자를 사용하지 않는 언어에 대해
라틴 문자 체계의 사용을 표시하려면
-Latn script 하위 태그를 추가할 수 있다.
예: 일본어 로마자 표기의 ja-Latn.
다른 문자 체계에는 다른 하위 태그가 존재하며,
ISO의 Code for the Representation of Names of Scripts와 ISO15924 script tag registry를 보라.
[ISO15924]
zh-Latn- 라틴 전사로 쓰인 중국어.
ko-Hani- 한자(중국 표의문자)로 쓰인 한국어.
tr-Arab- 아랍 문자로 쓰인 터키어.
mn-Cyrl- 키릴 문자로 쓰인 몽골어.
mn-Mong- 전통 몽골 문자로 쓰인 몽골어.
그러나 BCP47 script 하위 태그는
단일 문자 체계와 강하게 연결된 언어에는 일반적으로 사용되지 않으며
(사실 권장되지도 않는다);
대신 다른 것이 지정되지 않으면 그 문자 체계가 암시되는 것으로 기대된다.
[BCP47]
IANA는 이를 위해
language subtag
registry의
Suppress-Script 필드를 통해
여러 언어의 가장 일반적인 문자 체계 데이터베이스를 유지한다.
참고: 언어 태그 지정에 대한 더 많은 조언은 Internationalization Working Group의 “Language tags in HTML and XML” 및 “Choosing a Language Tag”에서 찾을 수 있다.
어떤 문자 체계도 명시적으로 표시되지 않은 경우, UA는 줄 나누기나 양쪽 맞춤 같은 언어에 민감한 조판 동작에 대해, 선언된 콘텐츠 언어의 가장 일반적인 문자 체계를 가정해야 한다. 그러나 작성자가 다른 문자 체계를 명시적으로 선언한 경우에는 UA가 그 문자 체계를 가정해서는 안 된다. UA가 특정 언어와 문자 체계 조합에 대한 언어별 지식을 가지고 있지 않으면, (필요한 경우 다른 언어의 관례를 가정하더라도) 선언된 문자 체계의 조판 관례를 사용해야 하며, 선언된 언어가 가정된 문자 체계 안에서 가지는 관례를 사용해서는 안 된다. 이는 선언된 문자 체계에 부적절하기 때문이다.
언어와 그 가장 일반적인 문자 체계 사이의 전체 대응 관계는 이 문서의 범위를 벗어난다. 그러나 사용자 에이전트는 적어도 다음을 가정해야 한다:
- 콘텐츠 언어가 중국어이고 문자 체계가 지정되지 않은 경우, 또는 어떤 콘텐츠 언어에 대해서든 문자 체계가 Hant, Hans, Hani, Hanb, 또는 Bopo ISO script 코드 중 하나로 지정된 경우, 그 문자 체계는 중국어이다.
- 콘텐츠 언어가 일본어이고 문자 체계가 지정되지 않은 경우, 또는 어떤 콘텐츠 언어에 대해서든 문자 체계가 Jpan, Hrkt, Hira, 또는 Kana ISO script 코드 중 하나로 지정된 경우, 그 문자 체계는 일본어이다.
- 콘텐츠 언어가 한국어이고 문자 체계가 지정되지 않은 경우, 또는 어떤 콘텐츠 언어에 대해서든 문자 체계가 Kore, Hang, 또는 Jamo ISO script 코드 중 하나로 지정된 경우, 그 문자 체계는 한국어이다.
-
문자
체계는
콘텐츠
언어 자체가 알려져 있지 않거나,
알 수 없는 문자 체계를 명시적으로 표시하는 경우에만
알 수 없음으로
간주된다.
참고: 콘텐츠 언어가 선언되어 있을 때 문자 체계 정보가 단순히 생략되었다는 것은 그 문자 체계가 알 수 없는 것이 아니라 암시된다는 뜻이다.
부록 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월 후보 권고안 초안 이후에 이루어졌다:
-
line-break: normal에서 작은 가나 앞의 나누기를 금지했다. (Issue 10363)
-
Level 4에서
hanging-punctuation: none규칙을 부록 C: 기본 UA 스타일시트로 백포트했다. -
Level 4 편집 변경 사항과 텍스트를 동기화했다.
다음 규범적 변경 사항은 2023년 9월 후보 권고안 초안 이후에 이루어졌다:
-
text-align-last의 Computed Value 행을 수정했다. (Issue 7331)
-
대체 요소 주변의 소프트 줄바꿈 기회를 명확히 했다. (Issue 9964)
두 문자 사이의 경계로 정의되는 소프트 줄바꿈 기회 또는 원자적 인라인 에 대해서는, 두 문자의 가장 가까운 공통 조상에 있는 white-space 속성이 나누기를 제어한다;
다음 규범적 변경 사항은 2023년 2월 후보 권고안 초안 이후에 이루어졌다.
-
부록 G: 작은 가나 매핑을 Unicode 15.0으로 갱신했다. (Issue 8442)
-
NBSP 이외의 맞춤 불가능한 Unicode 줄 나누기 제어가 원자적 인라인에 대한 우리의 규칙보다 우선하도록 했다. (Issue 8972)
웹 호환성을 위해 각 대체 요소 또는 기타 원자적 인라인 앞뒤에는 소프트 줄바꿈 기회가 있다. 일반적으로 그것들을 억제할 문자와 인접한 경우에도 마찬가지이다.
예를 들면포함하여 U+00A0 NO-BREAK SPACE. 그러나, U+00A0 NO-BREAK SPACE를 제외하면, 원자적 인라인과 Unicode GL, WJ, 또는 ZWJ 줄 나누기 클래스에 속하는 인접 문자 사이에는 소프트 줄바꿈 기회가 없어야 한다. [UAX14]
다음 규범적 변경 사항은 2020년 12월 후보 권고안 이후에 이루어졌다.
-
일반 텍스트 들여쓰기 관행을 수용하기 위해 hanging-punctuation: first가 U+3000 IDEOGRAPHIC SPACE를 행잉할 수 있도록 허용했다. (Issue 2462)
- first
-
요소의 첫 번째 서식 지정된 줄
시작에 있는 여는 괄호
,
또는따옴표 , 또는 표의 문자 공백 가 행잉된다. 이는 Unicode 범주 Ps, Pf, Pi의 모든 문자와 ASCII 따옴표 U+0027 ' APOSTROPHE 및 U+0022 " QUOTATION MARK 그리고 ASCII 따옴표 U+0027 ' APOSTROPHE 및 U+0022 " QUOTATION MARK에 적용된다 및 IDEOGRAPHIC SPACE U+3000 .
-
distribute가 단순히 동일하게 동작하는 것이 아니라, inter-character로 계산된다고 정의했다; 이것이 일부 엔진에 더 쉽고 호환성에 영향을 주지 않으므로, distribute를 레거시 값 별칭으로 구현할 수 있도록 허용했다. (Issue 6156, Issue 7322)
-
언어별 하이픈 넣기 규칙이 명시적 하이픈 넣기 기회에도 적용됨을 명확히 했다. (Issue 5973)
단어는 단어 안에 하이픈 넣기 기회를 명시적으로 제안하는 문자가 있는 곳에서만 하이픈 처리된다. UA는 적절한 언어별 하이픈 넣기 문자(들)를 사용해야 하며, 같은 지점에서 자동 하이픈 넣기를 할 때와 마찬가지로 적절한 철자 변경을 적용해야 한다.
-
match-parent가 루트 요소에서 주요 쓰기 모드에 대해 계산되는 대신 start로 계산되도록 정의했다. (Issue 6542)
-
text-transform에 관한 작성 조언을 규범적 권고로 만들었다. (Issue 8279)
참고: text-transform 속성은 표현 계층에만 영향을 주며; 의미론적 목적을 위한 올바른 대소문자는 원본 문서에 표현될 것으로 기대된다.권고: 작성자는 의미론적 목적을 위해 text-transform에 의존해서는 안 된다; 대신 올바른 대소문자와 의미는 원본 문서 텍스트와 마크업에 인코딩되어야 한다.
그 밖에도 몇 가지 사소한 편집상 수정이 있었다.
이전 변경 사항
또한 해당 후보 권고안 이전의 2020년 및 2019년 작업 초안을 다루는 이전 변경 사항 목록과, 2013년부터 2020년 사이의 모든 의견을 다루는 의견 처리 결과도 보라.