CSS テキストモジュール レベル 4

1. はじめに

このモジュールは CSS の組版制御について説明します。 すなわち、ソーステキストを整形され行折り返しされたテキストへ変換することを制御する CSS の機能です。 さまざまな CSS プロパティにより、 大文字・小文字変換、 空白の折り畳み、 テキストの折り返し、 行分割規則 および ハイフネーション、 配置と両端揃え、 間隔、 そして インデントを制御できます。 レベル 3 以降の追加については レベル 3 以降の追加を参照してください。

世界中のさまざまな言語および書記体系の 組版要件に関する詳細情報は、 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. 値の定義

この仕様は、[CSS2] の CSS プロパティ定義の規約に従い、 [CSS-VALUES-3] の 値定義構文を使用します。 この仕様で定義されない値型は CSS Values & Units [CSS-VALUES-3] で定義されます。 他の CSS モジュールとの組み合わせにより、これらの値型の定義が拡張される場合があります。

各定義に列挙されたプロパティ固有の値に加えて、 この仕様で定義されるすべてのプロパティは、 プロパティ値として CSS 全体キーワードも受け入れます。 読みやすさのため、これらは明示的には繰り返していません。

1.3. 言語と組版

最良の組版動作を得るため、著者はコンテンツに正確な言語タグを付けるべきです。

多くの組版効果は言語的文脈によって異なります。 言語および書記体系の慣習は、 行分割、ハイフネーション、両端揃え、グリフ選択、 そしてその他多くの組版効果に影響することがあります。 CSS では、言語固有の組版調整は 内容言語が既知（宣言済み）である場合にのみ適用されます。 したがって、 より高品質な組版を行うには、著者が文書内のテキストについて 正しい言語的文脈を UA に伝える必要があります。

要素の 内容言語とは、 文書言語の規則に従って、 その要素が属すると宣言されている（人間の）言語です。 要素の 内容言語が不明であることもあり得る点に注意してください—​たとえば、タグ付けされていない内容、 または言語タグ付け機能を持たない 文書言語内の内容は、 不明な 内容言語を持つと見なされます。

注: 著者は HTML のグローバル lang 属性 または XML の汎用 xml:lang 属性を使用して 内容言語を宣言できます。 HTML における HTML 要素の内容言語を決定する規則、 および XML 1.0 における XML 要素の内容言語を決定する規則を参照してください。 [HTML] [XML10]

要素が属すると宣言された 内容言語は、 その要素で使用されるその言語の特定の書記形式も識別します。 これは 内容書記体系として知られます。 内容言語を識別するための 文書言語の仕組みに応じて、 この情報は明示的な場合も暗黙的な場合もあります。 規範的な 付録 F: 内容の書記体系の識別を参照してください。

注: 一部の言語には複数の書記体系の伝統があります。 また、言語が外来の書記体系へ翻字される場合もあります。 著者は、UA が適切に適応できるよう、 そのような場合にはサブタグを付けるべきです。

1.4. 文字と字母

組版の基本単位は 文字です。 しかし、書記体系は基本的な英語アルファベットほど単純とは限らないため、 文字が実際に何を意味するかは、 その用語が使用される文脈によって異なります。 たとえば、ハングル（韓国語の書記体系）では、 1 つの音節を表す四角い表記 （例: 한=Han） を 文字と見なすことができます。 しかし、この四角い記号は実際には、音素を表す複数の字母から構成されています （例: ㅎ=h, ㅏ=a, ㄴ=n）。 そしてこれらもそれぞれ 文字と見なされる場合があります。

任意の符号化におけるコンピュータテキスト符号化の基本単位も 文字と呼ばれます。 符号化によっては、 1 つの符号化された 文字が、 事前合成された音節 文字全体（例: 한）に対応することも、 個々の音素的 文字（例: ㅎ）に対応することも、 または、基底字形（例: ㅇ） や、それを変化させる結合記号（例: 帯気を表す追加画）などの より小さな単位に対応することもあります。

さらに、1 つの符号化された 文字は、 データストリーム内で 1 つまたは複数のバイトとして表現されることがあります。 またプログラミング環境では、1 バイトが 文字と呼ばれることもあります。

したがって、技術的な精度が求められる場合、 文字という用語はかなり曖昧です。

テキストレイアウトでは、テキストの基本単位として 組版上の 文字単位を指すことにします。 テキストレイアウトの範囲内であっても、 関連する 文字単位は 操作によって異なります。 たとえば、行分割および字間調整は、 U+0E33 ำ THAI CHARACTER SARA AM を含むタイ文字列を異なる方法で分節します。 また、デーヴァナーガリーなどの文字体系における結合子音の挙動は、 使用されるフォントに依存する場合があります。 したがって、組版上の文字は、 特定の組版操作（行分割、first-letter 効果、字間調整、両端揃え、縦配置など）に関して 分割不能である、書記体系の単位—​たとえばラテンアルファベットの字母（発音区別符を含む）、 ハングル音節、 中国語の表意文字、 ミャンマー文字の音節クラスタ—​を表します。

Unicode Standard Annex #29: Text Segmentation は、組版上の文字に近似する 書記素クラスタと呼ばれる単位を定義しています。 [UAX29] UA は、UAX29 で定義される 拡張書記素クラスタ （旧来の書記素クラスタではない）を、 その 組版上の文字単位の基礎として使用しなければなりません。 ただし、既定の規則が常に適切または理想的であるとは限らないため、 UA は組版上の伝統に応じて定義を調整すべきであり、 必要に応じて操作ごとに異なる調整を行うことが期待されます。

注: このような調整の規則は CSS の範囲外です。

組版上の字母 単位 （またはこの仕様の目的における 字母） は、Letter または Number の 一般 カテゴリのいずれかに属する 組版上の文字単位です。 組版上の 文字単位の Unicode プロパティをどのように決定するかについては、 付録 E: 文字とプロパティを参照してください。

要素境界によって分割された 組版上の文字単位の描画特性は未定義です。 理想的には、各構成要素は、 組版上の文字単位全体の 正しいシェーピングと配置を維持しつつ、 それぞれの要素のプロパティの整形要件に従って描画されるべきです。 しかし、その部分間の整形上の違いの性質や 使用されるフォント技術の能力によっては、 これが常に可能とは限りません。 したがって、そのような 組版上の文字単位は、 境界のいずれか一方に属するものとして描画されたり、 または双方に属する何らかの近似として描画されたりすることがあります。 著者は、書記素クラスタ または合字を 要素境界で分割すると、一貫性のない、または望ましくない結果になる場合があることに注意してください。

1.5. テキスト処理

CSS は Unicode を基盤としています。 [UNICODE] Unicode をサポートする UA は、 CSS によって明示的に上書きされる場合を除き、 Unicode Core Standard のすべての規範的要件に従わなければなりません。 非 Unicode テキスト符号化モデルを基礎として実装された UA も、 適切な対応付けおよび類似の挙動を仮定することによって、 同じテキスト処理要件を満たすことが期待されます。

テキスト処理 （空白処理、テキスト変換、行分割など）のための隣接性を判断する目的では、 したがってこの仕様内では一般に、 介在する インラインボックス境界および 通常フロー外 要素 は無視しなければなりません。 ただし、テキストシェーピングに関しては、§ 8.7 要素境界をまたぐシェーピングを参照してください。

2. テキストの変換

2.1. 大文字・小文字変換: text-transform プロパティ

このプロパティは、スタイル付けの目的でテキストを変換します。 これは基礎となる内容には影響せず、 プレーンテキストのコピー＆ペースト操作の内容に影響してはなりません。

著者は、意味的な目的で text-transform に依存してはなりません。 むしろ、正しい大文字・小文字表記および意味は、 ソース文書のテキストとマークアップに符号化されるべきです。

値は次の意味を持ちます:

none

効果なし。

capitalize

各単語の最初の 組版上の字母単位が小文字である場合、 タイトルケースにします。 その他の文字は影響を受けません。

uppercase

すべての 字母を大文字にします。

lowercase

すべての 字母を小文字にします。

full-width

すべての 組版上の文字単位を 全角形式にします。 文字に対応する 全角形式がない場合、 そのままにされます。 この値は通常、ラテン字母や数字を 表意文字であるかのように組むために使用されます。

full-size-kana

すべての 小書き仮名 文字を、対応する 通常サイズの仮名に変換します。 この値は通常、ルビ注釈テキストに使用されます。 そこでは、ルビで通常使用される小さなフォントサイズにおける読みやすさの問題を補うため、 著者がすべての小書き仮名を大きな仮名として描画したい場合があります。

math-auto

MathML Core § 4.2 The math-auto transform を参照してください。

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

注: text-transform の目的は、 文書の意味に影響を与えずに 表示上の大文字・小文字変換を可能にすることです。 特に、text-transform の大文字・小文字操作は情報を失うものであり、 テキストの意味を歪める可能性がある点に注意してください。 アクセシビリティインターフェースは、 描画されたテキストの見かけ上の大文字・小文字を利用者に伝えたい場合がありますが、 変換されたテキストが文書の基礎となる意味を正確に表すことには依存できません。

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

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

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

2.1.1. マッピング規則

capitalize について、何が「単語」を構成するかは UA 依存です。 [UAX29] は そのような単語境界を判断するために推奨されます （ただし必須ではありません）。 通常フロー外ボックスおよび インラインボックス 境界は、 text-transform の単語境界を導入してはならず、 そのような単語境界を判断するときには無視しなければなりません。

注: 著者は、 capitalize が 言語固有のタイトルケース規約 （英語で冠詞を飛ばすなど）に従うことには依存できません。

UA は Unicode 文字に対する完全な大文字・小文字マッピングを使用しなければなりません。 これには、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.2. 単語間の拡張: word-space-transform プロパティ

一部の言語や書記体系には、 単語を区切る別の方法があります。 それは異なる区切り文字を使用する場合もあれば、 可視文字をまったく使用しない場合もあります。 このプロパティにより、著者はマークアップを変更する必要なく、 レンダリングをあるスタイルから別のスタイルへ変更できます。

none

このプロパティは効果を持ちません。

space

この要素の子 テキスト内の 拡張可能 区切り は U+0020 SPACE に置き換えられます。

ideographic-space

この要素の子 テキスト内の 拡張可能 区切り は U+3000 IDEOGRAPHIC SPACE に置き換えられます。

auto-phrase

内容 言語が既知であり、 ユーザーエージェントがその言語の言語解析をサポートする場合、 ユーザーエージェントは フレーズ境界を検出しなければなりません。 その境界に 単語区切り 文字、 その他の空白 区切り、 または U+200B ZERO WIDTH SPACE 文字が 既に存在しない場合、 UA は 仮想拡張可能区切りを挿入しなければなりません。

この値が省略されている場合、 または 内容 言語が不明である場合、 またはユーザーエージェントがその言語について フレーズ境界の検出をサポートしない場合、 仮想拡張可能区切りは存在しません。

このプロパティの目的では、 拡張可能 区切りとは、次のいずれかです:

• U+200B ZERO WIDTH SPACE 文字

• wbr 要素

• 仮想拡張可能区切り

仮想 拡張可能区切りとは、 ソース文書には他の形で出現しない 拡張可能区切り を表す、テキスト内で UA が検出した構文上の境界です。 これはこのプロパティ以外には効果を持ちません。

ユーザーエージェントは、 強制改行の 直前または直後にある 拡張可能 区切り を置き換えてはなりません （介在するインラインボックス境界、 および関連する margin/border/padding を無視します）。

注: 仮想拡張可能 区切りは インラインボックス境界に関与する最外側の要素内に配置されるため、 それが、親ボックスが word-space-transform: none の 使用値 を持つインラインボックスの境界と一致する場合、 その特定の 仮想拡張可能区切りは 拡張されません。 それは親ボックス内に配置されるためです。

text-transform と同様に、このプロパティはスタイル付けの目的でのみ テキストを変換します。 これは基礎となる内容には影響せず、 プレーンテキストのコピー＆ペースト操作の内容に影響してはなりません。

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

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

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

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

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

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

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

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

2.3. 処理の順序

複数の変換を適用する必要がある場合、 それらは次の順序で適用されます:

1. word-space-transform
2. capitalize、uppercase、 および lowercase
3. full-width
4. full-size-kana

単語間隔変換および テキスト変換は、§ 4.3.1 フェーズ I: 折り畳みと 変換の後、 ただし § 4.3.2 フェーズ II: トリミングと配置の前に発生します。 これは、たとえば full-width が 保持された 空白内の スペース（U+0020）のみを U+3000 IDEOGRAPHIC SPACE に変換することを意味します。

注: 付録 A: テキスト処理の処理順序で定義されるように、 変換は行分割およびその他の整形操作に影響します。

3. 空白と折り返し: white-space プロパティ

このプロパティは、white-space-collapse、text-wrap-mode、および white-space-trim の一括指定です。 これは 2 つのことを指定します:

• 空白が 折り畳まれるかどうか、およびどのように折り畳まれるか。 空白処理を参照
• 強制されない ソフト折り返し 機会で行が 折り返せるかどうか。 § 5 テキストの折り返しおよび 行分割を参照

注: この一括指定は、継承されるプロパティと 継承されないプロパティの双方を組み合わせます。 これが問題である場合は、CSSWG に知らせてください。

特に指定されない限り、省略された 個別指定 は、その 初期値に設定されます。

次の表は、 一括指定の特殊キーワードの値を、 それと等価な 個別指定値へ対応付ける規範的な対応表です。

注: 場合によっては、 保持された空白 および その他の空白区切り は行末にあるときに ぶら下がることがあります。 これは 内在的 サイズ決定でそれらが計測されるかどうかに影響する可能性があります。

次の参考表は、 さまざまな white-space 値の挙動を要約したものです:

4. 空白処理と制御文字

文書のソーステキストには、最終的なレンダリングには関係しない整形が含まれることがよくあります: たとえば、 編集しやすくするためにソースをセグメント （行）に分割したり、 ソースコードをインデントするために タブや スペースなどの 空白文字 を追加したりすることです。 CSS の空白処理により、著者はそのような整形の解釈を制御できます: 文書をレンダリングするときにそれを保持するか、折り畳んで取り除くかです。 CSS における空白処理 （white-space-collapse および white-space-trim プロパティで制御される） は、レンダリングのためだけに 空白文字を解釈します: 基礎となる文書データには影響しません。

注: 文書言語によっては、 セグメントは特定の改行シーケンス （ラインフィードや CRLF ペアなど）で区切られる場合もあれば、 SGML の RECORD-START および RECORD-END トークンなど、 別の機構で区切られる場合もあります。

CSS 処理では、 各文書言語で定義された「セグメント区切り」または「改行シーケンス」—​またはそれらが定義されていない場合は、テキスト内の各ラインフィード （U+000A）—​は セグメント区切りとして扱われ、 その後 white-space プロパティで指定されるようにレンダリングのために解釈されます。

HTML の場合、 改行は DOM 内での表現のために ラインフィード文字（U+000A）へ 正規化されます。 そのため、HTML 文書が DOM ツリーとして表現されるとき、 各ラインフィード（U+000A）は セグメント区切りとして扱われます。 [HTML] [DOM]

注: 最も一般的な CSS 実装では、 HTML は直接スタイル付けされません。 代わりに、DOM ツリーへ処理され、 その後スタイル付けされます。 HTML と異なり、 DOM はキャリッジリターン（U+000D）に特定の意味を与えないため、 それらは セグメント 区切りとして扱われません。 HTML 解析以外の手段でキャリッジリターン（U+000D）が DOM に挿入された場合、 それらは以下で定義されるように扱われます。

注: 文書パーサーは、 セグメント 区切りを正規化するだけでなく、 他の空白文字を折り畳んだり、 マークアップ規則に従って空白を処理したりすることがあります。 CSS 処理は解析段階の後に行われるため、 これらの文字をスタイル付けのために復元することはできません。 したがって、以下で指定される挙動の一部は これらの制限の影響を受けることがあり、 ユーザーエージェント依存となる場合があります。

注: 折り畳み可能な 空白のみで構成される匿名ブロックは、 レンダリングツリーから削除されます。 したがって、ブロックレベル要素を囲むそのような 空白は 折り畳まれて取り除かれます。 CSS 2 § 9.2.2.1 Anonymous inline boxes を参照してください。 [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 Preprocessing the input stream および Infra における normalize newlines の定義を参照）。 したがって CSS には U+000D CARRIAGE RETURN としては現れません。 [HTML] [INFRA]) ただし、文字はエスケープシーケンス （
）を使用して符号化された場合には保持され、 上記の規則を観察できます。

4.1. 空白の折り畳み: white-space-collapse プロパティ

この節はまだ 議論中であり、将来の草案で変更される可能性があります。

このプロパティは、 空白 を折り畳むかどうか、およびどのように折り畳むかを指定します。 値は次の意味を持ち、 空白処理規則に従って 解釈されなければなりません:

collapse

この値は、ユーザーエージェントに対し、空白の連続を 1 つの文字 （または場合によっては文字なし）へ折り畳むよう指示します。

preserve

この値は、ユーザーエージェントが 空白の連続を折り畳むことを防ぎます。 ラインフィードなどの セグメント区切りは 強制改行として保持されます。

preserve-breaks

collapse と同様に、 この値は連続する 空白文字を折り畳みますが、 ソース内の セグメント 区切りは 強制改行として保持します。

preserve-spaces

この値は、ユーザーエージェントが 空白の連続を 折り畳むことを防ぎ、 タブおよび セグメント区切りを スペースへ変換します。 （この値は、SVG における xml:space="preserve" の挙動を表すことを意図しています。）

break-spaces

挙動は preserve と同一ですが、 次の点を除きます:

• 保持された 空白 または その他の空白区切りの 任意の連続は、 行末を含めて常に空間を占めます。
• 保持された 空白文字の後、 および その他の空白区切りの後には （隣接するスペース間を含めて） 常に ソフト 折り返し機会が存在します。

注: この値は、 空白によるオーバーフローが決して発生しないことを保証しません: たとえば、行の長さが非常に短く、 単一の空白文字すら収まらない場合、 オーバーフローは避けられません。

discard

この値は、ユーザーエージェントに対し、 要素内のすべての空白を「破棄」するよう指示します。

これは 改行機会を保持するのか、それとも保持しないのか？ 別個の "hide" 値が必要か？ 改行機会を保持する場合、 word-space-transform の値で置き換えるべきかもしれない？

空白処理によって削除または折り畳まれなかった 空白は、 保持された空白と呼ばれます。

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

4.2. 空白のトリミング: white-space-trim プロパティ

このプロパティにより、著者は ボックスの先頭および末尾におけるトリミング挙動を指定できます。 値は次の意味を持ちます:

discard-before

この値は、要素の開始直前にあるすべての折り畳み可能な空白を 折り畳むよう UA に指示します。

discard-after

この値は、要素の終了直後にあるすべての折り畳み可能な空白を 折り畳むよう UA に指示します。

discard-inner

ブロックコンテナーに対して、この値は、 要素内の最初の非空白文字の前にある最後の セグメント区切りまで （それを含む）要素の先頭のすべての空白を破棄し、 さらに、要素内の最後の非空白文字の後にある最初の セグメント区切りから始まる 要素の末尾のすべての空白を破棄するよう UA に指示します。 その他の要素に対して、この値は、 要素の先頭および末尾のすべての空白を破棄するよう UA に指示します。

注: 文書空白を white-space-trim によって破棄すると、 テキスト中で ソフト折り返し機会が発生する場所が変化する可能性があります。

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

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

<pre>

  some
preformatted

  text

</pre>

<pre>  some
preformatted

  text</pre>

  some
preformatted

  text

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

start[<span>

  some
inline
  text

</span>]end

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

start[some inline text]end

white-space-trim の空白処理は、 § 4.3.1 フェーズ I: 折り畳みと変換の前に行われます。

4.3. 空白処理規則

別途指定されない限り、 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.3.1. フェーズ I: 折り畳みと変換

注: white-space-trim は このフェーズの前に考慮されます。

インライン整形コンテキスト内の 各インライン （匿名インラインを含む。 CSS 2 § 9.2.2.1 Anonymous inline boxes [CSS2] を参照） について、 空白文字は、 行分割 および 双方向 並べ替えの前に、 双方向 整形文字 （Bidi_Control プロパティを持つ文字 [UAX9]）を 存在しないものとして無視し、次のように処理されます:

• white-space-collapse が collapse または preserve-breaks に設定されている場合、 空白文字は 折り畳み可能と見なされ、 次の手順を実行することによって処理されます:
  1. セグメント区切りの直前または直後にある 折り畳み可能な スペースおよび タブの任意の連続は 削除されます。
  2. 折り畳み可能な セグメント 区切りは、 セグメント区切り変換規則に従って レンダリングのために変換されます。
  3. すべての 折り畳み可能な タブは、折り畳み可能なスペース（U+0020）に変換されます。
  4. 別の 折り畳み可能な スペースの直後にある 任意の 折り畳み可能な スペースは—​その スペースを含む インラインの境界の外側にあるものであっても、 両方の スペースが同じインライン整形 コンテキスト内にある限り—​前進幅が 0 になるように折り畳まれます。 （それは不可視ですが、 ソフト折り返し機会があれば、 それを保持します。）
• white-space-collapse が preserve-spaces に設定されている場合、 各 タブおよび セグメント区切りは スペースへ変換されます。
• white-space-collapse が preserve または preserve-spaces に設定されている場合、 スペースの任意の連続は、改行しないスペースの連続として扱われます。 ただし、 スペースおよび/または タブの各最大連続の末尾には ソフト折り返し 機会が存在します。 break-spaces では、 各 スペースおよび各 タブの後に ソフト折り返し機会が存在します。

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

A  BC

4.3.2. フェーズ II: トリミングと配置

次に、ブロック全体がレンダリングされます。 インラインは、 双方向並べ替えを考慮し、 text-wrap-mode および text-wrap-style プロパティで指定される 折り返しに従って レイアウトされます。 各行がレイアウトされる際、

1. 行の先頭にある 折り畳み可能な スペースの連続は 削除されます。
2. タブサイズが 0 の場合、 保持された タブはレンダリングされません。 それ以外の場合、各 保持された タブは、 次のグリフの開始端を次の タブ位置に揃える 水平方向の移動としてレンダリングされます。 この距離が 0.5ch 未満である場合、 代わりにその次の タブ位置が使用されます。 タブ 位置は、 保持された タブに最も近い ブロックコンテナー祖先の 開始コンテンツ端から、 タブサイズの倍数となる位置に発生します。 タブサイズは tab-size プロパティによって与えられます。

   注: タブ（U+0009）が bidi とどのように相互作用するかについては、Unicode の 規則を参照してください。 [UAX9]

3. 行末にある 折り畳み可能な スペースの連続は削除されます。 また、white-space-collapse プロパティが collapse または preserve-breaks である 末尾の U+1680   OGHAM SPACE MARK も削除されます。

   注: Unicode Bidirectional Algorithm の規則 L1 により、 双方向並べ替えの前に 行末に位置していた 折り畳み可能な スペースの連続は、 並べ替え後も行末にあります。 [UAX9] [CSS-WRITING-MODES-4]

4. 行末に 空白、 その他の空白 区切り、 および/または 保持された タブの連続が残っている場合 （双方向並べ替え後 [CSS-WRITING-MODES-4]）:
   • white-space-collapse が collapse または preserve-breaks である場合、 UA はこの連続を（無条件に） ぶら下げなければなりません。
   • white-space-collapse が preserve であり、 かつ text-wrap-mode が nowrap でない場合、 UA はこの連続を（無条件に） ぶら下げなければなりません。 ただし、その連続の後に 強制改行が続く場合は、 代わりにその連続を 条件付きでぶら下げなければなりません。 また、そうしなければオーバーフローするものについては、 文字の前進幅を視覚的に折り畳んでもよいです。

     注: 空白を折り畳むのではなく ぶら下げることで、 ユーザーはテキストを選択または編集するときにその空白を見ることができます。

   • white-space-collapse が break-spaces に設定されている場合、 スペース、タブ、および その他の空白 区切り は、他の可視文字と同じように扱われます: それらは ぶら下がることも、 前進幅を折り畳まれることもありません。

     注: したがって、そのような文字は 空間を占め、 利用可能な空間 および適用される行分割制御に応じて、 オーバーフローするか、行の折り返しを引き起こします。

   white-space-collapse: preserve-spaces の場合、 ここでは何が起こるべきか？

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

<p> 0 </p>

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

<p> 0 0 0 0 </p>

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

<p>0 0 0 0 </p>

4.3.3. セグメント区切り変換規則

white-space-collapse が collapse でない場合、 セグメント区切りは 折り畳み可能ではありません。 collapse または preserve-spaces （それらを スペースへ変換する） 以外の値では、 セグメント区切りは代わりに保持されたラインフィード （U+000A）へ変換されます。

white-space-collapse が collapse である場合、 セグメント区切りは 折り畳み可能であり、 次のように折り畳まれます:

1. まず、別の折り畳み可能な セグメント区切りの直後にある 任意の折り畳み可能な セグメント区切りは 削除されます。
2. 次に、残っている任意の セグメント 区切りは、 区切りの前後の文脈に応じて、 スペース（U+0020）へ変換されるか、 削除されます。 この操作の規則は、このレベルでは UA 定義です。

   これは レベル 4 で定義すべきか？

   注: この文脈が評価される前に、 空白処理規則は セグメント区切りの周囲にある 任意の タブおよび スペースを 既に削除しています。

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

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

注: 歴史的に、HTML と CSS は セグメント区切りを 無条件にスペースへ変換してきました。 これにより、中国語などの言語で作成された内容は、 ソース内で行を分割できない状態になっていました。 したがって、UA のヒューリスティックは、そのような言語への対応を改善しようとする一方で、 セグメント区切りを破棄する場所について 慎重である必要があります。

4.4. タブ文字のサイズ: tab-size プロパティ

このプロパティは、保持されたタブ文字（U+0009）をレンダリングするために使用される タブ サイズを決定します。 <number> は、 保持された タブに最も近い ブロックコンテナー祖先の スペース文字（U+0020）の前進幅の倍数としての寸法を表します。 これには、それに関連する letter-spacing および word-spacing も含まれます。 負の値は許可されません。

5. テキストの折り返し

インラインレベルの内容が行へレイアウトされるとき、それはラインボックスをまたいで分割されます。 そのような分割は 改行と呼ばれます。 明示的な改行制御 （保持された改行文字など） によって行が分割される場合、 またはブロックの開始または終了によって分割される場合、 それは 強制改行です。 内容の 折り返しによって行が分割される場合 （すなわち、内容を寸法内に収めるために UA が強制されない改行を作成する場合）、 それは ソフト折り返し 改行です。 インラインレベルの内容を行に分割する処理は、行分割と呼ばれます。

折り返しは、許可された分割点でのみ行われます。 その点は ソフト折り返し 機会と呼ばれます。 折り返しが有効な場合（white-space を参照）、 UA は、ソフト折り返し機会が存在するなら、 そこで行を折り返すことにより、 行からオーバーフローする内容の量を最小化しなければなりません。 有効な ソフト折り返し機会は、 内容言語 および書記体系、 ならびにそれらを制御する CSS プロパティに依存します。 § 6 行分割と単語境界を参照してください。

テキストがどこで折り返せるかは、 行分割規則および制御によって制御されます。 それが折り返しを許可されるかどうか、 および行内の複数の ソフト折り返し機会がどのように優先されるかは、 text-wrap-mode、 text-wrap-style、 wrap-before、 wrap-after、 および wrap-inside プロパティによって制御されます。

5.1. 折り返すかどうかの決定: text-wrap-mode プロパティ

このプロパティは、インラインレベル の内容が、 強制されない ソフト折り返し 機会で 折り返すかどうかを指定します。

注: このプロパティは、個別指定であり、 white-space と text-wrap の双方の個別指定です。

可能な値:

wrap

有効な行分割規則によって決定される、許可された ソフト折り返し 機会で、 折り返しが行われてもよく、 これは インライン軸方向のオーバーフローを最小化するためです。

注: § 6.5 行分割の詳細では、 ソフト折り返し機会に関する規則および制約について、 より詳しい情報を示しています。

nowrap

行は 強制改行でのみ分割されます。 ブロックコンテナー内に収まらない内容は、それをオーバーフローします。

text-wrap-mode の値に関係なく、 保持された セグメント区切り、 および BK、CR、LF、NL の行分割クラスを持つ任意の Unicode 文字は、 強制 改行として扱われなければなりません。 [UAX14]

注: そのような 強制改行の 双方向性への影響は、 Unicode Bidirectional Algorithm によって定義されます。 [UAX9]

5.2. ボックス内の分割制御: wrap-inside プロパティ

auto

有効な行分割規則によって決定される、許可された分割点で、 ボックス内の行が分割されてもよいです。

avoid

ボックス内での行分割は抑制されます: UA は、その行に他の有効な分割点がない場合に限り、 ボックス内で分割してもよいです。 テキストが分割される場合、 行分割制約は auto の場合と同様に尊重されます。

avoid を持つボックスが入れ子になっており、 UA がこれらのボックス内で分割しなければならない場合、 内側のボックス内の分割を使用する前に、 外側のボックス内の分割を使用しなければなりません。

5.2.1. フッター表示における 'wrap-inside: avoid' の使用例

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

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

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

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

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

5.3. ボックス間の分割制御: wrap-before/wrap-after プロパティ

これらのプロパティは、行分割 （および フレックス行分割 [CSS3-FLEXBOX]） における分割機会への変更を指定します。 可能な値:

auto

有効な行分割規則によって決定される、許可された分割点で、 ボックスの前後の行が分割されてもよいです。

avoid

ボックスの直前/直後での行分割は抑制されます: UA は、その行に他の有効な分割点がない場合に限り、 そこで分割してもよいです。 テキストが分割される場合、 行分割制約は auto の場合と同様に尊重されます。

avoid-line

avoid と同じですが、 行分割に対してのみです。

avoid-flex

avoid と同じですが、 フレックス行分割に対してのみです。

line

ボックスが インラインレベルボックスである場合、 その直前/直後に強制的に行分割します。

flex

ボックスが 複数行フレックスコンテナー内の フレックスアイテムである場合、 その直前/直後に強制的に フレックス行を分割します。

インラインレベルボックス上の強制行分割は、 ブロックレベルボックス上の 強制分割が、同じ 断片化コンテキスト内の任意の親 ブロックボックスを通じて上方へ伝播するのと同じ方法で、 任意の親 インラインボックスを通じて上方へ伝播します。 [CSS3-BREAK]

5.4. 折り返し方法の選択: text-wrap-style プロパティ

CSSWG は avoid-orphans のより良い名前を探しています。

折り返しが許可されている場合 （text-wrap-mode を参照）、 このプロパティは、行を折り返すための複数の方法の中から選択し、 速度、レイアウトの品質とスタイル、または安定性の間でトレードオフを行います。 これは、どの ソフト折り返し機会が存在するかを変えるものではなく、 ユーザーエージェントがそれらの中からどのように選択するかを変えます。 可能な値:

auto

どの ソフト 折り返し機会で分割するかを選択する正確なアルゴリズムは UA 定義です。 このアルゴリズムは、分割判断を行う際に複数行を考慮してもよいです。 UA は最良のレイアウトより速度を優先してもよいです。 UA は、balance の場合のように、 （最後の行を含む）すべての行を均等化しようとしてはなりません。 この値は、UA の推奨する（または最も Web 互換のある） 折り返しアルゴリズムを選択します。

balance

行分割は、各ラインボックス内に残る（空の）空間を バランスさせるように選択されます。 ただし、auto より良いバランスが可能な場合に限ります。 これは、text-wrap が auto に設定されていた場合に そのブロックが含むであろうラインボックスの数を 変更しないようにするべきであり、5 行以下の場合は変更してはなりません。

注: それでも、 どの内容が同じ行に現れるかの変化により、 ラインボックスの高さが変わることがあります。

考慮する残りの空間とは、 float とインライン内容を配置した後、 ただしテキストの両端揃えによる調整の前に残る空間です。 各ラインボックス内の残り空間の平均 インラインサイズからの標準偏差が、 ブロック全体で （強制改行で終わる行を含めて） 減少した場合、ラインボックスはバランスされています。

強制改行で区切られた行のグループは、 個別に処理されます。 要素が line-clamp の影響を受ける場合、 まずクランプ効果が適用され、 その後、残りの行がバランスされます。

正確なアルゴリズムは UA 定義です。

UA は、バランスを取る行が 10 行を超える場合、 この値を auto として扱ってもよいです。

stable

後続の行の内容は、分割判断を行う際に 考慮されるべきではないことを指定します。 これにより、テキスト編集中にカーソルより前の内容が 安定したままになります。 それ以外は auto と等価です。

pretty

UA が速度よりもより良いレイアウトを優先すべきであり、 分割判断を行う際に複数行を考慮することが期待されることを指定します。 それ以外は auto と等価です。

ユーザーエージェントは、とりわけ、 avoid-orphans と同様に、 過度に短い最終行を避けようとしてもよいですが、 さらに追加の方法でレイアウトを改善すべきです。 改善の正確な集合はユーザーエージェント依存であり、 次のようなものを含む場合があります: 行間の長さのばらつきを減らすこと、 タイポグラフィ上のリバーを避けること、 異なる種類の ソフト折り返し機会、 ハイフネーション 機会、または 両端揃え機会を優先すること、 あまりにも多くの連続する行でハイフネーションを避けること…

必要な計算は高コストになる可能性があります。 特に大量のテキストに適用される場合はそうです。 著者は text-wrap-style: pretty を使用する際に パフォーマンスへの影響を評価し、 重要な箇所に限定して使用することが推奨されます。

avoid-orphans

UA が過度に短い最終行を避けるべきであり、 分割判断を行う際に複数行を考慮することが期待されることを指定します （たとえば、孤立語を「修正」するために 直前の行を短くしすぎることを避けるため）。 ユーザーエージェントは、 それによって前の行の一部が大きく不均衡になる場合、 最終行の改善を行わないと判断してもよいです。 ユーザーエージェントは、 それらの改善が大きなパフォーマンスコストを伴う場合、 auto を超えてレイアウトの他の側面を改善しようとすべきではありません。

注: 西洋の組版では、“orphan” は 段落の最終行に単一語だけがあることを指す場合があります。 しかし、すべての言語や書記体系が単語境界で行を折り返すわけではなく、 またそうする言語であっても、 最終行に数個の非常に短い語だけがあることは望ましくない場合があります。 特に利用可能なインライン空間が長い場合はそうです。 したがって、この仕様は、 行が単一語だけで構成される場合に限って短すぎるとは厳密に定義せず、 何が過度に短いかの判断をユーザーエージェントに委ねます。

注: 断片化の制御および “orphans” のもう一つの組版上の意味については、 orphans プロパティも参照してください。

たとえば、与えられた行長では、次のテキストは最終行に単一語を置いて 折り返されることになり、 これは短すぎると判断される可能性があります。

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

text-wrap-style: avoid-orphans を適用すると、 代わりに次のような結果になり、 こちらの方がより好ましいと考えられます:

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

しかし、次の断片はより悩ましいものです:

Circumnavigating
the Mississippi
river

最終行を短すぎないようにするため、前の行を早めに折り返そうとすると、 次のような結果になります:

Circumnavigating
the
Mississippi river

最終行は確かに短くなくなりますが、 最後から 2 番目の行は見苦しくなります。 このような場合、ユーザーエージェントは、 text-wrap-style: avoid-orphans が設定されていても、 最初の描画を優先することが期待されます。

注: auto 値は通常、 Web ブラウザーの高速な従来の行分割に対応します。 これはこれまで first-fit/greedy アルゴリズムを使用してきており、 しばしば最適ではない結果を生じることがあります。 UA は、この既定値でより良い行分割アルゴリズムを試すことができますが、 最適な結果にはより多くの時間がかかることが多いため、 pretty および avoid-orphans は、 より良い結果のためにより多くの時間をかけることを選択する opt-in として提供されます。 どちらの値も本文向けであり、 最終行は平均的な行よりやや短いことが期待されます。 ただし avoid-orphans は、 パフォーマンスを保ちながら過度に短い最終行を避けることを目的とし、 一方 pretty は、 さらに良いレイアウトを追求するためにより多くの速度を犠牲にできます。 balance 値は、 同じ長さのテキスト行が好まれがちなタイトルやキャプション向けです。 そして stable は、 編集可能である、または編集可能へ切り替えられる可能性が高い部分向けです。

5.5. 折り返しの統合制御: text-wrap 一括指定プロパティ

このプロパティは、text-wrap-mode および text-wrap-style プロパティの一括指定です。 省略された任意の 個別指定は、その 初期値に設定されます。

6. 行分割と単語境界

ほとんどの書記体系では、 ハイフネーションがない場合、ソフト折り返し機会は通常、単語境界でのみ発生します。 そのような体系の多く（ラテンアルファベットで書かれた英語など）は、 単語を明示的に区切るために スペース または句読点を使用し、 ソフト折り返し機会はそれらの文字によって識別できます。

しかし、タイ語、ラオ語、クメール語などの文字体系では、 単語を区切るためにスペースや句読点を使用しません。 これらの文字体系では、ゼロ幅スペース（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] 追加で適切な参考文献に関する案内があれば、 大いに歓迎されます。

6.1. 字母の分割規則: word-break プロパティ

このプロパティは、「単語」の間および内部の ソフト折り返し機会、 すなわちテキスト行を分割することが「通常」であり許容される場所を指定します。 これは字母間の分割に焦点を当てており、 空白および その他の空白 区切りによって ソフト折り返し 機会が作成されるかどうか、およびどのように作成されるか （ただし auto-phrase は一部を抑制する場合があります）、 また句読点の周囲については定義しません。 （句読点および小書き仮名に影響する制御については、 line-break を参照してください。）

特に、 word-break は、 隣接する 組版上の字母単位の間に ソフト折り返し機会が 一般に存在するかどうかを制御します。 この目的（のみ）のため、 NU、 AL、 AI、 または ID の Unicode 行分割クラスに属する、字母でない 組版上の文字 単位を 組版上の字母単位として扱います。 [UAX14]

たとえば、 CJK 組版の一部のスタイルでは、 英単語はスペースやハイフネーション点でのみ分割されるのではなく、 任意の 2 つの字母の間で分割されることが許可されます。 これは word-break:break-all によって有効にできます。

別の例として、韓国語には 2 つの行分割スタイルがあります: 任意の 2 つの韓国語音節の間 （word-break: normal） または、英語のように主にスペースで （word-break: keep-all）。

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

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

エチオピア文字にも同様に 2 つの行分割スタイルがあり、 単語 区切りでのみ分割する （word-break: normal）か、 単語内の字母間の分割も許可する （word-break: break-all）かです。

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

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

注: オーバーフローの場合に限って 追加の分割機会を有効にするには、 overflow-wrap を参照してください。

値は次の意味を持ちます:

normal

単語は、上記で説明した慣習的な規則に従って分割されます。 一般に 2 つの異なる挙動を示す韓国語では、 任意の 2 つの連続するハングル/漢字の間での分割が許可されます。 同じく 2 つの異なる挙動を示すエチオピア文字では、 単語内のそのような分割は許可されません。

いくつかの書記体系では、慣習的に期待される ソフト折り返し機会を得るために、 § 6.1.1 解析的単語分割で説明するような 特定の処理が必要です。

break-all

「単語」内での分割が許可されます: 具体的には、 normal で許可される ソフト折り返し機会に加えて、 任意の 組版上の字母単位 （および、NU（“numeric”）、 AL（“alphabetic”）、 または SA（“Southeast Asian”） の行分割クラス [UAX14] に解決される任意の 組版上の文字単位）は、 行分割の目的では、代わりに ID （“ideographic characters”）として扱われます。 ハイフネーションは適用されません。

注: この値は、 句読点文字の周囲に ソフト折り返し機会 があるかどうかには影響しません。 任意の場所で分割を許可するには、 line-break: anywhere を参照してください。

注: このオプションは、 エチオピア文字に対するもう一つの一般的な挙動を有効にします。 また、テキストが主に CJK 文字で構成され、 短い非 CJK の抜粋だけを含み、 各行でテキストをよりよく分散させたい場合にもよく使用されます。

keep-all

「単語」内での分割は禁止されます: 組版上の字母単位 （または NU、 AL、 AI、 または ID の Unicode 行分割クラス [UAX14] に属する、その他の 組版上の文字単位） の間にある暗黙の ソフト 折り返し機会は抑制されます。 すなわち、そのような文字の組の間の分割は禁止されます （line-break の設定が anywhere 以外であれば、その設定に関係なく） ただし § 6.1.1.1 語彙的単語分割によって機会が存在する場合を除きます。 それ以外では、このオプションは normal と等価です。 このスタイルでは、CJK 文字の連続は分割されません。

注: これは韓国語 （単語間に スペースを使用する） に対するもう一つの一般的な挙動であり、 CJK 断片が、区切りに スペースを使用する 別の言語に混在する混在文字体系テキストにも有用です。

manual

normal と同じように振る舞いますが、 § 6.1.1.1 語彙的単語分割を 実行してはなりません。 具体的には、 組版上の文字単位のうち [UAX14] におけるクラス SA を持つものは、 クラス AL を持つものとして扱わなければなりません （すなわち、line-break の値が anywhere 以外であると仮定すると、 そのような文字の組の間に ソフト折り返し機会 はありません）。

注: この値は、 バリ語などの言語における単語内の音節ベースの ソフト折り返し機会には影響しません。 （そのような書記体系に関する議論については § 6.1.1.2 正書法的分割 を参照してください。）

あるいは、 この値は normal ではなく keep-all を基準にしてもよいかもしれません。 さらに別の変種として、この挙動を keep-all と統合することも考えられます。

注: 一部の東南アジア言語は、ユーザーエージェントによって誤検出されることがよくあります。 word-break: normal では、 その場合、不適切な言語固有ロジックを適用して 折り返し機会を見つけ、 それらを不適切に配置してしまいます。

たとえば、 タイ語以外の多くの言語がタイ文字を使用して書かれますが、 それらをタイ語であるかのように行分割すると、 一般に不十分で、場合によっては混乱を招く結果になります。

これが発生した場合、 この値により、著者は word-break: normal に対してユーザーエージェントに組み込まれた 単語境界検出を無効にできます。 これにより、折り返し機会を示すようテキストを手動でマークアップし、 妥当な結果を得ることができます。

この値を使用する著者は、 東南アジア言語の単語境界を手動で示すことが期待されます。 そのためには wbr または U+200B を使用します。 そうしなければ、ソフト折り返し機会 は存在せず、テキストがオーバーフローする可能性があります。

auto-phrase

normal と同じように振る舞いますが、 この値は、自然なフレーズ（複数の単語から成る）をまとめて保持することを優先するために、 ユーザーエージェントへ言語固有の内容解析を行うよう指示します。

要素の 内容 言語が不明である場合、 またはユーザーエージェントがその特定の言語について フレーズ境界を検出する 方法を知らない場合、 この値は normal として振る舞わなければなりません。 それ以外の場合、 ユーザーエージェントは フレーズ境界を検出し、 各フレーズ内の ソフト折り返し機会 を抑制すべきです。

内容言語 および フレーズ境界検出のサポートに関係なく、 ハイフネーション機会は、 hyphens: none が指定されたかのように抑制されます。

注: ある言語向けに設計された単語境界検出システムが、 その言語の一部またはすべての方言に適しているかどうかは、 ある程度主観的であり、 この仕様はそれをユーザーエージェントの裁量に委ねます。 検出システムが特定の方言のすべての微妙な違いに対処できないとしても、 ほとんどの場合に単語境界を正しく認識できるなら、 サポートを主張することは妥当かもしれません。 しかし、ほとんどの単語境界を検出できない、 または高い誤り率を持つ言語についてサポートを主張するなら、 ユーザーエージェントは著者と利用者に不利益を与えることになります。

ユーザーエージェントが広範な中国語群には適さない 広東語用の単語境界検出システムを持っている場合、 auto-phrase は、 lang=yue、lang=zh-yue、または lang=zh-HK とマークされた内容には効果を持つべきですが、 lang=zh または lang=zh-Hant には 効果を持つべきではありません。

しかし、ユーザーエージェントが中国語全般に適した 汎用の単語境界検出システムをサポートする場合、 auto-phrase は、 広い lang=zh 特性付けでマークされた内容にも効果を持つべきです。 また、lang=zh-yue、lang=zh-Hant-HK、 lang=zh-Hans-SG、または lang=zh-hak など、より具体的なものにも効果を持つべきです。

特定のカテゴリの字母と同じ方法で行分割される記号は、 それらの字母と同じように影響を受けます。

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

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

h1 {
  word-break: normal;
}

窓ぎわのトッ
トちゃん

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

h1 {
  word-break: keep-all;
}

窓ぎわの
トットちゃん

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

h1 {
  word-break: auto-phrase;
}

窓ぎわの
トットちゃん

ユーザーエージェントは、このプロパティのどの値に応じる場合でも、 次のような ソフト 折り返し機会を抑制してはなりません:

• wbr HTML 要素または U+200B ZERO WIDTH SPACE によって導入されるもの

• line-break プロパティによって要求されるもの

• アトミックインラインの周囲

word-break の効果は、 内在的 サイズを計算するときに考慮されます。

従来の内容との互換性のため、 word-break プロパティは、 非推奨の break-word キーワードもサポートします。 指定された場合、これは、 word-break: normal および overflow-wrap: anywhere と同じ効果を持ちます。 実際の overflow-wrap プロパティの値には関係ありません。

6.1.1. 解析的単語分割

6.1.1.1. 語彙的単語分割

東南アジア言語に対して期待される normal の挙動を提供するため、 組版上の文字単位のうち、 [UAX14] における行分割クラス SA を持つものは、 クラス AL を持つものとして扱われなければなりません。 ただし、ユーザーエージェントはさらに、 そのような文字の連なりの内容を解析して 単語 境界を検出し、 各境界を ソフト折り返し機会として扱わなければなりません。

さまざまな言語が、 クラス SA を持つ文字を使用する文字体系で書かれる可能性があるため、 内容言語が既知である場合、 ユーザーエージェントはこの情報を使用して 解析を調整すべきです。

6.1.1.2. 正書法的分割

正書法上の音節に基づく行分割を使用する文字体系 （バリ文字など）について、 UA は、ソフト折り返し機会を挿入すべき正しい位置を見つけるために、 内容を解析しなければなりません。

注: 執筆時点では、 Unicode はこの解析をどのように行うかを定義しておらず、 これらの書記体系のすべての文字を行分割クラス AL として扱っています。 しかし、 その問題を解決するための 提案が行われています。 これは最終版ではありませんが、 参照すると有益な場合があります。 [L2-22-080R]

6.1.1.3. フォールバック分割

予期しないオーバーフローを避けるため、 ユーザーエージェントが、 それを必要とする任意の 内容言語に対して、 行分割のために必要な語彙的または正書法的解析を実行できない場合—​たとえば、 クラス SA の文字で書かれた言語用の辞書がない場合—​、 その書記体系内の 組版上の字母単位の組の間に ソフト折り返し機会 があるものと仮定しなければなりません。

注: この規定は、 UA が特定のテキストランで単語境界を見つけられないというだけでは発動しません。 そのテキストランは単一の分割不能な単語である可能性も十分あります。 これは、たとえば、テキストランがクメール文字（U+1780 から U+17FF）で構成されており、 ユーザーエージェントがクメール語の単語境界の決定方法を知らない場合に適用されます。

6.1.2. フレーズベースの行分割に対するユーザー設定の表現

ユーザーエージェントは、ユーザー設定に応じて、 auto-phrase で説明される言語固有の内容解析を有効にしてもよいです。 この挙動を持つユーザーエージェントは、 word-break の 宣言値を、ユーザー出自において auto-phrase に設定することによって、 これを行わなければなりません。

注: これにより、著者は getComputedStyle() を呼び出すことで、この機能が有効かどうかを検出できます。 また、適切な場合には 著者出自でこれを上書きできます。

6.2. 行分割の厳密さ: line-break プロパティ

このプロパティは、要素内に適用される行分割規則の厳密さを指定します: 特に、折り返しが 句読点および記号とどのように相互作用するかです。 値は次の意味を持ちます:

auto

UA は使用する行分割制約の集合を決定し、 行の長さに基づいて制約を変化させてもよいです。 例: 短い行にはより制約の少ない行分割規則の集合を使用する。

loose

最も制約の少ない行分割規則の集合を使用してテキストを分割します。 通常、新聞などの短い行に使用されます。

normal

最も一般的な行分割規則の集合を使用してテキストを分割します。

strict

最も厳格な行分割規則の集合を使用してテキストを分割します。

anywhere

任意の 組版上の文字 単位の周囲、 任意の句読点文字または 保持された 空白の周囲、 あるいは単語の途中に ソフト折り返し機会があります。 行分割に対するいかなる禁止も無視されます。 これには GL、WJ、または ZWJ の行分割クラスを持つ文字によって 導入されるものや、 word-break プロパティによって義務付けられるものも含まれます。 [UAX14] 異なる折り返し機会には優先順位を付けてはなりません。 ハイフネーションは適用されません。

注: この値は、 端末で一般的に見られる行分割規則を引き起こします。

注: anywhere は、 white-space が break-spaces に設定されている場合にのみ、 行末の 保持された空白 を次の行へ折り返すことを許可します。 その他の場合は次のためです:

• 行末/行頭の 保持された空白は破棄される （normal、pre-line）
• 折り返しそのものが禁止される（nowrap、pre）
• 保持された空白が ぶら下がる （pre-wrap）。

保持された空白に対して効果を持つ場合、 white-space: break-spaces では、 連続の最初のスペースの前で分割することを許可します。 これは break-spaces 単独では行わないことです。

CSS は、テキスト折り返しの規則における 4 つの厳密さの水準を区別します。 loose、 normal、 および strict のそれぞれで有効となる正確な規則の集合は UA に委ねられており、 言語の慣習に従うべきです。 ただし、これら 3 つのキーワードについて、 この仕様は次を要求します:

• 次の分割は、normal および loose の行分割で、 書記体系が 中国語 または 日本語である場合に許可され、 それ以外では禁止されます:
  • 特定の CJK ハイフン風文字の前での分割:
    〜 U+301C, ゠ U+30A0
• 次の分割は、直前の文字が Unicode 行分割クラス ID [UAX14] に属する場合 （word-break: break-all により 直前の文字が ID として扱われる場合を含む）、 loose の行分割で許可され、 それ以外では禁止されます:
  • ハイフンの前での分割:
    ‐ U+2010, – U+2013
• 次の分割は、normal および strict の行分割では禁止され、 loose では許可されます:
  • 日本語の小書き仮名 または片仮名・平仮名長音記号の前での分割。 すなわち Unicode 行分割クラス CJ の文字。 [UAX14]
  • 繰り返し記号の前での分割:
    々 U+3005, 〻 U+303B, ゝ U+309D, ゞ U+309E, ヽ U+30FD, ヾ U+30FE
  • 分離不能文字間での分割 （‥ U+2025、… U+2026 など）。 すなわち Unicode 行分割クラス IN の文字。 [UAX14]
• 次の分割は、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 は、仕様の将来版において、 高度な出版要件を満たすために、 行分割に対するより細かな制御が必要になる可能性があることを認識しています。

6.3. ハイフネーション: 単語内の形態的分割

6.3.1. ハイフネーション制御: hyphens プロパティ

ハイフネーション とは、段落のレイアウトを改善するために、 通常は分割が許可されない場所で 単語を制御して分割することです。 通常は音節境界または形態素境界で単語を分割し、 多くの場合その分割を視覚的に示します （通常はハイフン、U+2010 を挿入します）。 場合によっては、ハイフネーションが単語の綴りを変更することもあります。 いずれにせよ、ハイフネーションはレンダリング効果にすぎません: これは基礎となる文書内容、 またはテキスト選択や検索に影響してはなりません。

ハイフネーションの慣行は言語によって異なり、 行分割の前にハイフンを挿入するだけでなく、 分割後にハイフンを挿入したり（またはその両方）、 U+2010 とは異なる文字を挿入したり、 単語の綴りを変更したりすることがあります。

言語	分割なし	前	後
英語	Unbroken	Un‐	broken
オランダ語	cafeetje	café‐	tje
ハンガリー語	Összeg	Ösz‐	szeg
中国語（官話）	tú’àn	tú‐	àn
	àizēng‐fēnmíng	àizēng‐	‐fēnmíng
ウイグル語
クリー語

ハイフネーションは、 有効な ハイフネーション機会で行が分割されるときに発生します。 これは、ハイフネーションが許可される単語内に存在する ソフト折り返し機会の一種です。 CSS では、ハイフネーション機会は hyphens プロパティで制御されます。 CSS Text Level 3 は ハイフネーションの正確な規則を定義しませんが、 UA には、分割点の選択を最適化し、 言語に適したハイフネーション点を選択することが強く推奨されます。

注: U+002D - HYPHEN-MINUS 文字または U+2010 ‐ HYPHEN 文字によって導入される ソフト折り返し機会は ハイフネーション機会ではありません。 折り返し時に分割の視覚的表示が作成されるわけではないためです: これらの文字は、その位置で行が折り返されるかどうかにかかわらず可視です。

ハイフネーション機会は、 min-content 内在サイズを計算するときに考慮されます。

注: これにより、表はその包含ブロックを オーバーフローする代わりに内容をハイフネーションできるようになります。 これはドイツ語のような長い単語を持つ言語で特に重要です。

このプロパティは、ハイフネーションが、 テキスト行内で追加の ソフト折り返し 機会を作成できるかどうかを制御します。 値は次の意味を持ちます:

none

単語内の文字が ハイフネーション機会を明示的に定義している場合でも、 単語はハイフネーションされません。

注: これは、 U+002D - HYPHEN-MINUS または U+2010 ‐ HYPHEN などの常に可視の文字によって導入される、 既存の ソフト 折り返し機会を抑制しません。

manual

単語は、その内部に ハイフネーション機会を明示的に示す文字がある場所でのみ ハイフネーションされます。 UA は、同じ位置での自動ハイフネーションの場合と同様に、 適切な言語固有のハイフネーション文字を使用しなければならず、 適切な綴りの変更があれば適用すべきです。

Unicode では、U+00AD は条件付きの "soft hyphen" であり、 U+2010 は無条件のハイフンです。 Unicode Standard Annex #14 は、 Unicode 行分割における soft hyphen の役割を説明しています。 [UAX14] HTML では、 &shy; は soft hyphen 文字を表し、 これはハイフネーション機会を示します。

ex­ample

auto

条件付きハイフンによって明示的に示されるものに加えて、 言語に適したハイフネーション資源によって自動的に決定される ハイフネーション機会で 単語を分割してもよいです。 単語が条件付きハイフン （&shy; または U+00AD SOFT HYPHEN）を含む場合、 単語内の他の場所にある自動 ハイフネーション機会は、 条件付きハイフンを優先して無視されなければなりません。 ただし、そのような機会で分割した後でも、 その単語の一部がまだ 1 行に収まらないほど長い場合は、 自動ハイフネーション機会を使用してもよいです。

正しい自動ハイフネーションには、 分割されるテキストの言語に適したハイフネーション資源が必要です。 したがって UA は、内容 言語が既知であり、 かつ適切なハイフネーション資源を持つテキストに対してのみ、 自動ハイフネーションを行わなければなりません。

UA は、自動ハイフネーションから特定の単語を除外するために、 言語に合わせたヒューリスティックを使用してもよいです。 たとえば、UA は特定の大文字化および句読点パターンに一致する単語を除外することで、 固有名詞でのハイフネーションを避けようとするかもしれません。 そのようなヒューリスティックはこの仕様では定義されません。 （そのようなヒューリスティックは言語ごとに異なる必要がある点に注意してください: たとえば英語とドイツ語では大文字化の慣習が大きく異なります。）

hyphens プロパティの目的では、 何が「単語」を構成するかは UA 依存です。 ただし、単語境界を決定するときには、 インライン要素境界および 通常フロー外要素を 無視しなければなりません。

条件付きハイフン文字 （U+00AD SOFT HYPHEN など）によって作成された ハイフネーション機会での ハイフネーションにより表示される任意のグリフは、 その文字によって表され、 その文字に適用されるプロパティに従ってスタイル付けされます。

注: アラビア文字などのシェーピングを伴う文字体系が、 ハイフネーションによって単語内で分割されることを許可されている場合でも、 文字は単語が分割されていないかのようにシェーピングされます。

たとえば、ウイグル語の単語 “داميدى” が ハイフネーションされた場合、 次のように表示されます 次のようにはなりません 。

6.3.2. ハイフン: hyphenate-character プロパティ

このプロパティは、ハイフネーションされた単語の部分間に表示される 文字列を指定します。 値は次の意味を持ちます:

auto

内容 言語の組版上の慣習に基づいて、 ユーザーエージェントが適切な文字列を見つけるべきであることを指定します。 それはハイフネーション辞書と同じソースから得られる可能性があります。

<string>

ハイフネーション時のハイフネーション分割位置に現れる文字列を指定します。 （この文字列の位置は影響されません: UA は、内容言語の組版上の慣習に従って 文字列を挿入しなければならず、 既定ではハイフネーション分割の直前に挿入します。） UA は、使用値を 限られた数の 組版上の文字単位に切り詰めてもよいです。 ただし、組版上の 文字単位の一部だけを切り詰めてはなりません。

注: 空文字列 "" を指定することは有効であり、 UA は可視のハイフネーション文字を挿入せずに ハイフネーション機会で分割します。

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

注: 自動ハイフネーションによって発生するハイフンと、 soft hyphen によって発生するハイフンのどちらも、 hyphenate-character に従って描画されます。

6.3.3. ハイフネーションのサイズ制限: hyphenate-limit-zone プロパティ

hyphenate-limit-zone は良い名前でしょうか？ コメント/提案は？

このプロパティは、ハイフネーションが発生して 次の行から単語の一部を現在の行へ引き上げる前に、 ラインボックス内に残されてもよい未充填空間 （両端揃え前）の最大量を指定します。

6.3.4. ハイフネーションの文字数制限: hyphenate-limit-chars プロパティ

このプロパティは、ハイフネーションされる単語内の 最小文字数を指定します。 単語内 / ハイフンの前 / ハイフンの後に必要な最小文字数を その単語が満たさない場合、 その単語はハイフネーションされてはなりません。 非間隔結合記号（Unicode 一般カテゴリ Mn） および単語内句読点（Unicode 一般カテゴリ P*）は、 最小数には数えません。

3 つの値が指定された場合、 1 番目の値は単語内の総文字数に必要な最小値、 2 番目の値はハイフネーション点より前の文字数の最小値、 3 番目の値はハイフネーション点より後の文字数の最小値です。 3 番目の値が欠落している場合、2 番目と同じです。 2 番目の値が欠落している場合、それは auto です。 auto 値は、 UA が現在のレイアウトに適応する値を選択することを意味します。

注: UA がより良い値を計算できない限り、 auto は 前後については 2、単語全体については 5 を意味することが推奨されます。

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

6.3.5. ハイフネーションの行数制限: hyphenate-limit-lines および hyphenate-limit-last プロパティ

このプロパティは、要素内で連続して ハイフネーションされる行の最大数を示します。 no-limit 値は、制限がないことを意味します。

場合によっては、ユーザーエージェントが指定された値を尊重できないことがあります。 （overflow-wrap を参照。） そのような緊急分割によって導入されたハイフネーションが 近くのハイフネーション点に影響するかどうかは定義されません。

このプロパティは、要素、段、ページ、および見開きの末尾における ハイフネーション挙動を示します。 見開きとは、読者に同時に見える 2 ページの集合です。 値は次の意味を持ちます:

none

制限は課されません。

always

要素の最後の完全な行、 または要素内の任意の段、ページ、見開き分割の前にある最後の行は、 ハイフネーションされるべきではありません。

column

要素内の任意の段、ページ、見開き分割の前にある最後の行は、 ハイフネーションされるべきではありません。

page

要素内のページまたは見開き分割の前にある最後の行は、 ハイフネーションされるべきではありません。

spread

要素内の任意の見開き分割の前にある最後の行は、 ハイフネーションされるべきではありません。

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

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

This is just a
simple example
to        show
Antarctica.

6.4. オーバーフロー折り返し: overflow-wrap（word-wrap）プロパティ

このプロパティは、通常なら分割不能な文字列が長すぎて ラインボックス内に収まらない場合に、 オーバーフローを防ぐため、 UA が行内の通常は許可されない点で分割してよいかどうかを指定します。 これは white-space が 折り返しを許可する場合にのみ効果があります。 可能な値:

normal

行は、許可された分割点でのみ分割できます。 ただし、 word-break: keep-all によって導入された制約は、 その行に他に受け入れ可能な分割点がない場合、 word-break: normal と一致するよう 緩和されてもよいです。

また、word-break: auto-phrase によって導入された制約も、 その行に他に受け入れ可能な分割点がない場合には緩和されます:

• 特定のフレーズ内の ソフト折り返し機会を抑制すると、 そのフレーズを他に何もない行に置いてもオーバーフローする場合、 ユーザーエージェントは、そのフレーズ内では normal と同じ ソフト折り返し機会に フォールバックしなければなりません。
• それでもオーバーフローを防ぐのに十分でない場合、 オーバーフローする各行内で ハイフネーション機会の抑制も 放棄されなければなりません。
• 中間的な措置として、 ユーザーエージェントは複数レベルのフレーズを検出し、 長いものがオーバーフローにつながる場合には より短いもの（場合によっては個々の単語まで）を選択してもよいです。

word-break: keep-all および word-break: auto-phrase によって導入された制約を緩和して得られた ソフト 折り返し機会は、 min-content 内在サイズを計算するときには 考慮されません。

anywhere

通常なら分割不能な 文字の連続は、 その行に他に受け入れ可能な分割点がない場合、 任意の点で分割されてもよいです。 シェーピング文字は、単語が分割されていないかのように引き続きシェーピングされ、 書記素クラスタは 1 つの単位としてまとまっていなければなりません。 分割点にハイフネーション文字は挿入されません。 anywhere によって導入された ソフト折り返し 機会は、 min-content 内在サイズを計算するときに 考慮されます。

word-break: auto-phrase の場合、 これらの追加の ソフト折り返し機会は、 overflow-wrap: normal で説明したように word-break: auto-phrase によって導入された制約を 緩和してもオーバーフローを防ぐのに不十分な場合にのみ導入されます。

break-word

anywhere と同様ですが、 break-word によって導入された ソフト折り返し 機会は、 min-content 内在サイズを計算するときに 考慮されません。

overflow-wrap に none 値を追加して、 overflow-wrap: normal によって許可される keep-all および auto-phrase の制約緩和を opt out できるようにする必要がありますか？

従来の理由により、UA は word-wrap を overflow-wrap プロパティの 旧来名エイリアスとして扱わなければなりません。

6.5. 行分割の詳細

行分割を決定するとき:

• 行分割と双方向テキストの相互作用は、 CSS Writing Modes 4 § 2.4 Applying the Bidirectional Reordering Algorithm および Unicode Bidirectional Algorithm （特に UAX9§3.4 Reordering Resolved Levels）によって定義されます。 [CSS-WRITING-MODES-4] [UAX9]
• 保持された セグメント区切り、 および—​white-space 値に関係なく—​Unicode の BK および NL 行分割クラスを持つ任意の文字は、 強制改行として扱われなければなりません。 [UAX14]

  注: そのような 強制改行 の双方向性への影響は、 Unicode Bidirectional Algorithm によって定義されます。 [UAX9]

• 明示的に別段定義されている場合 （例: line-break: anywhere または overflow-wrap: anywhere）を除き、 CM、 SG、 WJ、 ZW、 GL、 および ZWJ の Unicode 行分割クラスに対して定義された行分割挙動は 尊重されなければなりません。 [UAX14]
• CSS は、組版上の文字単位内に ソフト折り返し機会を 決して許可しません。 したがって、CM および SG の Unicode 行分割クラスは常に尊重されなければなりません。 [UAX14]
• 単語 区切りを使用する書記体系において、 それ以外の句読点での折り返しを許可する UA は、 分割点に優先順位を付けるべきです。 （たとえば、スラッシュ後の分割がスペースより低い優先度を与えられている場合、 “check /etc” という連続は "/" と "e" の間では決して分割されません。） そのような不自然な分割を避けるよう注意している限り、 単語 区切り以外の適切な句読点での分割を許可することが推奨されます。 これは、特に狭い行幅で、より均整の取れたマージンをもたらすためです。 UA は、包含ブロックの幅、テキストの言語、 line-break 値、 およびその他の要因を使用して優先度を割り当ててもよいです: CSS は ソフト折り返し機会の優先順位を定義しません。 ただし、word-break: break-all が指定されている場合、 単語区切りの優先順位付けは期待されません （この値は、単語区切りでの分割に基づかない 行分割挙動を明示的に要求するためです）—​また line-break: anywhere の下では禁止されます。
• 通常フロー外ボックス および インラインボックス境界は、 フロー内に 強制改行または ソフト折り返し 機会を導入しません。
• Web 互換性のため、 各置換要素またはその他の アトミック インラインの前後には ソフト折り返し機会が存在します。 通常ならそれを抑制する文字に隣接している場合でも同様で、 U+00A0 NO-BREAK SPACE も含まれます。 ただし、 U+00A0 NO-BREAK SPACE を除き、 アトミックインラインと、 Unicode の GL、WJ、または ZWJ 行分割クラスに属する隣接文字との間には、 ソフト折り返し機会があってはなりません。 [UAX14]
• 行分割時に消える文字（例: U+0020 SPACE）によって作成される ソフト折り返し 機会については、 その文字を直接含むボックス上のプロパティが、 その機会での行分割を制御します。 2 つの文字または アトミック インラインの境界によって定義される ソフト折り返し機会については、 その 2 つの文字の最も近い共通祖先上の white-space プロパティが 分割を制御します。 そのような境界における ソフト折り返し機会の 決定をどの要素の line-break、word-break、および overflow-wrap プロパティが制御するかは、 このレベルでは未定義です。
• ボックスの最初の文字の前または最後の文字の後にある ソフト折り返し 機会については、 分割はボックスの内容端と内容の間でボックスを分割するのではなく、 ボックスの直前/直後 （そのマージン端）で発生します。
• ルビ内/周囲の行分割は、 CSS Ruby Annotation Layout 1 § 3.4 Breaking Across Linesで定義されます。 [CSS-RUBY-1]
• アラビア文字などのシェーピングを伴う文字体系が、 単語内の強制されない ソフト折り返し 機会で 折り返す場合 （たとえば word-break: break-all、 line-break: anywhere、 overflow-wrap: break-word、 overflow-wrap: anywhere、 または ハイフネーションによる分割の場合）、 文字は、単語がなお完全なままであるかのように シェーピングされなければなりません （接続形が選択されなければなりません）。
  たとえば、 単語 “نوشتن” が “ش” と “ت” の間で分割される場合、 “ش” はなお語頭形（“ﺷ”）を取り、 “ت” は語中形（“ﺘ”）を取ります—​つまり “نوش | تن” ではなく、 “ﻧﻮﺷ | ﺘﻦ” のように形成されます。

7. 配置と両端揃え

配置と両端揃えは、 インライン内容がラインボックス内でどのように分配されるかを制御します。

7.1. テキスト配置: text-align 一括指定

この 一括指定プロパティは、 text-align-all および text-align-last プロパティを設定し、 内容がラインボックスを完全には満たさない場合に、 ブロックのインラインレベル内容が インライン軸に沿ってどのように配置されるかを記述します。 justify-all または match-parent 以外の値は、 text-align-all に割り当てられ、 text-align-last を auto にリセットします。

値は次の意味を持ちます:

start

インラインレベル内容は、ラインボックスの 始端側に配置されます。

end

インラインレベル内容は、ラインボックスの 終端側に配置されます。

left

インラインレベル内容は、ラインボックスの line-left 端に配置されます。 （縦書きモードでは、 writing-mode に応じて、 これは物理的な上または下のいずれかになり得ます。） [CSS-WRITING-MODES-4]

right

インラインレベル内容は、ラインボックスの line-right 端に配置されます。 （縦書きモードでは、 writing-mode に応じて、 これは物理的な上または下のいずれかになり得ます。） [CSS-WRITING-MODES-4]

center

インラインレベル内容はラインボックス内で中央揃えされます。

<string>

文字列は単一の文字でなければなりません。 そうでなければ宣言は無効であり、 無視されなければなりません。 表セルに適用された場合、そのセルの内容がその周囲で揃えられる 配置 文字を指定します。 詳細、およびこの値がキーワードとどのように組み合わされるかについては、 以下を参照してください。

justify

テキストは、ラインボックスを正確に満たすために、 text-justify プロパティで 指定された方法に従って両端揃えされます。 text-align-last によって 別途指定されない限り、 強制改行の前の最後の行は start 揃えです。

justify-all

text-align-all と text-align-last の両方を justify に設定し、 最後の行も強制的に両端揃えにします。

match-parent

この値は inherit （親の算出値へ算出される）と同じように振る舞いますが、 start または end の 継承値は、 親の direction 値に照らして解釈され、 left または right のいずれかの 算出値になります。 ルート要素に指定された場合は、 start に算出されます。

text-align 一括指定に指定された場合、 text-align-all と text-align-last の両方を match-parent に設定します。

テキストのブロックは、 ラインボックスの積み重ねです。 このプロパティは、各ラインボックス内のインラインレベルボックスが、 ラインボックスの始端側および終端側に対してどのように揃うかを指定します。 配置は ビューポート または包含ブロックに対するものではありません。

justify の場合、 UA は、テキストを調整することにより、 任意のインラインボックスを伸縮してもよいです。 （text-justify を参照。） 要素の 空白が 折り畳み可能でない場合、 UA は両端揃えの目的でそのテキストを調整する必要はなく、 代わりにそのテキストには 両端揃え機会がないものとして扱ってもよいです。 UA がテキストを調整することを選択した場合、 タブ位置が 空白処理規則によって要求されるとおりに 揃い続けることを保証しなければなりません。

（両端揃えがある場合はその後） ラインボックスのインライン内容が長すぎて収まらない場合、 その内容は 始端揃えされます: 収まらない内容は、 ラインボックスの 終端側からオーバーフローします。

ラインボックスの 始端および 終端を どのように決定するかの詳細については、 § 9.3 双方向性とラインボックスを参照してください。

7.2. 表の列における文字ベースの配置

列内の複数のセルに配置文字が指定されている場合、 その列内の各セルの配置文字は、 単一の列に平行な軸に沿って中央揃えされ、 列内の残りのテキストはそれに応じて移動されます。 （各セルで文字列が同じである必要はないことに注意してください。 通常は同じですが。）

これは、揃えられるべきなのは配置文字の中心である、 という意図なのでしょうか？ そう述べているかは明確ではありませんが、 異なる配置文字の出現が異なるフォントにある場合に何が起こるかを 説明するためには、 それ（または異なる挙動）を指定する必要があります。 （さらに、それが意図された挙動なのでしょうか？ おそらく考慮すべき最も重要なユースケースは太字と非太字のテキストであり、 幅はわずかにしか異なりません。） [フィードバック] [minutes face-to-face 2016-02-02 10:00 AM]

TD { text-align: "." center }

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

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

<string> 値と組み合わせてキーワード値を指定してもよいです。 指定されていない場合、既定は right です。 この値は次の場合に使用されます:

• 文字ベースの配置が、表セルでないボックスに適用される場合。
• テキストが（強制されない分割点で）複数行に折り返される場合。
• 文字揃えされたセルが複数の列にまたがる場合。 この場合、キーワード配置値は、 どの列の軸に揃えるかを決定するために使用されます: left では最も左の列、 right および center では最も右の列、 start では最始端の列、 end では最終端の列です。
• 列が十分に広く、文字配置だけでは 文字揃えされた内容の位置が決まらない場合。 この場合、配置文字が指定された列内の最初のセルのキーワード配置が、 列の幅を変えない範囲で可能な限りキーワード配置に一致するように、 文字揃えされた内容の位置をスライドするために使用されます。 center では、 UA は、揃えられた内容をその両端を使って中央揃えしてもよく、 配置軸自体を（可能な限り）中央揃えしてもよく、 または軸の両側にあるセル内容の範囲の加重平均を取るなど、 他の方法で揃えられた内容を光学的に中央揃えしてもよいです。

注: 文字ベースの配置では既定で右揃えが使用されます。 これは、ほとんどすべての数体系が、 右から左の書記体系であっても左から右であり、 文字ベースの配置の主なユースケースが数値配置であるためです。

配置文字がテキスト内に複数回現れる場合、 最初の出現が配置に使用されます。 配置文字がセル内にまったく現れない場合、 その文字列は、配置文字がその内容の末尾に挿入されたかのように揃えられます。

これは、配置文字を検索する対象のテキストを指定する必要があります。 それは包含ブロックがセルである in-flow テキストだけでしょうか？ それとも、セルによって確立されたブロック整形コンテキスト内の 任意の in-flow 子孫内のテキストも考慮されるのでしょうか？ その場合、それはその text-align プロパティが セルのものと一貫している限りでのみ考慮されるのでしょうか？ （配置文字について一貫しているのか、完全に一貫しているのか？）

配置文字がセル内容の末尾に挿入されたかのように揃えるこの挙動は、 文字中心の配置と組み合わさると、 <string> テキスト配置を持つ行が単独で 1 行にある場合に、 行の終端側に隙間を生じます。 これは、列のどの行にも配置文字がない場合、 または、より重要な場合として、 一部の行には配置文字があるが、 列が max-content 幅でレイアウトされていない場合に発生します。 これはおそらく望ましくありません。

配置文字が内容の末尾に挿入される場合、 どのフォントが使用されるのでしょうか？ （特に、配置文字が子孫ブロック内にある可能性がある場合、 それはブロックのフォントでしょうか、それとも表セルのフォントでしょうか？ または、挿入がインライン内の強制分割位置で行われる場合、 インラインのフォントを使用するのでしょうか、 それともブロックまたはセルのフォントを使用するのでしょうか？）

文字ベースの配置は、表セル幅の計算前に発生します。 これにより、自動幅計算は配置に十分な空間を残すことができます。 列にまたがるセルが幅計算の前または後に配置へ参加するかどうかは未定義です。 セル内容に対する幅制約により 列全体で完全な配置が妨げられる場合、 結果として得られる配置は未定義です。

これは、文字配置が （表列および表列内に入り得るすべての内容の） min-content および max-content 内在幅にどのように影響するかについて、 形式的な定義を持つべきです。 Max-content 内在幅は、 （配置文字の中心が揃えられると仮定すると） 3 つの数値に分割する必要があります: 配置文字を持たない幅、 配置文字の中心のインライン始端側の幅、 配置文字の中心のインライン終端側の幅です。 これは max-content 幅について、強制分割間のすべてのテキスト区間に基づいて動作します。 Min-content 幅については、 強制分割間のテキスト区間でその内部に任意分割を含むものは、 配置文字なしの幅にのみ寄与することは明らかです。 しかし、すべての min-content 幅がこのように動作すべきか、 それとも強制分割間の区間で任意分割を持たないもの （おそらく実際に配置文字を含むものだけ）が、 代わりに配置文字の始端側および終端側の min-content 幅に寄与すべきかは、 あまり明確ではありません。 この選択は、表の min-content サイズ決定が最も狭い妥当なサイズを意味することと、 より多くの場合に配置文字を尊重することとの間のトレードオフです。 別の選択肢として、任意分割の行分割が許可されるかどうかを、 どちらの挙動を使用するかの制御として用いることも考えられます。

<string> 値を持つ text-align の列またがりセルの 内在幅寄与を形式的に定義することは、 列またがりでないセルの内在幅寄与について行われた判断の 複雑な（ただし単純な）拡張であり、 これも形式的に定義されるべきです。 寄与は、配置に使用される始端側または終端側の列の 分割された内在幅に対して行われ、 他のまたがる列の配置文字なし内在幅にも行われることになります。

7.3. 既定のテキスト配置: text-align-all プロパティ

text-align 一括指定プロパティのこの個別指定は、 text-align-last の非 auto 値によって上書きされる最後の行を除き、 ブロックコンテナー内のインライン内容のすべての行の インライン配置を指定します。 値の完全な説明については text-align を参照してください。

著者は、このプロパティではなく text-align 一括指定を使用すべきです。

7.4. 最終行の配置: text-align-last プロパティ

このプロパティは、ブロックの最後の行、または 強制 改行の直前にある行が どのように配置されるかを記述します。

auto が指定された場合、 影響を受ける行の内容は text-align-all に従って配置されます。 ただし text-align-all が justify に設定されている場合は、 start 揃えになります。 その他のすべての値は、text-align について説明したとおりに解釈されます。

7.5. 両端揃え方法: text-justify プロパティ

このプロパティは、行の配置が justify に設定されたときに使用される両端揃え方法を選択します （text-align を参照）。 このプロパティはテキストに適用されますが、 ブロックコンテナーから、そのインラインレベル内容を含む ルートインラインボックスへ継承されます。 これは次の値を取ります:

auto

UA は、性能と十分な表示品質とのバランスに基づいて、 従うべき両端揃えアルゴリズムを決定します。 両端揃え規則は 書記体系 および 言語 によって異なるため、 UA は可能な場合、テキストに適した両端揃えアルゴリズムを使用すべきです。

たとえば、 UA は既定で、すべての書記体系に対する単純で汎用的な妥協案である 両端揃え方法を使用できます—​たとえば主に 単語区切り および CJK の 組版上の字母単位の間を拡張し、 さらに副次的に 東南アジアの 組版上の字母単位の間を 拡張する、といった方法です。 その後、段落の 内容言語が既知である場合には、 より言語に合わせた両端揃え挙動を選択できます。 たとえば、日本語については Requirements for Japanese Text Layout [JLREQ] に従う、 アラビア語では筆記体的伸長を使用する、 ドイツ語では inter-word を使用する、 などです。

none

両端揃えは無効になります: テキスト内に 両端揃え機会はありません。

注: この値は、ユーザースタイルシートで 可読性の改善またはアクセシビリティ目的に使用することを意図しています。

inter-word

両端揃えは 単語区切りでのみ間隔を調整します （実質的に、その行で使用される word-spacing を変化させます）。 この挙動は、英語や韓国語のように、 スペースを使って単語を区切る言語で典型的です。

inter-character

両端揃えは、 隣接する 組版上の文字単位の各組の間の 間隔を調整します （実質的に、その行で使用される letter-spacing を変化させます）。 この値は、日本語などの東アジア体系で使用されることがあります。

従来の理由により、 UA は代替キーワード distribute もサポートしなければなりません。 これは inter-character に算出されなければならず、 したがってまったく同じ意味と挙動を持ちます。 UA はこれを 旧来値エイリアスとして扱ってもよいです。

ruby

両端揃えは auto と同様に間隔を調整します。 ただし次を除きます:

• 両端揃え機会は、 単語 区切りで無効になります。

• 両端揃え機会は、 注音符号文字の間で無効になります

注: この値は ルビ注釈で使用することを意図しており、 妥当な既定配置を提供します。 [CSS-RUBY-1] を参照してください。

no-compress

両端揃えは、 text-spacing-trim または text-autospace によって制御される間隔を 圧縮してはなりません。 （この値が指定されていない場合、 両端揃え処理は、その間隔が行の先頭または末尾にある場合を除き、 そのような間隔を縮小してもよいです。）

注: 圧縮規則の例は、 日本語について [JLREQ] の 3.8 行の調整に示されています。

このキーワードは以前 text-spacing の一部でした。 ここに置かれた現在では、より具体的にするために改名が必要かもしれません。 たとえば U+0020 は圧縮できない、という含意を持つためです。 [Issue #7079]

最適な両端揃えは言語依存であるため、 著者は最良の結果を得るために内容へ正しく言語タグを付けるべきです。

注: このレベルの CSS における指針は、 完全な両端揃えアルゴリズムを記述していません。 これは完全なアルゴリズムが満たすべき 最小限の要件集合にすぎません。 要件集合を限定することで、UA は、 自身の必要性および品質・速度・複雑さの望ましいバランスを満たす 両端揃えアルゴリズムを選択する余地を持ちます。

7.5.1. テキストの拡張と圧縮

テキストを両端揃えする際、 ユーザーエージェントは、 行内容の端とそのラインボックスの端との間の残り空間を取り、 その空間を内容全体に分配して、 内容がラインボックスを正確に満たすようにします。 ユーザーエージェントは、代わりに負の空間を分配し、 通常の間隔条件では収まらないほど多くの内容を 行に置いてもよいです。

両端揃え機会とは、 両端揃えアルゴリズムがテキスト内の間隔を変更し得る点です。 両端揃え機会は、単一の 組版上の文字 単位 （単語区切りなど） によって提供されることもあれば、 2 つの 組版上の文字 単位の並置によって提供されることもあります。 ソフト折り返し機会の制御と同様に、 組版上の文字単位が 両端揃え機会を提供するかどうかは、 その親の text-justify 値によって制御されます。 同様に、 2 つの連続する 組版上の文字単位の間に 両端揃え機会が存在するかどうかは、 それらの最も近い共通祖先の text-justify 値によって 決定されます。

両端揃えによって分配される空間は、 letter-spacing または word-spacing プロパティによって定義される間隔に 加えて適用されます。 そのような追加空間が 単語区切りの 両端揃え機会へ分配される場合、 それは word-spacing と同じ規則の下で適用されます。 同様に、空間が 2 つの 組版上の文字単位の間の 両端揃え機会へ分配される場合、 letter-spacing と同じ規則の下で適用されるべきです。

両端揃えアルゴリズムは、両端揃え機会を 異なる優先度レベルに分割してもよいです。 あるレベル内のすべての 両端揃え機会は、 どの 組版上の文字単位がその機会を作成したかに関係なく、 同じ優先度で拡張または圧縮されます。 たとえば、 2 つの漢字の間の 両端揃え機会と 2 つのラテン文字の間のものが同じレベルにあると定義されている場合 （inter-character の両端揃えスタイルではそうです）、 それらは異なる 組版上の文字 単位に由来するからといって別扱いされません。 このレベルでは、 その他の要因 （フォントサイズ、letter-spacing、グリフ形状、行内位置など）が 行内の 両端揃え 機会への空間分配に影響し得るかどうか、またどのように影響するかは定義されません。

UA は、任意の方法でテキストの両端揃えを助けるために、 任意合字を有効化または解除してもよく、 代替グリフやグリフ圧縮などの他のフォント機能を使用してもよいです。 この挙動は、このレベルの CSS では制御されません。 ただし、 UA は必須合字を解除してはならず、 複雑な文字体系を正しくシェーピングするために必要な機能を その他の方法で無効にしてはなりません。

行内に 両端揃え機会が存在し、 かつ テキスト配置がその行について完全な両端揃え （justify） を指定している場合、 その行は両端揃えされなければなりません。

7.5.2. 記号と句読点の扱い

両端揃え機会を決定する際、 Unicode の記号（S*）および句読点（P*）クラスに属する 組版上の文字単位は、 一般に同じ文字体系の 組版上の字母単位と同じように扱われます （または、その文字の script プロパティが Common である場合、 支配的な文字体系の 組版上の字母単位として扱われます）。

しかし、組版上の伝統により、 記号および句読点の両端揃えを制御する追加規則が存在することがあります。 したがって UA は、 記号および句読点を含む 両端揃え機会を扱うために、 特定の文字を再割り当てしたり、 追加の優先順位レベルを導入したりしてもよいです。

7.5.3. 拡張できないテキスト

行のインライン内容をラインボックスの全幅まで伸ばすことができない場合、 それらは text-align-last プロパティで 指定されたとおりに配置されなければなりません。 （text-align-last が justify である場合、 それらは center と同様に配置されなければなりません。）

7.5.4. 筆記体文字体系

両端揃えは、アラビア文字などの 筆記体文字体系の 結合された 組版上の字母単位の間に 隙間を導入してはなりません。 可能であれば、 UA は、そのような 組版上の字母単位の連なり内の 両端揃え機会へ分配される空間を、 その連なりに対する何らかの筆記体的伸長へ変換してもよいです。 それ以外の場合、UA は、 筆記体文字体系における 任意の 2 つの 組版上の字母単位の間には （それらが結合するかどうかに関係なく） 両端揃え 機会が存在しないと仮定しなければなりません。

以下は、許容できない両端揃えの例です:

一部のフォント設計では、両端揃えのためにタトウィール文字を使用できます。 タトウィールに基づく両端揃えを行う UA は、 その使用規則を適切に扱わなければなりません。 タトウィール文字の正しい挿入は文脈に依存し、 関係する文字の組み合わせ、 単語内の位置、 および行内の単語の位置を含むことに注意してください。

7.5.5. auto 両端揃えの最小要件

auto 両端揃えについて、 この仕様は、すべての 両端揃え機会が何であるか、 それらがどのように優先順位付けされるか、 また複数レベルの 両端揃え 機会がいつ、どのように相互作用するかを定義しません。 しかし、次を要求します:

• 内容 言語の組版上の伝統 または隣接する記号/句読点によって禁忌とされない限り、 次のそれぞれは 両端揃え機会を提供します:
  • 単語区切り
  • 任意の ブロック 文字体系の 組版上の文字単位と、 任意の他の 組版上の文字単位との境界
  • 任意の クラスタ化文字体系の 組版上の文字単位と、 任意の他の 組版上の文字単位との境界
• すべての ブロック文字体系に 属するすべての 字母は同じように扱われ、 すべての クラスタ化文字体系に属する すべての 字母も同じように扱われます。 たとえば、漢字の後に別の漢字が続く場合の両端揃え機会と、 漢字の後にハングル字母が続く場合の両端揃え機会との間に 区別はありません。

テキストの両端揃えに関する追加情報は、 “Approaches to Full Justification” にあります（またはそこへ提出できます）。 これは書記体系と言語別に索引化されており、 W3C Internationalization Working Group によって保守されています。 [JUSTIFY]

7.6. コンテナー内でのテキストブロックの配置: text-group-align プロパティ

このプロパティは、テキスト配置を維持しながら、 ラインボックスの内容をグループとして配置します。

グループ配置は、 残り空間が最も短いラインボックスを見つけ、 その量の空間をラインボックスの片側または両側へパディングとして追加し、 その内容に利用できる空間の量を減らすことで行われます。 その後、テキスト配置が、 残りの空間内でその内容に適用されます。 同じ ブロック整形コンテキスト内の すべての子孫 in-flow ラインボックスは、 最短の残り空間を探す場合にも、 パディングを追加する場合にも考慮されます。 独立整形コンテキストを確立する子孫の内容は スキップされます。

このプロパティの変種は 継承され、 各ブロックコンテナーに個別に適用され、 そのブロックの直接の子であるラインボックスにのみ影響します。 これは有用性は低いですが、おそらく実装は容易です。

同じブロックコンテナーに 由来する float も 同じ量だけ何らかの方法で移動できれば、 より美しく揃うでしょう。 これは CJK レイアウトで特に有用です。 それが正確にどのように機能するか、 および祖先要素から侵入する float とどのように相互作用するかは、 読者への課題として残されています。

値は次の意味を持ちます:

none

テキスト配置は通常どおり行われます: グループ配置は行われません。

start

インラインレベル内容は、各ラインボックスの インライン終端側にパディングを加えることで、 インライン 始端側へ グループ配置されます。

end

インラインレベル内容は、各ラインボックスの インライン始端側にパディングを加えることで、 インライン終端 側へ グループ配置されます。

left

インラインレベル内容は、各ラインボックスの line-right 側にパディングを加えることで、 line-left 側へ グループ配置されます。

right

インラインレベル内容は、各ラインボックスの line-left 側にパディングを加えることで、 line-right 側へ グループ配置されます。

center

インラインレベル内容は、 各ラインボックスの両側にそれぞれ半分ずつ間隔をパディングすることで、 中央へ グループ配置されます。

8. 間隔

CSS は、通常のテキスト間隔を word-spacing、letter-spacing、および line-padding プロパティによって制御できます。 これらはそれぞれ、 単語区切りの周囲、 組版上の文字単位の間、 または行の先頭/末尾に追加の空間を指定します。 また、text-spacing-trim プロパティによって、 間隔の文脈的制御も提供します。 これは CJK 句読点の文脈的な全角対半角設定を可能にします。 さらに text-autospace プロパティは、 文字体系の変化位置または句読点の周囲に 追加空間を自動挿入できるようにします。

8.1. 単語間隔: word-spacing プロパティ

このプロパティは、「単語」間の追加間隔を指定します。 値は次のように解釈されます:

normal

追加間隔は適用されません。 0 に算出されます。

<length-percentage>

フォントによって定義される本来の単語間隔に 加えて追加間隔を指定します。

注: パーセンテージはそのまま継承され、 現在の要素の使用値の font-size に対して解決されます （したがって、それらが適用されるテキストのサイズに相対するサイズを表します）。 これは、継承元の要素の算出された font-size に対して 絶対長として解決される em 単位とは異なります。

追加間隔は、 空白処理規則が適用された後に テキスト内に残る各 単語区切りに適用され、 組版上の伝統によって別途指示されない限り、 その文字の両側に半分ずつ適用されるべきです。 値は負でもよいですが、実装依存の制限がある場合があります。

単語区切り文字とは、 主な目的および一般的な用法が単語を区切ることである 組版上の文字単位です。 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 など）、 ユーザーエージェントは単語間に追加間隔を作成してはなりません。

8.2. トラッキング: letter-spacing プロパティ

このプロパティは、隣接する 組版上の文字単位の間の 追加間隔 （一般に トラッキングと呼ばれます） を指定します。 Letter-spacing は bidi 並べ替えの後に適用され、 カーニング および word-spacing に加えて適用されます。 [CSS-WRITING-MODES-4] [CSS-FONTS-3] 有効な両端揃え規則に応じて、 ユーザーエージェントは、 テキストを両端揃えするために、 組版上の文字単位間の空間を さらに増減させてもよいです。

値は次の意味を持ちます:

normal

追加間隔は適用されません。0 に算出されます。

<length-percentage>

組版上の文字単位の間に 追加の間隔を指定します。 値は負でもよいですが、 実装依存の制限がある場合があります。

注: パーセンテージはそのまま継承され、 現在の要素の使用値の font-size に対して解決されます （したがって、それらが適用されるテキストのサイズに相対するサイズを表します）。 これは、継承元の要素の算出された font-size に対して 絶対長として解決される em 単位とは異なります。

従来の理由により、 0 の算出 letter-spacing は、 解決値 （getComputedStyle() の戻り値）として normal を返します。

letter-spacing の目的では、 アトミックインライン （画像やインラインブロックなど）の各連続する並びは、 単一の 組版上の文字単位として扱われます。

Letter-spacing は行頭に適用されてはなりません。 Letter-spacing が行末に適用されるかどうかは、このレベルでは未定義です。

p { letter-spacing: 1em; }

<p>abc</p>

2 つの 組版上の文字単位の間の letter spacing は、 その 2 つの 組版上の文字単位を含む 最も内側の要素に実質的に「属します」: 2 つの隣接する 組版上の 文字単位間の合計 letter spacing （bidi 並べ替え後）は、 その 2 つの 組版上の文字単位の境界を 含む最も内側の要素によって指定され、その内部で描画されます。 しかし UA は、代わりに要素境界で letter-spacing を その包含要素に関係する letter-spacing 値を使用して 一方または他方の 組版上の文字単位に 付与してもよいです。

注: この二次的な挙動は、 Web 互換性の懸念により、このレベルで許可されています。

p { letter-spacing: 1em; }

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

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

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

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

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

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

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

Letter spacing は、不可視のゼロ幅整形文字 （Unicode Cf カテゴリの文字など）を無視します。 間隔は、それらの文字が文書内に存在しないかのように追加されなければなりません。

2 つの文字間の有効な間隔が 0 でない場合 （両端揃え、または letter-spacing の非ゼロ値による場合）、 ユーザーエージェントは任意合字を適用すべきではありません。 すなわち、本質的に正しいグリフシェーピングに必須と定義されていない合字です。 ただし、低水準の font-feature-settings プロパティによって 指定された合字およびその他のフォント機能は、 この規則より優先されます。 CSS Fonts Module Level 3 § feature-precedence を参照してください。

注: OpenType では、必須合字は rlig 機能に関連付けられることが期待されます。 したがって、その他のすべての合字は任意と見なされます。 ただし場合によっては、UA またはプラットフォームのヒューリスティックが、 壊れたフォントを扱うために追加の合字を適用します。 この仕様は、そのような例外的な扱いを定義も上書きもしません。

8.2.1. 筆記体文字体系

可能であれば、 UA は、筆記体文字体系に letter spacing を適用する際、 そのような文字の連なりへ分配される合計追加空間を、 その連なりの同等の合計拡張（または圧縮）をもたらす 何らかの筆記体的伸長 （または負のトラッキング値の場合は圧縮） へ変換してもよいです。 それ以外の場合、 UA が 筆記体文字体系のテキストを 筆記体接続を壊さずに拡張できないなら、 その文字体系の任意の 2 つの 組版上の字母単位の間に 間隔をまったく適用してはなりません （letter-spacing の目的では、実質的に各単語を単一の 組版上の字母 単位として扱います）。 どちらの場合も、そのような字母間の有効な間隔は 0 になります。 ただし前者は、テキストを引き伸ばす感覚を保持します。

以下は、アラビア語テキストの間隔付けに関する適切な例と不適切な例です。

	—	元のテキスト
	BAD	各文字間に空間を均等に分配する。 これにより筆記体の接続が壊れることに注意！
	OK	∑letter-spacing を 組版上適切な筆記体的伸長によって分配する。 結果のテキストは、前の均等間隔の例と同じ長さです。
	OK	アラビア文字間の letter-spacing を抑制する。 letter-spacing は、それでも 非アラビア文字（スペースなど）には適用されることに注意。
	BAD	結合していない字母の間にのみ letter-spacing を適用する。 これは組版上の濃淡を歪め、単語境界を曖昧にします。

注: テキストの適切な筆記体的伸長または圧縮は、 文字体系、 書体、 言語、 単語内の位置、 行内の位置、 実装の複雑さ、 フォントの能力、 およびカリグラフィ上の好みによって変わることがあり、 特定の場合にはまったく不可能なこともあります。 これには短縮合字、 スワッシュ変種、 文脈形、 U+0640 ـ ARABIC TATWEEL などの伸長グリフ、 またはその他のマイクロタイポグラフィの使用が含まれる場合があります。 これらの効果に関する規則を定義することは CSS の範囲外です。 著者は、相互運用できない結果を受け入れる用意がない限り、 筆記体文字体系に letter-spacing を 適用することを避けるべきです。

8.3. 行頭/行末のパディング: line-padding プロパティ

letter-spacing は 組版上の文字単位の間の間隔を調整し、 行の先頭または末尾には適用されませんが、 このプロパティは行の先頭/末尾だけの間隔を調整します。 追加間隔は、ラインボックスの先頭/末尾にある 最も内側の インラインボックスによってのみ適用され、 その インラインボックスの内容端と、 隣接する インラインレベル内容 （テキストまたはアトミック インライン） の間に挿入されます。 この追加空間は 両端揃え機会ではありません。

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

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

Here is some
text

8.4. 自動文脈間隔: text-autospace プロパティ

同じ インライン整形コンテキスト内の同じ行にある 隣接文字間の間隔を、 文字クラスに基づく規則の集合を用いて制御し、 文字体系間の間隔および句読点周囲の間隔を 自動的に制御できるようにします。

値は次のように定義されます:

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

normal

ideograph-alpha ideograph-numeric と同じ挙動です。

no-autospace

自動空間は挿入されません。

insert

そこにどの種類の空白文字（Unicode 一般カテゴリ Z）も まだ存在しない場合、 指定された間隔が自動的に挿入されます。

insert も replace も 指定されていない場合、 挙動は insert と同じです。

replace

その位置にすでに スペース （U+0020）が存在する場合でも、 指定された間隔が自動的に挿入されます。 さらに、その スペース（U+0020）は削除されます。 他の種類の空白文字（Unicode 一般カテゴリ Z）は、 insert の場合と同様に 自動間隔を抑制します。

注: これは、適切な間隔の代わりに 入力しやすい U+0020 を使用しているテキストを修正するためのものです。

ideograph-alpha

表意文字の並びと 非表意文字の字母の並びとの間に 追加間隔を作成します。 § 8.4.1 文字体系間間隔を参照してください。

ideograph-numeric

表意文字の並びと 非表意文字の数字の並びとの間に 追加間隔を作成します。 § 8.4.1 文字体系間間隔を参照してください。

punctuation

言語固有の組版慣習によって必要とされるとおりに、 句読点の周囲に追加の非分割間隔を作成します。

このレベルでは、要素の内容言語がフランス語である場合、 フランス語 組版ガイドラインによって必要とされる位置に、 狭いノーブレークスペース（U+202F）およびノーブレークスペース（U+00A0）が挿入されます。 それ以外の場合、この値は効果を持ちません。 ただし将来の仕様では、他の言語の自動間隔挙動が追加される可能性があります。

auto

ユーザーエージェントは、組版上高品質な間隔値の集合を選択します。 異なるプラットフォーム上で動作する異なるユーザーエージェントは、 異なる値を選択する場合があります。

注: これらの間隔値は、 OS プラットフォームの慣習と一致する場合も、一致しない場合もあります。

このプロパティは、word-spacing および letter-spacing プロパティと加算的です。 つまり、letter-spacing 設定によって寄与される間隔量 （存在する場合）は、text-autospace によって 作成される間隔に加算されます。 同じことが word-spacing にも適用されます。

要素境界では、文字間に導入される追加間隔の量は、 その境界を含む最も内側の要素によって決定され、その内部で描画されます。

8.4.1. 文字体系間間隔

ideograph-alpha および ideograph-numeric 値は、 特定の文字クラス間の境界に、 それらが行上で直接隣接している場合、 すなわち、間に非ゼロの margin、border、または padding や介在する文字（引用符やスペースなど）がない場合に、 間隔を導入します。 これらのキーワードによって導入される空間量は CJK 前進幅の 1/8 です。 すなわち、使用値の font-size がその 算出値と 同じである場合、0.125ic です。

注: 間隔の慣習はさまざまですが、 値は典型的には 1/4ic から 1/8ic 程度までの範囲であり、 金属活字の制約により歴史的文脈では 1/4ic がより一般的で、 プロポーショナル組版では 1/6ic またはそれより細い値がより一般的です。 これらの空間は既定で （初期値 normal を通じて）挿入されるため、 CSS は干渉を控えめにするために 1/8ic を使用します。 このモジュールの将来レベルでは、 間隔量の制御が導入される可能性があります。

8.5. CJK 句読点間隔: text-spacing-trim プロパティ

同じ インライン整形コンテキスト内の同じ行にある CJK 句読点文字の周囲の間隔を、 文字クラスに基づく規則の集合を用いて制御し、 行内での位置および隣接文字に基づいて、 それらを半角または全角として設定できるようにします。

値は次のように定義されます:

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

space-all

すべての全角句読点文字は、全角グリフ（空きあり）で設定されます。

normal

各行の先頭では、全角始め句読点を全角グリフ （空きあり）で設定します。 各行の末尾では、全角終わり句読点を、 両端揃え前に他の方法では収まらない場合は半角グリフ （詰め）で設定し、 そうでなければ句読点を全角グリフで設定します。 さらに句読点グリフ間の間隔を 下で説明するように畳み込みます。

trim-both

各行の先頭では、全角始め句読点を半角グリフ （詰め）で設定します。 各行の末尾では、全角終わり句読点を半角グリフ （詰め）で設定します。 さらに句読点グリフ間の間隔を 下で説明するように畳み込みます。

space-first

全角始め句読点を、 ブロック コンテナーの最初の行、 および 強制改行の後の各行では 全角グリフ（空きあり）で設定します。 それ以外は normal と同じです。

この値は互換性要件のために存在します。

この値は、既存の中国語および日本語コンテンツの一部の整形を管理するために存在します。 それらでは trim-both が 組版上は適切であったはずですが、 最初の行が space-all と同様に設定されることを 期待してすでに書かれています。

具体的には、 UA 全体で信頼できる hanging-punctuation サポートがないため、 既存コンテンツ（特に ePub コンテンツ）は text-indent の代わりに U+3000 表意文字スペースを使用しますが、 段落が句読点で始まり、 それをインデント内にぶら下げたい場合にはこれを省略し、 ぶら下げ句読点効果を作り出します。 そのようなコンテンツの最初の行に trim-both を使用すると、 実効的なインデントが削り取られ、 その行が新しい段落の最初の行であるという区別が 不明瞭になります。

表意文字スペースをインデントに使用する この組版慣行 （時々、かつ必ずしも常にではない）は、 HTML と CSS が提供する内容とスタイルの分離に反することに注意してください。 文書のテキスト内容を微調整するのではなく、 hanging-punctuation および text-indent を使用して段落整形を制御することで、 文書ソース内のテキストの真の意味を保持し、 スタイルシート設計者が内容を変更する必要なく、 さまざまな間隔/インデントスタイルを自由に切り替えられるようになります。 例については § 8.5.3 CSS における日本語段落開始規約を参照してください。

さらに、行末での挙動は、 normal および trim-start 値と整合しており、 trim-both とは異なります。 つまり、両端揃え前に他の方法では収まらない場合にのみ、 グリフを詰めます。 組版を改善する場合は少なくなりますが、 互換性上の懸念を減らす space-all の旧来の挙動に より近いものです。

trim-start

各行の先頭では、全角始め句読点を半角グリフ （詰め）で設定します。 それ以外は normal と同じです。

trim-all

全角始め句読点、 全角終わり句読点、 および 全角中点句読点を、 行内での位置にも 隣接文字にも関係なく、 半角グリフで設定します。

auto

ユーザーエージェントは、組版上高品質な間隔値の集合を選択します。 異なるプラットフォーム上で動作する異なるユーザーエージェントは、 異なる値を選択する場合があります。

注: これらの間隔値は、 OS プラットフォームの慣習と一致する場合も、一致しない場合もあります。

auto は必要でしょうか？ 著者が最初の行の先頭で プラットフォーム依存の挙動を選ぶのは奇妙であり、 それ以外では trim-both を使用すべきです。

8.5.1. 全角句読点の畳み込み

通常、全角文字は標準的な漢字（例: 水 U+6C34）と同じ前進幅の グリフを持ちます。 しかし、多くの全角句読点グリフは、 全角デザイン空間の一部のみを占めます。 したがって、そのような句読点は常に全角で設定されるわけではありません。 text-spacing-trim のいくつかの値は、 そのような文字がいつ半角 （通常は表意文字の半分の幅）で設定され、 いつ全角で設定されるかを著者が制御できるようにします。

指定されたとおりにテキストを設定するために、UA は次のいずれかを行う必要があります

• グリフが全角で与えられており、半角として設定しなければならない場合、 グリフの空白半分を詰める（カーンする）、または
• グリフが半角で与えられており、全角として設定しなければならない場合、 グリフに空間を追加する。

UA は、特定のグリフに必要な詰めを行うために、 フォントによって実装されている場合、 OpenType の halt および vhal 機能を使用してもよいです。 UA は hwid 機能を使用してはならず、 その他の方法で半角形を代替してはなりません。 半角グリフへ切り替えるとグリフ形状が変わる可能性があり、 ここでは許容されないためです。

一部のフォントは、全角句読点文字にプロポーショナルグリフを使用します。 フォント内に全角対半角のグリフ形状を区別するためのサポート （たとえばフォント機能を通じたもの）がない場合、 そのようなプロポーショナルグリフについては、 与えられた前進幅は 同時に全角かつ半角であると見なされます: UA はこれらのグリフに空間を追加したり削除したりしてはなりません。

注: 標準的な漢字の前進幅は、 反対の書字モードに対する OpenType の ideo および idtp ベースラインなどの フォントメトリクスから決定するか、 水 U+6C34 のような漢字の前進幅を取ることで決定できます。 （一部のフォントは文字が正方形でなくなるように圧縮されているため、 反対の書字モードを使用しなければなりません。） OpenType メトリクスに関する詳細情報は、 OpenType 仕様にあります。 水 U+6C34、卜 U+535C、および 一 U+4E00 がすべて同じ前進幅を持たない場合、 そのフォントはプロポーショナル表意文字を持ち、 グリフを測定して全角前進幅を信頼性高く決定することはできないことに注意してください。

一部のフォントには、詰める（カーンする）には空白が小さすぎる 全角句読点文字があります。 UA は、グリフ境界ボックス、グリフメトリクス、またはフォント機能を通じて、 詰め（カーニング）がグリフの切れ、衝突、または過度なカーニングを引き起こす可能性があると 判断した場合、 詰め（カーン）ないことを選択してもよいです。

text-spacing-trim が trim-all である場合、 UA は、そのような全角グリフに通常関連付けられる空間を、 それらが現れる文脈に関係なく畳み込まなければなりません。 それ以外の場合、text-spacing-trim が space-all に設定されている場合 （またはフォントがプロポーショナル全角句読点グリフを持つ場合）を除き、 UA は、そのような全角グリフに通常関連付けられる空間を、 行上で隣接して置かれたとき、 次のように畳み込まなければなりません:

• 前の文字が次のいずれかである場合、全角始め句読点を半角に設定します:

  • 全角始め句読点

  • 全角中点句読点

  • 表意文字スペース（U+3000）

  • 同等またはそれより大きい font-size の 全角終わり句読点

  • Unicode 一般カテゴリ Ps に属する文字

  それ以外の場合は全角に設定します。

• 次の文字が次のいずれかである場合、全角終わり句読点を半角に設定します:

  • 全角終わり句読点

  • 全角中点句読点

  • 表意文字スペース（U+3000）

  • より大きい font-size の 全角始め句読点

  • Unicode 一般カテゴリ Pe に属する文字

  それ以外の場合は全角に設定します。

8.5.2. テキスト間隔文字クラス

このプロパティの文脈では、次の定義が適用されます:

クラスと Unicode コード ポイントは検討中であり、 Unicode へのより最近の追加に対応するには、少なくともいくつかの変更が必要です。 [Issue #9503]

表意文字

基底文字が以下に列挙される、すべての 組版上の文字単位 [CSS-TEXT-3] を含みます:

• U+3041 から U+30FF の範囲内のすべての文字。 ただし Unicode 句読点 [P*] 一般 カテゴリに属するものを除く。
• CJK Strokes（U+31C0 から U+31EF）。
• Katakana Phonetic Extensions（U+31F0 から U+31FF）。
• Han script プロパティを持つすべての文字。

非表意文字の 字母

Unicode 字母 [L*] および記号 [M*] 一般カテゴリに属する すべての 組版上の文字単位を含みます。 ただし、次のいずれかの条件を満たす場合を除きます:

• 表意文字として定義されている。
• [UAX11] によって East Asian Fullwidth (F) と分類されている。
• text-orientation プロパティ または text-combine-upright プロパティを用いた 縦書きテキストフローで正立している。

非表意文字の 数字

Unicode 十進数字 [Nd] 一般カテゴリに属する すべての 組版上の文字単位を含みます。 ただし、次のいずれかの条件を満たす場合を除きます:

• [UAX11] によって East Asian Fullwidth (F) と分類されている。
• text-orientation プロパティ または text-combine-upright プロパティを用いた 縦書きテキストフローで正立している。

全角 始め句読点

Unicode カテゴリ Ps の任意の始め句読点文字のうち、 CJK Symbols and Punctuation ブロック（U+3000–U+303F）に属するもの、 または [UAX11] によって East Asian Fullwidth (F) と分類されるものを含みます。 LEFT SINGLE QUOTATION MARK（U+2018）および LEFT DOUBLE QUOTATION MARK（U+201C）も含みます。 詰められる場合、左半分（横書きテキストの場合）または上半分（縦書きテキストの場合）がカーンされます。

全角 終わり句読点

Unicode カテゴリ Pe の任意の終わり句読点文字のうち、 CJK Symbols and Punctuation ブロック（U+3000–U+303F）に属するもの、 または [UAX11] によって East Asian Fullwidth (F) と分類されるものを含みます。 RIGHT SINGLE QUOTATION MARK（U+2019）および RIGHT DOUBLE QUOTATION MARK（U+201D）も含みます。 全角コロン句読点および/または 全角ドット句読点も含む場合があります （下記参照）。 詰められる場合、右半分（横書きテキストの場合）または下半分（縦書きテキストの場合）がカーンされます。

全角中点句読点

MIDDLE DOT（U+00B7）、HYPHENATION POINT（U+2027）、および KATAKANA MIDDLE DOT（U+30FB）を含みます。 全角コロン句読点および/または 全角ドット句読点も含む場合があります （下記参照）。

全角 コロン句読点

FULLWIDTH COLON（U+FF1A）および FULLWIDTH SEMICOLON（U+FF1B）を含みます。

全角ドット 句読点

次を含みます: IDEOGRAPHIC COMMA（U+3001）、 IDEOGRAPHIC FULL STOP（U+3002）、 FULLWIDTH COMMA（U+FF0C）、 FULLWIDTH FULL STOP（U+FF0E）。

全角コロン句読点および 全角ドット句読点を 全角終わり句読点と見なすべきか、または 全角中点 句読点と見なすべきかは、 句読点がグリフのボックス内のどこに描かれるかに依存します。 句読点が中央に配置されている場合、 それは中点句読点と見なされるべきです。 句読点が片側（横書きテキストでは左、縦書きテキストでは上）に描かれ、 したがってもう半分が空白である場合、 その句読点は終わり句読点と見なされ、それに応じて詰められるべきです。

UA は、全角コロン句読点および 全角ドット句読点を、 適切に 全角終わり句読点カテゴリまたは 全角中点句読点カテゴリのいずれかに 分類しなければなりません。 UA は、この分類を決定するために、 言語慣習および書字モード（横書き対縦書き）、 および/またはフォント情報に依存してもよいです。 UA はまた、適切に任意のカテゴリへ追加の文字を加えてもよいです。

8.5.3. CSS における日本語段落開始規約

日本語には一般的な開始端の組版方式が 3 つあり、 それらは始め括弧の扱いによって区別されます。

行頭における始め括弧の配置 [JLREQ]

p { margin: 1em 0; } という UA スタイルシートを仮定すると、 CSS は次の規則で日本語の組版スタイルを実現できます:

• 括弧をインデントに揃え、他の行にも揃える（第 1 方式）:

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

• 括弧がすべての行で全角間隔を保持する（第 2 方式）:

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

• 括弧をインデント内にぶら下げ、他の行には揃える（第 3 方式）:

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

8.6. 文字クラス間隔の一括指定: text-spacing プロパティ

このプロパティは、 text-spacing-trim と text-autospace を 単一の宣言で設定するための一括指定です。 値は次のように定義されます:

none

すべての text-spacing 機能を無効にします: text-spacing-trim を space-all に設定し、 text-autospace を no-autospace に設定します。

auto

text-spacing-trim と text-autospace の両方を auto に設定します。

<spacing-trim>

text-spacing-trim を指定された値に設定します。 <autospace> 値が与えられていない場合、 text-autospace はその 初期 値に設定されます。

<autospace>

text-autospace を指定された値に設定します。 <spacing-trim> 値が与えられていない場合、 text-spacing-trim はその 初期 値に設定されます。

注: normal は text-spacing-trim と text-autospace の両方の初期値であるため、 text-spacing: normal は両方を初期値にリセットします。

8.7. 要素境界をまたぐシェーピング

2 つの 組版上の文字単位を分離する境界を持つ任意のボックスについて、 次のいずれかが真である場合、 テキストシェーピングはインラインボックス境界で分断されなければなりません:

• インライン軸で 2 つの 組版上の文字単位を分離する margin/border/padding のいずれかが非ゼロである。
• vertical-align が baseline でない。
• その境界が bidi 隔離境界である。

整形に実効的な変化がない場合、 または唯一の整形変化がグリフに影響しない場合 （テキスト装飾の適用など）、 テキストシェーピングはインラインボックス境界をまたいで 分断されてはなりません。

それ以外の場合、 フォント技術の制約を考慮してその事例で合理的かつ可能であるなら、 テキストシェーピングはインラインボックス境界をまたいで 分断されるべきではありません。

9. 端の効果

端の効果は、 ブロック内の他の行に対する行のインデント （text-indent） および行の先頭端と末尾端で内容がどのように測定されるか （hanging-punctuation） を制御します。

9.1. 最初の行のインデント: text-indent プロパティ

このプロパティは、 ブロック内のインライン内容の行に適用されるインデントを指定します。 インデントは、ラインボックスの 始端側に適用される マージンとして扱われます。

each-line および/または hanging キーワードによって 別途指定されない限り、 要素の 最初の整形済み行である行のみが影響を受けます。 [CSS-PSEUDO-4] たとえば、匿名ブロックボックスの最初の行は、 それが親要素の最初の子である場合にのみ影響を受けます。

値は次の意味を持ちます:

<length>

インデント量を絶対長として与えます。

<percentage>

ブロックコンテナー自身の 論理 幅に対するパーセンテージとして、 インデント量を与えます。

パーセンテージは、内在サイズ寄与を計算する目的では 0 として扱われなければなりませんが、 レイアウトを行うときは常に通常どおり解決されます。

注: これは要素のオーバーフローにつながることがあります。 パーセンテージインデントと内在サイズ決定を一緒に使用することは推奨されません。

each-line

インデントは、各ブロックコンテナーの最初の行と、 強制改行の後の各行に影響します （ただし ソフト 折り返し分割後の行には影響しません）。

hanging

影響を受ける行を反転します。

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

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

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

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

注: text-indent プロパティは継承されるため、 ブロック要素に指定された場合、子孫の inline-block 要素に影響します。 このため、display: inline-block が指定された要素には、 text-indent: 0 を指定するのが 多くの場合賢明です。

9.2. ぶら下がるグリフ

行の先頭端または末尾端にあるグリフが ぶら下がる場合、 それは、行内容が収まるか、配置されるか、両端揃えされるかを測定する際に 考慮されません。 行の配置/両端揃えによっては、 その記号がラインボックスの外側に置かれる結果になることがあります。 ぶら下がるグリフは、 内在サイズ（min-content サイズ および max-content サイズ） およびそれらから派生する任意のサイズを計算する際にも考慮されません。 （この測定とカーニングの相互作用は現在 UA 定義です。 CSSWG はこの点について 助言を歓迎します。）

ぶら下がるグリフは、 なお親インラインボックスの内側に含まれ、 テキスト両端揃えにも参加します: その文字の前進幅が、 行にどれだけの内容が収まるか、 両端揃えのために行内容をどれだけ拡張または圧縮する必要があるか、 またはテキスト配置のためにラインボックス内で内容をどのように配置するかを決定する際に、 測定されないだけです。 実質的に、ぶら下がるグリフの文字前進幅は、 影響を受ける親 インラインボックスの端における 追加の負のマージンとして再解釈されます。 行はそれ以外は通常どおりレイアウトされます。 オーバーフローする ぶら下がるグリフは、 不要なスクロールバーを作成しないように、通常は インクオーバーフローと見なされるべきです。 ただし UA は、内容が編集可能である場合、 またはそれを スクロール可能オーバーフローとして扱うことが 利用者に有用であるその他の状況では、 スクロール可能オーバーフローとして扱ってもよいです。 [CSS-OVERFLOW-3]

場合によっては、行末のグリフは 条件付きで ぶら下がることがあります: 両端揃え前にそれが他の方法では行に収まらない場合にのみ、 それはぶら下がります。 それは、行内容が収まるかを測定する際に考慮されません。 しかし、収まらない任意の部分は ぶら下がるものと見なされます。 条件付きでぶら下がるグリフは、 min-content サイズ およびそれらから派生する任意のサイズを計算する際には考慮されませんが、 max-content サイズ およびそれらから派生する任意のサイズでは考慮されます。

ぶら下がり可能なグリフと 行端との間に非ゼロのインライン軸方向の border または padding がある場合、 そのグリフはぶら下がれません。 たとえば、末端パディングを持つインラインボックスの末尾にあるピリオドは、 行の末端で ぶら下がりません。

複数の隣接するグリフは一緒にぶら下がることができます。 ただし、ぶら下がりを許可される数に対する具体的な制限が指定される場合があります （例: 行の各端で最大 1 つの句読点文字だけが ぶら下がることができる）。

9.2.1. ぶら下げ句読点: hanging-punctuation プロパティ

このプロパティは、句読点記号が存在する場合に、 それがテキスト行の先頭または末尾で ぶら下がり、 ラインボックスの外側 （またはインデント内） に配置されてもよいかどうかを決定します。

注: ブロックコンテナーに十分なパディングがない場合、 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

行末の 終止符またはコンマが 条件付きでぶら下がります。

行の各端で、最大 1 つの句読点文字だけが ぶら下がることができます。

終止符 およびコンマのうち、ぶら下がりが許可されるものは次を含みます:

UA は適切に他の文字を含めてもよいです。

注: CSS Working Group は、 他の文字を含める UA が そのような追加についてワーキンググループへ通知することを歓迎します。

allow-end と force-end は、東アジアで使用される ぶら下げ句読点の 2 つの変種です。

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

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

allow-end では、 1 行目の末尾にある句読点はぶら下がりません。 ぶら下げなくても収まるためです。 しかし、force-end が使用される場合、 それは強制的にぶら下がります。 両端揃えは、ぶら下がる句読点を含めずに行を測定します。 したがって行が拡張されると、句読点は行の外側へ押し出されます。

9.3. 双方向性とラインボックス

ラインボックスの 始端 および 終端 側は、 そのラインボックスの インライン基底方向によって決定されます。 通常は一致しますが、 ラインボックスの インライン基底方向は、 包含ブロックまたは bidi 段落の インライン基底方向とは別個です。 ラインボックスの インライン基底 方向は、 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]:

• bidi 段落（すなわち、そのラインボックスが内容を保持する bidi 段落）が強い方向性を持つ場合、 その ラインボックスの インライン基底方向はその方向です。
• ラインボックスが空である場合 （すなわち、アトミックインラインまたは、 存在する場合の改行文字以外の文字を含まない場合）、 またはそれ以外で強い方向性を持たない場合 （弱い文字または中立文字のみを含む場合）、 その インライン基底方向は 先行するラインボックス（存在する場合）から取得され、 これが包含ブロック内の最初のラインボックスである場合は、 包含ブロックの direction プロパティから取得されます。 （これにより、内容が LTR 基底方向を持つ RTL ラインボックスになる場合があります。）

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

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

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

Hello!

</textarea>

付録 A: テキスト処理の処理順序

この付録は規範的です。

次のリストは、テキスト操作の順序を定義します。 （結果として得られるレイアウトが同じである限り、実装はこの順序に拘束されません。）

1. § 4.2 空白のトリミング: white-space-trim プロパティ
2. 空白処理 第 I 部（事前折り返し）
3. § 2.2 単語間の拡張: word-space-transform プロパティ および テキスト変換
4. テキスト結合 [CSS-WRITING-MODES-4]
5. テキストの向き [CSS-WRITING-MODES-4]
6. 行ごとに次を適用しながら テキスト折り返し:

   1. インデント

   2. 双方向並べ替え [CSS2] / [CSS-WRITING-MODES-4]

   3. 空白処理 第 II 部

   4. line-padding、letter-spacing、word-spacing、および text-spacing

   5. フォント/グリフ選択と配置 [CSS-FONTS-3]

   6. ぶら下げ句読点

   注: これらの操作は、 行にどれだけのテキストが収まるかに影響し、 したがって折り返しへループバックする場合があります。

7. 両端揃え （グリフ選択および/またはテキスト折り返しに影響し、そのステップへループバックする場合があります）
8. テキスト配置
9. テキストグループ配置

付録 B: プレーンテキストへの変換

この付録は、プレーンテキストのコピー＆ペースト操作の目的において規範的です。

CSS で描画された文書がプレーンテキスト形式へ変換される場合、 次が期待されます:

• text-transform プロパティは効果を持たない。
• white-space-trim および § 4.3.1 フェーズ I: 折り畳みと変換 が適用され、 ブロックの先頭または 強制改行の直後にある 折り畳み可能な 空白の任意の並びが 削除される。

付録 C: 既定の UA スタイルシート

この付録は参考情報です。 HTML の既定スタイルシートを実装する UA 開発者を支援するためのものですが、 UA 開発者は適切に無視または変更して構いません。

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

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

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

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

付録 D: 文字体系と間隔

この付録は規範的です。

組版上の挙動は言語によって多少異なりますが、 書記体系によって大きく異なります。 この付録は、Unicode 6.0 における一般的な script の一部を、 その両端揃えおよび間隔挙動に従って分類します。 カテゴリの説明は記述的であり、規定的ではありません。 決定要因は、両端揃え機会の優先順位付けです。

ブロック文字体系

CJK および拡張としてすべての Wide 文字 （East Asian Width [UAX11] を参照）。 次の Unicode script が含まれます: Bopomofo、Han、Hangul、Hiragana、Katakana、および Yi。 East Asian Width プロパティの Wide および Fullwidth の文字も含まれますが、 Ambiguous 文字は、 書記体系が Chinese、 Korean、 または Japanese である場合にのみ含まれます。

クラスタ化 文字体系

クラスタ化文字体系は離散的な単位を持ち、 単語境界でのみ分割しますが、 可視の単語区切りを使用しません。 空間の伸長を優先しますが、 両端揃えのために文字間隔を快適に受け入れます。 クラスタ化文字体系には、 次の Unicode script が含まれますが、これらに限定されません: Khmer、 Lao、 Myanmar、 New Tai Lue、 Tai Le、 Tai Tham、 Tai Viet、 Thai

筆記体文字体系

筆記体文字体系は、両端揃えまたは letter-spacing の いずれについても、 字母間の隙間を認めません。 次の Unicode script が含まれます: Arabic、 Hanifi Rohingya、 Mandaic、 Mongolian、 N’Ko、 Phags Pa、 Syriac

注: ベースライン接続子を持つインド系文字体系 （Devanagari や Gujarati など）は 筆記体文字体系とは見なされず、 組版上の文字単位の間に そのような隙間を認めます。 Indic Layout Requirements を参照してください。 [ILREQ]

ユーザーエージェントは、 Unicode サポートを更新する際にこのリストを更新して、 Unicode の将来バージョンでまだ符号化されていない筆記体文字体系に対応すべきであり、 CSSWG にこの仕様をそれに応じて更新するよう求めることが推奨されます。

付録 E: 文字とプロパティ

この付録は規範的です。

Unicode は、CSS 組版で参照される 4 つのコードポイントレベルのプロパティを定義します:

East Asian width プロパティ

Unicode Standard Annex #11 [UAX11] で定義され、 Unicode Character Database では East_Asian_Width プロパティとして与えられます [UAX44]。

一般カテゴリ

Unicode Standard Annex #44 [UAX44] で定義され、 Unicode Character Database では General_Category プロパティとして与えられます [UAX44]。

script プロパティ

Unicode Standard Annex #24 [UAX24] で定義され、 Unicode Character Database では Script プロパティとして与えられます [UAX44]。 （UA は、この対応付けに ScriptExtensions.txt の割り当てをすべて含めなければなりません。）

Vertical Orientation

Unicode Standard Annex #50 [UAX50] で、 Unicode Character Database における Vertical_Orientation プロパティとして定義されます [UAX44]。

Unicode は個々のコードポイントのプロパティを定義しますが、 組版上の文字単位のプロパティを 決定する必要がある場合もあります。 CSS Text の目的では、 組版上の文字単位のプロパティは、 最初の 書記素クラスタの基底文字によって与えられます—​ただし 2 つの場合を除きます:

• Common script の Enclosing Mark (Me) で形成された 書記素クラスタは、 Common script の Other Symbols (So) と見なされます。 それらは置換文字（U+FFFD）と同じ Unicode プロパティを持つと仮定されます。
• Space Separator (Zs) を基底として形成された 書記素クラスタは、 Modifier Symbols (Sk) と見なされます。 それらは基底と同じ East Asian Width プロパティを持つと仮定されますが、 その他のプロパティは その並び内の最初の結合文字から取得します。

付録 F: 内容書記体系の識別

この付録は規範的です。

ほとんどの言語には好まれる書記体系がありますが、 複数を持つものもあり、 また多くは 1 つ以上の外来書記体系へ転写できます。 一般的な例として、多くの言語は少なくとも 1 つのラテン文字転写を持ち、 したがってラテン文字書記体系で書くことができます。 転写されたテキストは通常、その書記体系の組版慣習を採用します: たとえば日本語の “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]

しかし、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 コードのいずれかに指定されている場合、 その 書記体系は Chinese です。
• 内容 言語が日本語であり、かつ 書記体系が指定されていない場合、 または任意の 内容言語について 書記体系が Jpan、 Hrkt、 Hira、 または Kana ISO script コードのいずれかに指定されている場合、 その 書記体系は Japanese です。
• 内容 言語が韓国語であり、かつ 書記体系が指定されていない場合、 または任意の 内容言語について 書記体系が Kore、 Hang、 または Jamo ISO script コードのいずれかに指定されている場合、 その 書記体系は Korean です。
• 書記 体系は、 内容 言語自体が不明である場合、 またはそれが不明な書記体系を明示的に示す場合にのみ、 不明と見なされます。

  注: 書記体系情報が単に省略されているだけで、 内容 言語が宣言されている場合、 それは 書記体系が不明ではなく、 暗黙であることを意味します。

付録 G: 小書き仮名のマッピング

この付録は規範的です。

付録 H: 単語とフレーズの検出

この付録は規範的です。

この仕様のいくつかの操作は、 自動化された 単語境界検出 または フレーズ境界検出 に依存します。

どちらの操作も似ています: ユーザーエージェントはテキストの言語解析を行い、 言語固有の意味のある文字列を識別します。 それらは、対象とするテキスト単位が 単語かフレーズかだけが異なります。

広い意味では容易に理解できますが、 単語とフレーズの両概念を正確に定義することは難しく、 特に複数の言語にまたがって機能する方法では困難です。 それでも、この文脈では:

• 単語は、1 つ以上の文字または音節から構成され得る、 認識可能な意味単位です。

  注: この概念に関する議論については、 What is a word? を参照してください。

• フレーズは、1 つまたは複数の単語からなる短いまとまりであり、 概念上または文法上の単位として一緒に立ち、 節または文の構成要素を形成します。

  注: これは、ここで用いられる英語の意味での phrase ではなく文を意味する フランス語の phrase と混同してはなりません。 日本語では、 これは文節の概念に対応します。

  フレーズは、 冠詞や前置詞または後置詞を伴う名詞、 句動詞、 複合動詞時制… であり得ます。

検出された各単語またはフレーズの開始位置と終了位置は、 単語 境界または フレーズ 境界と呼ばれます。 単語境界およびフレーズ境界はそれ自体では観測できませんが、 word-space-transform や word-break などのプロパティが、それらの位置で可視効果を引き起こすことがあります。

単語またはフレーズを検出し、 その境界を配置する具体的なアルゴリズムは UA 依存であり、 辞書ベースの語彙解析、 句読点またはその他の区切り文字の識別、 形態素解析、 機械学習手法… など、さまざまな要因または手法を考慮してもよいです。

それでも、次の制約は尊重されなければなりません:

• ユーザーエージェントは、 単一の 組版上の文字単位を構成する文字の間に 単語またはフレーズ境界を置いてはなりません。
• ユーザーエージェントは、 行分割クラス GL、WJ、または ZWJ を持つ任意の文字に隣接して 単語またはフレーズ境界を置いてはなりません。 2 つの候補となる単語またはフレーズがそのような文字で分離されている場合、 それらは単一のものとして扱われなければなりません。 [UAX14]
• 単語またはフレーズの直後に次の文字の 1 つ以上が続く場合、 ユーザーエージェントはそれらを先行する単語またはフレーズの一部と 見なさなければなりません:
  • 単語区切り 文字
  • その他の空白区切り
  • U+200B ZERO WIDTH SPACE 文字

• 句読点はそれ自体ではフレーズではありません: 隣接する言語的な単語またはフレーズの適切な側に付着されるべきです。 たとえば、 括弧や引用符などの囲み句読点は、それらが囲むフレーズの一部です。 コンマおよびセミコロンは先行するフレーズに接尾されます。 U+00BF INVERTED QUESTION MARK は後続の単語に付着します。 などです。

  しかし、スマイリー、顔文字、Perl スニペットなどの 句読点の慣例外の使用により、 ユーザーエージェントはこの原則から逸脱する必要が生じる場合があります。

• 単語またはフレーズ境界を決定するとき、 インラインボックス境界および 通常フロー外要素は無視されなければなりません。 しかし、 単語または フレーズ境界が 1 つ以上のインラインボックス境界と同じ位置で見つかった場合、 単語または フレーズ 境界は、 このインラインボックス境界に参加する最も外側の要素内に 挿入されなければなりません。
  次の例では、 赤い “|” は、 ユーザーエージェントが 単語境界を検出する際にそれらを置く合理的な位置を示します:

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

  その文にインラインマークアップが含まれていた場合、 次の例は単語境界を置く正しい位置を示します:

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

  次の例は誤った位置を示します:

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

  次は、より作為的な状況での正しい位置を示します:

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

プライバシーに関する考慮事項

この仕様は、ユーザーにインストールされているハイフネーション辞書および行分割辞書を漏えいさせます。

セキュリティに関する考慮事項

この仕様は新しいセキュリティ上の考慮事項を導入しません。

謝辞

この仕様は、以下の方々の助力なしには実現できませんでした: Addison Phillips, Aharon Lanin, Alan Stearns, Ambrose Li, Arnold Schrijver, Arye Gittelman, Ayman Aldahleh, Ben Errez, Bert Bos, Chris Lilley, Chris Pratley, Chris Thrasher, Chris Wilson, Dave Hyatt, David Baron, Emilio Cobos Álvarez, Eric LeVine, Etan Wexler, Frank Tang, Håkon Wium Lie, IM Mincheol, Ian Hickson, James Clark, Javier Fernandez, John Daggett, Jonathan Kew, Ken Lunde, Laurie Anna Edlund, Marcin Sawicki, Martin Dürst, Martin Heijdra, Masafumi Yabe, Masayasu Ishikawa, Michael Jochimsen, Michel Suignard, Mike Bemford, Myles Maxfield, Nat McCully, Paul Nelson, Pierre-Anthony Lemieux, Rahul Sonnad, Randy Edmunds, Richard Ishida, Shinyu Murakami, Stephen Deach, Steve Zilles, Takao Suzuki, Tantek Çelik, Xidorn Quan, Yaniv Feinberg。

変更点

この草案は [CSS-TEXT-3] と同期して維持されています。CSS Text 3 § Changesを参照してください。
レベル 4 固有の変更点を以下に示します。

2024 年 5 月 29 日の作業草案以降の重要な変更点は次のとおりです:

• avoid-orphans を text-wrap-style に追加しました。 （Issue 10837）

• 既定の UA スタイルシート内で text-spacing: none が 割り当てられる要素のリストに、 listing、 xmp、 および plaintext を追加しました。 （Issue 13369）

2024 年 2 月 19 日の作業草案以降の重要な変更点は次のとおりです:

• text-spacing-trim の値 trim-auto を trim-both に改名しました。 （Issue 10161）

• 行数が多い場合について、text-wrap-style: balance で行を変更しないことに関する要件を緩和しました。 （Issue 10186）

• text-wrap-style: balance と line-clamp の相互作用を定義しました （Issue 9310）

• text-transform に math-auto 値を追加しました。 （Issue 5386）

2023 年 10 月 20 日の作業草案以降の重要な変更点は次のとおりです:

• text-spacing-trim: space-first の定義から 誤って削除された “and each line after a forced line break” を 復元しました。 （Issue 9532）

• text-spacing-trim の初期値を normal にしました。 （Issue 9511）

• space-first の行末挙動を変更しました。 （Issue 9736）

• space-first は行分割後に適用されます。 （Issue 9532）

• 全角句読点の畳み込みの詳細を明確化しました。 （Issue 9225）

• ユーザーエージェントスタイル規則により、 pre が既定で hanging-punctuation を継承しないようにしました。 （Issue 9689）

2023 年 3 月 29 日の作業草案以降の重要な変更点は次のとおりです:

• text-wrap プロパティを 2 つの新しいプロパティ、 text-wrap-mode と text-wrap-style の一括指定として再構成し、 text-wrap-mode を text-wrap ではなく、 white-space プロパティの個別指定にしました。

• 付録 G: 小書き仮名のマッピングを Unicode 15.0 に更新しました。 （Issue 8442）

• word-break: auto-phrase word-break: manual 機能を再設計し （以前の試みである独立した word-boundary-detection プロパティから）、 word-space-transform に auto-phrase 値を追加しました （もはや word-boundary-detection に依存できないためです）。 さらに関連する支援機構を更新しました。

• word-boundary-expansion を word-space-transform に改名しました

• text-spacing-trim に trim-all を追加しました。 （Issue 8482）

• NBSP 以外の調整不能な Unicode 行分割制御は、 アトミックインラインに関する規則より優先されます。 （Issue 8972）

2023 年 3 月 1 日の作業草案以降の重要な変更点は次のとおりです:

• white-space を複数の 個別指定へ移行する作業を、次によって完了しました

  • すべての一括指定値を個別指定で表現できるように、 white-space-collapse に break-spaces を追加 （Issue 8256）

  • すべての個別指定キーワードを white-space 一括指定に統合

  • それに応じて本文を更新

• text-space-collapse および text-space-trim を white-space-collapse および white-space-trim に改名しました。 （Issue 8273）

2022 年 12 月 31 日の作業草案以降の重要な変更点は次のとおりです:

• text-spacing を次によって再設計しました:

  • 有用でないキーワードの組み合わせを削除 （Issues 4246, 8288）

  • space-first を初期値に変更 （Issue 2462）

  • 個別指定へ分割 （Issues 4246, 7183, 8288）

  • 各機能を「オフ」にできることを確保。 （Issues 6950, 8288）

  • ソース内の誤った空白文字を置換できるようにするキーワードを追加。 （Issues 318, 7183, 8263）

  • プレーンテキスト由来のソーステキスト慣行を補償するため、 hanging-punctuation が先頭の 表意文字スペースをぶら下げられるようにしました。 （Issue 2462）

  • no-compress は間隔よりも 両端揃えを制御するため、 text-justify へ移動しました。 （Issue 7079）

• text-spacing で評価される文脈文字を拡張し、 Pe および Ps カテゴリの文字を含めました。 （Issue 6091）

• text-space-collapse を white-space-collapse に戻して改名しました。 （Issue 8273）

2022 年 5 月 5 日の作業草案以降の重要な変更点は次のとおりです:

• text-justify に ruby 値を追加しました。 （Issue 771 Issue 779）
• text-spacing: normal が allow-end ではなく trim-end を使用するように切り替えました。 （Issue 7055）
• text-spacing: normal が ideograph-alpha および ideograph-numeric も適用するように切り替え、 等幅文脈からこれらを除外するよう UA 既定スタイルシートを更新し、 非ゼロの margin/border/padding が空間挿入を抑制することを指定し、 挿入される空間量を 0.125ic と定義しました。 （Issue 6950）
• text-align: match-parent が、実装の単純化のため、 ルート要素上で start に算出されるよう定義しました。 （Issue 6542）
• distribute キーワードを 旧来値エイリアスにすること、または単に inter-character に算出することを許可しました。 後方互換性においてその区別は問題にならないため、UA が容易な方を行えるようにするためです。 （Issue 7322）
• white-space-trim の trim-inner 値を、他の値との一貫性のため discard-inner に改名しました。 （Issue 448）

2019 年の作業草案以降の重要な変更点は次のとおりです:

• [CSS-TEXT-3] の全文を統合。
• 現在の font-size に相対するサイズを表すため、 word-spacing および letter-spacing にパーセンテージを追加。 （Issue 2165）
• textarea 内のスペースが折り畳まれないようにする UA 規則を提案。 （Issue 6309）

レベル 3 以降の追加

レベル 4 の新機能:

• word-break: auto-phrase。 行分割時に一緒に保つフレーズを自動的に決定するためのものです

• word-space-transform。 単語区切りを変換するためのものです

• white-space プロパティを複数の個別指定へ分解:

  • white-space-collapse と、その preserve-spaces および discard 値

  • white-space-trim。 要素境界の余分な空白をトリミングするためのものです

  • text-wrap-mode。 折り返しが発生するかどうかを制御するためのものです

• text-wrap-style と、その balance、stable、 および pretty 値

• wrap-before、wrap-after、および wrap-inside。 （ページ分割用の break-* プロパティに似た） 折り返しを回避または強制するためのものです

• hyphenate-character。 ハイフネーション文字を明示的に制御するためのものです

• hyphenate-limit-zone、hyphenate-limit-chars、hyphenate-limit-lines、hyphenate-limit-last。 自動ハイフネーションをよりよく制御するためのものです

• たとえば小数点で揃えるための、 text-align の <string> 値

• text-group-align。 text-align によって配置された 内容を持つ一連のラインボックスをグループ配置するためのものです

• line-padding。 行の先頭/末尾でインラインボックス内に空間を挿入するためのものです

• text-spacing。 句読点および文字体系の変化位置の周囲に自動間隔を入れるためのものです