CSS書き方モード レベル4

1. 書字モードの概要

CSS書き方モード レベル4は、左から右（例：ラテンやインド系）、右から左（例：ヘブライ語やアラビア語）、双方向（例：ラテン語とアラビア語の混在）、縦書き（例：アジア系文字）など、さまざまな国際的な書字モードをサポートするCSS機能を定義します。

CSSの書字モードは、writing-mode、direction、text-orientationプロパティによって決定されます。主にインライン基本方向とブロックフロー方向で定義されます：

ラテン系書字モード

モンゴル系書字モード

漢字系書字モード

インライン基本方向は、行内のコンテンツが並ぶ主方向であり、行の「開始」と「終了」がどちらかを定義します。directionプロパティは、ボックスのインライン基本方向を指定し、unicode-bidiプロパティやテキスト自体の持つ方向性とともに、行内のインラインレベルコンテンツの並び順を決定します。

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

組版モードは、縦書き文字に特有の組版慣習をテキストに適用するかどうかを決定します。 この概念は、縦書き文字のための縦フローと、横書きフローの回転とを区別します。

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

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

書記体系には通常1つまたは2つの固有の書字モードがあります。例：

• ラテン系書記体系は通常、左から右のインライン方向と下向き（上から下）のブロックフロー方向で書かれます。
• アラビア系書記体系は通常、右から左のインライン方向と下向き（上から下）のブロックフロー方向で書かれます。
• モンゴル系書記体系は通常、上から下のインライン方向と右向き（左から右）のブロックフロー方向で書かれます。
• 漢字系書記体系は、左から右のインライン方向と下向き（上から下）のブロックフロー方向、または上から下のインライン方向と左向き（右から左）のブロックフロー方向で書かれることが多いです。多くの雑誌や新聞では、この2つの書字モードを同一ページで混在させることがあります。

書字モードのtext-orientationコンポーネントは、グリフの向きを制御します。

書字モードと縦書きテキストのより詳しい解説については、Unicode技術ノート#22 [UTN22]（HTML版）をご覧ください。

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

このモジュールは、unicode-bidiおよびdirectionの機能（[CSS2]の8.6節と9.10節で定義）を置き換え・拡張します。 その機能が、テキストの行配置における他のテキスト操作とどのように相互作用するかは、CSS Text 3 § テキスト処理順序で説明されています。

computed values（算出値）は、writing-mode、direction、text-orientationプロパティ（これらのプロパティが適用されない要素にも適用される場合がある [CSS-CASCADE-4]）は、フォント相対長の算出や、算出されたフロー相対プロパティ（算出されたwriting modeや、writing modeに依存するフォントメトリクスに依存することがある）に基づくカスケードなど、他の無関係なプロパティの算出値に幅広く影響を与えることができます。

1.2. 値の種類と用語

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

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

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

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

多くの文字体系は左から右に記述されますが、一部の文字体系は右から左に記述されます。特にアラビア語やヘブライ語などで書かれた文書や、複数言語が混在する状況では、1つの（視覚的に表示される）ブロック内で混在した方向性のテキストが現れることがあります。この現象は双方向性（略称：bidi）と呼ばれます。

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

CSSには、directionとunicode-bidiの2つのプロパティがあり、CSS層での埋め込み・分離・上書き制御を明示的に提供します。 テキストの基本方向は文書の構造や意味に依存するため、directionやunicode-bidiプロパティは、ほとんどの場合、マークアップ内のbidi情報をCSSスタイルに対応付けるためだけに使用すべきです。

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

文書言語がbidi制御用のマークアップ機能を提供している場合は、著者やユーザーはそちらを優先して使用し、それを上書きするCSSルールを指定しないでください。

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

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

このプロパティは、ボックスによって確立されるbidi段落・埋め込み・分離・上書きのインライン基本方向または方向性を指定します。（unicode-bidiも参照。）さらに、テーブルの列レイアウト順序や、水平overflow方向、行内のテキストのデフォルト配置、その他ボックスのインライン基本方向に依存するレイアウト効果にも影響します。

このプロパティの値の意味は以下の通りです：

ltr

この値はインライン基本方向（bidi方向性）をline-leftからline-rightへと設定します。

rtl

この値はインライン基本方向（bidi方向性）をline-rightからline-leftへと設定します。

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

インラインボックス上で、この値はbidi-isolate（双方向分離）を行います。 これは方向性埋め込みに似ています（埋め込みレベルも増加します）が、ブロック境界や強制段落区切りで途切れないインラインレベルのボックスの各連続は分離されたシーケンスとして扱われます：

• シーケンス内のコンテンツは、ボックスのdirectionプロパティで指定された基本方向性を持つ独立した段落内にあるかのように並べられます。
• 包含する双方向段落でのbidi解決のために、そのシーケンスは1つのオブジェクト置換文字（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はdirectionプロパティに影響を与えません（plaintextの場合も同様）ので、direction依存のレイアウト計算には影響しません。

Unicodeアルゴリズムには埋め込みレベルの上限（125）があるため、unicode-bidi値（normal以外）の使い過ぎには注意が必要です。 特に、深くネストされたインラインマークアップではinheritの値は慎重に使うべきです。 ただし、一般的にブロック表示される要素には、unicode-bidi: isolateを設定しておくことで、displayがinlineに変更された場合でも要素を一体化できます（下記例参照）。

2.3. 双方向テキストの例

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

<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. 双方向並び替えアルゴリズムの適用

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

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

CSSでは、 段落の埋め込みレベルは (UAX9 HL1節に従い) UnicodeアルゴリズムのP2・P3ステップで示されたヒューリスティックではなく、段落を含むブロックのdirectionプロパティに従って設定しなければなりません。

ただし、例外が1つあります。 段落を含むブロックの算出されたunicode-bidiがplaintextの場合は、 HL1による上書きをせず、[UAX9]で記載されているP2・P3のUnicodeヒューリスティックが使用されます。

2.4.2. CSSとUnicode双方向制御コード変換、テキスト並び替え

各双方向段落内の文字の最終的な順序は、 上記unicode-bidiに記載された方法で双方向制御コードを追加し、 マークアップを除去したあと、得られた文字列を、 スタイリングされたテキストと同じ改行位置を持つプレーンテキスト用Unicode双方向アルゴリズムの実装に渡した場合と同じ順序になります。

ソーステキスト中の双方向制御コードは依然として尊重され、 文書ツリー構造と一致しない場合があります。 これにより、インラインの分割や双方向開始・終了制御コードのペアリングに予期しない影響が生じることがあります。

2.4.3. アトミックインラインの双方向処理

この処理において、置換要素でdisplay: inlineが指定されているものは、unicode-bidiプロパティがembedまたはbidi-overrideの場合を除き、中立文字として扱われます。 上記2つの場合は、要素に指定された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の双方向フォーマット制御には適用されません。 Unicode制御は双方向段落の終端でその効果が終了するように定義されています。

2.4.5. 並び替えによるボックス断片化

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

2.4.5.1. 並び替えによるボックス断片化の条件

双方向並び替えによって、間に他のコンテンツが介在することでインラインボックスが分割される場合、 インラインボックスは複数のボックス断片に分割されたものとみなされます。[CSS-BREAK-3] 無限に長い行で間にコンテンツが介在する場合に分割されるなら、行分割によって両方のボックス断片が隣り合って配置された場合でも、分割されたものとみなされます。 この場合、2つのボックス断片のテキストの最近共通祖先（トラッキングや両端揃えの扱いに影響する、[CSS-TEXT-3]参照）は、インラインボックス自身ではなく、2つの断片の最近共通祖先とみなされます。 ただし、間に介在するコンテンツがなければ、インラインボックスは双方向並び替えによって複数の断片に分割されたものとはみなされません。 （これらの規則は、可能な限りインラインボックスの一体性を保ちつつ、双方向断片化を行分割の違いに左右されず安定化します。）

<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プロパティは、行ボックス内でテキストがどのように配置されるかを決定します。

置換要素の内容は、writing-modeによって回転しません。 例えば画像や<iframe>などの外部コンテンツはそのまま立った状態で表示され、 既定のオブジェクトサイズ（300px×150px）は向きが変わりません。 ただしテキストを含む置換コンテンツ（MathMLやフォーム要素など）は、 UAがその置換コンテンツに縦書きモードをサポートしている場合は、要素の書字モード・行方向に合わせるべきです。

<style>
  form { writing-mode: vertical-rl; }
</style>
...
<form>
<p><label>姓名　<input value="艾俐俐"></label>
<p><label>语言　<select><option>English
                       <option>français
                       <option>فارسی
                       <option>中文
                       <option>日本語</select></label>
</form>

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

• そのボックスが本来なら算出値がinlineとなるin-flowボックスであれば、 displayは代わりにinline-blockに算出されます。
• そのボックスがブロックコンテナであれば、 独立したブロック整形コンテキストを確立します。
• より一般的には、指定されたinner display typeがflowの場合、 算出されるinner display typeは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値の対応

UAがこれらの値をCSS文脈でサポートする場合、次のように算出します：

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. ベースラインの概要

このセクションは規範的ではありません。

ベースラインは、行ボックスのインライン軸に沿った線で、個々のグリフが整列する基準となる線です。ベースラインはフォントのグリフ設計を導き（例：多くのアルファベットグリフの下端はアルファベットベースラインに揃う）、異なるフォントやフォントサイズのグリフの組版時の整列にも使われます。

文字体系によって好まれるベースラインテーブルは異なります。

よく設計されたフォントには ベースラインテーブル があり、 フォントの設計座標空間内で1つ以上のベースラインの位置を示します。（設計座標空間はフォントサイズに合わせて拡大縮小されます。）

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

水平・垂直テキストの整列のために、異なるベースラインテーブルが提供されることがあります。UAは垂直組版モードでは垂直テーブル、その他の場合は水平テーブルを使うべきです。

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

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

alphabetic

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

central

中央ベースライン。通常はemボックスの中心を通ります。フォントにこのベースラインがない場合は、アセンダー（over）とディセンダー（under）の中間とみなします。

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

将来のCSSモジュールでは、より詳細なベースライン制御や他の支配的ベースライン・整列オプションが扱われます。

4.3. アトミックインラインのベースライン

アトミックインライン（inline-block, inline-table, 置換インライン要素など）にベースラインがない場合、 UAは以下のようなベースラインテーブルを合成します：

alphabetic

アルファベットベースラインはunderマージン端にあるとみなします。

central

中央ベースラインはunderとoverマージン端の中間とみなします。

vertical-align プロパティ（[CSS2]）は、inline-tableやinline-blockボックスのベースラインを一部例外付きで定義しています。

4.4. ベースライン整列

支配的ベースライン（詳細は組版モードに基づき変化する場合あり）は、CSSで次の2つの場合に整列に使われます：

• 同じインラインボックス内で異なるフォントのグリフを整列させる。グリフは各フォントの支配的ベースラインの位置を一致させて整列します。
• 子インラインレベルボックスを親に整列させる。 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 を指定すると、同じ規則で親に整列されますが、ベースライン整列に加えて子が上付き位置に移動します。

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

  

5. 縦書きテキストレイアウトの概要

各書記体系は1つ以上の固有の向きを持っています。現代の文字体系は、次の3つの向きカテゴリに分類できます：

横書きのみ

横方向のみで固有の向きを持つ書記体系。 例：ラテン、アラビア、ヘブライ、デーヴァナーガリー

縦書きのみ

縦方向のみで固有の向きを持つ書記体系。 例：モンゴル、パスパ文字

両方向

縦横両方で固有の向きを持つ書記体系。 例：漢字、ハングル、日本語仮名

縦書きスクリプトは、縦方向に固有の向きを持つもの（縦書きのみまたは両方向）。 横書きスクリプトは、横方向に固有の向きを持つもの（横書きのみまたは両方向）。 （各スクリプトの固有向きの分類は付録A参照。）

現代の組版システムでは、全グリフに水平向きが与えられ、横書きレイアウト時に使われます。 縦書きレイアウトのためには、UAがテキストを水平向きから変換する必要があります。この変換が 両方向変換 であり、次の2種類があります：

rotate

グリフを横から縦に回転

translate

グリフを横から縦に平行移動

縦方向に固有の向きを持つスクリプトは、固有の両方向変換を持ち、縦書き時に正しく配置されます。CJK（中・日・韓）文字の多くは平行移動（常に立てて表示）、モンゴルなど他のスクリプトは回転します。

固有の縦向きを持たないスクリプトは、回転（横向き配置）または平行移動（立てて配置）を選択できます。どちらを使うかは、テキスト用途のスタイル的な好みによるもので、正しさの問題ではありません。 text-orientationプロパティのmixedとupright値は、横書きのみテキストの回転と平行移動を指定します。

5.1. テキストの向き：text-orientation プロパティ

このプロパティは行内のテキストの向きを指定します。 現在の値は垂直組版モードでのみ効果があります。 水平組版モードのボックスには効果がありません。

値の意味：

mixed

垂直書字モードでは、横書きのみスクリプトの組版文字単位は横向き配置（標準の横書きから時計回り90°回転）されます。組版文字単位が縦書きスクリプトの場合は固有の向きで配置されます。 詳細は縦書きの向きを参照。

この値は主に縦書きスクリプト主体のテキストレイアウトで用いられます。

upright

垂直書字モードでは、横書きのみスクリプトの組版文字単位は立てて配置（標準の横書き向き）されます。組版文字単位が縦書きスクリプトの場合は固有の向き・通常の字形で配置されます。 詳細は縦書きの向きを参照。

この値はused valueのdirectionをltrにし、双方向並び替えの際は全ての文字を強いLTRとして扱います。

注： used value（算出値ではなく）がdirectionに影響します。これにより、rtlが、方向上書きが適用されない子孫（たとえば横書きのinline-block内容など）にも適切に継承されます。

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モードでテキストを組版する場合、 テキストは下記の「立て組み」または「横向き組版」で処理されます：

立て組み

組版文字単位は、縦組みの行内で1つずつ立てて配置され、縦組み用フォントメトリクスで処理されます。 UAは、縦組みメトリクスがないフォントにはそれを合成しなければなりません。 （この仕様ではその合成方法のヒューリスティックは定義しません。） また、縦組み用のフォント機能（代替グリフやその他の変形）が利用可能であれば使用しなければなりません。 （例：OpenTypeのvert機能は有効化されるべきです。） さらに、横書きの連続体スクリプト（例：アラビア語など）の文字は、立て組みの場合には孤立形（isolated form）で字形化されます。

「立て組み」であっても、 一部のグリフは回転して表示されるべきです。 例えばダッシュや囲み句読点は、インライン軸に対して向きを合わせる必要があります。 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>、<integer>で90°の倍数を指定）が含まれる文書を処理する必要があります。 このプロパティのサポートは任意ですが、 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には3種類の方向用語があります：

物理

書字モードに依存せず、ページに対して解釈される。 物理方向は、 左、 右、 上、 下です。

フロー相対

コンテンツのフローに対して解釈される。 フロー相対方向は開始と終了、 または寸法も曖昧な場合はブロック開始、ブロック終了、インライン開始、インライン終了です。

行相対

行ボックスの向きに対して解釈される。 行相対方向は行左、行右、行上、行下です。

物理寸法は、幅、高さであり、 それぞれx軸（水平寸法）およびy軸（垂直寸法）に対応します。 抽象寸法はフロー相対・行相対用語の両方で同じなので、この用語セットは一種類のみです。

注：[CSS3-FLEXBOX]では、フレックス相対用語も定義されており、フレックスレイアウトの説明に使われます。

6.1. 抽象寸法

抽象寸法は下記の通り定義されます：

ブロック寸法

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

インライン寸法

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

ブロック軸

ブロック寸法の軸。 水平書字モードではy軸、 垂直書字モードではx軸。

インライン軸

インライン寸法の軸。水平書字モードではx軸、垂直書字モードではy軸。

ブロックサイズ

論理高さ

ブロック寸法での計測値。 水平書字モードでは物理高さ（垂直寸法）、 垂直書字モードでは物理幅（水平寸法）を指します。

インラインサイズ

論理幅

インライン寸法での計測値。 水平書字モードでは物理幅（水平寸法）、 垂直書字モードでは物理高さ（垂直寸法）を指します。

6.2. フロー相対方向

フロー相対方向、block-start、block-end、inline-start、inline-endは、ページ上のコンテンツの流れに対して定義されます。 LTRのhorizontal-tb書字モードでは、それぞれ上、下、左、右方向に対応します。 定義は以下の通りです：

block-start

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

block-end

block-startと反対側。

inline-start

インライン基本方向のテキストが始まる側。 direction値がltrの場合はline-left側。 direction値がrtlの場合はline-right側。

inline-end

startと反対側。

文脈で曖昧さがなく、両方の意味を包含する場合は、 start、 endという用語が、 それぞれblock-start/inline-startとblock-end/inline-endの代わりに使われます。

ボックスのblock-start、block-end側の決定はwriting-modeプロパティのみに依存しますが、 inline-start、inline-end側の決定は writing-modeプロパティだけでなく、 directionプロパティにも依存します。

6.3. 行相対方向

行の向きは、行ボックスの 論理的な「上」（アセンダー側）となる側を決定します。 writing-modeプロパティで決まります。 通常、行相対の「上」はblock-start側ですが、 モンゴル書字（vertical-lr書字モード）では、 行相対「上」がblock-end側になります。 そのため別の用語が必要です。

主にモンゴル語の文書（上図）は左から右への縦行で書かれますが、ラテン文字はグリフの上が右側を向くように配置されます。これにより、モンゴル語（上から下方向）と同じインライン方向・同じ向きで表示され、他の東アジアレイアウト（右から左への縦行）と同じく、グリフの上端が行の積み重ねの下側を向きます。英語段落では逆さになります。（モンゴルテキストレイアウトの図参照）

CSSでは「vertical-align: top」のような指定のため行相対「上」と「下」だけでなく、 「text-align: left」のような指定のため行相対「左」と「右」も参照する必要があります。 そのため、行の向きに対して定義される4つの行相対方向があります。定義は以下の通り：

over または line-over

行ボックスのアセンダー側または「上」側に対応する側。（上線が描画される側）

under または line-under

overと反対の側：行相対「下」またはディセンダー側。（下線が描画される側）

line-left

行ボックスの「左」側。LTRテキストの開始側。

line-right

行ボックスの「右」側。RTLテキストの開始側。（line-leftと反対側）

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

horizontal-tbにおける行の向き

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

sideways-lrにおける行の向き

6.4. 抽象→物理マッピング

以下の表は抽象→物理マッピングのまとめです（useddirectionとwriting-modeに基づく）：

注：usedのdirectionは、算出されたwriting-modeやtext-orientationに依存します。 縦書きモードで text-orientation値がuprightの場合、usedのdirectionはltrになります。

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

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

CSSボックスレイアウトは、縦書きモードにおいても横書きモードと同様の原則に従い、以下の原則に沿って処理されます：

レイアウト計算の規則（CSS2.1のSection 10.3等）は、横書きモードでは水平方向に適用されますが、縦書きモードでは垂直方向に適用されます。 同様に、縦方向の規則（CSS2.1のSection 10.6等）は、縦書きモードでは水平方向に適用されます。 したがって：

• 幅を参照するレイアウト規則は高さを用い、高さを参照する規則は幅を用います。

• *-leftや*-right（border, margin, padding, positionオフセットなど）のボックスプロパティを参照するレイアウト規則は、 *-topと*-bottomを代わりに用い、またその逆も同様です。 CSS2.1の横書きモードの規則を、フロー相対方向を使って縦書きモードの規則にマッピングします。 これらのプロパティが適用されるボックスの側自体は変わりません： どの値がどの計算の入力になるかだけが変わります。 例えば、margin-leftプロパティは左側のマージンに影響しますが、 vertical-rl書字モードでは margin-bottomの代わりにマージンの折り畳みに関与します。

• directionプロパティに依存して左右を選択するレイアウト規則（overflow、制約解決、text-alignの初期値、テーブル列の順序等）は、 startとend側に抽象化され、適切に適用されます。

テキスト揃え、float、リストマーカー位置等、主に行ボックスの左右またはその縦方向の並行側を参照し、上下の対応物がない機能には、 line-leftとline-right側が左右の基準として使われます。

同様に、下線・上線・ベースライン整列（vertical-align）等、 主に行ボックスの上下または横方向の並行側を参照し、左右の対応物がない機能には、 line-overとline-under側が上下の基準として使われます。

これらのマッピングの詳細は以下に示します。

7.2. 寸法マッピング

一部プロパティは論理的に下記のように動作します：

• border-spacingプロパティの第1・第2値は、必ずしも水平方向・垂直方向ではなく、列・行間の間隔を表します。[CSS2]
• line-heightプロパティは常に論理的な高さを表します。[CSS2]

heightプロパティ（height、 min-height、max-height）は物理的な高さを指し、 widthプロパティ（width、min-width、max-width）は物理的な幅を指します。ただし、 ボックス寸法や位置決定のための規則は論理的に計算されます。

例えば、CSS2.1 Section 10.3の計算規則はインライン寸法の計測に用いられます。 これはインラインサイズ （物理的な幅または高さのいずれか）とinline-startおよびinline-endのmargin/padding/borderに適用されます。 同様に、CSS2.1 Section 10.6の計算規則はブロック寸法に用いられ、 ブロックサイズおよびblock-start・block-endのmargin/padding/borderに適用されます。[CSS2]

結果として、margin/paddingプロパティのパーセンテージ値は、 CSS2.1では常に包含ブロックの幅に対して計算されますが、 CSS3では包含ブロックのインラインサイズに対して計算されます。

7.3. 直交フロー

ボックスのwriting-modeが その包含ブロックと異なる場合、2つのケースが考えられます：

• 2つの書字モードが互いに平行である場合（例：vertical-rlとvertical-lr）。
• 2つの書字モードが互いに直交している場合（例：horizontal-tbとvertical-rl）。

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

この場合の処理のため、CSSレイアウト計算は ボックスのサイズ決定と、そのフロー内での配置の2段階に分かれます。

• サイズ決定フェーズ（幅・高さの計算）では、ボックスおよび包含ブロックの寸法をインラインサイズ・ブロックサイズにマッピングし、 直交フローを確立するボックスの書字モードに従って計算します。
• 配置フェーズ（オフセット・margin・border・paddingの計算）では、ボックスおよびその包含ブロックの寸法をインラインサイズ・ブロックサイズにマッピングし、直交フローを確立するボックスの包含ブロックの書字モードに従って計算します。

autoマージンは包含ブロックの書字モードに合わせて解決されるため、直交フローを確立するボックスも サイズ決定後は他のブロックレベルボックス同様、autoマージンで包含ブロック内で揃えや中央配置が可能です。

7.3.1. 直交フローにおける利用可能空間

CSSでは、包含ブロックに定義済みのインラインサイズがある一方、 ブロックサイズが未定義の場合がよくあります。 これは、CSS2.1で包含ブロックにautoの高さが設定されている場合によく発生します。 例えば、幅は10.3.3で計算されますが、 ブロックサイズはコンテンツ依存です。 この場合、利用可能なインライン空間は包含ブロックのインラインサイズとなりますが、 利用可能なブロック空間（通常は包含ブロックのブロックサイズ）は無限大です。

直交フローを確立すると逆の現象が起こることがあります： ボックスの利用可能なブロック空間は定義済みだが、 利用可能なインライン空間が未定義となる場合です。 この場合は包含ブロックのインラインサイズのパーセンテージ値が定義できず、 インライン軸の計算が解決できません。 この場合、 明確な利用可能なインライン空間が必要な計算には、追加制約を フォールバックとして用います。その値は最小の

• 包含ブロックのinnermax size（固定の場合）を下限としてinnermin size（固定の場合）でfloorする
• 最も近い祖先scrollportのinner size（固定の場合）、なければinnermax size（固定の場合）、innermin size（固定の場合）でfloor
• 初期包含ブロックのサイズ

CSSのサイズ用語・概念の詳細は[CSS3-SIZING]参照。

7.3.2. 直交フロー内の自動サイズブロックコンテナ

直交フローを確立するボックスが ブロックコンテナまたはマルチカラムコンテナの場合、 そのボックスのインラインサイズがautoのとき：

1. 使用されるcolumn-widthを計算：
   • column-countとcolumn-widthが両方ともautoの場合、 以下のシュリンクトゥフィット式を使う： min(max-content, max(min-content, constraint)) ここで：

     min-content

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

     max-content

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

     constraint

     インライン軸サイズで 次の最小値へストレッチフィットする：

     • 利用可能空間： 包含ブロックのサイズ（固定なら）、 もしくは包含ブロックのinnermax size（固定なら）を innermin size（固定なら）で下限
     • 最も近い祖先scrollportのinner size（固定なら）、 なければinnermax size（固定なら）、 innermin size（固定なら）で下限
     • 初期包含ブロックのサイズ

     

     この要件により、すべてのブロックコンテナで自動的に多段組みフローが発生します。 これは、オーバーフローした内容が包含ブロックの側方向へはみ出るのではなく、包含ブロックのフロー方向にカラムに折り返されることで、T字型ドキュメントを防ぐためです。 著者はインラインサイズにcolumn-widthを指定することでカラム幅を制御したり、 inline sizeプロパティにauto以外（例：max-content）を指定してこの挙動を無効化できます。
     
   • column-countがautoでなく、column-widthがautoの場合、 上記と同じ式で使用値を計算。ただしconstraintをconstraint − (column-count − 1) × column-gapに置き換える。
   • column-countとcolumn-widthが両方ともauto以外の場合、 使用されるcolumn-widthは算出されたcolumn-widthとなる。 （この方法はオーバーフローを起こしやすいので推奨されません。column-widthとmax-block-sizeを設定する方が好ましい。）
2. 使用されるカラム長を計算： 算出されたblock sizeがautoであり、column-countまたはcolumn-widthのいずれかがautoの場合、 ボックスのblock size（定義済みなら）、 もしくはボックスのストレッチフィットblock size（定義済みなら）、 それ以外はボックスのmax-content block sizeを使う。 それ以外は通常のマルチカラムコンテナのサイズ付け規則に従う。

   この式にボックスのmin-content block sizeを含めるべきか？ 例えば大きな画像がボックスをはみ出すのではなく、ボックスが包含ブロックからはみ出すようにするため？

3. 使用されるcolumn-countを計算： 算出されたcolumn-countがautoの場合、 使用されるcolumn-countは マルチカラムレイアウトにボックスの内容を充填することで決まる。

結果として得られるマルチカラムコンテナの使用インラインサイズは次のように計算：

1. 内容がマルチカラムコンテナ内で改行・断片化しない場合、使用インラインサイズはボックス内容のmax-contentインラインサイズになる。 この条件により短い直交フロー内容は大きな空白を生まずにシュリンクトゥフィット動作となる。
2. それ以外の場合、使用値はcolumn-width、column-count、column-gapから計算する。

ボックスの使用block sizeは、 複数カラムが使われた場合は使用カラム長、 1カラムだけの場合は内容のmax-content block sizeとなる。 UAがCSSマルチカラムレイアウト[CSS3COL]をサポートしない場合、 UAは代わりにボックスのblock sizeを無限の利用可能ブロック空間として計算し、 内容を1カラムにレイアウトしてもよい。 （この場合、内容が包含ブロックからはみ出して切れる/アクセスできなくなることがあります。）

多段組みの自動発生はリスクがあり、CR期間中に削除される可能性があります。

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

行の長さを制限するため、ブロックコンテナは上記で定義される特別な自動サイズ挙動を持ちます。 これは利用可能インライン空間が無限大の場合（典型的には直交フローを確立した場合）に発生します。

他のレイアウトモデルは無限の利用可能インライン空間へ max-contentサイズで単純にレイアウトします。 ただし、それらが含むブロックコンテナへも無限の利用可能インライン空間を伝播し、 それらのブロックコンテナで特別な自動サイズ挙動を発生させる可能性があります（自身が直交フローでなくても）。

7.3.4. 直交フローの断片化

このセクションは参考情報です。

断片化に関しては、CSS2.1の規則が縦書きモード・直交フローでも有効です： 行ボックス内での改行機会はなく、行間のみで発生します。 UAが[CSS3COL]をサポートする場合、 カラム間（幅0の場合も含む）で改行が可能です。

内容がルート要素によって確立されたページネーションストリーム外にはみ出した場合、 UAはその内容を印刷する義務はありません。 書字モードを混在させて長いテキストのストリームを作る場合は、 すべての内容が文書のページネーション方向に流れるようCSSカラムを使うことを推奨します。

7.4. フロー相対マッピング

フロー相対方向は、ボックスの包含ブロックの書字モードに基づいて計算され、 ボックスのプロパティ（margin、border、padding）やボックスの位置決めに関連するプロパティ （float、clear、top、bottom、 left、right、caption-side）に対するレイアウト規則を抽象化するために使われます。 インラインレベルボックスの場合は、親ボックスの書字モードが使われます。 （left/right/top/bottom名のプロパティ値自体は物理的にマッピングされます。 ただしcaption-sideのみ例外で、 top/top-outsideやbottom/bottom-outside値は それぞれテーブルのblock-start・block-end側に対応します。)

例えば、ボックスのインライン寸法が過剰制約された場合にドロップされるマージンは、 包含ブロックの書字モードで決まるendマージンです。

マージン折り畳み規則は、 block-startマージンをtop marginに、 block-endマージンをbottom marginに置き換えて厳密に適用されます。 同様にblock-startパディング・ボーダーがtopパディング・ボーダーに、 block-endパディング・ボーダーがbottomパディング・ボーダーに置き換えられます。 つまり折り畳みされるのはblock-startとblock-endマージンのみです。

フロー相対方向はボックス自身の書字モードに基づいて計算され、 ボックス内容に関するレイアウト抽象化に使われます：

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

7.5. 行相対マッピング

行相対方向は、over、under、line-left、line-rightです。 LTRのhorizontal-tb書字モードでは、 それぞれ上、下、左、右方向に対応します。

line-rightとline-left方向は、ボックスの書字モードを基準に計算され、 以下のプロパティのleft・right値の解釈に使われます：

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

line-rightとline-left方向は、ボックスの包含ブロックの書字モードを基準に計算され、 以下のプロパティのleft・right値の解釈に使われます：

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

overとunder方向は、ボックスの書字モードを基準に計算され、 行ボックスの「top」（over）および「bottom」（under）側の解釈を次のように定義します：

• vertical-alignプロパティの場合、 行ボックスの「top」はover端、 「bottom」はunder端です。 正の長さ・パーセンテージ値はベースラインをline-over端側へ移動します。[CSS2]
• text-decorationプロパティの場合、 下線はテキストのunder側、 上線はテキストのover側に描画されます。[CSS2] CSS Text Decoration Moduleではさらに詳細に定義され、下線・上線の位置制御が追加されています。[CSS3-TEXT-DECOR]

7.6. 純粋な物理マッピング

以下の値は定義上純粋な物理値であり、書字モードの変化には反応しません：

• rect()記法によるclipプロパティ [CSS2]
• background系プロパティ [CSS2] [CSS3BG]
• border-image系プロパティ [CSS3BG]
• box-shadow・text-shadowプロパティのオフセット

8. 主要書字モード

文書の主要書字モードは、 ルート要素のusedwriting-mode、 direction、 text-orientationの値で決定されます。 この書字モードは、例えばスクロール方向や デフォルトのページ進行方向の決定などに使われます。

HTML文書を扱う特例として、 ルート要素が body 子要素[HTML]を持つ場合、 ルート要素のused valueとしてのwriting-mode・directionは、 ルート要素自身の値ではなく、その最初の子要素の算出値を採用します。 UAはtext-orientationの値も同様に伝播してもよいです。 なお、この伝播はルート要素自身の算出値には影響しません。

注：伝播は算出値ではなくused値で行われます。これは他のスタイル計算（継承、論理プロパティマッピングロジック、長さ値計算など）への影響を避けるためです。

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

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

@pageボックスにも伝播するか？

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

ページメディアでは、CSSはすべてのページを左ページまたは右ページとして分類します。 ページ進行方向（[CSS3PAGE]参照）は、 見開きで左ページ・右ページのどちらが先になるか、最初のページがデフォルトで左か右かを決定しますが、 これは主要書字モードによって次のように決まります：

注：特に指定がなければ、文書の最初のページは見開きの後半（例：left-to-right進行なら右ページ）から始まります。

9. グリフ合成

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

このプロパティは複数の組版文字単位を1つの組版文字単位分のスペースに合成することを指定します。 合成されたテキストが1emより広い場合、UAは内容を1em内に収めなければなりません（下記参照）。 合成されたものはレイアウト・装飾上1つの立てグリフとして扱われます。 このプロパティは縦書きモードでのみ効果があります。各値の意味は以下の通りです：

none

特別な処理なし。

all

ボックス内のすべての連続する組版文字単位を 縦行内の1つの組版文字単位分のスペースに水平組版しようとする。

digits <integer>?

ASCII数字（U+0030–U+0039）の連続する最大シーケンスで、指定された整数以下のものを水平組版し、 縦行内で1つの組版文字単位分のスペースに収めようとする。 整数が省略された場合は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でテキストを合成する場合、 合成されたテキストのグリフはbidi分離されて水平方向に配置されます。 （letter-spacingや強制改行は無視されますが、指定されたフォント設定は使用します） これは、inline-blockボックスの内容を 横書きモードで、line-heightを1emとして配置する場合に似ています。 合成テキストの先頭／末尾に含まれる文書の空白は インラインブロック先頭／末尾と同様に 処理されます [CSS-TEXT-3]。 合成の実効サイズは1em四方とみなされ、それを超えた部分はレイアウト上無視されます。 UAはグリフを1em四方内で水平・垂直方向に中央揃えすべきです。

合成のベースラインは、この正方形が親インラインボックスのtext-over／text-underベースライン間で （vertical-alignによる整列前に）中央に配置されるよう選択されなければなりません。 双方向並び替えでは、この合成は組版文字単位として、text-orientation: uprightで扱われます。 行分割の前後では、実際の内容の通常インラインとして扱われます。 その他のテキストレイアウト（例えば強調点、装飾、スペーシングなど）では、 この合成はオブジェクト置換文字U+FFFCを表す単一グリフとして扱われます。

9.1.3. 圧縮規則

UAは、合成テキストの合計アドバンス幅が1em以内に収まるよう、必要に応じて圧縮しなければなりません。 （必ずしもグリフが1em内に収まるとは限りません。グリフ設計上枠外に描画される場合もあります。） OpenType実装では、幅固有のバリアント（OpenType機能hwid/twid/qwid。fwidやpwid等は含まない）を 合成内の全組版文字単位で利用可能な場合は必ず用いて圧縮します。 そうでない場合、UAはフォントが提供する半角・3分幅・4分幅グリフの代用、他の横圧縮用フォント機能、文字のジオメトリ的スケーリング、 それらの組み合わせ等、任意の方法でテキストを圧縮して構いません。

一部フォントでは、漢字グリフが1em幅で1em高さより短く設計されています。 こうしたフォントに対応するため、UAは合成全体を「水」U+6C34のアドバンス高さに合わせて垂直スケールしてもよいです。 この場合、合成の高さは1emでなく「水」U+6C34のアドバンス高さとなります。

9.1.3.1. 全角文字

テキストを1emに圧縮する際に組版の色感（typographic color）を保つため、 合成テキストが2文字以上の組版文字単位からなる場合、 全角組版文字単位はまず text-transform: full-widthのアルゴリズムを逆にして 非全角に変換し、他の圧縮技法を適用します。[CSS-TEXT-3]

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

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

２
０
１
０
年
２
月
23
日

グリフ選択に影響するプロパティ（font-variantやfont-feature-settings等 [CSS3-FONTS]） は、合成テキストランでの文字の字形選択に影響する可能性があります。 text-combine-upright利用時は これらのプロパティの利用に注意してください。

10. プライバシーとセキュリティの考慮

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

変更点

2018年5月 CSS Writing Modes Module Level 4 Candidate Recommendation以降の変更点

• body要素から初期包含ブロック・ビューポートへの主要書字モードの伝播は、ルート要素のused値にも影響するが、算出値には影響しないことを明確化。 また、text-orientationの伝播も任意で許可。 この変更はレベル3にも適用。 (Issue 3066)
• text-combine-upright合成テキストシーケンスの 開始・終了部の空白はインラインブロックと同様に処理されることを明確化。 (Issue 4139) この変更はレベル3にも適用。

  text-combine-upright: allでテキストを合成する場合、 合成されたテキストのグリフはbidi分離されて水平方向に配置されます。 （letter-spacingや強制改行は無視されますが、指定フォント設定は使用） inline-blockボックスの内容として 横書きモード・line-height1emと同様に配置。 合成テキストの先頭／末尾の文書空白は、 インラインブロックと同様に処理されます [CSS-TEXT-3]。

Level 4の新規追加項目

このモジュールは2015年版CSS Writing Modes Level 3候補勧告の単なるコピーです。 現行CSS Writing Modes Level 3との違いは、 実装が遅れてLevel 3では見送られた機能群です：

• sideways-lr値とsideways-rl値の再導入（writing-mode）
• digits値の再導入（text-combine-upright）
• 直交フローの自動多段組み挙動の再導入
• 双方向並び替えによる断片化の条件の明確化（Issue 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を使うことで縦組みできます。