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ユーザーエージェントはCSSスタイリングを無効化できるため、HTML著者は正しい双方向レイアウトを確保するため、HTMLのdir属性、<bdo>要素、およびテキストレベルとグループレベルのHTML要素タイプの適切な区別を使用することを推奨します。HTML文書でunicode-bidiプロパティを使用すべきではありません。

通常（つまりunicode-bidiがnormalの場合）、 インラインボックスはUnicode Bidiアルゴリズムに対して透明になります。 コンテンツはボックスの境界が存在しないかのように並べられます。 unicode-bidiプロパティの他の値は、 インラインボックスがアルゴリズム内でスコープを作成し、 テキストの本来の方向性を上書きします。

次の参考表は、unicode-bidiのボックス内部および外部への影響をまとめたものです：

このプロパティの値の意味（規定）は以下のとおりです：

normal

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

embed

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

この値はインラインでないボックスには効果がありません。

isolate

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

• シーケンス内コンテンツは、ボックスのdirectionプロパティで指定された基準方向を持つ独立段落内として並べられます。
• 包含する双方向段落の解決のため、シーケンスは単一の「Object Replacement Character (U+FFFC)」として扱われます。

実質的に、ボックス内のコンテンツは外部コンテンツの双方向性に影響されず、 また外部コンテンツもボックス内コンテンツや方向性に影響されません。 ただし、ボックス内の強制段落区切りは包含段落にも対応する区切りを作成します。

この値はインラインでないボックスには効果がありません。

bidi-override

この値はボックスの直下インラインコンテンツに方向上書きを適用します。 インラインの場合、双方向アルゴリズム上は方向埋め込みとして機能しますが、 内部の並べ替えはdirectionプロパティに従い厳密に順番通りとなり、 双方向アルゴリズムの暗黙部分は無視されます。 ブロックコンテナの場合、上書きは全内容を囲む匿名インラインボックスに適用されます。

isolate-override

この値はisolation（隔離）挙動（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の時、親の支配的ベースラインと子の同じベースラインを一致させて整列します。（例：親の支配的ベースラインがalphabeticなら、子のalphabeticベースラインを親のalphabeticベースラインに揃えます。子の支配的ベースラインが異なっていても同様です。） 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（中国語／日本語／韓国語）文字の多くは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として扱います。

注: 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 モードでテキストを組版する場合、テキストは以下のいずれかで表示されます：

立てて表示（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書き方モードのみを対象としています。他の書き方モードでもレイアウトは類似していますが、CSS2.1の方向や寸法用語は抽象化して適切に再マッピングしなければなりません。

この節では、他の書き方モードのボックスレイアウトを定義するため、また将来の仕様がレイアウト概念を抽象的に定義できるように、抽象的な方向・寸法用語とそのマッピングを定義します。（次節ではこれらをCSS2.1のレイアウト計算に適用する方法や直交フローの扱いを解説します。） これらの抽象的なマッピングはテキストの挙動に由来しますが、行ボックスを含まないボックスにも適用されます。 算出はwriting-modeやdirectionプロパティの値から直接行われます。

CSSには3つの方向用語セットがあります：

物理

書き方モードに関係なくページ基準で解釈されます。 物理方向は、左、右、上、下です。

フロー相対

コンテンツの流れ基準で解釈されます。 フロー相対方向はstartと end、 またはblock-start、block-end、inline-start、inline-end（寸法が曖昧な場合）。

行相対

行ボックスの向き基準で解釈されます。 行相対方向はline-left、line-right、line-over、line-underです。

物理寸法は、幅と高さであり、 それぞれx軸（横方向寸法）とy軸（縦方向寸法）に対応します。 抽象寸法はフロー相対と行相対で共通なので、用語セットは1つのみです。

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

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」のような指定に対応するための行相対「上」「下」だけでなく、text-align: leftのような指定に対応する行相対「左」「右」も必要です。 したがって、行相対方向は行方向に対して次のように定義されます：

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のレイアウト計算は「サイズ決定フェーズ」と「配置フェーズ」に分かれます：

• サイズ決定フェーズ（幅・高さの計算）では、ボックス・包含ブロックの寸法をinline sizeとblock sizeにマッピングし、直交フローを確立するボックスの書き方モードで計算します。
• 配置フェーズ（オフセット・マージン・ボーダー・パディングの計算）では、ボックス・包含ブロックの寸法をinline sizeとblock sizeにマッピングし、直交フローを確立するボックスの包含ブロックの書き方モードで計算します。

autoマージンは包含ブロックの書き方モードに合わせて解決されるため、直交フローを確立するボックスも、サイズ決定後は他のブロックレベルボックス同様autoマージンで包含ブロック内で整列・中央寄せできます。

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

CSSでは、包含ブロックに明確なインラインサイズがあり、 明確なブロックサイズがない状況が一般的です。 これは通常、CSS2.1で包含ブロックの高さがautoの場合です。 例えば、幅は10.3.3の計算で決まり、 ブロックサイズは内容によって決まります。 このような場合、利用可能なインライン空間は 包含ブロックのインラインサイズとなり、 利用可能なブロック空間（通常は包含ブロックのブロックサイズ）は無限になります。

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

• 包含ブロックの内部最大サイズ（固定されていれば） を内部最小サイズ（固定されていれば）で下限
• 最も近い祖先スクロールポートの内部サイズ（固定されていれば）、 それ以外は内部最大サイズ（固定されていれば）で上限、 内部最小サイズ（固定されていれば）で下限
• 初期包含ブロックのサイズ

CSSのサイズ用語や概念の詳細は[css-sizing-3]を参照してください。

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

インライン軸の自動サイズは、 ブロックレベルまたはブロックコンテナの直交フロー（preferred size propertyがautoの場合に使われるサイズ）は、 fit-content sizeで計算されます。すなわち min(max-content inline size, max(min-content inline size, stretch-fit inline size) となります。 stretch-fit inline sizeの計算に使う利用可能な空間は、包含ブロックのサイズが明確な場合はそのサイズ、 そうでなければフォールバックサイズ（上記参照）となります。

直交自動サイズ調整は、直交マルチカラムコンテナ（両軸）、および上記以外のdisplay型については本仕様では定義しません。

注: 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マージンです。

マージン相殺ルールは、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. 純粋な物理マッピング

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

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

8. 主要書き方モード

文書の主要書き方モードは、 ルート要素のusedwriting-mode、direction、text-orientation値によって決まります。 この書き方モードは、例えばスクロール方向やデフォルトのページ進行方向を決定する際に使われます。

HTML文書の特例として、 ルート要素にbody子要素 [HTML] がある場合、 ルート要素のwriting-modeおよびdirectionプロパティのused値は、 ルート要素自身の値ではなく、最初のその子要素の算出computedのwriting-modeとdirectionから取得します。 UAはtext-orientation値も同様に伝播しても構いません。 なお、この方法はルート要素自身のwriting-mode、direction、text-orientationの算出値には影響しません。

注:伝播は算出値ではなくused値で行われます。これは、継承、論理プロパティマッピングロジック、 長さ値の計算など、他のスタイル計算に影響を及ぼさないようにするためです。

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でテキストを合成する場合、 合成テキストのグリフはbidi-isolateとなり、横方向に合成されます （letter-spacingや強制改行は無視しますが、指定されたフォント設定は使います）。 これは、inline-blockボックスの内容を横書きモード、line-heightは1emとして扱うのと似ています。 合成テキストに含まれる文書の空白の処理はこのレベルでは定義されていません。 合成結果のサイズは1em四方とみなし、四方からはみ出た部分はレイアウト計算に含めません。 UAはグリフを1em四方内で水平・垂直方向に中央揃えするべきです。

合成結果のベースラインは、親インラインボックスのtext-overとtext-underベースライン間で1em四方が中央揃えになるように選択しなければなりません（vertical-alignによるベースライン整列シフト前）。 双方向並べ替え処理では、合成はtypographic character unitでtext-orientation: uprightとして扱われます。 合成の前後での改行処理は、実際の内容を持つ通常のインラインと同様に扱われます。 その他のテキストレイアウト（圏点、text-decoration、間隔など）では、 合成結果はObject Replacement Character 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に圧縮する際に組版色を保つため、合成テキストが2文字以上の場合、 全角typographic character unitは まず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でテキストを合成する場合、 合成テキストのグリフはbidi-isolateとなり、横方向に合成（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以降の変更点

• 直交フローの自動サイズ決定規則をshrink-wrap対応強化。
• sideways-leftとsideways-right値（text-orientation）を削除、sidewaysをsideways-rightと同様動作に再定義、sideways-lrおよびsideways-rl値を非縦書き系用に追加。 (詳細は discussion)
• use-glyph-orientation値（text-orientation）を削除し、glyph-orientation-verticalをCSSエイリアス仕様に従いtext-orientationのエイリアスとして定義（例：page-break-inside）。
• glyph-orientation-verticalで整数degree対応を追加（SVG後方互換対応）。
• run-inボックス記述を削除（CSS2.1から削除済み、CSS Display Level 3で大幅に異なるため）。全display型一般化記述に置換し、用語も[CSS-DISPLAY-3]基準に更新。
• 主要書き方モードの算出値を伝播（body子要素→初期包含ブロック）。
• caption-sideプロパティをフロー相対マッピング対応に変更。
• SVGのwriting-mode値が新しい等価値に算出されることを明記。
• writing-modeはruby base containersおよびruby annotation containersには適用されないことを明記。
• 編集上の改善と一部機能をat risk指定。

謝辞

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）を使うことで組版可能です。