CSS 書字方向レベル 4

1. 書字モード入門

CSS 書字方向レベル 4 は、さまざまな言語の 書字モードをサポートする CSS 機能を定義します。これには、左から右（ラテン文字やインド系文字など）、右から左 （ヘブライ文字やアラビア文字など）、双方向（ラテン文字とアラビア文字の混在など）、および 縦書き（アジアの用字系など）が含まれます。

CSS における書字モードは、 writing-mode、direction、およびtext-orientationプロパティによって決定されます。これは主として、 インライン基底方向とブロックフロー方向の観点から定義されます:

ラテン文字ベースの書字モード

モンゴル文字ベースの書字モード

漢字ベースの書字モード

インライン基底 方向は、行内で内容が配列される主要な方向であり、 行の「始端」と「終端」がどちら側にあるかを定義します。directionプロパティは、ボックスの インライン基底方向を指定し、unicode-bidiプロパティおよび テキスト内容に固有の方向性とともに、 行内のインラインレベルの内容の順序を決定します。

ブロックフロー 方向は、ブロックレベルボックスが積み重なる方向、および ブロックコンテナー内で行ボックスが積み重なる方向です。writing-modeプロパティは、 ブロックフロー方向を決定します。

組版モードは、 縦書き 用字系に対して、縦方向のフローに固有の組版規則をテキストに適用すべきかどうかを 決定します。 この概念は、縦書き用字系の縦方向のフローを 回転させた横方向のフローから 区別します。

横書き モードは、テキストの行が水平である書字モード、 すなわち下向きまたは上向きのブロックフローです。 縦書き モードは、テキストの行が垂直である書字モード、 すなわち左向きまたは右向きのブロックフローです。

これらの用語を、垂直ブロックフロー （下向きまたは 上向きのブロックフロー）や、水平ブロック フロー（左向きまたは 右向きのブロックフロー）と混同しないでください。混乱を避けるため、CSS 仕様では、後者の一連の用語を使用しません。

書記体系には通常、固有の書字モードが一つまたは二つあります。 次に例を示します:

• ラテン文字ベースの体系は通常、左から右へのインライン 方向と、下向き（上から下）のブロックフロー方向を使用して記述されます。
• アラビア文字ベースの体系は通常、右から左への インライン方向と、下向き（上から下）のブロックフロー方向を使用して記述されます。
• モンゴル文字ベースの体系は通常、上から下への インライン方向と、右向き（左から右）のブロックフロー方向を使用して記述されます。
• 漢字ベースの体系は一般に、左から右へのインライン方向と 下向き（上から下）のブロックフロー方向、または上から下へのインライン 方向と左向き（右から左）のブロック フロー方向を使用して記述されます。多くの雑誌や新聞では、これら二つの書字 モードが同じページ内で混在します。

書字モードのtext-orientation構成要素は、 グリフの向きを制御します。

書字モードと縦書きテキストについてさらに詳しく紹介している Unicode Technical Note #22 [UTN22]（HTML 版）を 参照してください。

1.1. モジュール間の相互作用

このモジュールは、unicode-bidiおよびdirectionの [CSS2]の第 8.6 節および第 9.10 節で定義された機能を置換し、拡張します。 これらの機能と、 テキストの行を組む際の その他のテキスト操作との 相互作用については、CSS Text 3 § テキスト処理の 操作順序で説明されています。

算出値であるwriting-mode、direction、および text-orientationプロパティは、 （これらのプロパティ自体が適用されない要素上であっても、[CSS-CASCADE-4]） 無関係な他のプロパティの算出値に広範な影響を与えることができます。 これは、たとえば フォント相対長の計算や、算出されたフロー相対プロパティのカスケードが意図的に依存する 書字モード、または 書字モードに依存し得るフォントメトリクスを通じて行われます。

1.2. 値の型と用語

この仕様は、CSS プロパティ 定義の表記規則として[CSS2]のものに従います。 この仕様で定義されていない値の型は、CSS Values & Units [CSS-VALUES-3]で定義されます。 他の CSS モジュールによって、これらの値の型の定義が拡張される場合があります。

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

この仕様で使用されるその他の重要な用語と概念は、 [CSS2]および[CSS-TEXT-3]で定義されています。

2. インライン方向と双方向性

ほとんどの用字系の文字は左から右に記述されますが、 一部の用字系は右から左に記述されます。文書によっては、 とりわけアラビア文字やヘブライ文字で記述されたもの、および 一部の言語が混在する文脈において、単一の（視覚的に表示される） ブロック内のテキストが混在した方向性で表示されることがあります。この現象を双方向性、略して 「bidi」と呼びます。

Unicode 標準（Unicode 標準付録 #9）は、 双方向テキストの適切な順序を決定するための複雑な アルゴリズムを定義しています。このアルゴリズムは、 文字のプロパティに基づく暗黙的な部分と、 埋め込みおよび上書きのための明示的な制御から構成されます。CSS は、 適切な双方向レンダリングを実現するために、このアルゴリズムを使用します。

二つの CSS プロパティ、directionとunicode-bidiは、 CSS レイヤーに明示的な埋め込み、分離、および上書きの制御を提供します。 テキストの基底方向は文書の構造と 意味に依存するため、directionおよび unicode-bidiプロパティは、 ほとんどの場合、マークアップ内の双方向情報を 対応する CSS スタイルに写像するためだけに使用すべきです。

HTML 仕様（[HTML401]の第 8.2 節、および[HTML5]の第 10.3.5 節）は、 HTML 要素の双方向性の動作を定義しています。

文書言語が双方向性を制御するためのマークアップ機能を提供する場合、 著者と利用者は代わりにその機能を使用すべきです。それらを上書きする CSS 規則を指定しては なりません。

2.1. 方向性の指定: directionプロパティ

HTML UA は CSS スタイルを無効にできるため、HTML 著者には、 スタイルシートが存在しない場合にも正しい双方向レイアウトを確保するため、HTML の dir 属性と <bdo> 要素を使用することを推奨します。 著者は HTML 文書でdirectionを 使用すべきではありません。

このプロパティは、ボックスによって確立される双方向段落、埋め込み、分離、または上書きの インライン基底方向または方向性を指定します。 （unicode-bidiを参照してください。） さらに、表の列の レイアウト順序、 水平オーバーフローの方向、 行内のテキストの既定の配置、および ボックスのインライン基底方向に依存するその他のレイアウト効果にも情報を提供します。

このプロパティの値は、次の意味を持ちます:

ltr

この値は、インライン基底方向（双方向性）を 行左から行右に設定します。

rtl

この値は、インライン基底方向（双方向性）を 行右から行左に設定します。

directionプロパティは、unicode-bidi値がnormalであるインラインボックスに指定された場合、 双方向の並べ替えには影響しません。これは、ボックスが双方向アルゴリズムに関して 追加の埋め込みレベルを 開かないためです。

directionプロパティを表の列ボックスに指定しても、 列は文書ツリー内でセルの祖先ではないため、 その列内のセルには継承されません。したがって CSS では、 [HTML401]の第 11.3.2.1 節で説明されている「dir」属性の継承規則を容易に表現できません。

2.2. 埋め込みと上書き: unicode-bidiプロパティ

HTML UA は CSS スタイルを無効にできるため、HTML 著者には、 正しい双方向レイアウトを確保するため、HTML の dir 属性、<bdo> 要素、 およびテキストレベルとグループ化レベルの HTML 要素型の適切な区別を使用することを推奨します。 スタイルシートが存在しない場合でも有効です。著者は HTML 文書でunicode-bidiを使用すべきではありません。

通常（すなわち、unicode-bidiがnormalの場合）、 インラインボックスは Unicode 双方向アルゴリズムに対して透過的です。 内容は、ボックスの境界が存在しないかのように配列されます。 unicode-bidiプロパティのその他の値は、 インラインボックスにアルゴリズム内の スコープを作成させ、 テキストに固有の方向性を上書きさせます。

次の参考表は、unicode-bidiがボックスの内部と 外部に与える効果を要約したものです:

このプロパティの値は、次の（規範的な）意味を持ちます:

normal

ボックスは、双方向アルゴリズムに関して 追加の埋め込みレベルを開きません。インラインボックスの場合、 暗黙的な並べ替えはボックスの境界を越えて機能します。

embed

ボックスがインラインである場合、この値は双方向アルゴリズムに関して 追加の埋め込みレベルを開くことにより、方向埋め込みを作成します。 この埋め込みレベルの方向は、directionプロパティによって指定されます。ボックス内では、 並べ替えが暗黙的に行われます。

この値は、インラインではないボックスには影響しません。

isolate

インラインボックスでは、これは内容を双方向分離 します。 これは方向埋め込みに似ており（それに応じて埋め込みレベルも増加します）、 ブロック境界または強制段落区切りによって中断されないインラインレベルボックスの各シーケンスが、 分離 シーケンスとして扱われる点が異なります:

• シーケンス内の内容は、 ボックスのdirectionプロパティで指定された基底方向を持つ 独立した段落内にあるかのように 配列されます。
• それを包含する双方向段落内で双方向解決を行う目的では、 シーケンスは単一のオブジェクト置換文字（U+FFFC）であるかのように扱われます。

実質的に、ボックス内の内容が ボックス周囲の内容から双方向の影響を受けることも、 ボックス周囲の内容が、ボックスの内容または 指定された方向性から双方向の影響を受けることもありません。 ただし、ボックス内の強制段落区切りは、 それを包含する段落内に 対応する区切りを引き続き作成します。

この値は、インラインではないボックスには影響しません。

bidi-override

この値は、ボックスの直接のインライン内容を方向上書きに置きます。 インラインの場合、これは双方向アルゴリズムにおいて方向埋め込みのように動作しますが、 内部の並べ替えは、direction プロパティに従った順序で厳密に行われ、 双方向アルゴリズムの暗黙的な部分は 無視されます。 ブロックコンテナーの場合、上書きは、 そのすべての内容を囲む匿名インラインボックスに適用されます。

isolate-override

これは、isolateの分離動作と、 bidi-overrideの方向上書き動作を組み合わせます: 周囲の内容に対しては、isolateと同等ですが、 ボックス内では、bidi-overrideが指定されたかのように内容が配列されます。 実質的には、分離シーケンス内に 方向上書きを入れ子にします。

plaintext

この値はisolateと同様に動作しますが、 Unicode 双方向アルゴリズムの目的では、ボックスの各 双方向 段落（ブロックコンテナーの場合）または 分離 シーケンス（インラインの場合）の基底方向は、 Unicode 双方向アルゴリズムの規則 P2 および P3 の ヒューリスティックに従って決定されます （ボックスのdirectionプロパティは使用されません）。

Unicode 双方向アルゴリズムの条項 HL3 [UAX9]に従い、 normal以外の値は、対応する Unicode 双方向 制御コードを、 インライン要素の先頭と末尾にあるテキストストリームへ実質的に挿入してから、 段落を Unicode 双方向アルゴリズムに渡して並べ替えます。 （§ 2.4.2 CSS–Unicode 双方向制御の変換、テキストの並べ替えを参照してください。）

unicode-bidiプロパティは 継承されないため、 ブロックボックスにbidi-overrideまたはplaintextを設定しても、 子孫のブロックには影響しません。したがって、これらの値は、 ブロックレベルの構造を含まないブロックおよびインラインで 使用するのが最適です。

unicode-bidiは、plaintextの場合でもdirection プロパティには影響しないため、directionに依存するレイアウト計算にも影響しないことに注意してください。

Unicode アルゴリズムには埋め込みレベルが 125 までという制限があるため、 unicode-bidiのnormal以外の値を過度に使用しないよう注意してください。 特に、inherit値は、深く入れ子になったインライン マークアップで使用する際、細心の注意が必要です。 ただし、一般に ブロックとして表示されることを意図する要素では、要素を一体に保つため、unicode-bidi: isolateの設定が推奨されます。 これは、displayがinlineに変更された場合に備えるためです（下の例を参照）。

2.3. 双方向テキストの例

次の例は、双方向テキストを含む XML 文書を示しています。 これは重要な設計原則を例示しています。文書言語の 設計者は、その言語自体 （要素と属性）および付随するスタイルシートの両方で双方向性を考慮すべきです。 スタイルシートは、双方向性の規則が その他のスタイル規則から分離されるように設計すべきであり、文書言語の双方向性の動作が維持されるよう、 その規則が他のスタイルシートによって上書きされないようにすべきです。

<section dir=rtl>
  <para>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</para>
  <para>HEBREW6 <emphasis>HEBREW7</emphasis> HEBREW8</para>
</section>
<section dir=ltr>
  <para>english9 english10 english11 HEBREW12 HEBREW13</para>
  <para>english14 english15 english16</para>
  <para>english17 <quote dir=rtl>HEBREW18 english19 HEBREW20</quote></para>
</section>

/* 双方向性の規則 */
[dir=rtl] {direction: rtl; unicode-bidi: isolate; }
[dir=ltr] {direction: ltr; unicode-bidi: isolate; }

/* 表示の規則 */
section, para  {display: block;}
emphasis       {font-weight: bold;}
quote          {font-style: italic;}

               5WERBEH 4WERBEH english3 2WERBEH 1WERBEH

                                8WERBEH 7WERBEH 6WERBEH

english9 english10 english11 13WERBEH 12WERBEH

english14 english15 english16

english17 20WERBEH english19 18WERBEH

       2WERBEH 1WERBEH
  -EH 4WERBEH english3
                 5WERB

   -EH 7WERBEH 6WERBEH
                 8WERB

english9 english10 en-
glish11 12WERBEH
13WERBEH

english14 english15
english16

english17 18WERBEH
20WERBEH english19

2.4. 双方向並べ替えアルゴリズムの適用

双方向テキストをサポートするユーザーエージェントは、ブロック境界または 「双方向タイプ B」の 強制段落 区切りによって中断されないインラインレベルボックスの すべてのシーケンスに Unicode 双方向アルゴリズムを適用しなければなりません。 このシーケンスは、双方向アルゴリズムにおける段落単位を 形成します。

2.4.1. 双方向段落の埋め込みレベル

CSS では、 段落の埋め込みレベルは、 （UAX9 の条項 HL1に従い） Unicode アルゴリズムの手順P2およびP3で示されるヒューリスティックではなく、 段落の包含ブロックのdirectionプロパティに従って設定しなければなりません。

ただし、一つ例外があります: 段落の包含ブロックの算出されたunicode-bidiがplaintextの場合、 P2 および P3 の Unicode ヒューリスティックが、[UAX9]の説明に従って、 HL1 の上書きなしで使用されます。

2.4.2. CSS–Unicode 双方向制御の変換、テキストの並べ替え

各双方向段落内の最終的な文字順序は、 unicode-bidi（上記）について説明したとおりに双方向制御コードを追加し、 マークアップを取り除き、結果の文字シーケンスを、 スタイル付きテキストと同じ行区切りを生成するプレーンテキスト用 Unicode 双方向アルゴリズムの実装に 渡した場合と同じになります。

ソーステキスト内の双方向制御コードも引き続き尊重され、 文書ツリー構造に対応しない場合があることに注意してください。 これにより、インラインが分割されたり、双方向の開始／終了制御の組み合わせが 特殊な形で妨げられたりする場合があります。

2.4.3. 不可分インラインの双方向処理

この処理では、置換要素のうち、display: inlineであるものは中立文字として扱われます。 ただし、そのunicode-bidiプロパティがembedまたはbidi-overrideのいずれかである場合は、 要素に指定されたdirectionの 強い文字として扱われます。 （これは、置換要素がインライン化されたテキスト内容のレンダリングにフォールバックした場合に、 周囲のテキストに対する双方向の効果を置換レンダリングと一致させるためです。）

その他のすべての不可分インラインレベルボックスは、 常に中立文字として扱われます。

2.4.4. 埋め込みおよび分離内の段落区切り

インラインボックスが双方向段落の境界付近で分割された場合 （たとえば、ブロックまたは強制段落区切りによって分割された場合）、 ボックスの末尾に割り当てられたHL3双方向制御コードは、 中断の前にも追加され、 ボックスの先頭に割り当てられたコードはその後にも追加されます。 （言い換えると、ボックスによって開始された埋め込みレベル、分離、または上書きは、 段落区切りで閉じられ、その反対側で再び開かれます。）

<para>...<i1><i2>...<BR/>...</i2></i1>...</para>

<para>...<i1><i2>...</i2></i1><BR/><i1><i2>...</i2></i1>...</para>

この動作は、ボックスツリーに適用される、 CSS で宣言された双方向制御に対して CSS によって適用されます。 その効果が双方向段落の末尾で終了するよう定義されている Unicode の双方向書式制御には適用されません。

2.4.5. 並べ替えによって生じるボックスの断片化

双方向の並べ替えでは、論理的に連続するテキストを 分割して並べ替えることがあるため、 双方向テキストによって、そのようなテキストを含むインラインボックスが 分割され、その断片が行内で並べ替えられる場合があります。

2.4.5.1. 並べ替えによって生じるボックス断片化の条件

双方向の並べ替えによって、間にある内容のために インラインボックスが分割される場合、 そのインラインボックスは複数のボックス断片に分割されたものと見なされます。[CSS-BREAK-3] 無限に長い 行において間にある内容によって分割される場合、そのボックスは断片化されたものと見なされます。 これは、行の折り返しによって両方のボックス断片が 行上で互いに隣接して配置される場合でも同様です。 この場合、二つのボックス 断片内のテキストの最も近い共通祖先（ 二つのボックス断片間の字送りや両端揃えなど、テキスト整形の特定の側面を決定します。[CSS-TEXT-3]を参照） は、インラインボックス自体ではなく、 二つのボックス 断片の最も近い共通祖先であると見なされます。 ただし、間にある内容によって強制的に分割されない場合、 インラインボックスは、双方向の並べ替えによって 複数のボックス断片に分割されたとは見なされません。 （これらの規則は、可能な限りインラインボックスの完全性を維持しながら、 行の折り返しが変化しても、 双方向性によって生じる断片化を安定させます。）

<p>here is <em>some MIXED</em> TEXT.</p>

here is some TXET DEXIM.

here is some DEXIM
TXET.

<p>here is <em dir=rtl>some MIXED</em> TEXT.</p>

here is some DEXIM TXET.

here is some DEXIM
TXET.

2.4.5.2. 並べ替えによって生じるボックス断片のボックスモデル

各行ボックスについて、UA は各インラインボックスの断片を取得し、 視覚順（論理順ではありません）にマージン、ボーダー、およびパディングを割り当てなければなりません。 ボックスが出現する最初の行ボックス上で最も始端側にある断片には、 始端辺のマージン、ボーダー、およびパディングが割り当てられ、 ボックスが出現する最後の行ボックス上で最も終端側にある断片には、 終端辺のマージン、ボーダー、およびパディングが割り当てられます。 たとえば、horizontal-tb書字モードでは、次のようになります:

• 親のdirectionプロパティがltrの場合、 ボックスが出現する最初の行ボックス上で最も左側にあるボックス断片には、 左マージン、左ボーダー、および左パディングが割り当てられ、 ボックスが出現する最後の行ボックス上で最も右側にあるボックス断片には、 右パディング、右ボーダー、および右マージンが割り当てられます。
• 親のdirectionプロパティがrtlの場合、 ボックスが出現する最初の行ボックス上で最も右側にある断片には、 右パディング、右ボーダー、および右マージンが割り当てられ、 ボックスが出現する最後の行ボックス上で最も左側にある断片には、 左マージン、左ボーダー、および左パディングが割り当てられます。

縦書きモードにも同様の規則が適用されます。

box-decoration-breakプロパティは、この動作を上書きして、 各断片の両側にボックス装飾を描画できます。[CSS-BREAK-3]

3. 縦書きモード

このモジュールは、双方向テキストに対する CSS2.1 のサポートを拡張するだけでなく、 CSS で縦書きテキストのレイアウトをサポートするために必要な 規則とプロパティを導入します。

3.1. 縦書き入門

この小節は非規範的です。

主として横方向にレイアウトされるラテン文字を使用する言語とは異なり、 中国語や日本語などのアジア言語は 縦方向にもレイアウトできます。次の日本語の例は、同じテキストを 横書きと縦書きでレイアウトしたものです。横書きの場合、テキストは 左から右、上から下へ読まれます。縦書きの場合、テキストは 上から下、右から左へ読まれます。 左から右への横書きの場合における左端からのインデントは、 上から下への縦書きの場合には上端からのインデントに 置き換わります。

中国語と日本語では、行は右から左または上から下に 配列されますが、モンゴル語と満州語では、 左から右に配列されます。

横書きから縦書きへの変更は、 レイアウトだけでなく組版にも影響を与えることがあります。たとえば、約物の スペーシングボックス内での位置が横書きと 縦書きとで変化する場合があり、場合によっては代替グリフが使用されます。

ラテン文字のテキストや、通常は横書きで表示される その他の用字系のテキストを含む縦書きテキストでは、そのテキストを さまざまな方法で表示できます。たとえば、ラテン文字の単語を横倒しに回転したり、 各文字を正立させたりできます:

日付の 2 桁の数字など、一部の特殊な場合には、テキストが 単一の縦書き文字ボックス内にコンパクトに収められます:

レイアウトには、縦書き要素と横書き要素が混在することもよくあります:

縦書きテキストのレイアウトでは、双方向テキストのレイアウトも処理する必要があります。 たとえば、時計回りに回転したアラビア文字は、下から上へレイアウトされます。

3.2. ブロックフロー方向: writing-modeプロパティ

このプロパティは、テキストの行を横方向と縦方向のどちらにレイアウトするか、 およびブロックが進行する方向を指定します。指定できる 値は次のとおりです:

horizontal-tb

上から下へのブロックフロー方向です。 書字モードと 組版モードは どちらも横方向です。

vertical-rl

右から左へのブロックフロー方向です。 書字モードと 組版モードは どちらも縦方向です。

vertical-lr

左から右へのブロックフロー方向です。 書字モードと 組版モードは どちらも縦方向です。

sideways-rl

右から左へのブロックフロー方向です。 書字モードは 縦方向ですが、組版モードは横方向です。

sideways-lr

左から右へのブロックフロー方向です。 書字モードは 縦方向ですが、組版モードは横方向です。

writing-modeプロパティは、ブロックフロー方向を指定します。 これは、ブロック整形コンテキスト内のブロックレベルボックスの配列方向、 インラインを含むブロックコンテナー内の行ボックスの配列方向、 表内の行の配列方向などを決定します。 行ボックスの積み重ね方向を決定することにより、 writing-modeプロパティは、 行ボックスの向き（したがって書字モード）が 横方向か縦方向かも決定します。 その後、text-orientationプロパティが、行ボックス内でテキストをどのように レイアウトするかを決定します。

置換要素の内容は、書字モードによって回転しません。 たとえば画像や<iframe>からの外部内容は正立したままであり、 300px×150px の既定のオブジェクトサイズも向きを変えません。 ただし、テキストを伴う埋め込み置換内容 （MathML の内容やフォーム要素など）は、 UA がその置換内容について該当する縦書きモードをサポートする場合、 置換要素の書字モードと行の向きに一致すべきです。

<style>
  form { writing-mode: vertical-rl; }
</style>
...
<form>
<p><label>氏名　<input value="艾俐俐"></label>
<p><label>言語　<select><option>英語
                       <option>フランス語
                       <option>ペルシア語
                       <option>中国語
                       <option>日本語</select></label>
</form>

ボックスのwriting-mode値が親ボックス （すなわち、display: contentsではない最も近い祖先）と異なる場合:

• そのボックスが、それ以外の場合には算出されたdisplayがinlineであるフロー内ボックスになる場合、 代わりに、そのdisplayの算出値はinline-blockになります。
• ボックスがブロックコンテナーである場合、 独立したブロック整形コンテキストを確立します。
• より一般的には、指定された内部 表示型がflowである場合、 算出された内部表示型はflow-rootになります。[CSS-DISPLAY-3]

svg { writing-mode: initial; }

3.2.1. 廃止された SVG1.1 のwriting-mode値

SVG1.1 [SVG11]は、いくつかの追加値を定義しています: lr、lr-tb、rl、rl-tb、tb、およびtb-rl。

これらの値は、SVG1 文書以外のすべての文脈で廃止されているため、 非 SVG UA にとっては任意です。

3.2.1.1. CSS 構文における SVG1.1 のwriting-mode値の サポート

CSS の文脈でこれらの値をサポートする UA は、 次のように算出しなければなりません:

SVG1.1 の値は、 この仕様によって廃止された CSS のwriting-mode仕様の 旧版にも含まれていました。 その版に追加されていたtb-lr値は、 vertical-lrに置き換えられます。

3.2.1.2. プレゼンテーション属性における SVG1.1 のwriting-mode値のサポート

プレゼンテーション属性を持つ従来の内容をサポートし、 著者が旧式のクライアントをサポートする文書を作成できるようにするため、 SVG UA は、既定の UA スタイルシートに次のスタイルシート規則を追加しなければなりません:

@namespace svg "http://www.w3.org/2000/svg";
svg|*[writing-mode=lr], svg|*[writing-mode=lr-tb],
svg|*[writing-mode=rl], svg|*[writing-mode=rl-tb] {
  writing-mode: horizontal-tb; }
svg|*[writing-mode=tb], svg|*[writing-mode=tb-rl] {
  writing-mode: vertical-rl; }

svg|text { writing-mode: tb; writing-mode: vertical-rl; }

4. インラインレベルの整列

異なる種類のインラインレベルの内容を一つの 行にまとめて配置する場合、内容のベースラインとvertical-alignプロパティの設定によって、それらを行ボックスの 横断方向にどのように 整列するかが制御されます。この節では、ベースラインとは何か、その求め方、 およびvertical-alignプロパティとともに インラインレベルの内容の整列を決定するためにどのように使用されるかを説明します。

4.1. ベースライン入門

この節は非規範的です。

ベースラインは、行ボックスのインライン軸に沿う線であり、 テキストの各グリフはこの線に沿って整列されます。ベースラインは、 フォント内のグリフの設計を導き（たとえば、ほとんどのアルファベット グリフの下端は通常、アルファベットベースラインに揃います）、 組版時には異なるフォントやフォントサイズのグリフの整列を導きます。

書記体系によって、優先されるベースライン表は異なります。

適切に構築されたフォントにはベースライン 表が含まれており、 フォントの設計座標空間内にある一つ以上の ベースラインの位置を示します。（設計座標空間は、 フォントサイズに応じて拡縮されます。）

ベースライン表はフォントのプロパティであり、各種ベースラインの 位置はフォント内のすべてのグリフに適用されます。

横書きテキストと縦書きテキストの整列には、 異なるベースライン表を提供できます。UA は、縦方向の組版モードでは縦書き用の 表を使用し、それ以外では横書き用の表を使用すべきです。

4.2. テキストのベースライン

この仕様では、次のベースラインのみを考慮します:

アルファベット

アルファベット ベースライン。通常は、 ラテン大文字のグリフの下端に揃います。

中央

中央 ベースライン。通常は、 em ボックスの中央を通ります。フォントにこのベースラインがない場合、 em ボックスのアセンダー（上側）辺と ディセンダー（下側）辺の中間にあると見なされます。

縦方向の組版 モードでは、中央 ベースラインが、 text-orientationがmixedまたはuprightの場合に 支配的ベースラインとして使用されます。 それ以外の場合はアルファベットベースラインが使用されます。

将来の CSS モジュールでは、ベースラインがさらに 詳細に扱われ、その他の支配的ベースラインや整列 オプションを選択できるようになります。

4.3. 不可分インラインのベースライン

不可分 インライン（inline-block、inline-table、または置換インライン要素など）に ベースラインがない場合、 UA は次のようにベースライン表を合成します:

アルファベット

アルファベットベースラインは、下側のマージン辺にあると見なされます。

中央

中央ベースラインは、ボックスの下側と上側の マージン辺の中間にあると見なされます。

[CSS2]のvertical-alignプロパティは、 一部の例外を除き、inline-table および inline-block ボックスのベースラインを定義します。

4.4. ベースラインの整列

支配的ベースライン（組版モードに基づいて変化する場合があります）は、 CSS において、次の二つの場合の整列に使用されます:

• 同じインラインボックス内で異なるフォントのグリフを整列する場合。各グリフは、 対応するフォント内の支配的 ベースラインの位置を一致させることで整列されます。
• 子のインラインレベルボックスを親の中で整列する場合。vertical-align値がbaselineの場合、 親の支配的ベースラインと子の同じ ベースラインを一致させることで、子を 親に整列します。（たとえば、親の支配的ベースラインが アルファベットである場合、子の支配的ベースラインが 別のものであっても、子のアルファベットベースラインを 親のアルファベットベースラインに一致させます。） sub、super、<length>、および<percentage>の値では、baselineの場合と同様にベースラインを整列しますが、 子はvertical-align値で指定されたオフセットに従って移動します。

  次のマークアップ例が与えられたものとします:

  <p><span class="outer">Ap <span class="inner">ji</span></span></p>

  さらに、次のスタイル規則があるものとします:

  span.inner { font-size: .75em; }

  親（.outer）と子 （.inner）のベースライン表は、フォントサイズが異なるため一致しません。 支配的ベースラインはアルファベットベースラインであるため、子ボックスは、 両者のアルファベットベースラインを一致させることで親に整列されます。

  

  上の例の.inner要素にvertical-align: superを割り当てる場合、 同じ規則を使用して.innerの子を 親に整列します。唯一の違いは、 ベースラインの整列に加えて、子が 上付き文字の位置へ移動することです。

  span.inner { vertical-align: super; font-size: .75em; }

  

5. 縦書きテキストレイアウト入門

各書記体系には、一つ以上の固有の向きがあります。したがって、現代の用字系は、 向きに関する三つのカテゴリーに分類できます:

横書き専用

固有の向きが横書きには存在するものの、縦書きには存在しない用字系です。 含まれるもの: ラテン文字、アラビア文字、ヘブライ文字、デーヴァナーガリー

縦書き専用

固有の向きが縦書きには存在するものの、横書きには存在しない用字系です。 含まれるもの: モンゴル文字、パスパ文字

両方向

縦書きと横書きの両方に固有の向きが存在する用字系です。 含まれるもの: 漢字、ハングル、日本語の仮名

縦書き用字系とは、 固有の縦書き方向を持つ用字系です。 すなわち、縦書き専用または両方向のいずれかです。 横書き用字系とは、 固有の横書き方向を持つ用字系です。 すなわち、横書き専用または両方向のいずれかです。 （用字系を固有の向きによって分類したものについては、付録 Aを参照してください。）

現代の組版システムでは、すべてのグリフに 横書き方向が割り当てられており、テキストを横方向にレイアウトするときに使用されます。 縦書きテキストをレイアウトするには、UA はテキストを 横書き方向から変換する必要があります。この変換を両方向 変換といい、次の二種類があります:

回転

グリフを横書きから縦書きへ回転します

平行移動

グリフを横書きから縦書きへ平行移動します

固有の縦書き方向を持つ用字系には、 縦書きテキストで正しい向きにするための固有の 両方向変換があります。ほとんどの CJK（中国語／日本語／韓国語）文字は平行移動されます。 すなわち、常に正立します。モンゴル文字など、 その他の用字系の文字は回転します。

固有の縦書き方向を持たない用字系は、回転 （横倒しに組む）または平行移動（正立に組む）のいずれかを選択できます。使用する変換は、 正しさの問題ではなく、 テキストの用途に応じた様式上の選択です。 text-orientationプロパティのmixedおよびupright値は、 横書き専用テキストの回転と平行移動を指定するために用意されています。

5.1. テキストの方向付け: text-orientation プロパティ

このプロパティは、行内のテキストの向きを指定します。 現在の値は、縦方向の組版モードでのみ効果があります。 このプロパティは、横方向の組版 モードにあるボックスには影響しません。

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

mixed

縦書きモードでは、横書き専用の 用字系に属する組版文字単位は、 横倒しに組まれます。 すなわち、横書きテキストでの標準の向きから時計回りに 90° 回転します。縦書き 用字系に属する組版文字単位は、 固有の向きで組まれます。 詳細については、縦書き方向を参照してください。

この値は、主として縦書き用字系で構成されるテキストのレイアウトで一般的です。

upright

縦書きモードでは、横書き専用の 用字系に属する組版文字単位は、 正立して組まれます。 すなわち、標準の横書き方向になります。縦書き 用字系に属する組版文字単位は、 固有の向きで通常どおり字形処理され、組まれます。 詳細については、縦書き方向を参照してください。

この値により、directionの使用値がltrになり、 双方向の並べ替えの目的では、 すべての文字が強い LTR として扱われます。

注: directionで影響を受けるのは、算出値ではなく、 使用値です。 これにより、この方向上書きが適用されない 子孫（横書きinline-block の内容など）へ rtlを適切に継承できます。

sideways

縦書きモードでは、 すべてのテキストが、横方向にレイアウトされたかのように 横倒しに組まれますが、時計回りに 90° 回転します。

mixed	upright	sideways

text-orientationの値（writing-modeはvertical-rl）

このプロパティの値を変更すると、インラインレベルの整列に影響する場合があります。 詳細については、テキストのベースラインを参照してください。

UA は、後方互換性のために必要な場合、 sideways-rightを、算出値がsidewaysとなる値として受け入れてもかまいません。

.vertical-upright-hebrew {
    writing-mode: vertical-rl;
    text-orientation: upright;
    unicode-bidi: bidi-override;
    direction: ltr;
}

5.1.1. 縦組みとフォント機能

vertical-rlおよびvertical-lr モードでテキストを組む場合、 テキストは、次に定義するとおり「正立」または「横倒し」のいずれかで組まれます:

正立組版

組版文字単位は、それぞれ 縦書き用フォントメトリクスを使用して縦書きの行内に 正立して組まれます。 UA は、縦書き用フォントメトリクスを持たないフォントについて、それを合成しなければなりません。 （この仕様では、そのようなメトリクスを合成するためのヒューリスティックを定義しません。） さらに、縦組みでの使用を意図した フォント機能（代替グリフやその他の変換など）を使用しなければなりません。 （たとえば、OpenType のvert機能を有効にしなければなりません。） また、アラビア文字などの横書き筆記体用字系の文字は、 正立して組まれる場合、分離形に字形処理されます。

「正立」して組む場合でも、 一部のグリフは回転して表示すべきであることに注意してください。 たとえば、ダッシュや囲み約物は、 インライン軸を基準として方向付けるべきです。 OpenType では、通常、グリフ置換によって処理されますが、 すべてのフォントが、関連するすべてのコードポイントについて代替グリフを持つとは限りません。 （東アジアのフォントは通常、東アジアのコードポイント用の代替を提供しますが、 欧文フォントは一般に縦組み機能を持たず、 東アジアのフォントも一般に欧文コードポイント用の縦書き置換を持ちません。） Unicode は、どの文字を横倒しで表示すべきかについての草案データを、 この データファイルの SVO プロパティとして公開しました。 ただし、このプロパティは、現在の版の[UTR50]では廃止されています。

組版文字単位のうち、 [UTR50]でTrまたはTuに分類されるものには、 縦書きテキストで正立して組むための代替グリフまたは位置調整があることが期待されます。 Trの文字について、 そのような縦書き用代替グリフがフォントにない場合、 UA は、不足するグリフを横倒しに組むなどして 合成することを望む場合があります [RFC6919] （ただし、期待されているわけではありません）。

横倒し組版

組版文字単位は、正立方向から時計回りに 90° 回転した 一つのランとして組まれ、 横書き用のメトリクスと組版を使用し、 縦組み機能は使用されません。 ただし、縦書きの行内で横倒しに組まれる テキストに対して有効にすることを意図した機能 （たとえば、筆画の角度や整列を調整する機能）がフォントにある場合、 その機能が使用されます。 （そのような機能の例として、提案されているvrtr OpenType フォント機能があります。）

5.1.2. 混在する縦書き方向

[UTR50]は、向きが混在する縦書きテキストの 既定のグリフ方向を表すVertical_Orientation プロパティを定義しています。 text-orientationがmixedの場合、 UA は各組版文字単位の向きを、 そのVertical_Orientationプロパティによって決定しなければなりません。方向プロパティが U、Tu、またはTrの場合は正立して組み、 方向プロパティがRの場合は 横倒しに組みます（横書きから時計回りに 90°）。

UTR50 は、縦書きの文脈で -90° 回転する用字系を扱わないため、 そのような用字系はmixed方向では正しく組まれません。 そのような用字系にはsideways-lrを使用してください。

向きが混在する組版を意図した OpenType のvrt2機能は、 CSS では使用されません。 これは、グリフの向きを決定する責任をフォント設計者に委ねます。 CSS は代わりに、[UTR50]を通じて向きを指示し、 グリフを必要に応じて横倒しまたは正立して組むことで方向付けます。

5.1.3. 廃止: SVG1.1 のglyph-orientation-verticalプロパティ

一部の SVG ユーザーエージェントは、 廃止された SVG のglyph-orientation-verticalプロパティを含む文書を処理する必要があります。 このプロパティは、autoキーワードに加え、 <angle>と、90° の倍数を表す<integer>値を受け入れるよう定義されていました。 このプロパティのサポートは任意ですが、 サポートする UA は、次のようにglyph-orientation-verticalをtext-orientationの略式として別名化しなければなりません:

UA は、glyph-orientation-verticalプロパティの その他すべての値を無視して無効として扱い、 glyph-orientation-horizontal プロパティ全体を 無効として扱わなければなりません。

注: 180deg値と270deg値、 ラジアン値とグラジアン値、 およびglyph-orientation-horizontalプロパティは、 既知のユースケースも、 それらに依存する大量の内容も存在しないため対応付けられません。 したがって CSS の一部ではなく、 SVG からも同様に削除されています。

6. 抽象ボックスの用語

CSS2.1 [CSS2]は、CSS のボックスレイアウトモデルを 詳細に定義していますが、 horizontal-tb書字モードだけを対象としています。レイアウトは、 horizontal-tb以外の書字モードでも同様です。ただし、 CSS2.1 の方向および寸法に関する用語を抽象化し、 適切に対応付け直す必要があります。

この節では、その他の書字モードについてボックスレイアウトを定義し、 将来の仕様がレイアウトの概念を 抽象的に定義するための用語を提供するため、抽象的な方向および寸法の用語と その対応付けを定義します。（次の節では、これらを CSS2.1 のレイアウト計算に適用する方法と、直交フローの処理方法を説明します。） これらはテキストの動作から導出されますが、 抽象的な対応付けは、行ボックスを一つも含まないボックスにも存在します。 これらは、writing-modeおよびdirectionプロパティの値から直接計算されます。

CSS には、方向に関する用語が三組あります:

物理

書字モードとは無関係に、ページを基準として解釈されます。 物理 方向は、左、右、上、および下です。

フロー相対

内容のフローを基準として解釈されます。 フロー相対方向は、始端と 終端です。 寸法も曖昧な場合は、ブロック始端、ブロック終端、インライン始端、およびインライン終端です。

行相対

行ボックスの向きを基準として解釈されます。 行相対方向は、行左、行右、行上側、および行下側です。

物理寸法は、幅と高さです。 これらは、それぞれx 軸（水平寸法）およびy 軸（垂直寸法）に沿った測定値に 対応します。抽象寸法は、フロー相対用語と 行相対用語のどちらでも同一であるため、 これらの用語は一組だけです。

注: [CSS3-FLEXBOX]は、 フレックスレイアウトの説明に使用される フレックス相対用語も定義しています。

6.1. 抽象寸法

抽象寸法を次に定義します:

ブロック寸法

行内のテキストフローに垂直な寸法です。すなわち、 横書きモードでは垂直 寸法、 縦書きモードでは水平 寸法です。

インライン寸法

行内のテキストフローに平行な寸法です。すなわち、 横書きモードでは水平 寸法、 縦書きモードでは垂直 寸法です。

ブロック軸

ブロック寸法における軸です。 すなわち、横書きモードでは垂直軸、 縦書きモードでは水平軸です。

インライン軸

インライン寸法における軸です。すなわち、横書きモードでは水平 軸、縦書きモードでは垂直軸です。

ブロックサイズ

論理高さ

ブロック寸法における測定値です。 横書きモードでは物理高さ（垂直寸法）を指し、 縦書きモードでは物理幅（水平寸法）を指します。

インラインサイズ

論理幅

インライン寸法における測定値です。 横書きモードでは物理幅（水平寸法）を指し、 縦書きモードでは物理高さ（垂直寸法）を指します。

6.2. フロー相対方向

フロー相対方向である、ブロック始端、ブロック終端、インライン始端、およびインライン終端は、 ページ上の内容のフローを基準として定義されます。 LTRのhorizontal-tb書字モードでは、それぞれ 上、下、左、右の方向に対応します。 次のように定義されます:

ブロック始端

writing-modeプロパティによって決定される、 ブロックフロー方向において先に来る側です。 horizontal-tbモードでは物理的な上、 vertical-rlでは右、vertical-lrでは左です。

ブロック終端

ブロック始端の反対側です。

インライン始端

インライン基底方向のテキストが開始される側です。 directionの使用値がltrであるボックスでは、 行左側を意味します。 directionの使用値が rtlであるボックスでは、行右側を意味します。

インライン終端

始端の反対側です。

文脈上曖昧でない場合、または両方の意味を含む場合は、 始端および 終端という用語を、 それぞれブロック始端／インライン始端およびブロック終端／インライン終端の代わりに使用します。

ボックスのブロック始端側とブロック終端側の決定は、writing-modeプロパティだけに依存しますが、 ボックスのインライン始端側と インライン終端側の決定は、 writing-modeプロパティだけでなく、 directionプロパティにも依存することに注意してください。

6.3. 行相対方向

行の向きは、 行ボックスのどちら側が論理的な 「上」（アセンダー側）であるかを決定します。 これはwriting-modeプロパティによって与えられます。 通常、行相対の「上」は ブロック始端側に 対応しますが、常にそうであるとは限りません。 モンゴル語の組版（したがって、既定ではvertical-lr 書字 モード）では、行相対の「上」はブロック終端側に対応します。 このため、別個の用語が必要になります。

上のような主としてモンゴル語で構成される文書は、 左から右へ積み重なる縦書きの行で記述されますが、ラテン文字のテキストは、 グリフの上側が右を向くようにレイアウトされます。これにより、テキストは モンゴル語と同じインライン方向（上から下）に進み、 その他の東アジアのレイアウト（縦書きの 行が右から左へ積み重なるもの）と同じ方向を向きます。ただし、グリフの上側は 行の積み重なりの上側ではなく下側を向きます。これは英語の 段落では上下逆になります。（このモンゴル語 テキストレイアウトの 図を参照してください。）

「vertical-align: top」などを対応付けるための行相対の「上」と「下」に加え、 CSS では、text-align: leftなどを対応付けるため、行相対の 「左」と「右」を参照する必要もあります。 したがって、四つの行相対方向があり、 行の 向きを基準として次のように定義されます:

上側または行上側

名目上、行ボックスのアセンダー側または「上」側に 対応する側です。（通常、上線が描かれる側です。）

下側または行下側

上側の反対側、すなわち行相対の「下」 またはディセンダー側です。 （通常、下線が描かれる側です。）

行左

行ボックスの行相対の「左」側です。 名目上、LTRテキストが開始される側です。

行右

行ボックスの行相対の「右」側です。 名目上、RTLテキストが開始される側です。 （行左の反対側です。）

物理方向と行相対方向の正確な 対応付けについては、下の表を参照してください。

horizontal-tbにおける行の向き

vertical-rl、vertical-lr、およびsideways-rlにおける行の向き

sideways-lrにおける行の向き

6.4. 抽象から物理への対応付け

次の表は、使用directionおよびwriting-modeに基づく、 抽象から物理への対応付けをまとめたものです:

注: directionの使用値は、 算出されたwriting-modeおよびtext-orientationに依存します。 縦書き モードでは、 text-orientation値がuprightの場合、directionの使用値は強制的にltrになります。

7. 抽象ボックスレイアウト

7.1. 縦書きモードにおけるレイアウトの原則

縦書きモードにおける CSS ボックスレイアウトは、 次に概説する原則に従い、横書きモードにおけるレイアウトと同様になります:

横書きモードの水平寸法に適用される レイアウト計算規則（CSS2.1 の第 10.3 節にあるものなど）は、 縦書きモードでは垂直寸法に適用されます。 同様に、横書きモードの垂直寸法に適用される レイアウト計算規則（CSS2.1 の第 10.6 節にあるものなど）は、 縦書きモードでは水平寸法に適用されます。 したがって、次のようになります:

• 幅を参照するレイアウト規則では、代わりに高さを使用し、 その逆も同様です。

• *-leftおよび*-rightのボックスプロパティ（ボーダー、マージン、パディング、位置オフセット）を参照する レイアウト規則では、代わりに*-topと*-bottomを使用し、 その逆も同様です。 CSS2.1 の横書きモードの規則は、 フロー相対方向を使用して 縦書きモードの規則へ対応付けられます。 これらのプロパティが適用されるボックスの側は変わりません。 どの値がどのレイアウト計算への入力になるかだけが変わります。 たとえば、margin-leftプロパティは、引き続き左側のマージンに影響します。 ただし、vertical-rl書字モードでは、 margin-bottomの代わりに マージンの相殺に関与します。

• 左と右のいずれかを選択するためにdirectionプロパティに依存する レイアウト規則 （オーバーフロー、過剰制約の解決、text-alignの初期値、表の列の順序など）は、 始端側と終端側に抽象化され、 適切に適用されます。

主として行ボックスの左側または右側、 あるいはその長手方向に平行な線を参照するため、 上側または下側に相当するものが存在しない、テキストの整列、浮動、リストマーカーの配置などの機能では、 行左側と行右側を、 それぞれ左側と右側の基準として使用します。

同様に、主として行ボックスの上側または下側、 あるいはその横断方向に平行な線を参照するため、 左側または右側に相当するものが存在しない、下線、上線、ベースライン整列 （残念な名前のvertical-align）などの機能では、 行上側と行下側を、 それぞれ上側と下側の基準として使用します。

これらの対応付けの詳細を次に示します。

7.2. 寸法の対応付け

特定のプロパティは、論理的に次のように動作します:

• border-spacingプロパティの最初と二番目の値は、 それぞれ列間と行間の間隔を表すものであり、 必ずしもそれぞれ水平と垂直の間隔を表すわけではありません。[CSS2]
• line-heightプロパティは、常に論理 高さを参照します。[CSS2]

高さプロパティ（height、 min-height、およびmax-height）は 物理高さを参照し、幅プロパティ（width、min-width、およびmax-width）は物理幅を参照します。ただし、 ボックスの寸法と位置を計算するために使用される規則は論理的です。

たとえば、CSS2.1 第 10.3 節の計算規則は、 インライン寸法の測定に使用されます。 これはインラインサイズ （物理幅と物理高さのどちらの場合もあります）と、 インライン始端およびインライン終端のマージン、パディング、 ボーダーに適用されます。 同様に、CSS2.1 第 10.6 節の計算規則は、 ブロック寸法で使用されます。 これはブロックサイズと、 ブロック始端およびブロック終端のマージン、パディング、 ボーダーに適用されます。[CSS2]

その帰結として、CSS2.1 では常に包含ブロックの 幅を基準として計算されるマージンおよびパディングプロパティのパーセンテージは、 CSS3 では包含ブロックのインラインサイズを基準として計算されます。

7.3. 直交フロー

ボックスのwriting-modeが 包含ブロックと異なる場合、次の二つの可能性があります:

• 二つの書字モードが互いに平行である場合。（たとえば、vertical-rlとvertical-lr。）
• 二つの書字モードが互いに垂直である場合。（ たとえば、horizontal-tbとvertical-rl。）

ボックスの書字モードが包含ブロックに対して垂直である場合、 そのボックスは直交フロー内にある、または直交フローを確立するといいます。

この場合を処理するため、CSS レイアウト計算は、 ボックスのサイズ設定と、フロー内でのボックスの配置という二つの段階に分けられます。

• サイズ設定段階（ボックスの幅と高さを計算する段階）では、 ボックスと包含ブロックの寸法を インラインサイズと ブロックサイズに対応付け、 直交フローを確立する ボックスの書字モードを使用して、 それに従って計算を行います。
• 配置段階（位置オフセット、 マージン、ボーダー、およびパディングを計算する段階）では、ボックスと その包含ブロックの寸法をインラインサイズとブロックサイズに対応付け、直交フローを確立する ボックスの包含ブロックの書字モードに従って計算を行います。

autoマージンは包含ブロックの 書字モードと整合するように解決されるため、直交フローを確立するボックスは、 サイズ設定後、auto マージンを使用することで、その他のブロックレベルボックスと同様に 包含ブロック内で整列または中央配置できます。

7.3.1. 直交フローで利用可能な空間

CSS では、包含ブロックが確定したインラインサイズを持つ一方で、 確定したブロックサイズを持たないことが一般的です。 CSS2.1 では通常、 包含ブロックの高さがautoの場合などに この状況が発生します。 たとえば、その幅は10.3.3の計算によって与えられますが、 ブロックサイズは内容に依存します。 この場合、利用可能なインライン空間は、 包含ブロックのインラインサイズとして定義されます。 ただし、それ以外の場合には包含ブロックのブロックサイズとなる 利用可能なブロック空間は 無限になります。

ボックスを直交フロー内に配置すると、逆の結果になる場合があります。 すなわち、ボックスの利用可能なブロック空間は確定している一方で、 利用可能なインライン空間が不確定になる場合があります。 この場合、包含ブロックのインラインサイズに対するパーセンテージを定義できず、 インライン軸の計算を 解決できません。 この場合、 確定した利用可能なインライン空間を必要とする計算では、 利用可能なインライン空間の代わりに、 追加の制約をフォールバックとして使用します。次のうち最小のものです:

• 包含ブロックの内部最大サイズが表すサイズ （固定されている場合）。 ただし、その内部最小サイズが固定されている場合は、それを下限とします。
• 最も近い祖先のスクロールポートの内部サイズ（固定されている場合）。 そうでない場合、またはその内部最大サイズが固定されている場合は、それを上限とし、 その内部最小サイズが固定されている場合は、それを下限とします。
• 初期包含ブロックのサイズ

CSS のサイズ設定に関する用語と概念の詳細については、 [CSS3-SIZING]を参照してください。

7.3.2. 直交フローにおけるブロックコンテナーの自動サイズ設定

直交フローを確立するボックスが ブロックコンテナーまたは複数列コンテナーのいずれかであり、 ボックスのインライン サイズがautoである場合:

1. 使用column-widthを計算します:
   • column-countとcolumn-widthがどちらもautoの場合、 shrink-to-fit の式 min(max-content, max(min-content, constraint))を使用します。 ここで:

     min-content

     ボックスのmin-content インラインサイズ

     max-content

     ボックスのmax-content インラインサイズ

     constraint

     次のうち最小のものにstretch-fitする、 インライン軸のサイズ

     • 利用可能な空間: 包含ブロックのサイズが固定されている場合は、そのサイズ。 そうでない場合は、 包含ブロックの内部最大サイズが表すサイズ（固定されている場合）を、 内部最小サイズ（固定されている場合）を下限として使用します。
     • 最も近い祖先のスクロールポートの内部サイズ（固定されている場合）。 そうでない場合は、内部最大サイズ（固定されている場合）を上限とし、 内部最小サイズ（固定されている場合）を下限とします。
     • 初期包含ブロックのサイズ

     

     この要件により、すべてのブロックコンテナーで複数列フローが自動的に 起動されることに注意してください。これは、オーバーフローする内容が包含ブロックの 側面を越えて続く代わりに、 包含ブロックのフロー方向に列として折り返され、 T 字型文書を回避するためです。 著者は、column-widthを設定することで、これらの列のインラインサイズを制御できます。 また、インラインサイズ プロパティを、 max-contentなどの非 auto値に設定することで、この動作を無効にできます。
     
   • column-countがautoではなく、column-widthがautoである場合、 同じ式を使用して、使用column-widthを 計算します。 ただし、constraintを、constraint −（column-count − 1）× column-gapに置き換えます。
   • column-countとcolumn-widthがどちらも非 autoである場合、 使用column-widthは、 算出されたcolumn-widthです。 （オーバーフローが生じる可能性があるため、これは推奨されません。 代わりに、column-widthと max-block-size を設定する方が適切です。）
2. 使用される列の長さを計算します: 算出されたブロックサイズがautoであり、column-countとcolumn-widthの少なくとも一方の指定値がautoである場合、 ボックスのブロックサイズ（確定している場合）、 そうでなければボックスのstretch-fit ブロックサイズ（確定している場合）、 それも該当しなければボックスのmax-content ブロックサイズを使用します。 それ以外の場合は、複数列コンテナーの通常のサイズ設定規則に従います。

   この式では、 ボックスのmin-content ブロックサイズも考慮すべきでしょうか。 そうすれば、たとえば大きな画像がボックスからオーバーフローせず、 代わりにボックスが包含ブロックからオーバーフローするようになります。

3. 使用column-countを計算します: 算出されたcolumn-countがautoの場合、 使用column-countは、 結果として得られる複数列レイアウトを ボックスの内容で満たすことによって決まります。

次に、結果として得られる複数列コンテナーの 使用インラインサイズを計算します:

1. 内容が複数列コンテナー内で行折り返しも断片化もされない場合、 使用インラインサイズは、 ボックス内容のmax-content インラインサイズです。 この基準により、大きな空白を作ることなく、 短い直交フローの内容に shrink-to-fit 動作が与えられます。
2. それ以外の場合は、使用column-width、column-count、およびcolumn-gapから計算します。

ボックスの使用ブロックサイズは、 使用される列の長さ （複数の列を使用した場合）、 または内容のmax-content ブロックサイズ （一つの列だけを使用した場合）のいずれかです。 UA が CSS Multi-column Layout [CSS3COL]をサポートしない場合、 代わりに、無限の利用可能なブロック空間を想定して ボックスのブロックサイズを計算し、 その内容を単一の列にレイアウトしてもかまいません。 （ただし、包含ブロックからオーバーフローした場合、 内容がクリップされるか、その他の形でアクセス不能になる可能性があります。）

複数列フローの自動起動はリスクありとされ、CR 中に削除される可能性があります。

7.3.3. その他の直交フロールートの自動サイズ設定

行の長さを制限するため、 ブロックコンテナーには、利用可能なインライン空間が無限である場合 （通常は直交フローを確立するとき）に、 特別な自動サイズ設定動作（上で定義）があります。

その他のレイアウトモデルは、単に利用可能なインライン空間が無限の状態で、 max-content サイズとしてレイアウトされます。 ただし、それらが包含するブロックコンテナーには、無限の 利用可能なインライン空間が引き渡されます。 そのため、それらのブロックコンテナー自体が直交フローを確立しない場合でも、 特別な自動サイズ設定動作が起動される可能性があります。

7.3.4. 直交フローの断片化

この節は参考情報です。

断片化に関しては、CSS2.1 の規則が 縦書きモードと直交フローでも引き続き適用されます。改ページ位置は 行ボックス内ではなく、行ボックス間にのみ存在します。 ただし、[CSS3COL]をサポートする UA は、 列間の（幅がゼロの場合もある） 間隔で分割してもかまいません。

内容がルート要素によって確立されたページ付けストリームの 外側にはみ出した場合、UA はその内容を印刷する必要がないことに注意してください。 長いテキストストリームで書字モードを混在させたい著者には、 すべての内容が文書のページ付け方向に流れるよう維持するため、 CSS の列を使用することを推奨します。

7.4. フロー相対の対応付け

フロー相対方向は、ボックスの 包含ブロックの書字モードを基準として計算され、 ボックスプロパティ（マージン、ボーダー、パディング）および、 ボックスを包含ブロック内に配置することに関係するプロパティ （float、clear、top、bottom、 left、right、caption-side）に関係するレイアウト規則を抽象化するために使用されます。 インラインレベルボックスでは、代わりに親 ボックスの書字モードが使用されます。 （left／right／top／bottom という名前のプロパティと値自体は、引き続き物理的に対応付けられます。 ただし、caption-sideには特別な例外があり、 top／top-outside値とbottom／bottom-outside値は、それぞれ 表のブロック始端側と ブロック終端側に関連付けられます。）

たとえば、ボックスのインライン 寸法が過剰制約となった場合に破棄されるマージンは、 包含ブロックの書字モードによって決定される 終端マージンです。

マージン 相殺規則は、上マージンをブロック始端マージンに置き換え、下マージンをブロック終端マージンに置き換えて、 そのまま適用されます。 同様に、上パディングと上ボーダーは ブロック始端のパディングとボーダーに、 下パディングと下ボーダーはブロック終端のパディングと ボーダーに置き換えられます。 これは、ブロック始端とブロック終端のマージンだけが相殺されることを意味します。

フロー相対方向は、 ボックスの書字モードを基準として計算され、 ボックスの内容に関するレイアウトを抽象化するために使用されます:

• text-alignプロパティの初期値は、 行ボックスの始端辺に揃えます。
• text-indentプロパティは、行ボックスの始端辺からインデントします。
• 表では、列の順序は表のインライン始端側から始まり、行の順序は 表のブロック始端側から始まります。

7.5. 行相対の対応付け

行相対方向は、上側、下側、行左、および行右です。 LTRのhorizontal-tb書字モードでは、 それぞれ 上、下、左、右の方向に対応します。

行右と行左の方向は、 ボックスの書字モードを基準として計算され、 次のプロパティのleft値とright値を 解釈するために使用されます:

• text-alignプロパティ[CSS2]

行右と行左の方向は、 ボックスの包含 ブロックの書字モードを基準として計算され、次のプロパティの left値とright値を解釈するために使用されます:

• float プロパティ[CSS2]
• clear プロパティ[CSS2]
• caption-sideプロパティ[CSS2]

上側と下側の方向は、ボックスの書字モードを基準として 計算され、行ボックスの「上」（上側）と「下」（下側）を 次のように解釈するために使用されます:

• vertical-alignプロパティでは、 行ボックスの「上」は上側辺であり、 行ボックスの「下」は下側辺です。 正の長さ値およびパーセンテージ値は、 ベースラインを行上側辺に向かって移動させます。[CSS2]
• text-decorationプロパティでは、 下線はテキストの下側に描画され、 上線はテキストの上側に 描画されます。[CSS2] CSS Text Decoration Module は、 これをさらに詳しく定義し、下線と上線の位置を 制御するための追加の制御を提供することに注意してください。[CSS3-TEXT-DECOR]

7.6. 純粋に物理的な対応付け

次の値は、その定義が純粋に物理的であり、 書字モードの変更には応じません:

• clip プロパティのrect()表記[CSS2]
• 背景プロパティ[CSS2] [CSS3BG]
• border-image プロパティ[CSS3BG]
• box-shadowおよびtext-shadowプロパティのオフセット

8. 主要書字モード

文書の主要書字 モードは、 ルート要素の使用writing-mode、direction、および text-orientation値によって 決定されます。 この書字モードは、たとえば、 スクロール方向と、 既定のページ進行方向を決定するために使用されます。

HTML 文書を処理するための特殊な場合として、 ルート要素に body 子要素[HTML]がある場合、 ルート要素のwriting-modeおよびdirectionプロパティの使用値は、 ルート要素自身の値ではなく、 そのような最初の子要素の算出されたwriting-modeおよびdirectionから取得されます。 UA は、text-orientationの値も、 この方法で伝播してもかまいません。 これは、ルート要素自身のwriting-mode、direction、またはtext-orientationの算出値には影響しないことに注意してください。

注: 伝播は、算出値ではなく使用値に対して行われます。 これは、継承、論理 プロパティの対応付けロジック、 長さ値の計算など、 スタイル計算のその他の側面を妨げないためです。

8.1. 初期包含ブロックへの伝播

主要 書字モードは、 初期包含ブロックおよびビューポートへ伝播され、 それによってルート要素のレイアウトと ビューポートのスクロール方向に影響します。

@page ボックスにも 伝播するのでしょうか。

8.2. ページフロー: ページ進行方向

ページメディアでは、CSS はすべてのページを左ページまたは右ページに分類します。 見開きの左ページと右ページのどちらがフロー内で先になるか、 および最初のページが既定で左ページと右ページのどちらになるかを決定する ページ進行方向（[CSS3PAGE]を参照）は、 主要書字モードに 次のように依存します:

注: 別途上書きされない限り、 文書の最初のページは見開きの後半から始まります。 たとえば、左から右へのページ進行では右ページから始まります。

9. グリフ合成

9.1. 縦中横合成: text-combine-uprightプロパティ

このプロパティは、複数の組版文字単位を、単一の 組版文字単位の空間へ合成することを指定します。 合成されたテキストの幅が 1em より広い場合、UA は内容を 1em 内に収めなければなりません。以下を参照してください。 結果として得られる合成は、レイアウトと装飾の目的では単一の正立グリフとして扱われます。 このプロパティは縦書きモードでのみ効果があります。値は次の意味を持ちます:

none

特別な処理は行いません。

all

ボックス内で連続するすべての組版文字単位が、 縦書き行ボックス内の単一の組版 文字単位の空間を占めるよう、横書きで組むことを試みます。

digits <integer>?

指定された整数以下の桁数を持つ、 連続する ASCII 数字（U+0030–U+0039）の各極大シーケンスを、 縦書き行 ボックス内の単一の組版文字単位の空間を占めるよう、 横書きで組むことを試みます。 整数を省略した場合、その算出値は 2 です。 2～4 の範囲外の整数は無効です。

date { text-combine-upright: digits 2; }

<date>平成20年4月16日に</date>

<p>あれは10,000円ですよ！</p>

9.1.1. テキストランの規則

レンダリングとレイアウトの複雑化を避けるため、text-combine-uprightで 合成できるのは、プレーンテキスト、 すなわちボックス境界によって中断されない連続する組版文字単位だけです。

ただし、このプロパティは継承されるため、 UA は、合成を実行するボックスの内容が、 ボックスの外側で開始または終了する、 それ以外では合成可能なシーケンスの一部ではないことを保証しなければなりません。 その一部である場合、テキストは text-combine-uprightがnoneであるかのように、通常どおりレイアウトされます。 シーケンスの一部だけを合成しないようにするため、 合成可能性のあるランの境界が 一つ以上のインラインボックス境界だけによる場合、 UA はランの直前と直後に現れる 文字を調べなければなりません。 介在するボックスがなければ、これらの文字が （長すぎなければ）合成されるシーケンスを形成する場合、 候補ランは合成されません。

上の段落はリスクありとされています。実装者からのコメントを歓迎します。

tcy { text-combine-upright: digits 4; }

<tcy>12<span>34</span></tcy>

12<tcy><span>34</span></tcy>12<tcy><span></span>34</tcy>
12<tcy>34<span></span></tcy>

tcy { text-combine-upright: all; }

text-combine-uprightの値 （allまたはdigits）は、 合成できる組版文字単位の種類と、 合成可能なシーケンスの最大長だけに影響することに注意してください。 それ以外の動作は変わりません。

9.1.2. レイアウト規則

text-combine-upright: allの場合のようにテキストを合成するとき、 合成されたテキストのグリフは双方向分離され、横方向に組まれます。 （letter-spacingと強制改行は無視しますが、 指定されたフォント設定を使用します。） これは、横書きモードで、 line-heightが1emである inline-blockボックスの内容に似ています。 合成されたテキストの始端／終端に含まれる文書の空白は、 そのようなインラインブロックの始端／終端にあるものとして、[CSS-TEXT-3]に従って処理 されます。 合成の有効サイズは 1em 四方と見なされ、 その正方形の外側にあるものは、レイアウトの目的では測定されません。 UA は、測定された 1em 四方の中でグリフを水平方向および垂直方向の中央に配置すべきです。

結果として得られる合成のベースラインは、ベースライン整列による 移動（vertical-align）を行う前に、 正方形が親インラインボックスの text-over ベースラインと text-under ベースラインの間で 中央に配置されるよう選択しなければなりません。 双方向の並べ替えでは、合成は text-orientation: uprightである組版文字単位と同様に扱われます。 合成の前後における改行では、実際の内容を持つ通常のインラインとして扱われます。 強調記号、テキスト装飾、間隔など、 その他のテキストレイアウトの目的では、結果として得られる合成は、 オブジェクト置換文字 U+FFFC を表す単一のグリフとして扱われます。

9.1.3. 圧縮規則

UA は、必要に応じて合成テキストを圧縮し、 合成の合計送り幅が 1em 内に収まるようにしなければなりません。 （一部のグリフは幾何学的境界の外側に描画されるよう設計されているため、 必ずしもグリフ自体が 1em 内に収まることを意味しません。） OpenType の実装は、合成内のすべての組版文字単位で利用できる場合、 幅固有の異体字 （OpenType 機能のhwid／twid／qwid。 fwidやpwidなどのその他のグリフ幅機能は含みません）を使用して テキストを圧縮しなければなりません。 それ以外の場合、UA はテキストを圧縮するために任意の方法を使用できます。 これには、フォントが提供する半角幅、3 分の 1 幅、4 分の 1 幅のグリフへの置換、 テキストを水平方向に圧縮するために設計されたその他のフォント機能の使用、 テキストの幾何学的な拡縮、 またはそれらの任意の組み合わせが含まれます。

一部のフォントでは、表意文字のグリフが 幅 1em、高さ 1em 未満となるよう圧縮して設計されています。 そのようなフォントに対応するため、UA は、 指定されたフォント設定に従ってレンダリングされる「水」U+6C34 の送り高さに一致するよう、 合成を垂直方向に拡縮してもかまいません。 この場合、結果として得られる合成は、 1em ではなく「水」U+6C34 の送り高さを使用します。

9.1.3.1. 全角文字

テキストを 1em に圧縮するときに組版上の色調を維持するため、 合成されたテキストが複数の組版文字単位で構成される場合、 他の圧縮手法を適用する前に、全角の組版文字単位を、 [CSS-TEXT-3]のtext-transform: full-widthについて定義されたアルゴリズムを逆に適用して、 対応する非全角のものへ変換すべきです。

date { text-combine-upright: digits 2; text-transform: full-width; }

<date>2010年2月23日</date>

２
０
１
０
年
２
月
23
日

[CSS3-FONTS]で定義されるfont-variantおよびfont-feature-settingsプロパティなど、 グリフ選択に影響するプロパティは、 合成されたテキストランに含まれる文字の異体字選択に影響する可能性があります。 著者には、text-combine-uprightも使用する場合、 これらのプロパティを注意して使用することを推奨します。

10. プライバシーとセキュリティに関する考慮事項

この仕様では、「正しく実装すること」以外に、 新たなプライバシー漏洩やセキュリティ上の考慮事項は導入されません。

変更点

2018年5月の CSS 書字モードモジュール レベル 4 勧告候補以降の変更点

• body 要素から初期包含ブロックおよびビューポートへの 主要書字モードの伝播は、ルート要素の使用値にも影響するものの、 その算出値には影響しないことを明確にしました。 また、text-orientationも 任意で伝播できるようにしました。 この変更はレベル 3 にも適用されました。 （課題 3066）
• text-combine-uprightで合成されたテキストシーケンス内、特にその始端／終端にある空白は、 インラインブロック内と同じ方法で処理されることを明確にしました。 （課題 4139） この変更はレベル 3 にも適用されました。

  text-combine-upright: allの場合のようにテキストを合成するとき、 合成されたテキストのグリフは双方向分離され、横方向に組まれます。 （letter-spacingと強制改行は無視しますが、 指定されたフォント設定を使用します。） これは、横書きモードで、 line-heightが1emである inline-blockボックスの内容に似ています。 合成されたテキストの始端／終端に含まれる文書の空白は、そのようなインラインブロックの 始端／終端にあるものとして、処理されます。[CSS-TEXT-3]

レベル 4 の新機能

このモジュールは、単に2015年の CSS 書字モード レベル 3 勧告候補を複製したものです。 現在の CSS 書字モード レベル 3との違いは、実装への採用が遅かったためレベル 3 から延期された一連の機能です:

• writing-modeのsideways-lr値とsideways-rl値を再導入しました。
• text-combine-uprightのdigits値を再導入しました。
• 直交フローの自動複数列動作を再導入しました。
• 双方向の並べ替えによって生じる断片化の条件を明確にしました。 （課題 1509）

謝辞

L. David Baron, Brian Birtles, James Clark, John Daggett, Nami Fujii, Daisaku Hataoka, Martin Heijdra, Laurentiu Iancu, Richard Ishida, Jonathan Kew, Yasuo Kida, Tatsuo Kobayashi, Toshi Kobayashi, Ken Lunde, Shunsuke Matsuki, Nat McCully, Eric Muller, Paul Nelson, Kenzou Onozawa, Chris Pratley, Xidorn Quan, Florian Rivoal, Dwayne Robinson, Simon Sapin, Marcin Sawicki, Dirk Schulze, Hajime Shiozawa, Alan Stearns, Michel Suignard, Takao Suzuki, Gérard Talbot, Masataka Yakura, Taro Yamamoto, Steve Zilles

付録 A: Unicode における縦書き用字系

この節は参考情報です。

この付録では、Unicode 6.0 [UNICODE]に含まれる縦書き専用および両方向の用字系と、横書き方向から縦書き方向への変換を列挙します。 明示的に列挙されていない用字系は、横書き専用であると見なされます。 Unicode 文字の用字系分類は、[UAX24]によって与えられます。

例外: この仕様では、すべての全角（F）文字と幅広（W）文字を 縦書き用字系に属するものとして扱い、 半角（H）文字を横書き用字系に属するものとして扱います。[UAX11]

縦書き専用文字（モンゴル文字やパスパ文字など）については、 Unicode コード表内のグリフが縦書き方向で示されていることに注意してください。 横書きテキストでは、この向きから反時計回りに 90° 回転させて組まれます。

Unicode Technical Report 50 と CSS Writing Modes の現在の機能セットには 制限があるため、縦書きのmixed組版では、 オガム文字も古代テュルク文字も自動的に処理できません。 これらの用字系の文章を組むには、sideways-lrを使用できます。