CSS書き方モード レベル3

1. 書き方モードの概要

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

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

ラテン系書き方モード

モンゴル系書き方モード

漢字系書き方モード

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

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

組版モードは、縦書きスクリプトに対して、縦組み特有の組版慣習を適用するかどうかを決定します。 この概念は、縦書きスクリプトの縦組みと、回転した横組みを区別します。

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

これらの用語と、縦型ブロックフロー（下方向または上方向のブロックフロー）および横型ブロックフロー（左方向または右方向のブロックフロー）は混同しないでください。CSS仕様では混乱を避けるため、後者の用語は使用しません。

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

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

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

書き方モードや縦書きテキストの詳細な解説は、Unicode Technical Note #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]）は、font-relative lengths（フォント相対長）や、算出されたフロー相対プロパティ（算出値が書き方モードやフォントメトリクスに依存しうる）など、他の無関係なプロパティの算出値にも広く影響を与えることができます。これらは、算出された書き方モードや、書き方モードに依存するフォントメトリクスに基づいて計算されます。

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プロパティで、埋め込み・分離・上書きの制御を明示的に行うことができます。 テキストの基準方向は文書の構造や意味に依存するため、directionと unicode-bidiプロパティは、通常、マークアップ内のbidi情報をCSSスタイルにマッピングする用途で使用するべきです。

HTML仕様（[HTML401] 8.2節、[HTML] 14.3.5節）では、HTML要素の双方向性の挙動が定義されています。

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

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

HTMLユーザーエージェントは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

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

• シーケンス内の内容は、 独立した段落内にあるかのように並べられ、 その基底方向性はボックスの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は、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]に記載された通りUnicodeのP2・P3ヒューリスティックを使用します。

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の双方向制御文字には適用されません。Unicodeでは双方向段落の終端で制御の効果が終了するよう定義されています。

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

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

各行ボックスに対し、ユーザーエージェントは各インラインボックスの断片を取得し、マージン、ボーダー、パディングを論理順ではなく表示順（ビジュアル順）で割り当てなければなりません。 開始側の断片（そのボックスが初めて現れる行ボックスの端）は開始エッジのマージン、ボーダー、パディングを持ち、 最後の行ボックスの終了側の断片は終了エッジのマージン、ボーダー、パディングを持ちます。 例えば、horizontal-tb書き方モードの場合：

• 親のdirectionプロパティがltrの場合、 最初の行ボックスでボックスが現れる左端の断片は左マージン・左ボーダー・左パディングを持ち、 最後の行ボックスで右端の断片は右パディング・右ボーダー・右マージンを持ちます。
• 親のdirectionプロパティがrtlの場合、 最初の行ボックスで右端の断片は右パディング・右ボーダー・右マージンを持ち、 最後の行ボックスで左端の断片は左マージン・左ボーダー・左パディングを持ちます。

縦書きモードでも同様のルールが適用されます。

box-decoration-breakプロパティを使うことで、この挙動を上書きし、各断片の両端にボックス装飾を描画することもできます。[CSS3-BREAK]

3. 縦書きモード

CSS2.1の双方向テキスト対応の拡張に加え、このモジュールはCSSで縦書きレイアウトを実現するためのルールやプロパティを導入します。

3.1. 縦書きの概要

この節は規定ではありません。

主に横書きでレイアウトされるラテン文字系言語とは異なり、中国語や日本語などアジアの言語は縦書きでもレイアウトできます。下記の日本語の例では、同じテキストが横書きと縦書きで表示されています。横書きの場合、左から右、上から下に読みます。縦書きの場合は上から下、右から左に読みます。 横書きの左端からのインデントは、縦書きにすると上端からのインデントに変換されます。

中国語と日本語は、行が右から左または上から下に並びますが、モンゴル語や満州語は左から右に並びます。

横書きから縦書きに変えることで、レイアウトだけでなく組版にも影響が出ます。例えば、句読点のグリフ内の配置が横書きから縦書きで変わることがあり、場合によっては代替グリフが使われることもあります。

縦書きテキストがラテン文字など通常横書きの文字を含む場合、表示方法はいくつかあります。例えば、ラテン語の単語を横倒し（90度回転）で表示したり、各文字を立てて表示することもできます：

日付の2桁の数字など、特別なケースではテキストを1つの縦書き文字ボックスに収めてコンパクトに表示することもあります：

レイアウトはしばしば縦・横要素が混在します：

縦書きレイアウトでも双方向テキストの処理が必要です。例えば、アラビア語を時計回りに回転させた場合は下から上に並びます。

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

このプロパティは、テキストの行を横方向または縦方向にレイアウトするか、ブロックの進行方向を指定します。指定可能な値：

horizontal-tb

上から下へのブロックフロー方向。 書き方モードと 組版モードの両方が横書きとなります。

vertical-rl

右から左へのブロックフロー方向。 書き方モードと 組版モードの両方が縦書きとなります。

vertical-lr

左から右へのブロックフロー方向。 書き方モードと 組版モードの両方が縦書きとなります。

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

置換要素の内容は、writing-modeによって回転しません。 例えば画像や<iframe>などの外部コンテンツは立ったまま表示され、標準オブジェクトサイズ（300px×150px）も再方向付けされません。 ただし、テキストを含む埋め込み置換コンテンツ（MathMLやフォーム要素など）は、 UAがその置換コンテンツの縦書きをサポートしていれば、要素のwriting-modeと行の向きに合わせて調整されるべきです。

<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値を持つ場合：

• ボックスが、それ以外の場合にはインフローボックスになり、 その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値をサポートする

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ボックスの中心を横切ります。フォントにこのベースラインがない場合は、ascender（over）とdescender（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を指定すると、 同じ規則を使用して.innerの子を親に整列します。唯一の違いは、 ベースラインの整列に加えて、子が 上付き文字の位置へ移動されることです。

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

  

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

各書記体系には1つ以上の固有の書字方向があります。現代の文字体系は次の3つの方向カテゴリに分類できます：

横書きのみ

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

縦書きのみ

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

両方向型

縦・横両方の固有書字方向を持つ文字体系。 例：漢字、ハングル、日本語かな

縦書きスクリプトとは、固有の縦方向を持つ文字体系です。 すなわち、縦書きのみまたは両方向型のいずれかです。 横書きスクリプトは、固有の横方向を持つ文字体系です。 すなわち、横書きのみまたは両方向型のいずれかです。 （固有の書字方向による文字体系の分類については付録A参照。）

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

rotate

グリフを横方向から縦方向に回転する

translate

グリフを横方向から縦方向に平行移動する

縦方向の固有書字方向を持つ文字体系には、固有の両方向型変換があり、縦書きで正しく向きます。CJK（中国語／日本語／韓国語）文字の多くはtranslate（常に立てて表示）されます。他の文字体系（モンゴルなど）はrotate（回転表示）されます。

固有の縦方向を書字方向に持たない文字体系は、回転（横倒し表示）もしくは平行移動（立てて表示）どちらでも可能です。どちらの変換を使うかは、用途に応じたスタイルの選択であり、正誤の問題ではありません。 text-orientationプロパティのmixedとupright値で、横書きのみテキストの回転と平行移動を指定できます。

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

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

各値の意味：

mixed

縦書きモードでは、typographic character units（横書きのみ文字体系）は横倒し表示され、標準の横書き方向から90°時計回りに回転します。typographic character units（縦書き文字体系）は固有の向きで表示されます。 詳細は縦書き方向参照。

この値は主に縦書き文字が主体のレイアウトで使われます。

upright

縦書きモードでは、typographic character units（横書きのみ文字体系）は立てて表示され、標準の横書き方向のまま縦に配置されます。typographic character units（縦書き文字体系）は固有の向きで、通常通りにグリフ整形されます。 詳細は縦書き方向参照。

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

注記: 影響を受けるのは使用値であり、 算出値ではありません。 これはdirectionに対するもので、 これにより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 モードでテキストを組版する場合、テキストは以下のいずれかで表示されます：

立てて表示（upright typesetting）

typographic character unitsは縦行内で個々に立てて表示され、縦用フォントメトリクスを使います。 UAはフォントに縦メトリクスがない場合、縦メトリクスを合成する必要があります。 （本仕様ではその合成ヒューリスティクスは定義しません。） また、縦組み用のフォント機能（代替グリフや他の変形など）も利用しなければなりません。 （例：OpenTypeのvert機能は有効化する必要あり。） さらに、アラビア語など横書き草書文字体系の文字は、立てて表示の場合は孤立形で整形されます。

立てて表示でも一部グリフは回転表示すべきです。 例：ダッシュや括弧などはインライン軸に合わせて向きを調整します。 OpenTypeでは通常グリフ置換で処理しますが、すべてのコードポイントに代替グリフがあるとは限りません。 （東アジアフォントは東アジアコードポイントに代替を持ちますが、西欧フォントには縦組み機能がほとんどなく、東アジアフォントも西欧コードポイントの縦置換は持たないのが一般的です。） Unicodeではどの文字が横倒し表示（sideways）すべきかをSVO属性としてこのデータファイルで公開しましたが、現行[UAX50]改訂では廃止されています。

typographic character unitsが[UAX50]でTrまたはTu分類の場合、縦組み時の代替グリフまたは位置調整が期待されます。 Tr 文字について、フォントに縦用代替グリフがない場合は、UAは（必須ではないが）[RFC6919]に従って不足グリフを横倒し表示等で合成してもよいです。

横倒し表示（sideways typesetting）

typographic character unitsは、立てて表示の向きから90°時計回りに回転したランとして横メトリクス・横組み処理を使い、縦組み機能は使いません。 ただし、縦行内横倒しテキスト用にフォントに対応機能がある場合（例：筆運びや位置調整など）、それらは利用されます。 （例：提案されているvrtr OpenTypeフォント機能など。）

5.1.2. 混合縦書き方向

[UAX50]は、混合方向の縦書きテキストのデフォルトグリフ方向を示すVertical_Orientationプロパティを定義しています。 text-orientationがmixedの場合、 UAは各typographic character unit（組版文字単位）の方向を Vertical_Orientationプロパティに基づいて決定しなければなりません。プロパティがU、Tu、Trの場合は立てて表示し、Rの場合は横倒し表示（横向きから90度時計回りに回転）となります。

UAX50は縦書き文脈で-90°回転するスクリプトには対応していないため、 mixed方向では正しく組版されません。 sideways-lr値（Level 4）ではこれらのスクリプトを正しく表示できます。

OpenTypeのvrt2機能は混合方向組版用ですが、CSSでは使用されません。 グリフの方向決定はフォント設計者に委ねられています。 CSSは代わりに[UAX50]に従い、必要に応じてグリフを横倒しまたは立てて表示します。

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軸（垂直寸法）に沿った測定に 対応します。抽象寸法は、フロー相対用語と 行相対用語のどちらでも同一であるため、 これらの用語の集合は1つだけです。

注記: [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側に対応します。 そのため、区別された用語が必要です。

主にモンゴル語の文書（上図）は、縦行が左から右へ積み重なり、ラテン文字はグリフの上部が右側を向きます。これによりモンゴル語と同じインライン方向（上から下）で流れ、他の東アジアの縦書き（右から左に積み重なる）と同じ向きになりますが、グリフの上部が行スタックの下側を向くため、英語段落では上下逆転します。（モンゴル語テキストレイアウト図参照）

'vertical-align: top'のようなものを対応付けるための行相対の“上”と“下”に加えて、 CSSでは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での行方向

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

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

注: used directionは、算出writing-modeやtext-orientationに依存します。 縦書きモードでは、 text-orientation値がuprightの場合、usedの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プロパティに依存して左右を選択するレイアウトルール（overflow、過剰制約解決、text-alignの初期値、テーブル列の順序など）は、抽象化されてstartとend側に適用されます。

テキスト整列、フロート、リストマーカー位置など、主に行ボックスの左右やその縦方向の並びに関係し、上下の対応がない機能では、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 10.3節の計算ルールはインライン寸法に適用されます。 inline size （物理幅または物理高さのいずれか）やinline-start・inline-endのマージン、パディング、ボーダーに適用されます。 同様に、CSS2.1 10.6節の計算ルールはブロック寸法に適用され、 block sizeやblock-start・block-endのマージン、パディング、ボーダーに適用されます。[CSS2]

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

7.3. 直交フロー

ボックスのwriting-modeが包含ブロックと異なる場合、2通りあります：

• 両者の書き方モードが平行な場合（例：vertical-rlとvertical-lr）。
• 両者の書き方モードが直交する場合（例：horizontal-tbとvertical-rl）。

ボックスが包含ブロックと直交する書き方モードを持つ場合、それは直交フローを確立すると言います。

この場合、CSSのレイアウト計算は「サイズ決定フェーズ」と「配置フェーズ」に分かれます：

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

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

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

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

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

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

[css-sizing-3]を参照すると、CSSの サイズ設定に関する用語および概念の詳細を確認できます。

7.3.2. 直交フロールートの自動サイズ調整

インライン軸における自動サイズは、ブロックレベルまたはブロックコンテナの直交フローについて、 （すなわち、その優先サイズプロパティがautoの場合に使用されるサイズ） そのフィットコンテンツサイズとして算出されます。すなわち、 min(max-content inline size, max(min-content inline size, stretch-fit inline size)、 ここで、利用可能な空間は、ストレッチフィットインラインサイズの算出に使用されるものであり、 包含ブロックのサイズ（そのサイズが確定している場合）、 またはフォールバックサイズ（上記で定義されたもの）のいずれかです。

自動サイズ設定については、直交するマルチカラムコンテナ（両軸） および上記で言及されていないその他の表示型の場合、 この仕様では定義されません。

注記: CSS Writing Modes Level 4も参照してください。

7.3.3. 直交フローの分割

この節は参考情報です。

分割（fragmentation）に関しては、縦書きモードおよび直交フローでもCSS2.1のルールが有効です：改行可能箇所は行ボックス内では発生せず、行ボックス間でのみ発生します。 [CSS3COL]をサポートするUAは、（幅0の場合もある）カラム間の隙間で改行できます。

ルート要素が確立したページネーションストリームをはみ出した内容については、UAは印刷する必要がありません。 異なる書き方モードを混在し、長いテキストストリームを使用したい著者は、すべての内容が文書のページネーション方向に流れるよう、CSSカラムを使うことを推奨します。

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

フロー相対方向は、ボックスの包含ブロックの書き方モードに基づいて計算され、 ボックスプロパティ（マージン、ボーダー、パディング）や、ボックスを包含ブロック内で位置決めするプロパティ（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マージンです。

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

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

• 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. 純粋な物理マッピング

以下の値は定義上完全に物理的であり、writing-modeの変更には反応しません：

• 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. 初期包含ブロックへの伝播

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

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

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

注:特に指定がなければ、文書の最初のページは見開きの後半、つまり左から右ページ進行では右ページから始まります。

9. グリフ合成

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

このプロパティは複数のtypographic character unitを、 1つのtypographic character unitの空間に合成します。 合成テキストが1emより広い場合、UAは内容を1em内に収めなければなりません（下記参照）。 合成結果はレイアウトや装飾の観点では単一の立てて表示されたグリフとして扱われます。 このプロパティは縦書きモードのみ効果があります。値の意味は以下の通りです:

none

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

all

ボックス内の連続するtypographic character unitをすべて横組みで合成し、 縦行ボックス内で1つのtypographic character unitの空間に収めます。

date span { text-combine-upright: all; }

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

将来のCSS Writing Modesでは、よく使われるシーケンスを自動検出する値が導入されます。 例えば、CSS Writing Modes Level 4では、数字列を合成するdigits値が導入されます。

9.1.1. 合成テキストランのルール

レンダリングやレイアウトの複雑さを避けるため、text-combine-uprightは プレーンテキストのみ合成できます。 すなわち、ボックス境界で途切れない連続するtypographic character unitのみが対象です。

ただし、このプロパティは継承するため、UAは合成を行うボックスの内容が他の合成可能なシーケンスの一部になっていないことを保証すべきです。 もしそうなら、テキストは通常通りにレイアウトされ、text-combine-uprightがnoneであるかのように扱われます。

tcy { text-combine-upright: all; }

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

9.1.2. レイアウトルール

text-combine-upright: allの場合と同様にテキストを結合すると、 結合されたテキストのグリフは双方向分離され、水平方向に組版されます （letter-spacingおよびあらゆる強制改行を無視し、 指定されたフォント設定を使用します）。 これはinline-blockボックスの内容と同様であり、 そのボックスは横書きモードを使用し、line-heightは1emです。 文書の空白が結合テキストに含まれる場合の処理は、 このレベルでは定義されていません。 合成結果の実効サイズは1em四方であると仮定され、 その正方形の外側にあるものはレイアウト上の寸法測定には含まれません。 UAは、グリフを測定対象となる1em四方の領域内で水平方向および垂直方向の中央に配置するべきです。

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

9.1.3. 圧縮ルール

UAは、合成の進行幅が1em以内になるように、必要に応じて合成テキストを圧縮しなければなりません。 （これはグリフ自体が必ず1emに収まることを意味するものではありません。グリフによっては幾何学的境界外に描画されるものもあります。） OpenType実装は、合成内のすべてのtypographic character unitに幅指定のバリアント（OpenType機能hwid/twid/qwid。fwidやpwidなど他の幅機能は含みません）が利用可能な場合は、それらを使って圧縮しなければなりません。 そうでない場合、UAはフォントが提供する半角・三分幅・四分幅グリフの代替、水平圧縮用フォント機能、幾何学的な縮小、またはそれらの組み合わせなど、任意の方法でテキストを圧縮しても構いません。

一部のフォントでは、表意文字グリフが1em幅だが高さは1em未満になるなど圧縮設計となっています。 このようなフォントに対応するため、UAは合成結果を指定フォント設定で描画した「水」U+6C34の進行高さに合わせて垂直方向にスケーリングしても構いません。 その場合、合成結果の高さは1emではなく「水」U+6C34の進行高さとなります。

9.1.3.1. 全角文字

テキストを1emに圧縮する際に組版上の色調を維持するため、 結合テキストが複数のタイポグラフィ文字単位からなる場合、 全角のタイポグラフィ文字単位はすべて、 まず対応する非全角文字へ変換するべきです。 これを行うには、text-transform: full-widthについて[CSS-TEXT-3]で定義されたアルゴリズムを逆に適用してから、他の圧縮手法を適用します。

グリフの選択に影響するプロパティ、 例えばfont-variantおよびfont-feature-settingsプロパティ（[CSS3-FONTS]で定義）は、 結合テキストランに含まれる文字のバリアント選択に影響を与える可能性があります。 作者には、これらのプロパティをtext-combine-upright と併用する際、慎重に使用することが推奨されます。

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

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

変更点

2019年9月 CSS Writing Modes Module Level 3 Candidate Recommendation以降の変更点

実質的な変更なし。細かな編集修正（4293、4272、4273参照）。

2019年7月 CSS Writing Modes Module Level 3 Candidate Recommendation以降の変更点

• 直交フローのサイズ決定規則を復活。記述を最新の[css-sizing-3]用語に更新（Issue 4220）

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

• 主要書き方モードのbody要素から初期包含ブロック・ビューポートへの伝播は、ルート要素のused値に影響するが算出値には影響しないことを明確化。また、text-orientationの伝播も任意で許可（Issue 3066）
• text-combine-upright合成テキストシーケンス内の空白処理をこのレベルでは未定義と明記（Issue 4139）

  text-combine-upright: allの場合と同様にテキストを結合すると、 結合されたテキストのグリフは双方向分離され、水平方向に組版されます （letter-spacingおよびあらゆる強制改行を無視し、 指定されたフォント設定を使用します）。 これはinline-blockボックスの内容と同様であり、 そのボックスは横書きモードを使用し、line-heightは1emです。 文書の空白が結合テキストに含まれる場合の処理は、 このレベルでは定義されていません。

2017年12月 CSS Writing Modes Module Level 3 Candidate Recommendation以降の変更点

• 直交フローのフォールバック「利用可能空間」で、max-height（およびmin-height）を考慮し忘れていたのを修正。 (Issue 2239)

2015年12月 CSS Writing Modes Module Level 3 Candidate Recommendation以降の変更点

• sideways-lrおよびsideways-rl値（writing-mode）をLevel 4に延期。
• digits値（text-combine-upright）をLevel 4に延期。
• 直交フローの自動マルチカラム動作をLevel 4に延期。
• 直交フローのフォールバック「利用可能空間」を、最も近い固定サイズscrollportに変更。 (Issue 1391)
• プライバシーとセキュリティに関する考慮事項セクションを追加。
• その他編集上の明確化。

コメント対応一覧も利用可能です。

2014年3月 CSS Writing Modes Module Level 3 Candidate Recommendation以降の変更点

• シュリンクラップをより適切に処理できるよう、直交フローの自動サイズ設定規則を修正しました。
• sideways-leftおよびsideways-rightというtext-orientationの値を削除し、 sidewaysをsideways-rightとして動作するよう再定義し、 非縦書きの書字体系で使用するためにsideways-lrおよびsideways-rlという値をwriting-modeに追加しました。 （議論を参照。）
• use-glyph-orientationというtext-orientationの値を削除し、glyph-orientation-verticalをtext-orientationのエイリアスとして、CSSエイリアスの 扱いと整合するよう定義しました（例としてpage-break-insideを参照）。
• 度数を整数として扱う処理をglyph-orientation-verticalに追加しました。 これはSVGの後方互換性に必要です。
• run-inボックスに関する記述を削除しました。この値はCSS2.1から削除され、 CSS Display Level 3では大幅に異なるモデルを持つためです。 新しい[CSS-DISPLAY-3]の用語を使用した、すべての表示型に関する一般化された記述に置き換えました。
• 算出値の伝播を、writing-modeプロパティおよびdirectionプロパティについて、 body子要素から初期包含ブロックへ行うよう変更しました。
• caption-sideプロパティをフロー相対マッピングに変更しました。
• SVGのwriting-mode値が新しい等価値として算出されることを規定しました。
• writing-modeがルビベースコンテナおよびルビ注釈コンテナには適用されないことを規定しました。
• 複数の編集上の改善を行い、一部の機能をリスクありとしました。

謝辞

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（CSS Writing Modes Level 4）を使うことで組版可能です。