CSS Writing Modes Module Level 3

概要

CSS3 Writing Modesは左から右(ラテン語やインド語)、右から左(ヘブライ語やアラビア語)、双方向(ラテン語とアラビア語の同時使用)、縦組(アジア言語の文章)のような、世界各国の組方向をサポートするCSSの機能を定義している。

根本的に下から上へ進む文章はこのバージョンでは扱われない。関連する問題は[UTN22] を参照のこと。

この文書の位置づけ

このセクションは、公開時点でのこの文書の位置付けについて述べている。他の文書がこの文書を置き換えることがある。W3Cが現在公開しているリストとテクニカルレポートの最新版は、W3C technical reports index (http://www.w3.org/TR/)で見つけることができる。

Working Draftでの公開は W3Cメンバーの支持を意味するものではない。下書きのドキュメントであり、いつでも更新、他のドキュメントによる置き換えや廃止扱いにされうる。これは、進行中の作業以外のものとしてこのドキュメントを引用することは不適切である。

(アーカイブされている) 公開メーリングリスト www-style@w3.org (参加手順はこちら) をこの仕様の議論に推奨している。eメールを送る際には、サブジェクトに “css3-writing-modes” を追加してほしい。できれば “[css3-writing-modes] …summary of comment…”のように。

このドキュメントはCSS Working Group ( Style Activityの一環)で製作された。

このドキュメントは2004年2月6日のW3C特許ポリシーに従うグループによって製作された。W3Cはグループの成果を結びつけて作られたあらゆる開示特許の公開リストを管理しており、ここには特許開示の指示も含まれている。 本質的な特許請求の範囲に含まれると思われる特許について実際の知識を持っている人は、 W3C特許ポリシーの第6章に従い、情報を公開しなければならない。

以下の機能は抜ける恐れがあるもので、おそらくCRまでには落とされるだろう:

• ‘text-orientation’の‘use-glyph-orientation’
• ‘text-combine-horizontal’の値である ‘ascii-digits’, ‘digits’, ‘alpha’, ‘latin’, そして ‘alphanumeric’
• ‘text-combine-mode’ プロパティ

目次

• 1. Writing Modesの紹介
  • 1.1. モジュールの関係
  • 1.2. 値について
• 2. 字詰め方向と双方向性
  • 2.1. 方向の指定: ‘direction’ プロパティ
  • 2.2. 埋め込みと上書き: ‘unicode-bidi’ プロパティ
  • 2.3. 双方向テキストの例
  • 2.4. 双方向文中にあるインライン要素のためのボックスモデル
• 3. 縦書きの導入
  • 3.1. 行送り方向: ‘writing-mode’ プロパティ
    • 3.1.1. SVG1.1 の ‘writing-mode’ の値
• 4. インライン要素の配置
  • 4.1. ベースラインの導入
  • 4.2. テキストのベースライン
  • 4.3. 原子的なインラインベースライン
  • 4.4. ベースラインの配置
• 5. 縦書きテキストレイアウトの導入
  • 5.1. テキストの方向: ‘text-orientation’ プロパティ
• 6. 抽象ボックスの用語
  • 6.1. 論理的な次元
  • 6.2. 抽象的で物理的な方向
  • 6.3. 行相対の方向
  • 6.4. 送り相対の方向
  • 6.5. 抽象と物理のマッピング
• 7. 抽象的なボックスレイアウト
  • 7.1. 縦組でのレイアウト原則
  • 7.2. 次元のマッピング
  • 7.3. 送り方向が直行する場合
    • 7.3.1. 送り方向が直交する場合のオートサイジング
    • 7.3.2. 送り方向が直交する場合のマルチカラムレイアウト
    • 7.3.3. 送り方向が直交する場合の改ページ
  • 7.4. 送り相対のマッピング
  • 7.5. 行相対マッピング
  • 7.6. 純粋に物理的なマッピング
  • 7.7. 表題のマッピング: ‘caption-side’ keywords
• 8. Page Flow: ページの進行方向
• 9. グリフの合成
  • 9.1. 縦組での水平合成: ‘text-combine-horizontal’ プロパティ
  • 9.2. 縦組における水平方向グリフのスケーリング: ‘text-combine-mode’ プロパティ
• 変更点
  • May 2011 CSS Writing Modes Module Level 3 WDからの変更点
• 10. 適合性
  • 10.1. 文書規約
  • 10.2. 適合クラス
  • 10.3. 部分的実装
  • 10.4. 実験的実装
  • 10.5. 非実験的実装
  • 10.6. CR より先へ進むための基準
• 謝辞
• 付録 A. 文字とプロパティ
• 付録 B: 双方向変換
• 付録 C: 縦組での合成
• 付録 D: 本質的な次元
  • マルチカラムレイアウトでの本質的サイズ
• 付録 E: HTMLのためのバイダイルール
• 参考文献
  • 引用規格
  • その他参考
• プロパティインデックス

1. Writing Modesの紹介

CSS3 Writing Modesは左から右(ラテン語やインド語)、右から左(ヘブライ語やアラビア語)、双方向(ラテン語とアラビア語の同時使用)、縦書き(アジア言語の文章)のような、世界各国の組方向をサポートするCSSの機能を定義している。

CSSのwriting modeは、‘writing-mode’, ‘direction’, ‘text-orientation’ のプロパティによって決定される。writing modeでは、 inline base direction(字詰め方向:1つの行で、1つの文字から次の文字へと続く方向)と block flow direction(行送り方向:1つの行から次の行へと続く方向)によって定義されている:

ラテン語を基本としたシステムのwriting mode

モンゴル語を基本としたシステムのwriting mode

ハン語を基本としたシステムのwriting mode

inline base directionは、両端に開始と終了がある行の上に並べられたコンテンツの主方向である。 The ‘direction’ プロパティは要素の字詰め方向を指定し、‘unicode-bidi’ プロパティやテキスト固有の方向とともに、行内のinline-level contentの順序を決定している。

block flow directionは、 ブロックコンテナ内での、ブロックレベルボックスを積む方向や、行ボックスを積む方向である。 ‘writing-mode’ プロパティは行送り方向を決定している。

horizontal writing mode(横書き) はテキストの水平行を持つ。そして上方向や下方向へ行送りする。 vertical writing mode(縦書き) はテキストの垂直行を持つ。そして右方向か左方向へ行送りする。

これらの言葉はvertical block flow (上方向や下方向への行送り)や horizontal block flow (左方向や右方向への行送り)と混同すべきではない。 混乱を避けるため、CSSの仕様ではこの後者の用語セットを用いていない。

Writing systemsは通常1つか2つのnative writing modesを持っている。いくつか例を示す:

• ラテン語を基本としたsystemでは、通常下方向(上から下)の行送り方向で、左から右の字詰め方向を使って書かれている。
• アラビア語を基本としたsystemでは、通常下方向(上から下)の行送り方向で、右から左の字詰め方向を使って書かれている。
• モンゴル語を基本としたsystemでは、通常右方向(左から右)の行送り方向で、上から下の字詰め方向を使って書かれている。
• ハン語を基本としたsystemでは、一般的に下方向(上から下)の行送り方向で、左から右の字詰め方向 か、左方向(右から左)の行送り方向で、上から下の字詰め方向を使って書かれている。 多くの雑誌と新聞は、同一ページにこれら2つのwriting modeを合わせて使うことになるだろう。

writing modeの ‘text-orientation’ コンポーネントは、 line orientation と typesetting modeを決定し、glyph orientation のようなテキストレイアウトの詳細を制御している。

writing modeとvertical textのさらに深い導入は、Unicode Technical Note #22 [UTN22] (HTML version)を参照のこと。

1.1. モジュールの関係

このモジュールは[CSS21]のセクション8.6と9.10で定義されている ‘unicode-bidi’ と ‘direction’ の機能を置き換え、拡張する。

1.2. 値について

本仕様は[CSS21]に書かれたCSS property definition conventions(CSSプロパティの定義規則)に従っている。 本仕様で定義されていない値の型は、CSS Level 2 Revision 1[CSS21]で定義されている。[CSS3COLOR]を例に挙げると、このモジュールを組み合わせて使うと、本仕様の中でも <color> の値の型の定義が拡張される。

これらの定義にリストアップされたプロパティの固有値に加えて、本仕様で定義されている全プロパティでも、これらのプロパティの値のように inherit keyword(キーワード継承)を受け入れる。読みやすさを考慮して、本件は明示的に繰り返さない。

2. 字詰め方向と双方向性

ほとんどの文字が左から右に書かれている一方で、いくつかの文字は右から左に書かれている。一部の文章、特にアラビア語かヘブライ語の文字で書かれ、その中に複数言語が混在する文脈があると、単一の(視覚的に表示された)ブロック内のテキストで複数方向が混在することがある。この現象はbidirectionality(双方向性), もしくは短く "bidi(バイダイ)"と呼ばれる。

Unicode standard (Unicode Standard Annex #9) では、双方向テキストの適切な方向を決定するための複雑なアルゴリズムを定義している。このアルゴリズムは文字のプロパティの他に、埋め込みや上書きの明確なコントロールに基づいた暗黙的な部分で構成されている。CSSは適切な双方向レンダリングを実現するために、このアルゴリズムを頼りにしている。 ‘direction’ と ‘unicode-bidi’ のプロパティは、作者にドキュメント言語の要素と属性を、このアルゴリズムとどうマッピングするか指定できるようにしている。

双方向性をもったテキストをサポートするユーザーエージェントは、強制 (bidi class B) 改行かブロック境界で中断されない全てのインラインボックスの配列に対しUnicode双方向アルゴリズムを適用しなくてはならない。この配列は双方向アルゴリズムでのparagraph(段落)単位を形成する。

‘unicode-bidi’の‘plaintext’が有効な場合を除き、段落埋め込みレベルはUnicodeアルゴリズムのP2とP3にあるヒューリスティックに得られたものよりも、むしろ段落中要素の‘direction’プロパティの値に応じて設定されている。通常、段落中要素は包含ブロックであるが、isolation(分離した)バイダイを含む段落では、分離したインライン要素がその代わりとなる。

テキストの書字方向が文章の構造と意味に依存していることから、ほとんどの場合 ‘direction’と‘unicode-bidi’のプロパティは、マークアップ中でのバイダイ情報と、適合するCSSスタイルとを割り当てるべきである。ドキュメント言語がバイダイをコントロールするマークアップ機能を提供するのであれば、作者とユーザーはそれらの機能を使うべきであり、これらを上書きするCSSのルールを指定すべきではない。

HTML 4の仕様 ([HTML401], section 8.2) では、双方向性はHTML要素のふるまいであると定義している。HTML4の仕様には双方向性における問題の詳細情報が含まれている。

HTMLのユーザーエージェントがCSSのスタイル機能をOFFにすることができるので、スタイルシートが無い状態でも正しい双方向レイアウトを保証するため、我々はHTML作者に‘dir’属性と<bdo> 要素を使うよう忠告している。

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

このプロパティはテキストと行内の要素の書字方向、Unicode双方向アルゴリズムで使われる埋め込みと上書き (‘unicode-bidi’を参照) の方向を指定している。加えて、table(表)の行レイアウト順序、水平overflow(はみ出し)の方向、行内のテキストのデフォルトの並べ方、他に字詰めの基本方向に依存するものに作用している。

このプロパティの値の意味を以下に示す:

ltr

左から右の方向になる。

rtl

右から左の方向になる。

‘direction’プロパティは、‘unicode-bidi’ プロパティの値が ‘normal’であるインライン要素に指定されたバイダイの並び替えには何の影響も与えない。

ルート要素の‘direction’プロパティの値も初期包含ブロックへ伝搬され、‘writing-mode’プロパティの値と共にドキュメント全体の基本となる組方向を決定する (こちらを参照)。

注: HTML BODY要素の‘direction’プロパティはビューポート(コンテンツが表示される領域)に伝搬されない。この特殊な振る舞いはbackgroundとoverflowのプロパティにのみ適用される。

表のcolumn要素に指定された‘direction’ プロパティは、ドキュメントツリーにおいて列がセルの祖先でないため、列内のセルへは継承されない。このように、CSSは[HTML401]のsection 11.3.2.1.に書かれている "dir" 属性の継承ルールを簡単に取得することができない。

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

このプロパティの値の意味を以下に示す。

normal

この要素は、双方向アルゴリズムに関してはレベルを追加する埋め込み(入れ子)を受け入れない。インライン要素だと、暗黙の並び替えは要素の境界を越えて作用する。

embed

インライン要素なら、この値は双方向アルゴリズムに関してレベルを追加する埋め込み(入れ子)を受け入れる。この埋め込んだレベルの方向は‘direction’プロパティにより与えられる。要素の中では、並び替えは暗黙で行われる。これは、要素の始めだと、‘direction: ltr’に対しては LRE (U+202A)か、‘direction: rtl’に対しては RLE (U+202B)の追加に相当し、要素の終わりでは、 PDF (U+202C) の追加に相当する。この値はインライン要素でない場合、何の影響も及ぼさない。

isolate

Unicode双方向アルゴリズムのために、要素のコンテンツは、分離・独立し、‘direction’プロパティによって書字方向が指定された段落の中にあるとされている。 そして(もし、あれば)バイダイ段落を含むバイダイ解決のために、要素自身がObject Replacement Character (U+FFFC) のように扱われる。(要素が複数行にわたって改行された場合、要素の各ボックスはObject Replacement Characterとして扱われる。)

bidi-override

インライン要素に対しては、この値は上書きを実現する。ブロックコンテナ要素に対しては、この値はその他のブロックコンテナ要素ではなく、そのインラインレベルの子孫への上書きを実現する。これは、要素の中においては、並び替えが‘direction’ プロパティに従った順序に厳密であることを意味しており、双方向アルゴリズムの暗黙の部分は無視される。これは、要素の始めでは、‘direction: ltr’ に対しては LRO (U+202D)が、‘direction: rtl’ に対しては RLO (U+202E)の追加に相当し、要素の終わりでは PDF (U+202C) の追加に相当する。

plaintext

Unicode双方向アルゴリズムのために、要素が包含ブロックを形成するためにあるバイダイ段落の書字方向は、通常、要素が計算した‘direction’では決定されない。しかし、ヒューリスティックなUnicodeアルゴリズムのルールP2とP3には従う。インライン要素では、ブロックコンテナを除き、この値は ‘isolate’と同様に振る舞う。字詰め方向は‘direction’の値ではなく、Unicodeのヒューリスティックなものを用いて決定される。

各バイダイ段落の中にある文字の最終的な順序は、上記のようにバイダイのコントロールコードが埋め込まれているものと同じであり、マークアップは削除されており、結果として得られる文字の順序は、スタイル付きテキストと同じ改行が生成されたplain text用のUnicode双方向アルゴリズム実装に渡されている。

このプロセスでは、‘unicode-bidi’プロパティが‘normal’以外の値、つまり要素に指定された‘direction’で強い文字(文字自身に方向を持つ)として扱われるような場合を除き、‘display:inline’で置換される要素はニュートラルな文字(右から左でも、左から右でも使用できる文字)として扱われる。他のアトミックなインラインレベルボックスは全て常にニュートラルな文字として扱われる。

インライン要素がバイダイ段落境界の周辺で分解された場合(例えば、ブロックや強制段落改行により分離された場合)、要素の終わりに相当するバイダイのコントロールコードは分解箇所の前に追加され、要素の開始に相当するコントロールコードは分解箇所の後ろに追加される。(言い換えれば、要素のどんな追加レベルや上書きも、段落改行で閉じられ、もう一方で再び開く。)

Unicodeアルゴリズムは追加レベルの制限が 61レベルであるため、適切な場合を除き、値が‘normal’以外の‘unicode-bidi’プロパティを使わないよう注意すること。 特に値が‘inherit’の場合は注意を払うこと。しかし、しかし、一般的に、ブロックとしての表示を意図している要素は、displayをinlineに変更しつつ、要素を維持するため‘unicode-bidi: isolate’ とするのが好ましい。(以下のサンプルを参照)

2.3. 双方向テキストの例

双方向テキストのXMLを使ったXMLドキュメントの例を以下に示す。これは重要な設計原理を説明している。ドキュメント言語の設計者は言語の適正さ(要素と属性)と添付されたスタイルシートの双方で、バイダイを考慮に入れるべきである。スタイルシートはバイダイのルールがスタイルのルールと分離されるように、またドキュメント言語のバイダイの振る舞いが保護されるよう、記述したルールが他のスタイルシートで上書きされないように設計されるべきである。

<HEBREW>
  <PAR>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</PAR>
  <PAR>HEBREW6 <EMPH>HEBREW7</EMPH> HEBREW8</PAR>
</HEBREW>
<ENGLISH>
  <PAR>english9 english10 english11 HEBREW12 HEBREW13</PAR>
  <PAR>english14 english15 english16</PAR>
  <PAR>english17 <HE-QUO>HEBREW18 english19 HEBREW20</HE-QUO></PAR>
</ENGLISH>
    

/* Rules for bidi */
HEBREW, HE-QUO  {direction: rtl; unicode-bidi: embed;}
ENGLISH         {direction: ltr; unicode-bidi: embed;} 

/* Rules for presentation */
HEBREW, ENGLISH, PAR  {display: block;}
EMPH                  {font-weight: bold;}
    

               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. 双方向文中にあるインライン要素のためのボックスモデル

バイダイの再配置は論理的に連続しているテキストを分割して並び替えできるので、双方向テキスト行中のインラインボックスも分割・並び替えされうる。

インラインボックスを同じ方向にフロー(流し込み)できるようにするために(全て左から右か、全て右から左)、匿名のインラインボックスが生成されることに注意すること。

各ラインボックスのために、ユーザーエージェントは各要素に生成されたインラインボックスを取得し、マージン・ボーダー・パディングを表示順序(論理的な順序ではない)に従い描画しなければならない。要素が登場する最初のラインボックスにあるstart-most box(最初のボックス)は、start edge's margin(開始マージン)、border(ボーダー)、padding(パディング)を持つ。要素が登場する最後のラインボックスにある end-most box(最後のボックス)は、end edge's margin(終了マージン)、 border(ボーダー)、padding(パディング)を持つ。例えば、writing modeプロパティが‘horizontal-tb’の場合:

• 親要素の‘direction’プロパティが‘ltr’なら、要素が登場する最初のラインボックスでは、一番左に生成されたボックスは左マージン、左ボーダー、左パディングを持つ。要素が登場する最後のラインボックスでは、一番右に生成されたボックスは右パディング、右ボーダー、右マージンを持つ。
• 親要素の‘direction’プロパティが‘rtl’なら、素が登場する最初のラインボックスでは、一番右に生成されたボックスは右マージン、右ボーダー、右パディングを持つ。要素が登場する最後のラインボックスでは、一番左に生成されたほとんどのボックスは左パディング、左ボーダー、左マージンを持つ。

これと似たルールが縦組を保っている。

‘box-decoration-break’プロパティは、各ボックス両サイドにて装飾を描画するために、この振る舞いを上書きすることができる。[CSS3BG]

3. 縦書きの導入

この章は参考である。

CSS2.1の双方向テキストサポート拡張に加えて、このモジュールはCSSでの縦書きレイアウトサポートに必要なルールとプロパティを導入している。

主に水平の文字を配置していくラテン系の文字を使用した言語とは違い、中国語や日本語のようなアジア圏の言語は文字を垂直に配置する。下の日本語の例は、同じテキストを水平と垂直それぞれに配置したものである。水平の場合は、テキストは左から右に、そして上から下へ読まれる。垂直の場合は、テキストは上から下へ、そして右から左へ読まれる。左から右へ進む水平の場合における左端からのインデントは、上から下へ進む垂直の場合に変換すると、上端からのインデントになる。

中国語と日本語の行は右から左、もしくは上から下へ並べられる。しかしモンゴル語と満州語は左から右へ並べられる。

横書きから縦書きへの変更による影響はレイアウトだけではない。組版にも影響を与えている。例えば、spacing boxに含まれる句読点は横書きから縦書きへ変更することができるが、その場合は違うグリフが使われることがある。

ラテン文字や、その他普通は横書きされる文字のテキストを含む縦書きのテキストは、その横書きされるテキストを様々な方法で表示することができる。例えば、ラテン文字を横向きに回転させたり、各文字を上向きに並べることができる:

日付の2桁数字のような特殊なケースでは、テキストが縦書き一文字分のキャラクターボックスにぴったり詰めこまれる:

レイアウトにはよく縦書きと横書きの要素が混ざったものがある:

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

3.1. 行送り方向: ‘writing-mode’ プロパティ

このプロパティは行送り方向を設定する。指定可能な値は以下:

horizontal-tb

行送り方向は上から下。横書き。

vertical-rl

行送り方向は右から左。縦書き。

vertical-lr

行送り方向は左から右。縦書き。

The ‘writing-mode’プロパティは行送り方向を決定している。これがブロック書式付けコンテキストにあるブロックレベルボックスの進行を決定している。インラインを含むブロックコンテナのラインボックスの進行と、表の行の進行である。ラインボックスを積む方向が決定されるおかげで、 ‘writing-mode’プロパティは、このようにラインボックスが横組なのか縦組なのかも決定している。

‘writing-mode’プロパティは ‘direction’プロパティと共にroot要素に設定されると、ドキュメント全体のprincipal writing mode(基本となる組方向)を決定する。 この組方向は、基本となるページ進行方向を決定したりする。([CSS3PAGE]を参照) root要素の ‘writing-mode’ の値は初期包含ブロックにも伝播し、初期ブロック書式付けコンテキストの行送り方向を設定している。

HTML BODY要素の‘writing-mode’プロパティはビューポートに伝播されないことに注意すること。この特別な振る舞いはbackground と overflow プロパティにのみ適用される。

もし要素がその包含ブロックと異なる行送り方向を持っていた場合は:

• その要素が ‘display’ を ‘inline’ にしているのなら、その ‘display’ は ‘inline-block’ となる。 [CSS21]
• その要素が ‘display’ を ‘run-in’ にしているのなら、その ‘display’ は ‘block’ となる。 [CSS21]

そのような要素がブロックコンテナの場合、新しいブロック書式付けコンテキストを作り出す。

置き換えられた要素のコンテンツはwriting modeによって回転しない。例では、imageは直立したままである。しかし、ユーザーエージェントがコンテンツを置換する縦書きをサポートしていた場合は、テキストを含む要素(MathMLやform要素など)の置き換えは、置き換えられた要素の組方向と行の向きに一致しなければならない。

<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>

::marker { writing-mode: horizontal-tb;
            vertical-align: text-top;
            color: blue; }

3.1.1. SVG1.1 の ‘writing-mode’ の値

SVG1.1 [SVG11] ではいくつかの値が追加で定義されている: ‘lr’, ‘lr-tb’, ‘rl’, ‘rl-tb’, ‘tb’, ‘tb-rl’である。

これらの値は、SVG1の文章を除くコンテキストでは 非推奨とされている。CSSのコンテキストでこれらをサポートする実装は,その値を次の表のように扱う必要がある:

SVG1.1の値は、CSS ‘writing-mode’の以前のリビジョンに存在していて、本仕様で廃止された。以前のリビジョンに存在していた値 ‘tb-lr’ は、‘vertical-lr’に置き換えられる。

SVG1.1では、これらの値がinline progression direction(行内の進行方向)を設定している。言い換えると、グリフが追加される度に現在のテキストの位置が進む方向である。これはバイダイの再配置後に起こる幾何学的プロセスなので、 ‘direction’ プロパティ(‘writing-mode’ から独立している)の解釈には何の影響も及ぼさない。(Relationship with bidirectionalityを参照のこと。[SVG11])

このプロセスが "writing-mode: rl" に対して、単にテキストの文字列をシフトさせているのか、それともテキスト中の全グリフ順序を逆にしているのかは、様々な解釈がある。

4. インライン要素の配置

異なる種類のインライン要素コンテンツが同じ行に配置されると、コンテンツのベースラインと ‘vertical-align’ プロパティの設定が、ラインボックスの横軸の中でインライン要素コンテンツをどう配置するかを制御する。この章では、ベースラインがどのようなもので、その見つけ方や、インライン要素の並び方を決定する ‘vertical-align’ プロパティと共にどのように使われるかを述べている。

4.1. Introduction to Baselines

本章は参考である。

A baseline(ベースライン)は、テキストの個々のグリフが配置されたラインボックスのinline axis(インライン軸)に沿ったラインである。ベースラインはフォントのグリフをデザインするガイドになり(例えば、大半のアルファベット文字の底は大抵アルファベットのベースラインと一致している)、また、組版時に異なるフォントやフォントサイズのものとグリフをどう配置するかのガイドにもなる。

異なる表記法は異なるベースラインテーブルを選択する。

うまく構成されたフォントには、フォントデザインの座標空間にある1つ以上のベースラインの位置を示す ベースラインテーブルが含まれている(デザイン座標空間はフォントサイズにより見積もられる)。

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

縦書きテキストと横書きテキストでは、異なるベースラインテーブルが提供されうる。ユーザーエージェントは、縦組では縦組用のテーブルを、横組では他のテーブルを使うべきである。

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

この仕様では、以下のベースラインだけが考慮されている:

alphabetic

通常、alphabetic baselineはラテン大文字グリフの底辺に沿っている。横書きの活版印刷では、優先されるベースラインである。

central

通常、 central baselineは仮想ボディの中心と交わっている。縦書きの活版印刷では、優先されるベースラインである。フォントにこのベースラインが無い場合は、仮想ボディのascender(上端)(over)とdescender(下端)(under)の真ん中であるとみなされる。

将来のCSSモジュールでは、さらに細かいベースラインを扱い、他の優先されるベースラインと配置オプションを選択できるようにする予定である。

4.3. 原子的なインラインベースライン

もし atomic inline(原子的なインライン) (インラインブロックやインラインテーブル、もしくはインライン要素に置き換えられたもの) が自身のベースライン情報を提供出来ない場合は、ユーザーエージェントはこのようにベースラインテーブルを合成する:

alphabetic

alphabetic ベースラインは、under(下) マージン辺にあると仮定される。

central

central ベースラインは、ボックスの under(下) と over(上) のマージン辺の真ん中にあると仮定される。

4.4. ベースラインの配置

CSSでは、dominant baseline(優先ベースライン) (writing modeに基づいて変更可能) の配置時の使われ方は2つのケースがある:

• 同じインラインボックスに異なるフォントのグリフを配置する場合。 グリフは優先ベースラインの位置に合わせて配置される。
• 親の中に子のinline-level boxを配置する場合。‘baseline’の値が‘vertical-align’なら、子は親の箇所に、親の優先ベースラインと子の同じベースラインを一致させ配置される(例えば、親の優先ベースラインがalphabeticの場合、子の優先ベースラインが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) )はフォントサイズが異なるため一致しない。優先ベースラインがalphabeticベースラインなので、子のボックスは親のalphabeticベースラインに合わせて配置される。

  

  上の例で、 ‘vertical-align: super’ を .inner の要素に適用した場合、親と同じ配置ルールが子の .inner にも使われる。唯一の違いは、ベースラインの配置に加えて、子が上付き文字の位置にシフトされることである。

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

  

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

どの筆記体型にも本来のテキストの方向が1つ以上ある。ゆえに、近代の書記方法はテキストの方向について3つに分類することができる:

horizontal-only(水平のみ)

本来のテキストの方向は水平のみであり、垂直はない。ラテン文字、アラビア文字、ヘブライ文字、デーヴァナーガリが該当する。

vertical-only(垂直のみ)

本来のテキストの方向は垂直のみであり、水平はない。モンゴル文字、パスパ文字が該当する。

bi-orientational(水平と垂直の両方向)

本来のテキスト方向として垂直と水平の両方がある。ハン語の文字、ハングル文字、日本語のかな文字が該当する。

近代の組版では、全グリフが水平方向に配置される。これはテキストを水平に配置するときに使われている。テキストを垂直に配置するためには、ユーザエージェントはテキストを水平方向から変換する必要がある。この変換はbi-orientational transform(bi-orientationalにおける変換)であり、2つのタイプがある:

rotate

水平から垂直にグリフを回転する

translate

水平から垂直にグリフを変換する

本来のテキスト方向として縦方向を持つ書記方法には固有のbi-orientational変換があり、それは縦書きでの方向を訂正する。例えばCJK(中国/日本/韓国)の文字変換があり、文字は常に直立状態にされる。モンゴル文字等の他の書記方法では回転させる。(固有の両方向変換は付録Bを参照)

本来のテキスト方向として縦方向を持たない書記方法は、回転(横倒しにセットされる)か変換(直立状態にセットされる)のどちらも可能である。使用される変換は、正しさよりはむしろテキストの使われ方に応じたスタイルが優先される。‘text-orientation’ プロパティの ‘upright-right’ と ‘upright’ の値は、水平のみのテキストを回転するのか、それとも変換するのかを指定するために用意されている。

‘text-orientation’ の値である ‘sideways-left’, ‘sideways-right’, ‘sideways’ は装飾的なレイアウト効果のために、そして下から上へよむ文章のCSSサポート制限を回避するために提供されている。

理想的には、句読点は主要な書記方法が水平のみか垂直かに応じて、横倒しか直立状態にとなるべきである。しかし、この情報(書字方向のようなコンテンツのプロパティ)を我々は利用できない(縦書きのコンセプトが使われているUTN 22では、この問題に対応すべく、‘direction’ 経由やHTMLの dir 属性で情報が与えられる)。現在の仕様では、East Asian Widthプロパティを使うことで問題に対処している。しかし、このアプローチは縦書きの書記方法が横書きのみの書記方向と句読点を共有していない場合しか有効でない。

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

このプロパティは行中の文字の向きを指定し、行の向きを設定する。現在の値はvertical writing modeの時のみ有効である。

読みやすさを考慮し、本章ではcharacter(文字)という言葉を extended grapheme cluster(書記素クラスタ) の意味で使用する。Characters and Propertiesに詳細が記述されている。

この値の意味を以下に示す:

upright-right

縦書きでは、horizontal-onlyの表記方法で使われていた文字は横倒しになる。言い換えると、横書きの一般的な文字の向きから90度時計回りに回転される。

縦書きでは、この値はvertical typographic modeの要素に設定され、これが縦書きの表記方法の主要なレイアウトの典型例となる。

upright

縦書きでは、horizontal-onlyの表記方法で使われていた文字は直立状態となる。言い換えると、これは横書きの一般的な文字の向きでである。これらの表記方法からの文字整形は孤立した形となる。垂直の表記方法で使われている文字はそれ固有の文字方向に設定され、形も普通である。可能であれば、縦書き用グリフと縦書きフォントのメトリクスがテキストに設定される。ユーザーエージェントは何も持たない書記素クラスタのために、縦書き用フォントのメトリクスを合成しなければならない。

バイダイの再配置のために、この値は全ての文字をstrong LTRとして扱わせている。この値は、‘direction’ の値 ‘ltr’ が使われる原因となっている。

縦書きでは、この値はvertical typographic modeの要素に設定される。

sideways-right

縦書きでは、この値はテキストを水平レイアウト(横書き用グリフとメトリクスを使用する)にセットするが、時計回りに90度回転される。この値は horizontal typographic modeの要素に設定される。

sideways-left

縦書きでは、この値はテキストを水平レイアウト(横書き用グリフとメトリクスを使用する)にセットするが、反時計回りに90度回転される。この値はhorizontal typographic modeの要素に設定される。

親が ‘sideways-left’ でないものがインライン非置換要素に設定された場合は、bidi isolationが強制される: ‘unicode-bidi’ の値が ‘normal’ と ‘embed’ なら、算出値は ‘isolate’ となり、‘bidi-override’ なら算出値は ‘bidi-override isolate’ となる。インラインの先祖(ブロックコンテナのルートインラインを含む)から伝播したテキスト装飾の位置は鏡像関係にならないが、要素によって導入されたテキスト装飾には鏡像関係となったベースラインテーブルを用いて位置付けが行われる。

同様に、要素のインライン子要素の ‘text-orientation’ の値が ‘sideways-left’ 以外であった場合、相似の変換(そしてbidi isolation)が適用される。

sideways

この値はwriting modeが ‘vertical-rl’ の場合に ‘sideways-right’ を指定したとき、またwriting modeが ‘vertical-lr’ の場合に ‘sideways-left’ を指定したときと同じである。横組のみのドキュメントを縦組にするときに役立つ。

use-glyph-orientation

[SVG11] ではテキストの方向をコントロールすることを目的とした ‘glyph-orientation-vertical’ プロパティと ‘glyph-orientation-horizontal’ プロパティを定義している。これらのプロパティは非推奨とされており、非SVGエレメントには適用されない。実装がこれらのプロパティをサポートしている場合、SVG要素に ‘use-glyph-orientation’ が設定されると、SVGの ‘glyph-orientation-vertical’ プロパティと ‘glyph-orientation-horizontal’ プロパティがテキストのレイアウトをコントロールする。これらを実装したユーザーエージェントは、SVG用のデフォルトユーザーエージェントスタイルシートとして、 ‘text-orientation: glyph-orientation’ を全てのSVGテキストコンテンツ要素に設定しなければならない。

その他全てのコンテンツと、glyph orientation プロパティをサポートしていない実装においては、‘use-glyph-orientation’ は ‘upright-right’ と同様に振る舞う。

この値は抜ける恐れがあるもので、おそらくCRまでには落とされるだろう。

‘upright-right’	‘upright’	‘sideways-left’	‘sideways-right’

‘text-orientation’ の値 (‘writing-mode’ が ‘vertical-rl’ の場合)

一般的なもの、継承されたもの、未知のカテゴリの文章に属する文字の向きはAppendix Cに定義されている。このルールに対するフィードバックを募集しています

フォントのデータに依存しない全ユニコード文字の向きに関する定義の明快な標準定義が必要である。

横組のみのドキュメントのルート要素に、 ‘sideways’ が設定された例を以下に示す。制作者はテキストが ‘vertical-rl’ か ‘vertical-lr’ かを気にすることなく、ドキュメントの ‘writing-mode’ を適切に設定することができる。

      :root { text-orientation: sideways; }
      caption { caption-side: left; writing-mode: vertical-lr; }
      thead th { writing-mode: vertical-lr; }
      h1.banner { position: absolute; top: 0; right: 0; writing-mode: vertical-rl; }
    

6. 抽象ボックスの用語

[CSS21] では、ボックスレイアウトモデルが詳細に定義されている。しかし、writing modeが ‘horizontal-tb’ の場合しか定義していない。方向と次元を抽象的かつ適当に置き換えていれば、‘horizontal-tb’ 以外のwriting modeでのCSSボックスレイアウトはCSS2.1のボックスレイアウトと似たものになる。本章では他のwriting mode用ボックスレイアウトを定義するために抽象的な方向と次元の用語、そしてそれらのマッピングを定義し、レイアウトの概念を抽象化する将来の機能のための用語を提供する。

6.1. 論理的な次元

block flow dimension

行のテキスト送り方向に垂直な次元で、横組ではvertical dimension(垂直方向の次元)、縦組ではhorizontal dimension(水平方向の次元)となる。

inline dimension

行のテキスト送り方向に水平な次元で、横組ではhorizontal dimension(水平方向の次元)、縦組ではvertical dimension(垂直方向の次元)となる。

inline-axis

block flow dimensionの軸。例えば、横組ではvertical axis(垂直軸)であり、縦組ではhorizontal axis(水平軸)となる。

block-axis

inline dimensionの軸。例えば、横組ではhorizontal axis(水平軸)であり、縦組ではvertical axis(垂直軸)となる。

extent or logical height

block flow dimensionの寸法で、横組みでは物理的な高さ(vertical dimension)を参照し、縦組みでは物理的な幅(horizontal dimension)を参照する。

measure or logical width

inline dimensionの寸法で、横組みでは物理的な幅(horizontal dimension)を参照し、縦組みでは物理的な高さ(vertical dimension)を参照する。(measure という用語は typography の用語に由来する)

6.2. 抽象的で物理的な方向

left, right, top, and bottom という用語は、例えばページとは独立した組方向に対しても、常に物理的に解釈される。2つの抽象的なマッピングはこれらの方向を可能にする。line-relativeとflow-relativeである。定義を以下に示す。

これらの用語はテキストの振る舞いに由来するが、これらの方向を表す言葉はラインボックスを全く含まないボックスのためにも存在している。これらは ‘writing-mode’ プロパティ、‘text-orientation’ プロパティ、‘direction’ プロパティの値から直接算出される。

6.3. 行相対の方向

‘writing-mode’ により決まる行送り方向は、行の方向が水平か垂直かを決定するが、それは行内のコンテンツがどう配置されるかについて何も決定していない。

line-relative directions にはover, under, line-left, line-rightがある。 ‘text-orientation’ と ‘writing-mode’との組み合わせから得られる line orientationは、行のどちら側が "top" であるかを決定する。よって、行のunder (ascender側)と over (descender側)が決まる。行の方向は行の横軸における配置(‘vertical-align’)に影響する。

行の方向が垂直であるline boxには、over と under に加え、"left" と "right" がある。それらがボックスの端である line-left と line-right である(行の物理的な左側と右側とは異なる)。ボックスの line-left の端は名目上 LTR のテキストが開始される端となっている。ボックスの line-right の端は名目上 RTL のテキストが開始される端となっている。 ‘writing-mode’ プロパティと ‘text-orientation’ プロパティによって、ボックスのline-left側は物理的な左、上、下となりうる。

行方向のコンパス

縦組の典型的な方向

‘text-orientation: sideways-left’ のときの行方向

over と under の directions はよく before と after を同じ方向にマッピングするが、そのマッピングは ‘writing-mode’ と ‘text-orientation’ の組み合わせによって逆になることに注意すること。

6.4. 送り相対の方向

flow-relative directions(送り相対の方向) は before, after, start, endからなる。LTR ‘でwriting modeが horizontal-tb’ であれば、対応するdirectionはそれぞれtop、bottom、left、rightとなる。

ボックスの before の端は、名目上ブロック進行の手前の端になり、‘writing-mode’ プロパティで決定される。同様に after の端はブロック進行の後ろ端になる。

ボックスの start の端は、名目上テキストの字詰めが始まる端になる。‘direction’ の値が ‘ltr’であるボックスでは、line-left の端になる。‘direction’ の値が ‘rtl’であるボックスでは、line-right の端になる。startの端と向かい合わせが end の端になる。

‘writing-mode’ プロパティだけに依存してボックスの before と after を決定しているが、ボックスの start と end の端は ‘writing-mode’ プロパティだけでなく ‘direction’ プロパティと ‘text-orientation’ プロパティにも依存していることに注意すること。

                  <----- width / measure  ----->

                             top side/
                            before side
                  +------------------------------+                  A
      left side/  |   ---inline direction --->   |  right side/     |
      start side  |  |                           |  end side        |
                  |  | block      * horizontal * |                height/
                  |  | direction  *writing mode* |                extent
                  |  V                           |                  |
                  +------------------------------+                  V
                             bottom side/
                              after side
    

                  <----- width / extent ------>

                             top side/
                            start side
                  +------------------------------+                  A
      left side/  |    <---block direction---    |  right side/     |
      after side  |                           |  |  before side     |
                  |  *  vertical  *     inline|  |                height/
                  |  *writing mode*  direction|  |                measure
                  |                           V  |                  |
                  +------------------------------+                  V
                            bottom side/
                             end side
    

6.5. 抽象と物理のマッピング

抽象と物理をマッピングし要約した表を以下に示す:

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

7.1. 縦組でのレイアウト原則

縦組でのCSSボックスレイアウトは横組のレイアウトに似ており、以下に示す原則の概要に従う:

横組にて水平次元に適用されるレイアウトの算出ルール(CSS2.1のSection 10.3のものなど)は、縦組の垂直次元へ適用される。同様に、横組にて垂直次元に適用されるレイアウト算出ルール(CSS2.1のSection 10.6のものなど)は、縦組の水平次元に適用される。従って:

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

• ‘*-left’ と ‘*-right’ のボックスプロパティ(border, margin, padding)を参照するレイアウトルールは、代わりに ‘*-top’ と ‘*-bottom’ を使用する。その逆も同様。ボックスのどちらのサイドのプロパティは、変更せずに適用される。値を入力した側のみレイアウトの算出値が変化する。例えば、‘margin-left’ プロパティはまだ左側のマージンに影響している。しかし、writing modeが ‘vertical-rl’ の場合は ‘margin-bottom’ の代わりにmargin collaspe(マージンの折りたたみ)が発生する。

• 左と右のどちらかを選択する ‘direction’ プロパティに依存するレイアウトルール(例えば、overflow、overconstraint resolution、‘text-align’ の初期値、表の列順序)は、start と end に抽象化されて、適切に適用される。

たとえばテキストの配列、フローティング、リストマーカーの配置のような、主にラインボックスの右側や左側、横方向の平行線を参照するために、topやbottomに相当するものを持っていない機能は、line left と line right を右側と左側としてそれぞれ参照している。

同様に、アンダーライン、オーバーライン、baseline alignment (残念ながら名前は ‘vertical-align’)のような、主にラインボックスの上側や下側、縦方向の水平線を参照するために、左や右に相当するものをもっていない機能は、over と under を上側と下側としてそれぞれ参照している。

マッピングの詳細は以下を参照のこと。

7.2. 次元のマッピング

いくつかのプロパティは以下のように論理的に振る舞う:

• ‘border-spacing’ プロパティの1つめと2つめの値は、それぞれ行と列の間のスペースを表し、水平方向と垂直方向のスペーシングであるとは限らない。[CSS21]
• ‘line-height’ プロパティは常に論理的な高さを参照している。[CSS21]

高さのプロパティ(‘height’, ‘min-height’, ‘max-height’)は物理的な高さを参照しており、幅のプロパティ(‘width’, ‘min-width’, ‘max-width’)は物理的な幅を参照している。しかし、ボックスの次元を算出する際に使われるルールは論理的なものである。

CSS2.1 Section 10.3の算出ルールがインライン次元の寸法に使われている場合、そのルールは寸法(物理的な幅または物理的な高さの場合がある)、開始と終了のマージン、およびborderに適用される。同様に、CSS2.1 Section 10.6の算出ルールがブロック次元の寸法に使われている場合、そのルールは範囲、beforeマージン、afterマージン、パディング、borderに適用される。[CSS21]

当然の結果として、CSS2.1では包含ブロック幅から常に相対的に算出されている、マージンとパディングのプロパティにおけるパーセンテージは、CSS3では包含ブロックの measure(寸法)から相対的に算出されることになる。

7.3. 送り方向が直交する場合

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

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

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

/* HTML dir attribute creates an embedding */
*[dir="ltr"]    { direction: ltr; unicode-bidi: embed; }
*[dir="rtl"]    { direction: rtl; unicode-bidi: embed; }

/* BDO element creates an override */
bdo[dir="ltr"]  { direction: ltr; unicode-bidi: bidi-override; }
bdo[dir="rtl"]  { direction: rtl; unicode-bidi: bidi-override; }

/* HTML4.01:8.2.6 - preserve bidi behavior if 'display' is changed */
html, body,
div, address, blockquote, p,
ul, ol, li, dl, dt, dd,
fieldset, form,
h1, h2, h3, h4, h5, h6,
{ unicode-bidi: isolate; }