摘要

この文書は、CSSのテキストのフォーマット処理のプロパティセットを提供する。CSSの2[CSS2]ですでに存在するものに加えて、多くの新しいプロパティが、国際的なコンテキスト(東アジア言語や双方向言語がほとんど)において、基礎的に必要とするものを扱っている。しかしながら、この用法は、それらの実例によって制限されない。

この文書の地位

この文書はスタイルアクティビティの一部である、CSS策定団体の策定中の草案である。これは、CSSのレベル3に含まれている特徴に対する提案を含む。

この文書はW3Cの国際化の活動と、スタイルアクティビティの協力によって作り出されたものである。また、XSLの策定団体(会員専用)の会員によって製作された、広範な寄稿も含んでいる。最後に、提案の中には、スカラの可能なベクタグラフィックス(SVG)の1.0の仕様で実装されたものもある。結局は、どのようなプロパティや仕様が、CSS自体に引用されるかを反映するために、この文書は複製されてきた。

この草案の旧題は"国際的なレイアウト"であった。

フィードバックは大変ありがたい。コメントは編者に直接送ることもできるが、メーリングリストwww-style@w3.org(使用説明書を参照)も開かれていて、本書および、スタイルの範囲のその他の草案の話し合いに対して好まれている。

この策定中の草案は、いつでも、ほかの文書によって更新されたり、置き換えられたり、時代遅れになったりするかもしれない。W3Cの策定中の草案を参考書の資料として使用したり、あるいは、"策定進行中"ではないものとして引用するのは不適当である。この公開は、W3Cの会員の資格やCSS&FP策定団体(会員専用)による保証は含まれない。

この草案の最新版を見つけるには、上方の"最新版"のリンクをたどるか、技術報告の一覧表をたずねてください。

目次

• 1. 他のモジュールへの依存
• 2. 序論
• 3. テキストのレイアウト
  • 3.1. テキストのレイアウトの序論
  • 3.2. 基本のテキストの進行方向の設定:'writing-mode'およびspan class="property">'direction'プロパティ
  • 3.3. テキストの流れの中にある標識の方向:'glyph-orientation-vertical' と'glyph-orientation-horizontal'のプロパティ
  • 3.4. 組み込みと上書き:'unicode-bidi'のプロパティ
  • 3.5. 文字の分類:'script'のプロパティ
• 4. テキストの配置と行そろえ
  • 4.1. テキストの配置:'text-align'のプロパティ
  • 4.2. 行そろえ:'text-justify'のプロパティ
  • 4.3. 最後の行の整列:'text-align-last'のプロパティ'
  • 4.4. 最大と最小のフォントサイズ:'min-font-size'と'max-font-size'のプロパティ
  • 4.5. 付加的な圧縮: The 'text-justify-trim'のプロパティ
  • 4.6. Kashidaの効果:'text-kashida-space'のプロパティ'
• 5. 基準線の整列
  • 5.1. フォントによって提供される基準線の情報
  • 5.2. 基準線の識別子
  • 5.3. 基準線の整列の過程の概観
  • 5.4.もっとも有力な基準線:'dominant-baseline'というプロパティ
  • 5.5. 要素の整列の点の整列:'alignment-baseline'というプロパティ
  • 5.6. 整列の点の設定:'alignment-adjust'というプロパティ
  • 5.7. もっとも有力な基準線の再配置:'baseline-shift'というプロパティ
  • 5.8. 縦の整列:the 'vertical-align'というプロパティ、基準線の整列のプロパティとの関係
• 6. インデント:'text-indent'というプロパティ
• 7. 行分け
  • 7.1. 行分けの種類
  • 7.2. 行分け:'line-break'というプロパティ
  • 7.3. 語分け:'word-break-CJK'、'word-break-wrap', 'word-break-inside'というプロパティと簡略表記法である'word-break'というプロパティ
• 8. テキストの送り込み処理、空白の制御とテキストのあふれ
  • 8.1. 空白のくずし処理:'text-space'というプロパティ
  • 8.2. テキストの送り込み処理:'text-wrap'というプロパティ
  • 8.3. 空白:'white-space'というプロパティ
  • 8.4. テキストのあふれ:'text-overflow-mode', 'text-overflow-ellipsis'というプロパティと簡略表記法の'text-overflow'というプロパティ
• 9. テキストのスペース処理
  • 9.1. 文字のスペース処理:'letter-spacing'というプロパティ
  • 9.2. 単語のスペース処理:'word-spacing'というプロパティ
  • 9.3. 句読点の整理:'punctuation-trim'というプロパティ
  • 9.4. スペースを追加する処理:'text-autospace'というプロパティ
  • 9.5. テキストのカーニング:'kerning-mode'と'kerning-pair-threshold'というプロパティ
• 10. テキストの装飾
  • 10.1. 序論
  • 10.2. 下線の制御:'text-underline-style'、'text-underline-color', 'text-underline-mode'、'text-underline-position'というプロパティと簡略表記法の'text-underline'というプロパティ
  • 10.3. つらくぬ線の制御:'text-line-through-style'、'text-line-through-color'、'text-line-through-mode'、プロパティと簡略表記法の'text-line-through'というプロパティ
  • 10.4. 上線の制御:'text-overline-style'、'text-overline-color', 'text-overline-mode' properties and the shorthand 'text-overline' property
  • 10.5. 下線を引く処理、乗船を引く処理、貫く線を引く処理および明滅する処理:'text-decoration'という簡略表記法のプロパティ
  • 10.6. テキストの影:'text-shadow'というプロパティ
• 11. 文書の格子
  • 11.1. 文書の格子とは何か
  • 11.2. 格子の種類:'layout-grid-type'というプロパティ
  • 11.3. 行の格子の値:'layout-grid-line'というプロパティ
  • 11.4. 文字の格子の値:'layout-grid-char'というプロパティ
  • 11.5. 格子の形態:'layout-grid-mode'というプロパティ
  • 11.6. レイアウトの格子:簡略表記法の'layout-grid'というプロパティ
  • 11.7. 'gd'という長さの単位
• 12. 種種雑多なテキストのフォーマット処理
  • 12.1. 大文字使用:'text-transform'というプロパティ
  • 12.2. 句読点の送り込み:'punctuation-wrap'というプロパティ
  • 12.3. テキストの結合処理:'text-combine'というプロパティ'
• 13. プロパティの索引
• 14. プロフィール
• 15. 用語集
• 付録A:CSSのプロパティに関する縦のレイアウトの効果
• Appendix B: Usage of baseline alignment (informative)
• 謝辞
• 参考文献
• 前の策定中の草案からの変更

1. 他のモジュールへの依存

このCSSのモジュールは以下の他のCSSのモジュールに依存している。

• フォント

以下の他のCSS3のモジュールに、標準を立てるものではない(知識を与えるものである)関連がある。

• TBD

2. 序論

CSS1とCSS2の両方において、テキストのフォーマット処理は、たとえば、テキストの装飾、テキストの配置や、文字のスペース処理のような、単純な効果に限られていた。しかしながら、国際的な印刷の体裁は、特別なワークアラウンドやグラフィックスを使わなければ成しえないフォーマット処理の種類を含んでいる。

既存のテキストに関連したプロパティとともに、この文書は、そのようなフォーマット処理を表現するために、いくらかの新しいCSSのプロパティを提供する。たとえば、この提案が含む特徴の中に、縦書きのテキストや、レイアウトをするときの升目といった、東アジアの印刷の体裁のための、2つの最も重要な特徴がある。

いくつかのイラストレーションに、以下に説明文が用意されている。

-テキストの連続の中でn番目の文字である全角の標識(たとえば、漢字)、
-テキストの連続の中でn番目の標識である半角の標識(たとえばローマ字)、
-テキストの連続の中でn番目の標識であるつながった標識(たとえばアラビア文字)

東アジア言語の印刷の体裁における、多くの印刷上のプロパティは、全角の文字か半角かのどちらか一方として、一般的な方法で描写しているという事実に依存している。ユニコードの標準によって描写されるすべての文字は、幅のプロパティで分類することができる。これは、ユニコードのウェブサイトから入手できるユニコードの技術報告(TR#11)に含まれている。

図表において、上に述べた記号がとる方向は、UAで描写されるときに、表現する標識がとると意図される方向と一致する。図表におけるそれらの文字の間の空白は、故意に点を作るように変えられなければ、たいていは記号である。

3. テキストのレイアウト

3.1. テキストのレイアウトの序論

この項は、左から右へ(たとえば、ローマ字)、右から左へ(たとえば、ヘブライ文字やアラビア文字)、双方向(たとえば、ローマ字をアラビア文字と混在させたもの)や、縦書き(たとえば、アジア文字)のような、さまざまな国際的な文書の方向を含む、CSSでサポートされているテキストのレイアウトの特徴を説明する。

'writing-mode'プロパティは、行中の進行や、ブロックの進行とも呼ばれる行から行への進行を決定する。たとえば、ローマ字は、一般的に左から右へ、また上から下へと書かれる。標識の方向は、基本のテキストの進行方向と関係がある、描写される文字の視覚的な形を決定する。

行中において、現在のテキストの位置の調整は、テキストの進行方向、単に描写される標識の計量、フォントにおけるカーニングの表、現在のスペース処理のプロパティのような、さまざまな属性の現在の値と関係がある、現在の標識の方向に基礎づけられている。

'writing-mode'や、標識の方向の値で、テキストの適切な方向性が、アルゴリズムによって決定されるだろうときに、双方向性は、多くのテキストのレイアウトにおいて、別の水準の複雑さをもたらす。ユニコードの標準([UNICODE]、セクション3.12)は、組み込むための明示的なコントロールと同様に、文字のプロパティに基礎付けられた、明示的な部分からなる、そのようなアルゴリズムを定義し、上書きする。'writing-mode'と'unicode-bidi'プロパティの組み合わせを使って、内容の文字の本来の双方向性を上書きすることも可能である。

CSS3は適切なテキストの双方向の描写を成し遂げるのにこのアルゴリズムに頼る。しかしながら、文字の描写は、標識の方向プロパティの、特定の値に対してのみ起こる。厳密な制約に対するその説明を参照してください。

CSS2は、行中の進行のみを決定する、'writing-mode'プロパティのサブセットである、'direction'プロパティを明示した。'direction'プロパティは行から行への進行の変更が望まれるときに、いまだに使われている。

HTMLの4.0の仕様書([HTML40]、セクション8.2)は、HTMLの要素に対する双方向性の挙動を定義している。それゆえに、仕様に適合しているHTMLのユーザエージェントは、著作者と使用者のスタイルシートにおいて、'direction'と'unicode-bidi'プロパティを無視してもよい。[HTML40]で明示された、双方向の挙動を成し遂げるスタイルシートの規則は、見本のスタイルシートで与えられる。HTMLの4.0の仕様は、双方向性の問題に関する情報もより多く含んでいる。HTMLの4.0は、'writing-mode'プロパティによって説明されるもっと一般的な場合を含んでいない。

最後に、このモジュールは、(一般的な西洋のテキストのレイアウトにおいて、'before'、'after'、'start'と'end'の位置とそれぞれ一致する)'top'、'bottom'、'left'と'right'に関して、絶対的な位置から独立して、テキストの進行方向に関するボックスの四隅を明示する'before'、'after'、'start'と'end'の表記を表記広範囲にわたって用いている。この表記は、同じ目的のために、[XSL]においても広範囲にわたって用いられた。

3.2. 基本のテキストの進行方向の設定:'writing-mode'および'direction'プロパティ

'writing-mode'プロパティは、基本のテキストの進行方向を、左から右へ、右から左へ、あるいは上から下へさせたいかを明示する。(基本のテキストの進行方向が、左から右か右から左のどちらかであったときでも、ユニコード[UNICODE]の双方向のアルゴリズムのために、あるいにこのプロパティや'direction'と'unicode-bidi'の結果上書きする明示的なテキストの進行方向のために、与えられた要素内の内容の一部または全部が、反対の方向に進行するかもしれないことに注意。このプロパティは、要素に対して、'direction'プロパティを変更したりもする。双方向のテキストに関するそれ以上のことには、組み込みと上書きについての項を参照。

lr-tb | lr

ほとんどのローマ字に基礎付けられた文書において普通であるような、左から右への方向に基本のテキストの進行方向を、上から下への方向に行の進行方向を設定する。大部分の文字に対して、現在のテキストの位置はそれぞれの標識が描写された後、左から右へ進む。'direction'プロパティは'ltr'に設定される。

rl-tb | rl

アラビア文字やヘブライ文字において普通であるような、右から左への方向に基本のテキストの進行方向を、上から下への方向に行の進行方向を設定する。directionのプロパティは'rtl'に設定される。

tb-rl | tb

アジア文字において普通であるような、上から下への方向にテキストの進行方向を、右から左への方向に行の進行方向を設定する。基線の配置は、このコンテキストにおいては独特であるかもしれない。一般的に、もっとも有力な基線は、まっすぐな標識の中央を走る。directionのプロパティは'ltr'に設定される。

tb-lr

上から下への方向に基本のテキストの進行方向を、左から右への方向に行の進行方向を設定する。横書きほど頻繁であることはほとんどないが、ラテン語に基礎付けられた文書で、特に表の行や列のラベルで、この種類の縦書きのレイアウトも起こる。基線の配置はこのコンテキストにおいては独特であるかもしれない。一般的に、もっとも有力な基線は、まっすぐな標識の中央を走る。directionのプロパティは'ltr'に設定される。

bt-rl

下から上への方向に基本のテキストの進行方向を、右から左への方向に行の進行方向を設定する。この値は、現行のwriting-modeのプロパティの値が'tb-rl'か'tb'である要素に適用される、方向のプロパティの値'rtl'の場合に含まれるためだけに存在する。directionのプロパティは'rtl'に設定される。

bt-lr

下から上への方向にテキストの進行方向を、左から右への方向に行の進行方向を設定する。この値は、現行のwriting-modeのプロパティの値が、'tb-lr'である要素に適用される、directionのプロパティの値'rtl'の場合に含まれるためだけに存在する。directionのプロパティは'rtl'に設定される。

writing-modeのプロパティによって設定される、基本のテキストの進行方向と、行の進行方向の組み合わせは、流れの方向にも関連している。そのようなコンテキストにおいて、lr-tb、lr、rl-tbやrlという値は、横書きの流れの方向に一致し、その他のもの(tb-rl、tb、tb-lr、bt-rl、bt-lr)は、縦書きの流れの方向に一致する。

横書きの流れの方向に対して、上下の余白は崩されてしまうことがある。縦書きの流れの方向に対して、左右の余白は崩されてしまうことがある。崩れてしまう余白の詳細は、CSS3のボックスのモジュール[公開間近]における、崩れてしまう余白を参照。

このプロパティは表の行のレイアウトの方向、基本のテキストの進行方向と同じように方向付けられるあふれ(たとえば、writing-mode:lr-tbに対しては、ブロックの要素が水平面の右にあふれるだろう)、テキストの配置、そして、'text-align: justify'の場合における、ブロックにおいて完結していない最後の行の位置をも明示する。

以下の条件の一つまたは両方が満たされたときのみ、'writing-mode'のプロパティが、inline-levelの要素に何らかの影響ももたらす。

• 新しいテキストの進行方向が、親の方向と直角を成しているか、
• 要素の中の文字の標識の方向が、'auto'か、縦書きのレイアウトにおいて90/-90度か、横書きのレイアウトにおいて0/180度であり、'unicode-bidi'のプロパティが、'embed'か'bidi-override'である。

その親と違ったwriting-modeの値を持つ、inline-levelの要素は、行中のブロックの要素になる。

編者注:CSS3のボックスのモジュールにおける、'width'と'height'のプロパティの説明は、縦書きの流れの方向のためのアルゴリズムを、より詳細に説明するために更新される必要がある。たとえば、縦書きの流れの方向において、高さは、親の、レイアウトの高さ(引く余白やボーダー)の最小限度や、要素の最適条件の高さより大きくなりうるだろうと予期される。要素の最適条件の高さは、一般的に、10文字の表意文字の'進行の幅'の長さだとして、決定される。この仕組みは、'無限に'長い縦書きの行や、一行だけの縦書きの流れを避けるのに必要とされる。特に、ボックスのモジュールのセクションの7.2は、横書きの流れの要素に含まれる、縦書きの流れの要素に対する、'auto'の場合について議論すべきである。

これが、横書きの流れ(writing-mode:lr-tb)の図表である。

これが、東アジアで使われる縦書きの流れ(writing-mode:tb-lr)のための図表である。

そして最後に、ウイグルとモンゴル語で使われる別の流れ(writing-mode:tb-lr)のための図表である。

東アジアの文書において、次のように、それらの文字列が現れるテキストの行の流れの形態にかかわらず、年の数字のような、あるラテン語に基礎付けられた文字列を、常に横書きのレイアウトの流れの中に、表示するのがよく好まれる:

この効果は"縦中横"として知られている。これを成し遂げるためには、次のように、ラテン語の文字列を、横書きの流れの方向を持っている、SPANの要素のなかに囲むべきである。

<span STYLE="writing-mode: lr-tb">1996</span>

これは、より初めのころに説明されたものであるが、行中の要素の流れの変化を適用するものである。改行は、テキストのそのような流れのために、通常無効にされる。CSSの'white-space: nowrap'の設定を使って、これを成し遂げることができる。

このプロパティに対する値は以下の意味を持っている。

ltr

左から右への方向。

rtl

右から左への方向。

このプロパティは、ユニコードの双方向のアルゴリズムに対して、テキストの進行方向と組み込みと上書きの方向('unicode-bidi'を参照)という、行の方向の構成要素の方向を明示する。値'のltr'と'rtl'は、行の方向に'相対的に'解釈される。加えて、表の行のレイアウトの方向、基本のテキストの進行方向と同じように方向付けられるあふれの方向(たとえば、writing-mode: lr-tbに対して、ブロックの要素が水平面の右にあふれるだろう)、テキストの配置、'text-align: justify'の場合において、ブロックの中の完結していない最後の行の位置を明示する。 'direction'プロパティが、inline-levelの要素に何らかの影響をもたらすのに、'unicode-bidi'のプロパティの値は、'embed'か'bidi-override'でなければならず、要素の中の文字の標識の方向が、縦書きのレイアウトにおいて90/-90度か、横書きのレイアウトにおいて0/180度でなければならない。

block-levelのブロックの水準の要素に対する'direction'のプロパティを用いるのは、'writing-mode'のプロパティが取って代わるため、CSS3においては反対されている

注意。'writing-mode'と'direction'のプロパティは、表の行の要素に対して明示されているとき、行が文書のツリーにおいて存在しないため、行におけるセルに継承されない。したがって、[HTML40]のセクションの11.3.2.1.に説明されているCSSは"dir"の属性の継承の規則を容易に保持することはできない。

注意。'writing-mode'と'direction'のプロパティは、互いに相互作用する。そういうものとして、'writing-mode'は、'direction'の値を置き換える。同様に、'writing-mode'の後の'direction'の修正は、実際上、'writing-mode'の値を、反対の行中の進行に変える。たとえば、'writing-mode:lr-tb'のある要素に適用される'direction:rtl'は、実際上、'writing-mode:rl-tb'にする。これは、二つのプロパティの混在した使用法が反対されてるか、少なくとも大いに慎重に使われるべきである、主な理由のひとつである。

注意。これらのプロパティは背景の画像の位置に影響しない。

3.3. テキストの流れの中にある標識の方向:'glyph-orientation-vertical'と'glyph-orientation-horizontal'のプロパティ

場合によっては、基本のテキストの進行方向に関連した、文字の連続の方向を変えることが必要とされることがある。必要とするものは、時々の半角のローマ字のテキストが横書きに、ほかのときは縦書きに表示される、東アジアの文書の縦書きのレイアウトに、個々に適用できるものである。

二つのプロパティは、基本のテキストの進行方向に関連した、標識の方向を制御する。'glyph-orientation-vertical'の制御する。'glyph-orientation-vertical'は、基本のテキストの進行方向が縦書きであるときに、標識の方向を制御する。'glyph-orientation-horizontal'は、テキストの進行方向が横書きであるときに、標識の方向を制御する。以下の理由のため縦書きと横書きの間を区別することが必要である。

• 基本のテキストの進行方向が縦書きのとき、典型的な標識の方向は、関連した文字に依存するというものである。'auto'の値の説明を参照してください。この値は、横書きのレイアウトにおいては必要ない。
• 初期値が二つのプロパティで異なっている。

<angle>

ユーザエージェントは、角度の値を、ユーザエージェントによってサポートされている標識の値に丸めてもよい。適合しているユーザエージェントは、以下の値しかサポートしないくてもよい。0deg、90deg、180deg、270deg。

"0deg"の値は、すべての標識が、基本のテキストの進行方向に向かって、標識の下端を基準にして、方向付けられ、互いの上端においては、結果として、垂直に積み重ねられる標識となることを明示する。"90deg"の値は、"0deg"の方向から時計回りに90度回転することを明示する。このプロパティを90または270度に設定された文字に対しては、最初に再整理が、ユニコードの双方向のアルゴリズムによって適用され、それから、結果となる標識が、<angle>の値によって回転される。

auto

基本のテキストの進行方向に関係のある、標識の方向は、描写される文字のユニコードの文字の番号によって、自動的に決定される。

(表意文字の句読点を除いた、)全角の表意文字と、全角のローマの標識は、"0degの<angle>が明示されているかのように描写する(すなわち、すべての標識が、基本のテキストの進行方向に向かって、標識の下部を基準にして、方向付けられ、互いの上部においては、結果として、垂直に積み重ねられる標識となる)

表意文字の句読点と、交互に横書きと縦書きの標識の形をしている、その他の表意文字は、標識の縦書きの形を用いることにする。

全角でないテキストは、"90deg"の<angle>が明示されているかのように設定される。したがって、半角のローマ字のテキストは、全角の表意文字と全角のローマ字のテキストに対して、時計回りに90度回転される。

ヘブライ語とアラビア語のテキストは、時計回りに90度回転される。テキストの視覚的な整形は、回転より前に適用される、双方向のアルゴリズムによって決定される。

注意。autoの値は、普通ヨーロッパの文字と日本語を混在する慣用で期待された結果を生成する。しかしながら、その厳密なアルゴリズムは、多くの要因の間の複雑な相互関係に基礎付けられており、したがって異なるアルゴリズムが、異なるプロセスの環境で用いられるかもしれない。厳密な制御のためには、明白な<angle>の値を明示してください。

このプロパティは、'writing-mode'のプロパティによって決定される、行中の進行に関連した、標識の方向を明示する。このプロパティは、縦書きのwriting-modeで書かれたテキストにしか適用されない。適合したユーザエージェントは、順々に高度になっていく水準のサポートにおいて、以下のことをしてもよい。

1. 90degの値のみをサポートする。
2. 0deg、90deg、180でdegと270degをサポートする。

このプロパティの値は、作用される標識に対して生成される、標識の領域の、配置と高さの両方に影響する。標識の標準の方向が、dominant-baselineに平行となるようになされれば、回転された標識の縦のalignment-pointが、その標識に適切なalignment-baselineを基準にして配置される。回転される標識が配置される基線は、標識の属しているスクリプトに対する"alignment-baseline"によって見分けられる垂直の基線である。標識の領域は、標識に対する高さのフォントの特性によって決定される。

横の配置の点、基線、(標識の進行の幅として計算される)高さは、もし、標識の標準の方向がdominant-baselineに平行であれば、使用される。

下の図表は、'glyph-orientation-vertical'の異なる使用を説明する。左の図表は、ローマ字に対する'glyph-orientation-vertical'が、autoか"90deg"であるときに、半角のローマ字と全角の表意文字を混在させた結果を示す。右の図表は、ローマ字が、"0deg"の'glyph-orientation-vertical'を持つように明示されているときに、半角のローマ字と全角の表意文字を混在させた結果を示す。

双方向のアルゴリズムと'glyph-orientation-vertical'プロパティには、以下の相互作用がある。

1. 双方向のアルゴリズムは、同じglyph-orientation-verticalの値がある、それぞれ隣接するテキストの範囲に、分かれて適用される。言い換えれば、プロパティの値における変化は、双方向のアルゴリズムを再設定する。
2. glyph-orientation-verticalの値が270度のとき、すべての正当の双方向のプロセス処理後の、すべての反転する記号は、時計回りに270度回転される前に、反転される(すなわち、その標識が、'水平'の軸に沿って反対にされる)。これは、望まれる描写の結果を成し遂げるためになされ、それによって反転する文字が、それが取り囲んでいるテキストを'内部'に向けるようになる。

<angle>

ユーザエージェントは、角度の値を、ユーザエージェントによってサポートされている標識の値に丸めてもよい。"0deg"の値は、すべての標識が、基本のテキストの進行方向に向かって、標識の右端を基準にして方向付けられることを明示する。"90deg"の値は。"0"の方向から、時計回りに90度の方向を明示する。0か180度に設定されたこのプロパティを持つ文字に対しては、描写はこのプロパティを90または270度に設定された文字に対しては、最初に描写の処理が、ユニコードの双方向のアルゴリズムによって適用され、それから、結果となる標識が、<angle>の値によって回転される。

このプロパティは、'writing-mode'のプロパティによって決定される、行中の進行方向に関連した、標識の方向を明示する。このプロパティは、横書きのwriting-modeで書かれたテキストにしか適用されない。適合したユーザエージェントは、順々に高度になっていく水準のサポートにおいて、以下のことをしてもよい。

1. 90degの値のみをサポートする。
2. 0deg、90deg、180でdegと270degをサポートする。

このプロパティの値は、作用される標識に対して生成される、標識の領域の、配置と幅の両方に影響する。標識の標準の方向が、dominant-baselineに平行となるようになされれば、回転された標識の縦のalignment-pointが、その標識に適切なalignment-baselineを基準にして配置される。回転される標識が配置される基線は、標識の属しているスクリプトに対する"alignment-baseline"によって見分けられる水平の基線である。標識の領域は、標識に対する幅のフォントの特性によって決定される。

横の配置の点、基線、幅は、もし、標識の標準の方向がdominant-baselineに平行であれば、使用される。

3.4. 組み込みと上書き: 'unicode-bidi'のプロパティ

このプロパティは、新しい組み込みの段階や、方向の上書きをできるようにすることによって、ユニコードの双方向のアルゴリズムの、さらに進んだ制御をできるようにする。このプロパティに対する値には、以下のような意味がある。

normal

要素は、双方向のアルゴリズムで、付加的な水準の組み込みを開かない。inline-levelの要素に対しての暗黙の描写処理が、要素の境界にまたがって動作する。

embed

もし要素がinline-levelであれば、この値は、双方向のアルゴリズムに関して、付加的な水準の組み込みを開く。この組み込みの水準の方向は、'direction'によって与えられる。要素の中では、描写が暗黙になされる。これは、要素の最初に、LRE(U+202A;'direction: ltr'に対するもの)やRLE(U+202B;'direction: rtl'に対するもの)を、要素の最後にPDF(U+202C)を加えたものと一致する。

bidi-override

もし要素がinline-levelの要素しか含まない、inline-levelかblock-levelの要素であれば、これは上書きを生成する。これは、要素の中では、描写は、'direction'によって、厳密に連続の中にあり、双方向のアルゴリズムの、暗に示された部分は無視される。これは、要素の最初に、LRO(U+202D;'direction: ltr'に対するもの)かRLO(U+202E;'direction: rtl'に対するもの)を、要素の最後にPDF(U+202C)を加えたものと一致する。

それぞれのbolock-levelの要素における文字の最終の整形は、双方向の制御のコードを上に説明したように加え、mark-upを取り去り、そして、スタイル処理がなされたテキストと同じline-breaksを生成するプレーンテキストに対して、結果となる文字列を、ユニコードの双方向のアルゴリズムの実行に通していたのと同じである。この経過において、'unicode-bidi'のプロパティは、要素に対して明示された'direction'において、強調した文字として扱われる場合の'normal'よりほかの値を持っていれば、画像のような、テキストでないエンティティは、はっきりしない文字として扱われる。

注意。一定の方向(完全に左から右への方向か、完全に右から左への方向であるかのどちらか)である行中の要素を流すことができるようにするために、より多くの行中のボックス(匿名の行中のボックスを含む)が生成しなければならないかもしれず、行中のボックスの中には、ふるい落とされ、そして流す前に最整形されなければならないものもあるかもしれない。

ユニコードのアルゴリズムには、組み込み処理の61の段階の制限があるから、ふさわしくなければ、'normal'よりほかの値で'unicode-bidi'を使わないように注意すべきである。特に、'inherit'の値は、非常に用心して使われるべきである。しかしながら、概して、ブロックのように表示されるように意図された要素に対しては、'unicode-bidi: embed'の設定は、表示が行中に変更される場合には、要素をともに保つために好まれる(下の例を参照)。

以下の例は、双方向のテキストのある、XMLの文書を示す。次に重要な設計の原理を説明する。DTDの設計者は、本来の言語(要素や属性)と付属のスタイルシートの両方で、双方向を考慮に入れるべきである。双方向の規則は、ほかのスタイルシートで上書きされず、その結果、文書の言語やDTDの、双方向の挙動が維持されるべきである。

<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

3.5. 文字の分類:'script'のプロパティ

テキストのレイアウトにおいて、挙動の多くが文字種に基づく文字の分類に関連している。たとえば、行分けや行そろえの挙動は、要素のテキストの内容の'diminant'の文字に依存する。これは、要素において、あいまいでない、文字の識別子のある、最初の文字を見つけることによって、発見的に決定される。'script'のプロパティを使うことによっても、明示的に示すことができる。

値は以下の意味を持っている。

auto

要素の内容のもっとも有力な文字を決定するための、あいまいでない文字の識別子をもつ、[文字の方向と、双方向性のため、どんな描写の後でも、]最初の文字の子孫を使ってください。これは、計算された文字の値を決定する。しかしながら、要素のそれぞれのテキストのコンポーネントは、文字の識別子によって指示されるような、印刷上関係のある挙動を行うかもしれない。明らかな文字の識別子があるテキストのコンポーネントがなければ、(あるいは、まったくテキストの内容がなければ、)計算される値は'Latin'である。

none

文字が、未知であるか、この要素の適切なフォーマット処理に重要でないことをを明示する。

<script>

[ISO15924]に従った文字の定義。要素のすべてのテキストのコンポーネントは、これらのテキストのコンポーネントの固有の文字の値ではなく、この文字の値によって指示されるような、印刷上関係のある挙動を行う。

4. テキストの配置と行そろえ

4.1. テキストの配置:'text-align'のプロパティ

このプロパティは、ブロックの行中の内容がどのように配置されるかを説明する。値には、以下の意味がある。

start

テキストは、現行のテキストの進行方向によって決定されるような、行中の進行の最初の部分に配置される。

end

テキストは、現行のテキストの進行方向によって決定されるような、行中の進行方向の最後の部分に配置される。

left, right

横書きの行中の進行において、テキストはそれぞれ左か右に配置される。縦書きの行中の進行においては、配置はUAに依存する。値'start'および'end'が、代わりに用いられるべきである。'left'と'right'の使用は、CSS3においては推奨されない。

center

テキストは中央に配置される。

justify

テキストは行をそろえられる。行そろえのアルゴリズムは、'text-justify'のプロパティを使用することによって、さらにまた改良される。適合するユーザエージェントは、値'justify'を'start'であるものとして解釈してもよい。

<string>

表の行におけるセルが配置される文字列を明示する(詳細と実例については行における縦書きの配置の項を参照)。この値は、表のセルにのみ適用される。もし、その他の要素に設定されると、'start'のように扱われるだろう。

テキストのブロックは、行のボックスの積み重ねである。'start'、'end'、'left'、'right'および'center'の場合においては、このプロパティは、それぞれの行のボックスの中にあるインラインのボックスは、それぞれの行のボックスの、最初と最後の側に関して配置される。配置は、閲覧領域に関してなされるのではないのである。'justify'の場合においては、UAは、その位置を調節するのに加えて、行中のボックスを引き伸ばしてもよい。'letter-spacing'と'word-spacing'も参照。)

例:

この例において、'text-align'が継承されるため、'class=center'をもつDIVの内部のすべてのblock-levelの要素は、その行中の内容が中央にくるようにさせる。

DIV.center { text-align: center }

4.2. 行そろえ:'text-justify'のプロパティ

このプロパティは、行そろえの配置の種類を選択する。これは、'text-align'が'justify'に設定されているときにのみ、テキストのレイアウトに影響する。このように、このプロパティをサポートしていないUAは、完全に行そろえがなされたようなテキストを今までどおり描写するだろうが、ほとんどのときは、それは少なくとも部分的に正しい。一般的に、最後の行がそれ自体で行そろえがなされていなければ、text-justifyのプロパティは、最後の行には影響しない。text-justifyの値のほとんどは、非常に明確な風に、文書体系に影響する。その文書体系(やその集団)は、次のものである。

• CJKとHangul、および、拡大すると、すべての'wide'の文字。
• BengaliやGurmukhiのように、ベースラインのコネクタを使う、Devanagariやすべての南アジアの文字。
• 単語の間に空白を使わない東南アジアの文字(Thai、Lao、Khmer、Myanmar)。
• Arabicのような続け書きの文字。
• コネクタを使わずに単語の間に空白を用いる文字(Latin-basedやHebrewなど)や記号。

テキストの構成要素のtext-justificationの挙動は、文字列の文字の分類によって導かれる。'script'プロパティを用いると、その構成要素の挙動を変更することができる。

text-justifyの値により、空白処理は単語や文字の間において変更されるかもしれない。

text-justifyのプロパティに可能な値は次のものです。

auto

UAは、性能と十分な表示の質に基づいて、従う行そろえのアルゴリズムを決定する。単語間の伸長は、単語の区切り符号として空白を用いるすべての文字で、一般に使われる。しかしながら、kashida-spaceのプロパティが0でない値をもてば、アラビア語のテキストに、kashidaの伸長を使うように推奨されるだろう。

inter-word

最も単純で最も早い完全な行そろえの挙動を選択する。それは、単語の間のスペースの幅を増やすことだけにより、行にまたがって平等にテキストを広げる。単語の考えは、文字依存であり、厳密なアルゴリズムは、ユーザエージェントによって決定される。最小限度、行そろえは、それぞれの透明な空白の境界で起こると期待される。単語の中で、伸長や圧縮は少しも起こらない。すなわち、文字の空白処理は、まったく生成されない。kashidaの効果も、まったく起こらない。

下の図表は、どのように文字が要素の最後の二行においてレイアウトされるかを示すことによって、この形態を説明する。

図の3.2.1:inter-wordの行そろえがなされた要素で、最後の二行における混在した標識のレイアウト

たとえば、ビューアは以下のように'inter-word'の行そろえがなされた段落を描写することができる。

図の3.2.2:混在したテキストに適用された、単語間の行そろえ

newspaper

単語間と文字間の両方の空白処理が、テキストを全体の行にまたがって広げるために広げたり減らしたりされる、行そろえの挙動を選択する。そしてその上、どんな与えられた行におけるテキストの配置も、先あるいは後の数行のレイアウトや内容に依存する。これは、特に狭い行に便利であるような、新聞や雑誌において好まれる完全な行そろえの挙動の、かなり時間がかかり、きわめて複雑な種類である。たとえば、一般的に、圧縮が最初に試みられる。もし、成功しなければ、伸長が起こる。単語間の空白は、 広げられ、最後に文字間の伸長が行われる。これは、ベースラインのコネクタを使う、Devanagariやその他の南アジアの文書体系を除くすべての文字の集団に適用される。はじめの値は、(文字の総数における)行の幅に関連付けられてもよい。厳密なレイアウトのアルゴリズムは、ユーザエージェントによって決定される。

以下の図表はこの形態を説明する。

図の3.2.3:newspaperの行そろえの要素の最後の二行における混在した文字のレイアウト

inter-ideograph

この様式において、letter-spacingの調節はCJKの集団に対してのみ起こる。ほかは単語間の伸長のみを用いる。kashidaの効果は、少しも起こらない。これは、ラテン語や韓国語ではなく、日本語の文書体系のコンテキストにおいて好まれる行そろえである。

下の図表はこの様式を説明する。

図の3.2.4:inter-ideographの行そろえの要素の最後の二行における、混在した標識のレイアウト

下はこの様式が動作する方法の例である。

図の3.2.5:混在したテキストに適用された、inter-ideographの行そろえ

distribute

'newspaper'のように、(Hindiを除く)ほとんどの文字の集団に対して、文字の空白処理を調整できるようにするが、newspaperと違い、単語の空白処理と文字の空白処理の間で優先順序をつけない。すなわち、空白の文字に、ほかの文字と同じ、文字の空白処理の調節を行う。そして、結果は、狭いのと広い行の間に変化がない。この値は東アジアのコンテキストにおいて最もよく使われる。

下の図表はこの様式を説明する。

図の3.2.6:distributeの行そろえの要素の最後の二行における、混在した文字のレイアウト

たとえば、ビューアは、以下のように'distribute'の行そろえがなされた段落を描写することができる

図の3.2.7:混在したテキストに適用されたdistributeの行そろえ

inter-cluster

inter-ideographと同じ役割だが、東南アジアの文字に対しての役割を果たす。すなわち、文字の空白処理はその文字に属するクラスタに対してのみ起こる。クラスタは単一の単位としてフォーマットがなされる文字の集団と定義される。

kashida

inter-ideographと同じ役割だが、Kashidaの効果を経て、アラビアの文字に対しての役割を果たす。すなわち、ほかの文字に対しては、少しも文字の空白処理は起こらない。

以下の表は、それぞれの適切なtext-justifyの値に対する、それぞれの文字の集団や、text-justifyのプロパティの値の組み合わせのための伸長・圧縮の手順を説明する。

*autoに対して示される値は、推奨でしかない。UAは、違った方法を実装してもよい。

*Devanagariの記載事項は、BengaliとGurmukhiのようなベースラインのコネクタを用いる、インドで使われるほかの文字や文書体系をも、同様に表す。

4.3. 最後の行の整列:'text-align-last' のプロパティ'

このプロパティがブロックの行中の内容の最後の行がどのように整列されるかを説明する。これは、もしもたった一つの行であるBRの要素の前置きとしている行と、匿名のブロックの最後の行までを含んでいれば、唯一のブロックの行に適用する。典型的に最後の行はブロックの要素のほかの行のように整列され、これは'text-align'のプロパティで定められる。しかしながら、'text-align'のプロパティが'justify'に定められるときのような状態の中では、最後の行が違ったふうに整列されるかもしれない。

値は次に続く意味を持つ。

auto

最後の行は、'text-align'のプロパティの値によって決定されるほかの行のように整列される。しかしながら、もしも'text-align'のプロパティが'justify'の値に定められれば、最後の行は行中の前進の出だしに整列される。

start、endおよびcenter

それぞれ出だし、終わりおよび中央のテキスト。

justify

最後の行は、'text-justify'によって定められる両端のそろえの種類を使っているほかの行のように、両端をそろえられるだろう。しかしながら、もしも最後の行において、少しも拡大の機会がなければ、行が両端をそろえられると見えないかもしれないことに注意せよ。

size

行の内容は行に対して適合させるように拡大・縮小されるすべての行に対するフォントは、同じ要因によって拡大・縮小されなければならず、その要因はできるだけ小さく(すなわち、できるだけ行に対してたくさんを適合させ)なければならない。典型的に、この値はたった一行の要素に対して用いられる。

次に続く例は、すべての行が分配される両端のそろえでそろえられる場合において、整列のプロパティの使用法を示す。これは一般的に東アジアの印刷の体裁の中に見つけられる。

P.distributealllines
 { text-align: justify; text-justify: distribute; text-align-last: justify }

4.4. 最小と最大のフォントサイズ:'min-font-size'と'max-font-size'のプロパティ

もしも、'text-align-last'が'size'ならば、要素の最後の行のフォントが'font-size'のsmallerと'min-font-size'より小さくなることは許されない。

もしも'text-align-last'が'size'ならば、最後の行のフォントが'font-size'のlargerと'max-font-size'よりも大きくなることは許されない。'auto'は少しの制限もないことを意味する。

4.5. 付加的な圧縮:'text-justify-trim'のプロパティ

'text-justify'が'inter-word'よりほかの何かであるとき、これは、テキストの両端のそろえのアルゴリズムに対して、個々のフォントの空白の圧縮の許可を定める。この特殊な種類のスペースの圧縮は、フォントの水準上で起こる。すなわち、文字範囲の中の空白は、標識の出現に影響を及ぼさずに、それ自身減少させてもよい。これは幅の広いセルの標識にだけ適用する。可能な値は、

none

幅の広いセルのフォントのスペースの圧縮は少しも許されない。

図の3.4.1:少しも圧縮のない標識のレイアウト

punctuation

スペースは、幅の広いセルの句読点からだけ取り除かれることができる

図の3.4.2:句読点の圧縮のある標識のレイアウト

punct-and-kana

スペースの圧縮は幅の広いセルの句読点と幅の広いセルのかなの標識に関して許される

図の3.4.3:句読点とかなの圧縮のある文字のレイアウト

4.6. Kashidaの効果:'text-kashida-space'のプロパティ'

kashidaはアラビア語におけるいくつかの注意深く選ばれた点で文字の伸長を許す、アラビア語の文書体系で使われる印刷上の効果である。おのおのの伸長は、kashidaの点のおのおのの側でのたった一つの文字か符号である、kashidaの標識の数を使って成し遂げられることができる(UAはフォントに基礎付けられた機構か、または体系の特性を用いてよい)。text-kashida-spaceのプロパティは、0%は少しもkashidaの拡大をしないことを意味し、100%はkashidaの拡大だけを意味するという、空白の拡大の大きさに対するkashidaの拡大の比率を表現する。このプロパティは、kashidaの拡大が用いられる両端のそろえのスタイルとともに使われる。(今のところ、text-justify: auto、kashida、distributeおよびnewspaper).

アラビア語のテキストの二つのまったく同じ段落を示す下の図表において、第2番目の行(両端をそろえられない)の中の青い線は、赤い下線で示されるような最初の行(両端をそろえられる)におけるkashidaに対して用いられ、伸長の機会の中で分割される長さを示す。

その例の中では、text-kashidaのプロパティが100%に定められるということを示し、少しの拡大も、単語それ自身の間で起こらない。

5. 基準線の整列

5.1. フォントによって提供される基準線の情報

与えられた文字体系の標識は、おのおのの標識に関する個々の点である整列の点が、その文字体系におけるほかの標識の整列の点と整列するように配置される。異なった文字体系の標識は、典型的に標識に関する異なった点で整列される。たとえば、西洋の標識が大文字の底に基づいて整列され、(Devanagari、Gurmukhi、Bengaliという文字体系からの標識を含めて、)あるインド語派の標識は、標識の上に近い水平な字画の上で整列され、東アジアの標識は、標識の全角の枠の底かまたは中央で整列される。文字の中で、ただ1個のフォントのサイズがあるテキストの行の中に、基準線と呼ばれる幾何学的な線を、行中の前進の方向の中で整列の点の連続が定義する。西洋とたいていのほかのアルファベットや音節を表す標識は、"アルファベット"の基準線に整列され、上に述べたインド語派の文字列は"吊り下げ"の基準線に整列され、"表意文字"の基準線に整列される。

基準線の表は、設計の空間の座標の体系において、ひとつかもっと多い基準線の位置を明示する。基準線の表の機能は、異なった文字体系が同じテキストの行の上に混合するときに、お互いに関してその整列を容易にするためのものである。望ましい相対的な整列は、どの文字体系が行(かブロック)の中のもっとも有力であるかに依存するかもしれない。加えて、違った整列の位置が横と縦の文書形態に対して必要とされる。それゆえに、フォントは、典型的に横の文書形態に対してひとつかもっと多く、縦の文書形態に対してはゼロかもっと多い、基準線の表の一そろいを持ってもよい。

あるフォントに対するフォントの表は、そのフォントにおける個々の標識に対するフォントの特質を含む。CSSは、フォントの表が、横の文書体系に対するひとつの幅の値、ひとつの整列の基準線とひとつの整列の点を、フォントにおけるおのおのの標識に対して、当然含むと決めてかかる。縦の文書体系がサポートされれば、おのおのの標識は、縦書きの文書形態に対する、もうひとつの幅の値、整列の基準線と整列の点を持たなければならない。(幅として明示されるが、縦の文書形態に対しては、幅は縦の方向に用いられる。)

標識が属する文字体系は、標識が整列される基準線を決定する。設計の空間の座標の体系における基準線の位置は、整列の点の、デフォルトのブロックの前進の方向の位置を決定する。整列の点の、行中の前進の方向の位置は、標識の出だしの端にある。

5.2. 基準線の識別子

基準線の整列のプロパティは、その親について、子供の要素の整列を制御する。その基準線の位置は、次に続く図中で説明される。

下の基準線の識別子は、この仕様書の中で使われる。その中には、フォントによって提供される基準線の情報を説明している項の中で説明されるように、フォントに含まれる基準線の表によって決定されるものもある。ほかは、下に説明されるほかのフォントの特質から計算される。

アルファベット

これはたいていのアルファベットや音節を表す文字体系によって用いられる基準線を識別する。これは、多数の西洋、南インド、東南アジア(表意文字でない)の文字体系を含むが、それらに限定されない。

表意文字

これは。表意文字の文字体系によって用いられる基準線を識別する。歴史的な理由のために、この基準線は表意文字の全角の枠のそこにあり、象形文字の全角の枠の中央にはない。"中央"の基準線を見よ。表意文字の文字体系は、中国語、日本語、朝鮮語とベトナムのChu Nomを含む。

吊り下げ

これは、あるインド語派の文字体系によって用いられる基準線を識別する。この文字体系はDevanagari、GurmukhiとBengaliを含む。

数学

これは、数学の記号で使われる基準線を識別する。

中央

これは、全角の枠の中央にある計算された基準線を識別する。基準線は、テキストの前の端とテキストの後の端という基準線の中間に位置する。

注意せよ。表意文字のフォントに対して、この基準線はしばしば標識を整列するのに使われる。これは、表意文字の基準線の代わりにとりうる方法である。

中間

これは、xの高さの値の1/2だけ、変化の方向に、アルファベットの基準線から隔てられる基準線を識別する。基準線の位置は、フォントのデータから得られるかもしれないし、"xの高さ"に対してフォントの特質を持つフォントに対して得られるかもしれない。情報のそれらの断片のどちらか一方を欠くときは、基準線の位置は、"中央"という基準線に近づけられてもよい。

テキストの前の端

これは、全角の枠の前の端を識別する。この基準線の位置は、基準線の表中に明示されてもよいし、計算されてもよい。

注意せよ。この基準線の位置は普通はアセンダのあたりか、その上部にあるが、標識より上に現れることができるすべてのアクセントを取り囲んではならない。それらのフォントに対しては、"上昇"のフォントの特質の値が使われる。表意文字のフォントに対して、この基準線の位置は、通常は"表意文字"の基準線から変化の方向に1全角である。しかしながら、表意文字のフォントの中には、もっと厳格な調節を可能にするために、行中の前進の方向に切り詰めた幅を持つものもある。縦の文書様式に対してだけ設計された、そのようなフォントが横の文書形態の中で使われるとき、"テキストの前の端"という基準線はテキストの後の端から1全角より小さいかもしれない。

テキストの後の端

これは、全角の枠の後の端を識別する。この基準線の位置は、基準線の表中に明示されてもよいし、計算されてもよい。

注意せよ。ディセンダのあるフォントに対しては、その基準線の位置は通常はディセンダのあたりか、その下部にある。それらのフォントに対して、"降下"のフォントの特質の値が使われる。表意文字のフォントに対しては、基準線の位置は通常は"表意文字"という基準線にある。

ほかに、行の枠のためだけに定義される二つの計算された基準線がある。おのおのの行の枠に対して、すべての行を完全に含む最も近い祖先の要素のそれである、もっとも有力な基準線、基準線の表と、基準線の表のfont-sizeがある。"前の端"と"後の端"という基準線は次のとおり定義される。

前の端

行のもっとも有力な基準線からの、行の"前の端"という基準線の隔たりは、整列の基準線が"前の端"または"後の端"のいずれかであるすべての行中の枠を無視することによって決定される。"前の端"に対しては、広さが、枠の(相対的な)上部に向かう方向に、もっとも有力な基準線から測定される。"前の端"という基準線の隔たりは、残っている範囲の割り当ての矩形の"前の端"の最大の広さに定められる。もしも行の範囲の中のすべての行中の範囲が"前の端"か"後の端"のどちらかに整列されれば、行の"テキストの前の端"という基準線の隔たりを行の"前の端"の基準線の隔たりとして用いよ。

後の端

行のもっとも有力な基準線からの、行の"後の端"という基準線を隔たりは、整列の基準線が後の端であるすべての行中の枠を無視することによって決定される。"後の端"に対しては、広さが、参照の範囲の(相対的な)下部に向かう方向に、もっとも有力な基準線から測定される。"後の端"という基準線の隔たりは、(1)残っている範囲の割り当ての矩形の"後の端"の最大の広さ足す、(2)行の"前の端"の隔たりを引いた、無視される範囲の割り当ての矩形の最大の高さの、最大の負数に定められる。

注意せよ。もしも行の領域の中の行中の領域が、"後の端"に整列されれば、"前の端"に対する詳述は、行の"テキストの前の基準線"と一致するように"前の端"という基準線を定めるだろう。それから、上の事例(2)は、"前の端"の基準線までの割り当ての矩形までの最大の高さのある範囲の"前の端"を整列するであろう、"底の端"という基準線までの隔たりを決定するだろう。

注意せよ。"前の端"と"後の端"に対して上に述べた詳述は、次に続く三つのプロパティを持つ。(1)すべての範囲の割り当ての矩形が"前の端"の下にあり、(2)すべての範囲の割り当ての矩形が"後の端"の上にあり、(3)"前の端"と"後の端"の間の距離は(1)か(2)を破らずに減少されることができない。"前の端"と"後の端"の明示された配置は、(1)-(3)が満足したものにすることができる唯一の方法ではないが、"前の端"までの最も小さい可能な隔たりに満足したものにすることができる唯一の方法である。

"前の端"と"後の端"の整列を示している例

横の文書形態に対してだけ定義される四つの基準線もある。

top

この基準線は、横の文書形態において"前の端"という基準線と同じであり、縦の文書形態においては定義されていない。

text-top

この基準線は、横の文書形態において"テキストの前の端"という基準線と同じであり、縦の文書形態においては定義されていない。

bottom

この基準線は、横の文書形態において"後の端"という基準線と同じであり、縦の文書形態においては定義されていない。

text-bottom

この基準線は、横の文書形態において"テキストの後の端"という基準線と同じであり、縦の文書形態においては定義されていない。

5.3. 基準線の整列の過程の概観

その親に関する要素の整列は、親の調整された基準線の表と、整列されている要素の整列の基準線と整列の点という、三つの事によって決定される。整列より前に、親の調整された基準線の表が移し変えられるかもしれない。下のプロパティの詳述は、親と子供の要素を整列するのに必要な情報を提供する。

'dominant-baseline'、'alignment-baseline'、'baseline-shift'と'alignment-adjust'という、基準線の上に述べたセットに要素の整列を制御する四つのプロパティがある。それらのプロパティはすべて独立していて、典型的に、プロパティのひとつの詳述だけが、個々の整列の目的を成し遂げるのに必要とされるように設計される。

基本の基準線のプロパティは'dominant-baseline'というプロパティである。このプロパティは三つの構成要素のある複合の値を持っている。もっとも有力な基準線の識別子という構成要素は、二つの行中の範囲を整列するときに使われるために、デフォルトで'alignment-baseline'である。基準線の表という構成要素は、フォントの設計の空間の座標の中で基準線の位置を明示する。基準線の表は音楽のスタッフのように何かを務める。標識と行中の要素が整列されるブロックの前進の方向に沿って個々の点を定義する。基準線の表の'font-size'という構成要素は、基準線の表のための調整の要因を提供する。

'font-family'というプロパティの値がフォントのリストであるから、基準線の表の首尾一貫した選択を保証するために、標識のデータが利用できるリストの中の最初のフォントとして、フォントのリストの中の名目のフォントを定義する。これは、出会われるおのおのの文字のための、標識を含むことができる最初のものである。(この定義のために、もしも、フォントの代用がなされれば、あるいは、フォントが統合されれば、標識のデータは現在のものと決められる。)この定義は、使われるだろうフォントと基準線の表の内容の独立した決定を保証する。

便宜上、詳述は、(用語の誤用において)"もっとも有力な基準線"として、"dominant-baseline"というプロパティという、もっとも有力な基準線の識別子という構成要素によって識別される基準線に言及するときもある。

モデルは、おのおのの標識が、標識が整列されることになる基準線を明示する'alignment-baseline'の値を持っていると決めてかかる。('alignment-baseline'は、オープンタイプの基準線の表の説明における"基準線のタグ"と呼ばれる。)'alignment-baseline'の初期値は、与えられた標識と関連付けられた基準線の識別子を使う。'alignment-baseline'に対する交互の値は、文字体系のメンバであることに関してあいまいである'*'のような標識に役に立つことができる。

モデルは標識が描かれるフォントが、基準線の表であるフォントの基準線の表を持っていると決めてかかる。この基準線の表は、(0,0)という点からフォントが知っている基準線のおのおのまで全角ごとの構成単位における隔たりを持っている。

基準線の表における隔たりの値は、全角の端数の構成単位を意味する"設計の構成単位"において、ある。CSSはそれを"全角ごとの構成単位"と呼ぶ。だから、現在の'font-size'がもっとも有力な基準線から交互の基準線までの現実の隔たりを決定するのに使われる。

標識は、その'alignment-baseline'によって確認されるその基準線が、もっとも有力な基準線の表から、同じ名前のある基準線で整列されるように、整列される。

'alignment-baseline'によって識別されるもっとも有力な基準線から親の基準線までの隔たりは、もっとも有力な基準線の表と、もっとも有力な基準線の表のフォントの大きさを使って計算される。標識に適用できるフォントの基準線の表とフォントの大きさは、識別された基準線から標識の(0,0)という点までの隔たりを計算するために使われる。第2番目の隔たりは、変化の方向に(0,0)という点の位置を得るために、最初の隔たりから減じられたものである。両者の隔たりは、基準線の表からの基準線の値かける適切なフォントの大きさの値によって計算される。

もしも、'alignment-baseline'がもっとも有力な基準線を識別すれば、最初の隔たりはゼロで、標識はもっとも有力な基準線とともに整列される。そうでなければ、文字は選ばれた交互の基準線とともに整列される。

第3番目の基準線の整列のプロパティは、'baseline-shift'というプロパティである。"dominant-baseline"というプロパティよりほかのプロパティのように、このプロパティは基準線の表か基準船の表のフォントのサイズを変えない。内部の行中の要素が親の基準線のひとつに整列されたとき、内部の行中の要素が移るように、親の要素の全体の基準線の表を移す。

第4番目のプロパティは'alignment-adjust'というプロパティである。このプロパティは、特定の文字体系に属さず、あらかじめ定義された整列の点を持たない要素である、グラフィックスのようなものに対して主として使われる。"alignment-adjust"というプロパティは、作者が、オブジェクトの最初の端に、その要素のための整列の点が位置する場所を割り当てるのを可能にする。

これらのプロパティの次に続く定義に加えて、情報を与えるappendix: Bは、これらのプロパティの使用例を提供する。

5.4. もっとも有力な基準線:'dominant-baseline'というプロパティ

The 'dominant-baseline'というプロパティは、調整された基準線の表を決定するか再決定するのに用いられる。調整された基準線の表は、三つの構成要素のある複合の値を持つ。

• もっとも有力な基準線に対する基準線の識別子。'もっとも有力な'基準線の識別子(つまり、要するに'もっとも有力な基準線')としての資格を持つことができる。基準線の識別子は、基本的に'alignment-baseline'の値である。
• さまざまな文字体系に関係のある付加的な基準線の識別子のための定義を含む基準線の表
• そして基準線の表のfont-size

プロパティの値の中には、すべての三つの値を再定義するものもある。基準線のフォントサイズだけを再制定するものもある。プロパティに対する値は、以下に続く意味を持っている

auto

もしもこのプロパティがブロックや行中の要素に生ずれば、基準線の識別子の値は、'script'というプロパティの値に依存する。もしscriptというプロパティの値が'auto'ならば、基準線の識別子は、横の'writing-mode'の値に対して'alphabetic'であり、縦の'writing-mode'の値に対して'central'である。scriptというプロパティが'auto'よりほかの値であれば、基準線の識別子の値はその文字体系に基礎付けられる。'writing-mode'の値である、横であるか縦であるかは、基準線の識別子に一致する基準線の表を選択するのに使われる。基準線の表のfont-sizeという構成要素は、この要素の'font-size'というプロパティの値に定められる。
そうでなければ、このプロパティが行中の水準の要素上で生じれば、基準線の識別子と基準線の表という構成要素は、親の要素のそれらと同じままになる。また、計算された'baseline-shift'の値が実際に基準線を移さなければ、基準線の表のフォントサイズも、親のと同じになる。それから、基準線の表のfont-sizeは、この要素の'font-size'というプロパティの値に定められる。もしも、親の要素がなければ、もっとも有力な基準線という構成要素は、ブロックの要素に対するものとして定められる。

use-script

もっとも有力な基準線の識別子は'script'というプロパティの計算された値を使って定められる。'writing-mode'の値である、横か縦かは、その基準線の識別子と一致する基準線の表を選択するのに使われる。基準線の表のfont-sizeという構成要素は、この要素の'font-size'というプロパティの値に定められる。

no-change

もっとも有力な基準線の識別子、基準線の表と基準線の表のfont-sizeは、親のそれと同じままである。

reset-size

もっとも有力な基準線の識別子と基準線の表は、同じままであるが、基準線の表のfont-sizeは、この要素の'font-size'というプロパティの値に変えられる。

ideographic

もっとも有力な基準線の識別子は、親の基準線の表と基準線の表のfont-sizeを使って'表意文字'の基準線に定められ、基準線の表は'表意文字'の基準線に一致するように変えられ、そして基準線の表のfont-sizeは、この要素の'font-size'というプロパティの値に変えられる。

hanging

もっとも有力な基準線の識別子は、親の基準線の表と基準線の表のfont-sizeを使って'吊り下げ'の基準線に定められ、基準線の表は'吊り下げ'の基準線に一致するように変えられ、そして基準線の表のfont-sizeは、この要素の'font-size'というプロパティの値に変えられる。

alphabetic

もっとも有力な基準線の識別子は、親の基準線の表と基準線の表のfont-sizeを使って'アルファベット'の基準線に定められ、基準線の表は'アルファベット'の基準線に一致するように変えられ、そして基準線の表のfont-sizeは、この要素の'font-size'というプロパティの値に変えられる。('アルファベット'の基準線は、ローマ字の文字体系に対して標準の基準線である。)

mathematical

もっとも有力な基準線の識別子は、親の基準線の表と基準線の表のfont-sizeを使って'数学'の基準線に定められ、基準線の表は'数学'の基準線に一致するように変えられ、そして基準線の表のfont-sizeは、この要素の'font-size'というプロパティの値に変えられる。

もしも名目のフォントに基準線の表がなければ、あるいは基準線の表が望ましい基準線に対する記載事項を欠いていれば、ユーザエージェントは望ましい基準線の位置を決定するのに、ヒューリスティックを用いてもよい。

5.5. 要素の整列の点の整列:'alignment-baseline'というプロパティ

このプロパティは、行中の水準の要素がどのようにその親に関して整列されるかを明示する。それは、親の基準線のいずれにこの要素の整列の点が整列されるかである。'dominant-baseline'というプロパティの違って、'alignment-baseline'というプロパティは、子供のもっとも有力な基準線に影響を持たない。

注。'alignment-adjust'というプロパティは、どのように整列の点が決定するかを明示し、alignment-baselineというプロパティの計算された値と同じ名前を持った基準線をデフォルトにする。

'auto-script'に対してを除いて、すべての基準線は、親のもっとも有力な基準線の、それぞれの基準線の識別子という構成要素とを参照し、要素の中の標識は、要素そのものと同様に整列される。'auto-script'に対する説明は、明確にそれらの点を含む。プロパティの値は以下に続く意味を持っている。

baseline

整列されている要素の整列の点は、親のもっとも有力な基準線で整列される。

auto-script

もしも要素の'script'というプロパティの値が'auto'であれば、それぞれの標識の整列の点は、標識が属する文字体系の基準線の識別子で整列される。もしも要素の'script'というプロパティが'auto'よりほかであれば、それぞれの標識の整列の点は、'script'というプロパティによって明示される基準線の識別子で整列される。基準線の識別子の位置は、親の要素のもっとも有力な基準線のセットに関係のある適切な情報を用いて決定される。要素そのものの整列の点は、'baseline'に対してのように整列される。

before-edge

枠の整列の点は、親の'前の端'という基準線で整列される。

text-before-edge

整列されつつある要素の整列の点は、親の'テキストの前の端'という基準線で整列される。

after-edge

枠の整列の点は、親の'後の端'という基準線で整列される。

text-after-edge

整列されつつある要素の整列の点は、親の'text-after-edge'という基準線で整列される

central

枠の整列の点は、親の'中央'の基準線で整列される。

middle

枠の整列の点は、親の'middle'という基準線で整列される。

ideographic

整列されつつある要素の整列の点は、親の'表意文字'という基準線で整列される。

alphabetic

整列されつつあるようその整列の点は、親のもっと低い基準線で整列される。

hanging

整列されつつある要素の基準線の点は、親の吊り下げの要素で整列される。

mathematical

整列されつつある要素の整列の点は、親の数学の基準線で整列される。

before-edge、text-before-edge、after-edgeとtext-after-edgeという値は、すべてwriting-modeのプロパティの値に関係して作用する。

注意せよ。'baseline'が、(類似したXSLのプロパティでは、'autoと呼ばれる')'auto-script'の代わりに初期値になっている理由は、今日のほとんどのフォントが、ラテン語でない文字体系に属している標識に対してさえ、'アルファベット'の水準でおかれる整列の点で設計されるという事実と関係がある。ユーザエージェントは、制約を処理しなければならず、だから、初期値として'baseline'という値を使うのである。

5.6. 整列の点の設定:'alignment-adjust'というプロパティ

'alignment-adjust'というプロパティは、基準線の表を持っていないか、その基準線の表の中の望ましい基準線を欠く、要素のもっと精密な整列である、グラフィックのようなものを可能にする。'alignment-adjust'というプロパティで、'alignment-baseline'によって識別される基準線の位置が、はっきりと決定されることができる。また、テキストの要素の仲のおのおのの標識に対する配置の点もはっきりと決定する。ユーザエージェントは与えられた要素に対する存在していない基準線の位置を決定するために、ヒューリスティックを使うべきである。

プロパティに対する値は、以下の意味を持っている。

auto

要素の中のテキストの情報と一致しているおのおのの標識に対して、整列の点は文字・符合の枠の出だしの端の交点であり、フォントからの整列の点のブロックの前進の方向の位置である。パディング、ボーダーかマージンは、その整列の点に影響を及ぼさない。もしもこの基準線が要素のもっとも有力な基準線に対する基準線の表に存在するとき、行中の水準の要素の整列の点それ自身は最初の行中の枠の出だしの端と'alignment-baseline'というプロパティによって識別される基準線の交点である。もしも行中の要素が行中のブロックであれば、整列の点は行中のブロックの要素の最後の行に生じる。もしも明白に示された基準線が存在しなければ、ユーザエージェントはそのあるべきところにない基準線があるだろう場所を決定するのにヒューリスティックを使ってもよい。画像のようなほかの行中の枠の内容に対して、ユーザエージェントは整列の点の位置を決定するのにヒューリスティックを使うだろう。たとえば、結果として生じている基準線が'アルファベット'か'表意文字'であれば、それぞれのマージンを含めて、整列の点は行中の枠の出だしの端と後の端の交点であるだろうことが期待される。もしも結果として生じる基準線が'吊り下げ'であれば、そのそれぞれのマージンを含めて、行中の枠の出だしの端と前の端の交点が、代わりに使われる。

baseline

整列の点は、要素の出だしの端と、要素のもっとも有力な基準線との交点である。

before-edge

整列の点は、要素の出だしの端と、要素の'前の端'という基準線との交点である。

text-before-edge

整列の点は、要素の出だしの端と、要素の'テキストの前の端'という基準線の交点である。

central

要素の出だしの端と、要素の'中央'という基準線との交点である。

middle

整列の点は、要素の出だしの端と、要素の'中間'という基準線との交点である。

after-edge

整列の点は、要素の出だし端と、要素の'後の端'という基準線との交点である。

text-after-edge

整列の点は、要素の出だしの端と、要素の'テキストの後の端'という基準線の交点である。

ideographic

整列の点は、要素の出だしの端と、要素の'表意文字'という基準線との交点である。

alphabetic

整列の点は、要素の出だしの端と、要素の'アルファベット'という基準線との交点である。

hanging

整列の点は、要素の出だしの端と、要素の'吊り下げ'という基準線との交点である。

mathematical

整列の点は、要素の出だしの端と、要素の'数学'という基準線との交点である。

<percentage>

プロパティの計算された値は、要素の計算された'line-height'(これは取り替えられる要素のマージンを含む)にかけられたパーセンテージである。整列の点は、行中の枠の出だしの端上にある。もっとも有力な基準線と出だしの端の交点に関連した、出だしの端に沿ったその位置は、計算された値だけ隔てられる。隔たりは変化の方向と反対側(正の値)か変化の方向(負の値)である。'0%'という値は、もっとも有力な基準線を整列の点とする。

<length>

整列の点は、行中の最初の端にある。もっとも有力な基準線と出だしの端の交点に関連した、出だしの端に沿った位置は、<length>という値だけ隔てられる。隔たりは、変化の方向の反対側(正の値)か変化の方向(負の値)である。'0cm'という値は、もっとも有力な基準線を整列の点とする。

5.7. もっとも有力な基準線の再配置:'baseline-shift'というプロパティ

'baseline-shift'というプロパティは、もっとも有力な基準線に関連した、もっとも有力な基準線の再配置を許可する。移されたオブジェクトは、下あるいは上付き文字となるかもしれない。移された要素の中で、ほんの一つだけの基準線ではなく、全体の基準線の表が隔てられる。下あるいは上付き文字に対して、隔たりの量は親の名目のフォントから決定される。

プロパティに対する値は次に続く意味を持っている。

baseline

基準線の変化はない。もっとも有力な基準線が最初の位置に残る。

sub

もっとも有力な基準線は、下付き文字のデフォルトの位置に移される。この位置に対する隔たりは、親要素の最も有力な基準線の表のfont-sizeによって調整されるような、親の名目のフォントに対するフォントのデータによって決定される。適切なフォントデータがなければ、ユーザエージェントは隔たりを決定するのにヒューリスティックを用いてもよい。

super

もっとも有力な基準線は、上付き文字のデフォルトの位置に移される。この位置に対する隔たりは、親要素の最も有力な基準線の表のfont-sizeによって調整されるような、親の名目のフォントに対するフォントのデータによって決定される。適切なフォントデータがなければ、ユーザエージェントは隔たりを決定するのにヒューリスティックを用いてもよい。

<percentage>

プロパティの計算された値は、親の要素の'line-height'にかけられた、このパーセンテージである。もっとも有力な基準線は、計算された値だけ親の範囲の変化の方向(正の値)か変化の方向の反対側(負の値)に移される。'0%'という値は'baseline'と同等である。

<length>

もっとも有力な基準線は、<length>の値だけ親の領域の親の領域の変化の方向(正の値)か変化の方向の反対側(負の値)に移される。

注意せよ。'baseline-shift'と'alignment-adjust'というプロパティが同じことをしているように思われるかもしれないが、重要な違いがある。'alignment-adjust'の場合は、パーセンテージの値は整列されつつある要素の'line-height'を参照する。'baseline-shift'の場合は、パーセンテージの値は親の要素の'line-height'を参照する。同様に、それは配置されつつある要素の'sub'と'super'という隔たりよりむしろ、移された基準線を整列するのに使われる親の'sub'と'super'という隔たりである。一貫した下あるいは上付き文字の位置を保証するために、下あるいは上付き文字における"font-size"の変化のため"line-height"を変えたかもしれない下つき文字の要素よりむしろ、参照として親を使うことが、道理にかなっている。
"alignment-adjust"というプロパティを使うことは、内部のテキストの構造を持っていない配置しつつある要素である、グラフィックスのようなものに対して、もっと適当である。 "baseline-shift"は、もっとも有力な基準線に関連して定義される名づけられた隔たりよりむしろ、明白に示された基準線の隔たりを定義する方法を提供する。さらに、"baseline-shift"があることは、ツールが適切なプロパティを生成するのをもっと用意にする。多くのフォーマット処理のプロパティは、基準線の変化の考えをすでに持っている。

5.8. 縦の整列:'vertical-align'というプロパティ、基準線の整列のプロパティとの関係

このプロパティは、行中の水準の要素によって生成される枠である行の枠の中の縦の配置処理に影響を与える。次に続く値は、親の行中の水準の要素に関してだけ、もしも匿名の行中の枠を生成するならな親のブロックレベルの要素に対して、意味を持っているそのような親が存在しなければ何の影響も及ぼさない。

auto

親のもっとも有力な基準線を、同等物かヒューリスティックで再構成された、要素の基準線で整列する。もしも枠に親のもっとも有力な基準線がなければ、親のもっとも有力な基準線で、マージンを含めて、枠の下部を整列する。もしも行中の枠が数行(行中のブロックの要素)を含んでいれば、最後の行の基準線を使う。もしも親がないか、親とこの要素の間にフローの方向の変化があれば、もっとも有力な基準線は横のフローに対して'alphabetic'に、縦のフローに対して'center'に定められる。

use-script

親の要素の同等の基準線で、(再整理処理の後に要素の中の最初の視覚的な文字によって決定される)要素の文字体系の好まれる基準線を整列する。

baseline

親の枠の'アルファベット'の基準線で枠の'アルファベット'の基準線を整列する。もしも枠に'アルファベット'の基準線がなければ、親の'アルファベット'で、取り替えられうる要素に対するマージンを含めて、枠の下部を整列する。もっとも有力な基準線は、もし親がないか、この要素とその親の間にフローの方向の変化があれば、'alphabetic'に定められ、そうでなければ'no-change'に定められる。

central

親の枠の中央の基準線で枠の縦の中間点を整列する。

middle

xの高さの半分をプラスした親の枠の基準線で枠の縦の中間点を整列する。

sub

枠の基準線を親の枠の下付き文字に適切な位置まで下げる。(この値は要素のテキストのフォントの大きさに何の影響も及ぼさない)

super

親の要素の上付き文字に適切な位置まで枠の基準線を引き上げる。(この値は要素のテキストのフォントの大きさに何の影響も及ぼさない)

text-top

親の要素のフォントの前の端で枠の上部を整列する。

text-bottom

親の要素のフォントの後の端で枠の下部を整列する。

<percentage>

この距離(要素の計算された'line-height'のパーセンテージ)だけ枠を引き上げる(正の値)か下げる(負の値)。値である'0%'は'baseline'と同じを意味する。

<length>

この距離だけ枠を引き上げる(正の値)か下げる(負の値)。値である'0cm'は'baseline'と同じを意味する。

残っている値は、生成された枠が出現する行の枠を参照する。

top

行の枠の前の端で枠の上部を整列する。

bottom

行の枠の後の端で枠の下部を整列する。

基準線の整列のプロパティの設定はvertical-alignというプロパティに少しの影響もないから、'vertical-align'はそれらのための簡略表記法ではない。しかし、vertical-alignというプロパティは、次のとおりそれらを定めるので、たとえば、それらの整列のプロパティのマクロのように見られることもできる。

編集者の注:XSLの定義と次に続く違いがある。

1. alignment-baslineの初期値は、(XSLにおいて'auto'と呼ばれる)'auto-script'の代わりにbaselineである。これはユーザエージェントの現在の実行を反映する。

2. 'vertical-align: baseline'は、(autoの代わりに)dominant-baseline:'alphabetic'か'no-change'にマップされる。

3. (新しい初期として提案される値)'vertical-align: auto'は、'dominant-baseline:auto'にマップされる。

編集者の注:vertical-alignを四つのほかの整列のプロパティの簡略表記法のプロパティにするのは心をそそるが、しかしながらいくつかの問題点がある。

1. vertical-alignは、たったひとつ挙げられるプロパティであり、簡略表記法にそれを変えることは、DOMの観点から問題を引き起こす。

2. 個々のプロパティの値の名前は、alignment-base、alignment-adjustとbaseline-shiftに伴われて、最初にもっとも有力な基準線を持つように、厳密な連続が強制的でなければ、たった一つの簡略表記法で使われるために設計されない。使用は扱いにくい。

6. インデント:'text-indent'というプロパティ

このプロパティがブロックの中のテキストの最初の行のインデントを明示する。もっと正確には、ブロックの最初の行の枠に流れる最初の枠のインデントを明示する。枠は、行の枠の始まりの端に関してインデントされる。ユーザエージェントは空白としてこのインデントを描写すべきである。

値は以下に続く意味を持っている。

<length>

インデントは固定された長さである。

<percentage>

インデントは包含するブロックの幅のパーセンテージである。

'text-indent'の値は負であってもよいが、それらは実装に特定の制限があってもよい。

 P { text-indent: 3em }

7. 行分け

7.1. 行分けの種類

ラテン語に基礎付けられた言語で書かれた文書の中で、文字の連続が単語と単語を構成するところは、スペースやハイフンで分けられ、行分けは相対的に簡単である。もっとも一般的な場合においては、(ハイフンの辞書はひとつもUAにすぐ利用できないと仮定すると)行分けは、U+ 00AD SOFT HYPHENを含めて空白文字やハイフンでだけ生じることができる。

しかしながら、たった一つの標識として現れるものが全体の単語を表すことができ、少しのスペースも、少しの単語の隔てている文字も必要とされない表意文字の印刷の体裁において、行分けの機会はスペースほど明らかでない。多数のほかの文字の後か前で生じることができる。一定の行分けの制限はそれでもなお適用されるが、ラテン語の印刷の体裁におけるのほど厳密ではない。

(付帯的な注として、タイ語はそれに独特な特殊な行分けの規則のある別の興味を起こさせる例である。タイ語の単語は文字の連続から構成されるから、その点においてはラテン語に似ている。しかし、単語の区切り文字としてのスペースや、事実上首尾一貫した単語の区切り文字がないことは、CJKと類似させる。ハイフンでつなぐための辞書がないときのラテン語と似ていて、タイ語は単語の中では決して行分けしない。実際は、語彙の認識がタイ語のテキストを行分けすることができようにするのに必要である。)。最終的に、U+200B ZERO WIDTH SPACEというユニコードの文字が、明確な行分けの機会を明示するためにそのような文字体系に挿入されることができる。

いくつかの"厳密さ"の水準は、日本語の印刷の体裁において使われることができる。これらの水準は、行分けの制限を加えるか取り除く。この仕様書の中で提供されるモデルは、'line-break'というプロパティを使って、日本語のテキストのための二つのもっとも一般に使われる行分けの水準を区別する。

表意文字の印刷の体裁において、常に好まれはしないが、それらのここの文字体系の改行の規則に従わずに、引用されたラテン語とハングルの内部で生じる行分けを許可する。この文書で提案されるモデルは、作者に'word-break-CJK'というプロパティを通して、その振る舞いの制御を与える。

最後に、付加的な語分けの機会は、長い単語に対して非常時に単語を分けることとハイフンでつなぐことを許可する、'word-break-wrap'と'word-break-inside'で制御される。すべてのそれらのプロパティは'word-break'の簡略表記法のプロパティを通してもまた利用可能である。

行分けは、ユニコードのウェブサイトから入手できるユニコードの技術上の報告書(TR#14)にもまた含まれる。詳細な勧告と、それは、それぞれのユニコードの文字に対する一致しているデータを含む。

7.2. 行分け:'line-break'というプロパティ

このプロパティは、テキストのために使われるための行分けの規則のセットを選択する。下に説明される値は、特にCJKの作者に役に立つが、プロパティ自身は、なおまだCJKでない作者のための設定を明示していないものの、ほかに開かれている。(これは未来の拡張のための領域である。)

normal

CJKに対する標準の行分けの形態を選択する。UAは自由に'normal'という形態に対してそれの独特の制約を定義するのことができるといっても、平凡なカタカナとひらがなの文字の間の行分けは許可されることが推奨される。これは、狭い欄に対して特に望ましい、現代の日本の印刷の体裁においての好みである。日本語のカタカナの単語は長くなる傾向があり、両端のそろえによる過度の拡張があるよりも、行分けがこのような文字の間に生じることを可能にするのがより望ましい。

strict

CJKのテキストに対するもっと制限的な行分けの形態を選択する。UAは自由に'strict'という形態に対してそれの独特の制約を定義することができるといっても、JIS X-4051によって明示される制約が守られることを推奨する。それはこの形態において、平凡なカタカナとひらがなの文字が行をはじめることは許されないことを含む。

日本語において、行分けの制約のセットは、"禁則"と呼ばれる。JIS X-4051[JIS]は、規則の厳密なセットを使っているこの挙動のために参考となる評判のよい情報源である。このアーキテクチャは行分けの振る舞いの種類に文字を分類することを必要とする。それらの種類はそれから、それらの種類の発生でとられる一組の行動を、おのおのの横の列と縦の列の位置が表す二次元の振る舞いの表で分析される。二つのたとえば、閉じるための文字の種類と開くための文字の種類を与えられ、それらの二つの種類のその表の交点(開くための種類に属している最初の文字と閉じるための種類に属している二番目の文字)は行分けの機会を示さない。JIS X-4051で説明される規則は、もっと早くに簡単に述べられたユニコードの技術上の報告の#14に取って代わられた。

'normal'と'strict'という両者の値が、行分けの制約のセットが用いられていることを含むことに注意せよ。事実上、改行が表意文字の中のまさしくどこにでも現れることができるCJKにおける正当な改行の形態がないように見える。

7.3. 語分け:'word-break-CJK'、'word-break-wrap'、'word-break-inside'というプロパティと簡略表記法である'word-break'というプロパティ

このプロパティは、CJLの観点から単語の中の行分けの振る舞いを制御する。

normal

CJKでない文字体系を(それら自体の規則にしたがって)まとめる。同時にハングルと(朝鮮語のHanjaという文字を含めた)CJKは、どこでも、あるいは'line-break'の形態の規則にしたがって分かれる。しかしながら、CJKでない文字体系の振る舞いは、'word-break-wrap'における値である'emergency'か'word-break-inside'というプロパティにおける値である'hyphenate'と取り替えられうる。

break-all

CJKおよびハングルについては'normal'と同じであるが、CJKでない文字体系は、どこででも分かれることができる。この選択は、たいてい、テキストが、CJKでない引用句をほとんど用いずに、圧倒的にCJKの文字を使っていて、テキストが各行によりよく分配されることが望ましいコンテキストにおいて使われる。しかしながら、UAはタイ語のようなクラスタを使っている文字体系に対して、どこでも分かれる振る舞いを制限してもよい。

keep-all

CJKでない文字体系に対しては'normal'と同じである。CJKおよびHangulはまとめられる。この選択は、朝鮮語の文書体系においてのような平凡なクラスタにおいて使われるCJKのコンテキストにおいてだけ使われるべきだ。

以下に続く例は、CJKでない文字体系がどこででも別れることができる段落を示す。

P.anywordbreaks { word-break: break-all }

このプロパティは、単語に対する送り込むための振る舞いを制御する。もしも単語がただ一行の中に合うことができなければ、単語が行の終わりで任意に振り落とされることを可能にする。たとえば、これは、許可されるスクロールのない固定された容器の中の無理な非常に長い単語を扱う。可能な値:

normal

単語は常に単一の行にとどまるべきである。しかしながら、これは'word-break-CJK'というプロパティにおける値である'break-all'か'word-break-inside'における値である'hyphenate'を使うことによって取り替えられうることに注意せよ。

emergency

これは、たとえほかの分析が分かれの機会を見つけることができなかったとしても、別の分かれの機会が創造されることを可能にする。たとえば、これは、許可されるスクロールがない固定した容器の中の無理な非常に長い単語の状態を扱う。

このプロパティは、単語の内部でのハイフンでつなぐ振る舞いを制御する。可能な値:

normal

単語は常にただ一行の中にとどまるべきである。しかしながら、'word-break-CJK'というプロパティにおける値である'break-all'か'word-break-wrap'というプロパティにおける値である'emergency'を使うことによって取り替えうる。そのうえ、明白なハイフンでつなぐ文字(ハイフン、ソフトハイフン、など...)は、行分かれの機会をそれでもなお創造する。

hyphenate

単語は、適当なハイフンでつなぐ点で分かれうる。ユーザエージェントが分かれつつあるテキストの言語に対するハイフンでつなぐ辞書を持っていることを必要とする。この値はユーザエージェントにおいて、ハイフンでつなぐエンジンを作動させる。

'word-break'というプロパティは、スタイルシートにおいて、同じ場所で'word-break-CJK'、'word-break-wrap'と'word-break-inside'を定めるための、簡略表記法のプロパティである。

すべての語分けに関係のあるプロパティは、まず初期値(すべて'normal')におきなおされる。それから、'word-break'という簡略表記法において明示的な値を与えられたそれらのプロパティは、それらの値に定められる。

たとえば、次に続く規則、

P { word-break: emergency }

は、

P { word-break-CJK: normal }
P { word-break-wrap: emergency }
P { word-break-inside: normal }

と同等である。

8. テキストの送り込み処理、空白の制御とテキストのあふれ

CSS2における'white-space'というプロパティは、実際には、包含しているブロックの枠の流れの端に達するとき、テキストを送り込むかどうか、元の中の空白を崩れさせるかどうかという二つの独立した軸を制御する。二つの新しいプロパティが、空白を越えた独立した作者/使用者の制御を許可するそれらの独立した軸を表すために、CSS3において取り入れられる。'white-space'というプロパティは、その二つの新しいプロパティを定める簡略表記法のプロパティと再定義される。

8.1. 空白のくずし処理:'text-space'というプロパティ

このプロパティは、テキストの流れの中の空白が崩されるかどうか制御するか、あるいは現状のままでとっておく。

normal

要素の内容において、現在の空白を崩す。

honor

要素の内容において、現在のままで空白をとっておく。その文字に適切なようにおのおのの空白文字を描写/配置する。'text-align: justify'と'text-align-last: justify'というプロパティの値は無視される。

8.2. テキストの送り込み処理:'text-wrap'というプロパティ

このプロパティは、包含しているブロックの枠の流れの端に達するとき、テキストが送り込まれるかどうかを制御する。

normal

テキストの内容に適切なようにテキストを送り込む。始まっているおよび終わっているスペースとタブ文字は無視される。明白に示された行分けのアルゴリズムは、'line-break'と'word-break'というプロパティによって決定される。

none

テキストの内容を送り込まない。包含するブロックの枠の中に合わないほど長いテキストの内容は、内容の枠の流れの端を通り過ぎてあふれる。

8.3. 空白:'white-space'というプロパティ

このプロパティは、要素の中の空白がどんなふうに処理されるかを宣言する。Setting a value on the 'white-space'というプロパティ上の値を定めることは、'text-space'と'text-wrap'上のそれぞれの値を定める。

PRE        { white-space: pre }
P          { white-space: normal }
TD[nowrap] { white-space: nowrap }

したがっているユーザエージェントは、作者と使用者のスタイルシートの中の'white-space'というプロパティを無視してもよいが、デフォルトのスタイルシートの中でそれに対する値を明示しなければならない。

8.4. テキストのあふれ:'text-overflow-mode', 'text-overflow-ellipsis'というプロパティと簡略表記法の'text-overflow'というプロパティ

テキストのあふれは、writing-modeというプロパティの値によって決定されるような、そのテキストの前進の方向に要素の枠からあふれ出るとき、テキストの内容が切られる状態を処理する。(UAの振る舞いが、ただ内容のスクロール処理に帰着するだけの後者の場合において、)この状態は'overflow'というプロパティが、ただhidden、scrollかautoという値を持つときだけに起こるかもしれない。

テキストのあふれは、作者が(後か最後の)要素の枠の中にあるテキストの流れの二つの末尾の境界で、視覚的な暗示を紹介することを可能にする。実際は文字の描写は変わるかもしれないが、暗示は一般的には省略文字の"..."である。画像が代わりに用いられるかもしれない。どちらか一方のテキストの流れの境界に対して、空でない文字列(あるいはimgに対するuri)を定めることにより、暗示の体裁を可能になる。もしも両方の暗示が現れるはずならば、'後'のヒントが描写される。ただ行の暗示の最後だけは示される(左から右への初期のテキストの前進の方向に対してのどんなあふれた行でも右側に一致する)。

tezt-overflowは、ヒントの文字の体裁を制御する'text-overflow-mode'と、枠の境界で表示されるヒントの文字の値を制御する'text-overflow-ellipsis'というプロパティと、'text-overflow'という簡略表記法のプロパティに分けられる。

clip

テキストの内容に当てられるようなテキストを切る。テキストの標識の描写は、部分的にだけ描写されるかもしれない。

ellipsis

省略の文字列がテキストのあふれが生じるおのおのの境界に挿入される。それらの省略の文字列の値は、'text-overflow-ellipsis'というプロパティによって決定される。挿入はテキストの行のいっぱいの最後の描写の境界で起こる。

ellipsis-word

'ellipsis'と類似しているが、テキストの行の中の単語の最後のいっぱいの標識の描写の境界で起こる。

暗示の文字は、テキストの情報だけに取って代わる。もしも切り取りが取り替えられる要素で起これば、標準の切り取りが起こる。

プロパティは継承されないが、静的かまたは相対的におかれ、明示された幅または高さをもたないあふれている子供のブロックは、その親のtext-overflow-modeというプロパティの値を明示されたように暗示を与えられるだろう。次に続く例をよく考えてください。

<div>
<p><span>I didn't like the play,</span> but then I saw
it under adverse conditions - the curtain was up.
<div class="attributed-to">_Groucho_Marx_</div>
</p>
</div>

これはあふれの状態を制御しているスタイルシートである。

div { width:100px; border: thin solid red; overflow: hidden;
       text-overflow-mode:ellipsis;font-size:14px }
span { white-space : nowrap; }
div.attributed-to { position: relative;left:8px }

これは、spanの内容に部分的に目に見えるように帰着し、省略符号が示され、相対的に配置される内部のdivが、ピクセルのほとんどない隔たりであるようにただ一部分の省略符号だけを示すだろう。

絶対的に配置されるブロックのような、ほかの子供のブロックまたは、明示された幅や高さがあるブロックは、暗示を示さないだろう。たとえば、次に示すスタイルを前の図の要素にに定めている、

p { width :100px; margin-top : 50px; margin-left : 50px; }

は、(明示された幅をもち、そのうえテキストの送り込みが親の要素の'hidden'というあふれの領域で起こるから)その内容に対して省略符号は決して表示されないだろう。これは、次のように示されるだろう。

言い換えれば、text-overflow-modeは、それ自身の行中の流れの中で関係するブロックの要素のテキストの内容にだけ影響を及ぼす。

<ellipsis-end>

要素の枠のそれぞれの行の中のテキストの流れの後に描写される暗示の文字の値を制御する。テキストの文字列を値としてとる。空の文字列は暗示を動作しないようにする。初期値は'...'である。横のテキストの流れ('writing-mode' = 'lr-tb)の場合においては、暗示の文字列はテキストが右にあふれる要素の枠のおのおのの行に現れる。

<ellipsis-after>

要素の枠の中でテキストのあふれの後で描写される暗示の文字の値を制御する。テキストの文字列を値としてとる。空の文字列はヒントを動作しないようにする。初期値は空である。横のテキストの流れの場合においては、暗示の文字列は最後の行の右端に現れるだろう。もしも<ellipsis-after>が空でなく、<ellipsis-end>より同じ位置に現れるだろうならば、 ただ<ellipsis-after>だけが示されるだろう。

uri

そしてuriが文字列の値のどれでもに取って代わることができ、暗示の指示として使われるための画像を定めることができる。明示されるのは、それぞれの省略符号に対して空でない文字列と同等である。

省略文字に対して使われるfont-seizeは、要素のfont-sizeである。

このプロパティは、'text-overflow-mode'と'text-overflow-ellipsis'に対する簡略表記法である。

9. テキストのスペース処理

9.1. 文字のスペース処理:'letter-spacing'というプロパティ

このプロパティはテキストの文字の間のスペース処理の振る舞いを明示する。値は次に続く意味を持つ。

normal

スペース処理は現在のフォントに対して標準のスペース処理である。一般的に0の長さである。しかしながら、この値はユーザエージェントにテキストの両端をそろえるために文字の間のスペースを変えることを許す。

<length>

この値はデフォルトのスペースに加えて単語間のスペースを示す。この値は要素の最後の文字を含めて、おのおののスペース処理している文字または、(タイ語、クメール語などのような)たった一つのgraphemeの単位の中に密集した文字の塊の前進の幅に加えられる。続け書きのフォントに適用する効果によって、あるいは標準の印刷の体裁の規則(アラビア語のの文字体系、Devanagariのような北インドの文字体系)によって、結合される文字は、おのおののスペース処理している文字に加えられる値を持っている。(スペース処理ではなく)文字の結合処理は、何の文字のスペース処理の効果も得ず、基礎である文字の結合と、その結合している文字が、文字のスペース処理の効果を得る。

両端のそろえの目的のためには、ユーザエージェントは、(文字のスペース処理の拡大/圧縮に対立するものとしての単語のスペース処理より先に)できるだけ文字のスペース処理に関する効果を極小化するべきである。

値は負であってもよいが、実装に特定の制限があってもよい。なおそのうえに、両端のそろえのアルゴリズムは、文字間のスペース処理を修正してもよい。

たとえばアラビア語のような結合された文字を用いた文書体系上で文字の空白処理を修正するという、視覚のほう快適な効果のために、プロパティの使用はその場合において思いとどまらされる。

行の全長に合う目的で文字の内容を拡大または圧縮するための、行の中に機会がほかに何もないから、両端のそろえが文字のスペース処理の効果をすべて変える日本語や中国語の文書体系のような場合がある。

文字のスペース処理のアルゴリズムはユーザエージェントに左右される。たとえば、空白処理はおのおのの文字の間では必ずしも起こらないだろうが、その代わりに文字かまたはクラスタ単位かいずれかを構成する標識の間で起こる。なお、このプロパティは、文字をつなぐ文字体系および/またはフォント(ローマ字の文字体系の続け書きのフォント、すべてのアラビア語の場合、Devanagariのような見出しがあるインド語派のなど)に対して用いられるべきではない。文字の空白処理は両端のそろえによっても影響される('text-align'というプロパティを見よ)。

BLOCKQUOTE { letter-spacing: 0.1em }

BLOCKQUOTE { letter-spacing: 0cm }   /* Same as '0' */

結果として生じるスペースがデフォルトのスペースと同じではないとはいえ、ユーザエージェントは合字を使うべきではない。

適合しているユーザエージェントは、'letter-spacing'というプロパティの値を'normal'だとみなしてもよい。

9.2. 単語のスペース処理:'word-spacing'というプロパティ

このプロパティは単語の間のスペース処理の振る舞いを明示する。値は次に続く意味持っている

normal

現在のフォントおよび/またはユーザエージェントによって定義されるような、標準の単語間のスペース。もしも単語間の空白の境界がひとつかいくつかの空白文字によって境界を定められれば、目に見えるべきである。もしも文字がひとつもなければ、ユーザエージェントは付加的な文字の前進の幅を創造する必要はない。

none

単語間の空白はない。すべての空白文字はゼロの長さの文字のようにみなされる。

<length>

この値は、単語の間のデフォルトのスペースに加えて単語間の空白を指し示す。 値は負であってもよいが、実装に特有の制限があってもよい。

単語のスペース処理のアルゴリズムはユーザエージェントに左右される。単語の境界を決定することは、一般的に空白の文字を検出することによってなされる。しかしながら、(日本語、中国語、タイ語などのように)何の文字によってもその単語を分けない多くの文字体系や文書体系があり、そのような場合において単語の境界を検出することは、すべてのユーザエージェントによってサポートされなくてもよいアルゴリズムに基づいた辞書を必要とする。単語の空白処理は両端のそろえによっても影響される('text-align'というプロパティを見よ)。

H1 { word-spacing: 1em }

適合しているユーザエージェントは'word-spacing'というプロパティの値を'normal'だとみなしてもよい。

9.3. 句読点の整理:'punctuation-trim'というプロパティ

このプロパティは、その"インク"が上や下の行の中の最初の標識とともに並ぶために、全角の句読点の目印の符号が切り取られるかどうかを決定する。シナリオの中には、たとえば、文字・符号は縦に並ぶ傾向があることがもっと重要なときに、先導する句読点の目印が整えられるのを許さないことが、作者にとってむしろ望ましいかもしれないものもある。ほかのシナリオにおいては、たとえば、できるだけ多量のテキストがたった一つの行の上に合うことが作者にとって重要なとき、そのような効果が望ましい。

可能な値:

none

先導する句読点は整えられない。

図の8.3.1: 先導する句読点の圧縮が少しもない標識のレイアウト

start

先導する句読点は整えられる。

図の8.3.2: 先導する句読点の圧縮のある標識のレイアウト

(このプロパティは、全角だけでなく、そのうえ句読点のほかの種類に対するほかの句読点の振る舞いを含むように広げられるかもしれないことに注意せよ。)

9.4. スペースを追加する処理:'text-autospace'というプロパティ

表意文字でないまたは数の文字の流れが、表意文字のテキストの内部に現れるとき、周囲の表意文字の標識から離すために、一定の量のスペースが表意文字でないテキストの両側でしばしば好まれる。このプロパティは、テキストを描写するとき、そのスペースの創造を制御する。その加えられる幅は、付加的なスペースの文字の挿入と一致しないが、その代わりとして存在している標識の幅の増加に一致する。

(この振る舞いを決定するための通例使われるアルゴリズムはJIS X-4051 [JIS]において明示される。)

このプロパティは、'word-spacing'および'letter-spacing'[CSS2]というプロパティに付加的なものあり、すなわち、'letter-spacing'の調節によって寄与されるスペース処理の量は、(もしあるなら、)'text-autospace'によって創造されるスペース処理に加えられる。同一のことは、'word-spacing'にも適用される。

可能な値:

none

特別なスペースは少しも創造されない。

ideograph-numeric

表意文字のテキストと数の標識の流れの間に特別な空白処理が創造される。

ideograph-alpha

表意文字のテキストと、ラテン語に基礎付けられたもの、キリル文字、ギリシャ文字、アラビア文字またはヘブライ文字のような、表意文字でないテキストの流れの間に特別な空白処理が創造される。

ideograph-space

表意文字に囲まれている限り、スペースの文字の幅を広げる。

ideograph-parenthesis

普通の(全角でない)丸括弧と表意文字の間の特別な空白を創造する。

<SPAN style="text-autospace:none">[表意文字]1997[表意文字]</SPAN>

は、

のように現れるだろうが、一方、

<span STYLE="text-autospace:ideograph-numeric">[表意文字]1997[表意文字]</span>

は、もっと、

のように現れるだろう。

9.5. テキストのカーニング:'kerning-mode'と'kerning-pair-threshold'というプロパティ

このプロパティはすべてのカーニングの効果を制御する。カーニングの効果の中には、フォント上にはっきりとおかれる情報に基礎付けられる(ペアカーニング)。ほかのものはコンテキストと文字の中の一般的なインクの配置に基礎付けられる。ペアカーニングは、ラテン語、ギリシャ語とキリル語の文字体系に対して主に用いられる。ペアカーニングの一般的な例は、'Wa'という一組である。コンテキストのカーニングのよい例は、(広い幅の変形を用いるとき)'[['という一組である。可能な値:

none

カーニングは何も動作しないようにされる

pair

ペアカーニングが動作可能にされる

contextual

コンテキストのカーニングが動作可能にされる

このプロパティはフォントサイズのはじめを制御し、(もし動作可能にされれば)上のそのペアカーニングが有効とされる。

10. テキストの装飾

10.1. 序論

CSS2まで、利用できるテキストの装飾は、下線、上線、貫く線など...といったさまざまな効果を受けさせている'text-decoration'というプロパティと、text-shadowsというプロパティを通じて利用可能なものだけであった。しかしながら、text-decorationというプロパティには、構文から生じている制限がいくらかあり、多くの部分からなる'text-decoration'のフォーマットが同時に明示されることを許すが、そのフォーマット処理の効果のおのおののもっとすばらしい制御を不可能にする。もっと具体的にいうと、下線、上線または貫く線の色または線のスタイルを制御する方法を何も提供しない。

CSS3はそのフォーマット処理の効果の付加的な制御を許している新しいプロパティを紹介することによって、モデルを拡張する。また、CSS3はほかの'text-decoration'の調整に少しも影響を及ぼさない可能性の上で、あるいはから離れて、そのフォーマット処理の効果を変えることになる。

なお、東アジアの縦の文書の場合において、下線の使用法を反映するために、新しい制御が下線の配置に関して提供され、これは、下線がフォーマット処理されたテキストの前に(縦のテキストの流れの場合において右側に)、または後に(縦のテキストの流れの場合において左側に)現れることを可能にする。そのプロパティは、'text-underline-position'と呼ばれる。

'text-decoration'というプロパティそれ自身は、今ではすべてのその新しいプロパティに対する簡略表記法のプロパティである。

それらのプロパティは、要素のテキストに加えられる装飾を説明する。ブロックの水準の要素に対して明示されれば、要素のすべての行中の水準の子孫に影響を及ぼす。もし行中の水準の要素に対して明示されれば、(つまり、影響を及ぼせば、)生成されるすべての枠に影響する。要素が内容やテキストの内容(たとえば、HTMLにおけるIMG要素)を何も持っていなければ、ユーザエージェントはこれらのプロパティを無視しなければならない。

最後に、ユーザエージェントは、子供のテキストの大きさと基準線に基礎付けられた'線'のテキストの装飾の太さと位置を平均するか、または別々におのおのの子供を処理するかのどちらでも選んでもよい。次に続く図は下線に対して平均する処理を示す。

下線の細長い線は、おのおのの、連続する、下に線を引かれたテキストの部分に対する、大きなテキストの比が増加するにつれて、もっと低く、そして太く、下線のテキストの3つの部分に描かれる。

注:一般的に下線の上付き文字のテキストの部分は平均され、一方下付き文字の部分はされない。

10.2. 下線の制御:'text-underline-style'、'text-underline-color'、'text-underline-mode'、'text-underline-position'というプロパティと簡略表記法の'text-underline'というプロパティ

このプロパティは下線のスタイルを明示する。可能な値:

none

下線なし

solid

実線の下線

double

二重線の下線

dotted

点線である下線。

thick

もっと大きな線の幅を用いているただひとつの線である下線。

dashed

破線である下線のスタイル。

dot-dash

点と短い線のパターンからなっている下線のスタイル。

dot-dot-dash

二つの点とひとつの短い線のパターンからなっている下線のスタイル。

wave

波線である下線。

single-accounting

ただ基準線の下であるよりもむしろ文字の下部の下に描かれるただ一つの線。

double-accounting

ただ基準線の下であるよりもむしろ文字の下部の下に描かれる二重線

このプロパティは下線に対する色を明示する。

初期値である'auto'は、'color'というプロパティによって決定されることを示す。

このプロパティは、下線に対する形態、つまり、下線が切れ目のないものであるかどうか、語の下にだけ現れ空白の下には現れないのかどうかを明示する。可能な値:

continuous

この値は下線が切れ目のないものであることを示す。

words

これは、空白でないテキストだけが下線を引かれることを示す。

このプロパティは、text-decorationというプロパティを通して定められるときの下線の位置を定める。その基準線の方向に対する関係におけるテキストの流れの'前'(横の流れにおいて上)または後(横の流れにおいて下)のいずれかに現れることができる。このプロパティは、下線をテキストの流れの'前'に現れさせることが望ましいかもしれない縦の文書のコンテキストにおいて一般的に用いられる。これは、下線が縦の文書の段の右側に現されていることに帰着する。

auto-pos

縦の行中の前進において、もしも定められれば、下線はテキストの後に現れるだろう。縦の行中の前進において、言語が日本語に定められているとすれば、もしも定められていれば下線はテキストの前に現れるだろう。

before

もしも定められていれば下線はテキストの前に現れるだろう。

after

もしも定められていれば、下線はテキストの後に現れるだろう。

このプロパティは、'text-underline-style'、'text-underline-color'、'text-underline-mode'および'text-underline-position'に対する簡略表記法である。

10.3. 貫く線の制御: 'text-line-through-style'、'text-line-through-color'、'text-line-through-mode'、プロパティと簡略表記法の'text-line-through'というプロパティ

このプロパティは貫く線のスタイルを明示する。可能な値:

none

貫く線なし

solid

ただひとつの線である貫く線

double

二重線の貫く線。

dotted

貫く点線。

thick

もっと大きな線の幅を用いているただひとつの線である貫く線。

dashed

貫く破線のスタイル。

dot-dash

点と短い線のパターンからなっている貫く線のスタイル。

dot-dot-dash

二つの点とひとつの短い線のパターンからなっている貫く線のスタイル。

wave

貫く波線

このプロパティは貫く線に対する色を明示する。

初期値である'auto'は、'color'というプロパティによって決定されることを示す。

このプロパティは、貫く線に対する形態、つまり、貫く線が切れ目のないものであるかどうか、語を貫いてだけ現れ空白の貫いては現れないのかどうかを明示する。可能な値:

continuous

この値は貫く線が切れ目のないものであることを示す。

words

これは、空白でないテキストだけが貫く線を引かれることを示す。

このプロパティは、'text-line-through-style'、'text-line-through-color'および'text-line-through-mode'に対する簡略表記法である。

10.4. 上線の制御:'text-overline-style'、'text-overline-color'、'text-overline-mode'というプロパティと簡略表記法の'text-overline'というプロパティ

このプロパティは上線のスタイルを明示する。可能な値:

none

上線なし

solid

ただひとつの線の上線

double

二重線の上線。

dotted

点線である上線。

thick

もっと大きな行の幅を用いているただひとつの線の上線。

dashed

破線である上線のスタイル。

dot-dash

点と短い線のパターンからなっている上線のスタイル。

dot-dot-dash

二つの点とひとつの短い線のパターンからなっている上線のスタイル。

wave

波線である上線

このプロパティは上線に対する色を明示する。

初期値である'auto'は、'color'というプロパティによって決定されることを示す。

このプロパティは、上線に対する形態、つまり、上線が切れ目のないものであるかどうか、語の上にだけ現れ空白の上には現れないのかどうかを明示する。可能な値:

continuous

この値は上線が切れ目のないものであることを示す。

words

これは、空白でないテキストだけが上線を引かれることを示す。

このプロパティは、'text-overline-style'、'text-overline-color'および'text-overline-mode'に対する簡略表記法である。

10.5. 下線を引く処理、乗船を引く処理、貫く線を引く処理および明滅する処理:'text-decoration'という簡略表記法のプロパティ

このプロパティは要素のテキストに加えられる装飾を説明する。もしもプロパティがブロックの水準の要素に明示されれば, すべての要素の行中の水準の子孫に影響を及ぼすだろう。inline-levelの要素に明示されれば、(あるいは、影響を及ぼせば、)要素によって生成されるすべての枠に影響を及ぼす。(たとえばHTMLの場合におけるIMG要素のように、)もしも要素が内容やテキストの内容を何も持っていなければ、ユーザエージェントはこのプロパティを無視しなければならない。

値は簡略表記法の説明(text-underline、text-overlineおよびtext-line-through)のプロパティの部分の組み合わせと、次に続くような明白な値の一そろいである。

none

テキストの装飾を何も生じさせない。

{ text-underline: none; text-overline: none; text-line-through: none; }

を用いることにおいて同等である。

underline

要素のテキストの内容は下線を引かれる。

{ text-underline-style: solid; }

を用いることにおいて同等である。

overline

要素のテキストの内容は上に線を持っている。

{ text-overline-style: solid; }

を用いることにおいて同等である。

line-through

要素のテキストの内容は中央を貫く線を持っている。

{ text-line-through-style: solid; }

を用いることにおいて同等である。

blink

テキストは明滅する(目に見えるのと目に見えないとの間を交互に繰り返す)。適合しているユーザエージェントは、この値をサポートすることを必要とされない。

テキストの装飾に対して必要とされる色は、最初は'color'というプロパティの値から得られるが、 個々のプロパティを用いることによって変更されることができる。加えるに、もしもテキストの装飾のスタイルが、テキストの装飾のいくつかに対してだけ存在するならば、結果は、たとえば、次に続く例におけるように、ほかの装飾のスタイルは初期値であるままであることになる。

P { text-decoration: "single accounting" blue; }

Pという要素の内容は、'single accounting'という下線を引くためのスタイルで青で下線を引かれるだろう。ほかのテキストの装飾は一つもそのスタイルを持っていないので、初期値(none)であるままである。

このプロパティは継承されないが、ブロックの枠の子孫の枠は、同じ装飾でフォーマットされるべきだ(たとえば、すべて下線を引かれるべきだ)。子孫の色は、たとえ子孫の要素が異なる'color'の値を持っていたとしても同じままであるべきだ。

A[href] { text-decoration: underline }

10.6. テキストの影:'text-shadow'というプロパティ

このプロパティは、要素のテキストに適用されるべき影の効果の、コンマで分けられたリストを受け入れる。影の効果は、明示された順序で適用され、したがってお互いを上塗りするかもしれないが、テキストそれ自身は決して上塗りしないだろう。影の効果は枠のサイズを変更しないが、その境界を越えて拡大するかもしれない。影の効果の積み重ねの水準は、要素それ自身に対するものと同じである

おのおのの影の効果は影の隔たりを明示しなければならず、かすんで見える半径と影の色は任意に明示してもよい。

影の隔たりは、テキストからの距離を示す二つの<length>という値で明示される。最初の長さの値は、テキストの右へ横の距離を明示する。負の横の値はテキストの左へ影を配置する。第2番目の長さの値は、テキストの下へ縦の距離を明示する。負の縦の長さはテキストの上へ陰を配置する。

かすんで見える半径は、影の隔たりの後に任意に明示されてよい。かすんで見える半径は、かすんで見える効果の境界を示す長さの値である。かすんで見える効果を計算するための正確なアルゴリズムは明示されない。

色の値は影の効果の長さの値の前か後に任意に明示されてよい。色の値は影の効果に対して基準として用いられるだろう。もしも色が明示されなければ、'color'というプロパティの値が代わりに用いられるだろう。

テキストの影は:first-letterおよび:first-lineという擬似要素で用いられてもよい。

H1 { text-shadow: 0.2em 0.2em }

H2 { text-shadow: 3px 3px 5px red }

H2 { text-shadow: 3px 3px red, yellow -3px 3px 2px, 3px -3px }

SPAN.glow {
    background: white;
    color: white;
    text-shadow: black 0px 0px 5px;
}

11. 文書の格子

11.1. 文書の格子とは何か

中国語あるいは日本語のような、東アジアの言語で書かれた文書の中の標識に対して、明示された一または二次元の格子にしたがってページの上にレイアウトされるために、たいへんありふれたものである。格子の構想は、ほかの、点字や、単一の空間を保たせられるレイアウトのような、表意文字でないコンテキストにおいてもまた用いられる。

下の図表は、日本人のユーザが、行ごとの9つの標識に帰着する格子(明晰のために示された灰色の格子の線)の上にレイアウトされることを意図した、混合の全角や半角の標識のあるページにおいて、横のテキストの断片を表す。

格子は標識の配置に影響を及ぼすだけでなく、また字下げの大きさ、マージンあるいは段落の整列のような、いくつかのほかのレイアウトに関係のある振る舞いであるその振る舞いも修正する。

中国語の場合おいてたいていだが、日本語の場合おいても時折使われる(別名"原稿")厳密なもの、日本語の場合において頻繁に、朝鮮語の場合において時々使われる厳密でないものも、点字、あるいは一般的に単一の間隔を保たせられるレイアウトのような、表意文字でないテキストにもしかすると役に立つ固定したものも、格子の三つの種類を区別することができる。

格子の種類は、UAがテキストの行をレイアウトするときどれだけ多くの適応性を可能にされるかを決定するレイアウトの規則の一そろいを必然的に伴う。

異なった格子が文書の違った場所に対して定義されることができる。

格子はテキストの断片の上にどちらか一方の次元において、選択的に動作しないようにされることができる。

行の格子は、個々の段落に対して動作しないようにされることができる。もしも行の格子がある段落に対して動作しないようにされれば、段落の行は、まるで行の格子が何も明示されていないかのようにレイアウトされる。動作しないようにされた行の格子のある段落の中の標識は、もしも明示されていれば、文字の格子を伴う。

この項で説明されたCSSのモデルは、作者が制御するために必要とする必要な格子のパラメータを受けさせる。

11.2. 格子の種類:'layout-grid-type'というプロパティ

用いるための格子の種類を明示する。格子が動作可能にされ、明示されているとき、おのおのの格子の種類は、描写している内容に対する規則の違った一そろいを必然的に伴う。可能な値:

loose

一定の幅の増加が次のとおりすべての標識に適用される日本語やたまに朝鮮語において用いられる格子の種類。

• (半角のかなはもちろん)全角の標識は、'layout-grid-char'によって明示された量と等しいスペース処理の増加を受け取る。
• (続けがきのフォントでフォーマットされた結合された標識と標識を除いては、)ほかの半角の標識は、(UAが自由に違った量を選ぶことができるが、)全角の標識に適用される半分の増加を受け取る。
• すべてのほかの(すなわち、結合された)標識は、少しもスペース処理の増加を受け取らない。換言すれば、まるで文字の格子のセットが何もないかのようにふるまう。

下の図表は格子の種類を説明する。

図の10.2.1:looseの格子におけるスペース処理の増加の配分 dFは全角の標識の間に適用されるスペース処理の量を表す。looseの格子のコンテキストの場合において、その量は'layout-grid-char'によって定められる。

図の10.2.2:混合されたテキストに適用されたlooseの格子

この形態の場合において、全角の標識あるいは(いくつかのカタカナの標識のような)ちょうどの半角の標識が使われさえしていれば、結果が実際上strictの格子のように見えるかもしれない。しかしながら、すべてのほかの幅の調整が有効であれば(テキストの両端のそろえ、文字の幅の調整、テキストの独自のスペースなど)、最終の結果は、一般的に、厳密でなく整列された格子のレイアウトである。テキストの流れの最初の部分は別として、格子は表意文字でない文字が流れにおいて現れてすぐに、'変則'のものとして現れるだろう。

strict

伝統的に中国語でも、時折日本語(別名"原稿")および朝鮮語で用いられる格子の種類。この形態はさまざまな文字のセットに次に続く方法で適用する。

• ただひとつの格子のスペースの中に合うことができる(半角のかなはもちろん)おのおのの全角の標識は、格子のスペースの横の中央に描写される。格子のスペースの幅は、'layout-grid-char'の調節によって決定される。
• 続けがきで半角、そして結合された標識は、ただ一片として扱われ、そしてそれは中に合うように必要な格子のスペースのもっとも小さな数の中央に配置される。まるで、'layout-grid-mode'というプロパティが、そのあたりで'none'または'line'に定められたかのように振舞う。もしもその一片の中で行分けが起これば、ただ一片に対してのそれらと同じ規則にこの配置が従う、二つの分かれた別々の一片として、一片は扱われる。
• 分けることができない物体(たとえば、画像)とある理由でただひとつの格子のスペースより幅の広い全角の標識は、合うのに必要な格子のセルの最も小さい数の中に、中心におのおのおかれる。

図の10.2.3:strictの格子における混合した標識のレイアウト

図の10.2.4:の格子における物体のレイアウト

strictという形態は、すべての特別のテキストの両端のそろえおよび、要素の内容に標準的に適用される、標識の幅の調整を動作しないようにされる。

行分けの機会が行の境界を超えているテキストの流れの中に見つけられることができなければ、テキストの流れは次の行に下へ推し進められるだろうし、前の行の最後の部分は、左の余白になるだろう。

ここに格子における混在するテキストの例がある。

図の10.2.5:混合したテキストに適用されたstrictの格子

fixed

この種類の格子は、単一の間隔を保たせられたレイアウトを成し遂げるために用いられる。レイアウトの規則は簡単である。すべての接続されていない標識が同等のものとみなされる。すなわち、どの標識もみな、デフォルトによってたった一つの格子のスペースの中に中心におかれる。接続された標識は、'strict'の格子の中と同じ方法で一片とみなされる。両端のそろえ、あるいはほかの文字の幅を変えるためのどんな振る舞いでも、動作しないようにされる。

図の10.2.6:fixedの格子の場合における混合した標識のレイアウト

たとえば、

図の0.2.7:混合したテキストに適用されたfixedの格子

11.3. 行の格子の値:'layout-grid-line'というプロパティ

このプロパティは要素に対して行の格子の値を定める。もしも要素のテキストのレイアウトの流れが横ならば、このプロパティは"縦の"格子の大きさまたは格子の高さとみなされることができる。言い換えれば、レイアウトの流れの形態にかかわらず、常に行のスペース処理の増加を決定する。効果は、'line-height'の値を適用するという効果と、見た目はやや似通っている。'line-height'というプロパティはどうかといえば、ブロックの前進の方向と関係がある効果を持つ。横の流れの形態の場合においては高さに、また、縦の流れの形態の場合においては幅に、影響を及ぼす(レイアウトの流れの形態は'writing-mode'というプロパティによって制御される)。

このプロパティが効果を持つためには、'layout-grid-mode'が'line'か'both'に定められなければならないことに注意せよ(後者は初期値である)。

このプロパティが'none'よりほかの何に定められても、テキストの行は、デフォルトによって、格子の列の中で縦の中心におかれ、基準線とともに整列される。もしも計算されたline-heightが格子のスペースより大きければ、全体の行の枠は、行の枠が合うのに必要な格子の列の最も小さい数の中で中心におかれる。始まっている整列の点はそれに応じて移される。これは下で例証される。そこでaは数の'layout-grid-line'の値を表し、bとcは、計算されたline-heightと、それぞれlayout-grid-lineかまたは二倍の値かのいずれかとの間の、半分の違いである。

可能な値:

none

どんな行の格子も明示されない。

auto

格子の行の大きさは計算されたline-heightによって決定される。

<length>

行の格子の単位のスペースの大きさ(別名"行のピッチ")。

<percentage>

親の要素の論理的な高さに比例する行の格子の単位のスペースの大きさ。もしも親がどんな明示的な高さも持っていなければ、'auto'とみなされる。

一定のline-heightの計算に関する限り、ルビの枠は特別に扱われる。line-heightの決定の過程と類似した仕方の場合において、ただルビの基部の要素だけが、中心におくための目的のためによく考えられるが、上に述べたおよび/あるいは後のスペースは、格子の行のスペースの中の基部のテキストの上および/あるいは後に合うのに十分であるべきだ。もしもこれがその場合でなければ、格子の行の大きさは全体のルビの枠があうまで格子の列の倍数に増やされる必要がある。

次に続くマークアップ、

DIV.section1 { writing-mode: lr-tb; layout-grid-line: .5in }

は、横にレイアウトされた文書の部分の場合において、テキストのおのおのの行を0.5インチの縦のスペースの中に描写されるようにするだろう。また、下に示されるように、0.5インチのline-heightを持っているのとも同等である。

もしもその部分のレイアウトの流れが縦であれば、0.5インチが縦のテキストのおのおのの縦の段の幅である。このとき、0.5インチの値はおのおののセルの'幅'に適用される:

もしも作者が、むしろ要素の中に現れるための行の明白に示された数(たとえば20)のほうを好めば、パーセンテージの値を用いるだろう。

DIV.section1 { layout-grid-line: 5% }

11.4. 文字の格子の値:'layout-grid-char'というプロパティ

、もしも、'layout-grid-type'というプロパティが'strict'または'fixed'に定められるならば、文字の(つまり、もしも横のレイアウトの場合においてならば"横の")要素に対する格子の大きさを制御する。しかしながら、もしも、'layout-grid-type'が'loose'ならば、このプロパティは、おのおのの全角の標識に加えられる増加と、'layout-grid-type'の詳述の中の説明により、間接的に半角の標識に加えられた増加の、大きさを定める。'loose'の格子の場合におけるその効果は、'letter-spacing'というプロパティの効果にやや類似する。'layout-grid-line'というプロパティは、ブロックの前進の方向に関係がある効果を持っている。横の流れの形態は幅を、そして縦の流れの形態の場合においては高さに影響を及ぼす(レイアウトの流れの形態は、'writing-mode'というプロパティのよって制御される)。

このプロパティが効果を持つためには、'layout-grid-mode'が'line'か'both'に定められなければならないことに注意せよ(後者は初期値である)。

可能な値:

none

文字の格子なし。

auto

要素のフォントにおける最も幅の広い標識の幅が、文字の格子として用いられる。

<length>

格子の単位のスペースの幅。

<percentage>

親の要素の論理的な幅に比例する格子の単位のスペースの幅。もしも親がどんな明示的な幅も持っていなければ、'auto'とみなされる。

DIV.section1 { layout-grid-char: .5in }

は、横のレイアウトされた文書の一部におけるおのおのの標識を、0.5インチ横のスペースの中に描写させる。

もしも部分のレイアウトの流れが縦であれば、0.5インチは、縦の段における連続する文字の間の縦の距離になる。

もしも作者が、むしろ行の中に現れるための行の明白に示された数(たとえば5)のほうを好めば、パーセンテージの値を用いるだろう。

DIV.section1 { layout-grid-char: 20% }

11.5. 格子の形態:'layout-grid-mode'というプロパティ

このプロパティは、選択的に、格子の二つの次元を動作可能にするか、動作しないようにする。可能な値:

none

格子はどちらの次元においても有効ではない。

line

ただ行の格子だけが用いられる。これは、行中の使用が、テキストの流れの上の横の格子を動作させないように推薦される値であり、含まれる標識の性質にかかわらず、たった一つの単位として格子の中にレイアウトされる"一片"に変える。

char

ただ文字の格子だけが用いられる。行の行使は動作しないようにされる。これは、段落のような、ブロックの水準の要素の上の使用を推薦される値で、それに対して行の格子は動作しないようにされるつもりである。

both

(もしもbothが明示されれば、)両方の次元における格子を動作可能にする。この調整は、完全に要素の上のレイアウトの格子を動作可能にする。これは初期値である。

11.6. レイアウトの格子:簡略表記法の'layout-grid'というプロパティ

'layout-grid'というプロパティは、スタイルシートの中で同時に'layout-grid-mode'、'layout-grid-type'、'layout-grid-line'と'layout-grid-char'を定めるための簡略表記法のプロパティである。簡略表記法のプロパティに関して値である'none'を用いることは、'layout-grid-mode'を'none'に定める。値である"none none"を用いることは、'layout-grid-mode'と'layout-grid-line'を'none'に定め、値である"none none none"を定めることは、前のプロパティも、'layout-grid-char'も'none'に定める。

明示された最初の数、パーセンテージ、あるいは'auto'の値は、'layout-grid-line'を定める。もしも、第2番目の数、パーセンテージ、あるいは'auto'の値があれば、'layout-grid-char'を定める。たとえば、

DIV.section1 { layout-grid: both strict .5in 20% }

上の'layout-grid'というプロパティは、'layout-grid-type'を'strict'に定めさせ、'layout-grid-mode'を'both'に、'layout-grid-line'を0.5inに、そして'layout-grid-char'を親の幅の20%にするために定められる。

注意

• <line>が任意の<char>に先んずる理由は、日本語において、文字の格子は、可能であるけれども、必要とされない。横の日本語のテキストにおいて、行の格子が文字の格子なしにしばしば用いられる。
• 簡略表記法のプロパティの初期値は、定義されないけれども、当然、含まれるプロパティの初期値から由来するような下記と思われる。

   { layout-grid: both loose none none }

  'none'という値は、格子を無効にする。ほかの'layout-grid-line'または'layout-grid-char'に関するどんなほかの値を定めるのであっても、その形態のどちらか一方あるいは両方において格子を有効にするだろう。

• 'layout-grid-line'および'layout-grid-char'の効果は'layout-grid-mode'の値に左右されるから、それらの2つの調整に対する値を提供することにより、何の効果も持っていないだろう状況を創造することは可能である。たとえば、次に続く調整において、

  DIV.section1 { layout-grid: strict line .5in 20% }

  20%という'layout-grid-char'の調整は有効にされないだろう。しかしながら、もっと後の'layout-grid-mode'を'both'かまたは'char'に変えれば、 有効になるだろう。制御のこの意義は、さまざまな次元が、テキストの部分に対して選択的に時折動作しないようにしたり、あるいは動作可能にしたりされるのではなく、同じ格子の次元が全体の文書中に使われるシナリオの場合において非常に役に立つ。

11.7. 'gd'という長さの単位

要素における格子の存在は、格子の単位の見地からその要素の中のさまざまな寸法を表現するのに非常に役に立つ。格子の単位は、東アジアの印刷の体裁において、特に左、右、上、下の要素のマージンに対して、非常に頻繁に用いられる。

それゆえ、作者に要素の見地からさまざまな寸法を明示することを可能にさせる、gdという新しい長さの単位が必要である。

たとえば、次に続くスタイルをよく考えよ。

P { layout-grid: strict both 20pt 15pt; margin: 1gd 3gd 1gd 2gd }

このように、すべてのPの要素は、15ptの上のマージン、60ptの右のマージン、60ptの右のマージン、40ptの左のマージンを事実上得る。

もしも要素が何も明示されなければ、gdという単位は、emという単位と同じとみなされるべきだ。

編集者の注:これは単位の定義のモジュールに移されるべきだ。

12. 種種雑多なテキストのフォーマット処理

12.1. 大文字使用:'text-transform'というプロパティ

このプロパティは要素のテキストの大文字使用の効果を制御する。値は以下に続く意味を持つ。

capitalize

おのおのの単語の最初の文字を大文字でで置く。

uppercase

おのおのの単語のすべての文字を大文字で置く。

lowercase

おのおのの単語のすべての文字を小文字で置く。

none

大文字使用の効果なし。

わずかであるけれども、ケースをマップするための処理には言語の依存がいくつかある。よく知られた例の中に、トルコ語とギリシャ語がある。HTMLの要素の言語を見つけるための方法としては、HTML[HTML40]を見よ。XMLはXML:LANGと呼ばれる属性を用い、そして言語を決定するためのほかの言語特有の方法があるかもしれない。

ユニコードの標準の3.0によって明示される文字のレパートリーに対するケースをマップするための規則は、ユニコードの協会のhttp://www.unicode.orgのウェブサイト上で見つけることができる。

適合するユーザエージェントは、ユニコードの標準の3.0にしたがって、その標準によって明示されるすべての文字に対して、ケースをマップする規則をサポートしなければならない。適合の規則は、CSSのもっと初期のバージョンより厳重であることに注意せよ。

H1 { text-transform: uppercase }

12.2. 句読点の送り込み:'punctuation-wrap'というプロパティ

このプロパティは、句読点の記号が、もしあれば、パディングあるいはマージンの範囲の中の、内容の範囲の外側に配置されてもよいかどうかを決定する。句読点が、行の末尾でぶら下がることを可能にすることは、東アジアの印刷の体裁の場合において、ありふれた慣習である。句読点の有効な描写を許すための意味のあるパディングやマージンの範囲を創造することは、スタイルの作者の責任である。また、この効果から独立して、句読点の文字の圧縮を含めて、行の中で圧縮が起こるかもしれないことも注意されるべきことだ。

可能な値:

none

句読点が内容の範囲の外側に配置されることは許されない。

start

先導する句読点が、もしあれば、内容の範囲の最初に突き出るかもしれない。パディングまたはマージンの範囲の配置される。

end

終わるところの句読点が、もしあれば、内容の範囲の末尾に突き出るかもしれない。パディングまたはマージンの範囲の中に配置される。

both

句読点が、もしあれば、内容の範囲の出だしかまたは末尾で突き出るかもしれない。

ここに突き出る処理が許されない例がある。

図の11.2.1:ぶら下がっている句読点は少しも許されない(明晰のために青で示された先行する句読点および文字)

次に続く例の場合においては、突き出る処理は内容の末尾で許容される。

図の11.2.2:行のパディングの領域の末尾に現れているぶら下がっている句読点(明晰のために青で示された先行する句読点および文字)

注:ユーザエージェントは、ただ最初の行だけか、またはすべての行かのいずれかを切り落とすために、文字体系の慣習に従うべきだ。ローマ字のテキストの中では、ただ最初の行の最初の点に現れている句読点だけが内容の範囲の外側に配置されるかもしれない。ほかの行においては不適切に見える。以下に続く図は現在の使用を示す。

12.3. テキストの結合処理:'text-combine'というプロパティ'

このプロパティは混成の文字(別名"組み文字")または行(別名"割注")の創造を制御する。

可能な値:

none

混成の文字は創造されない。

letters

大きさにおいて減らし、そして、おのおのに接してまたは/かつ上部に積み重ねることによって、たった一つの全角の標識のスペースの中に合うように標識を創造する。この効果は、JIS[JIS]においては直接に定義されていないが、アジアの印刷の体裁においてよく使われる。

5つより多くない標識が一度に結合されることができる、もしも五つより多い標識がこのプロパティの調整とともに要素の中に含まれれば、ただ最初の五つの標識だけが結合されるべきだ。残りは正規のテキストとして描写されるべきである。以下に続くテキストは、2、3、4および5つの文字に対する配置を示す。

図の11.3.1:有効な"組み文字"の配置

以下のマークアップ、

SPAN.kumimoji { text-combine: letters }

は、以下に続く4つの文字がひとつの文字として現れるようにすることができる(明晰のために青で示される)。

図の11.3.2:四つの文字に適用された"組み文字"

lines

等しい長さと高さである二行の中に合うように、標識を結合する。そして、その結合された高さは、規則の特別のセット[JIS]にしたがって、現れる行の高さよりわずかに大きい。この結合はJISによって明示されたような二行に制約される。これは、この特徴に対してアジアのコンテキストの中に見つけられる一般的な使用法である。

図の11.3.3:"割注"の中の標識のレイアウト

次に続くマークアップ、

SPAN.warichu { text-combine: lines }
    

は、取り囲まれたテキストを次に続くように見えさせる(明晰のために青で示される)。

図の11.3.4:10の文字に適用された"割注"

Note that それを成し遂げるための正確なアルゴリズムは些細なものではないことがありうるが、"割注"は、行にまたがって、分かれることも許される。また、割注のテキストは、丸括弧の内側に取り囲まれる。それらの丸括弧は、作者によって挿入される。

13. プロパティの索引

14. Profiles

この章によって定義される三つのモジュールがある。

CSS1のテキストのモデル:

CSS2のテキストのモデル:

CSS3のテキストのモデル:

CSS1のテキストのモジュールは、次に続くプロパティ値から作られる。

以下に続く表は、CSS2のテキストのモジュールを説明する。すべてのプロパティが、'inherit'という値を追加していて、媒体の種類を持っているから、すべてのCSS1のプロパティはなお示されている。加えられたプロパティは、'direction'、'text-shadow'および'unicode-bidi'である。さらに、'text-align'および'vertical-align' は、それぞれ<string>と<length>という新しい値を持っている。最後に、'vertical-align'は、表のセルの要素にもまた適用する。

CSS3のモジュールは次に続くプロパティを追加する。

• テキストのレイアウトの流れ:'glyph-orientation-horizontal'、'glyph-orientation-vertical'、'writing-mode'、'script'、
• テキストの整列と両端のそろえ:'min-font-size'、'max-font-size'、'text-align-last'、'text-justify'、'text-justify-trim'、'text-kashida-space'、
• 基準線の整列:'alignment-adjust'、'alignment-baseline'、'baseline-shift'、'dominant-baseline'、
• 行分け:'line-break'、'word-break'、'word-break-CJK'、'word-break-inside'、'word-break-wrap'、
• テキストの送り込み、空白制御およびテキストのあふれ:'text-overflow'、'text-overflow-ellipsis'、'text-overflow-mode'、'text-space'、'text-wrap'
• テキストのスペース処理:'kerning-mode'、'kerning-pair-threshold'、'punctuation-trim'、'text-autospace'、
• テキストの装飾:'text-line-through'、'text-line-through-color'、'text-line-through-mode'、'text-line-through-style'、'text-overline'、'text-overline-color'、'text-overline-mode'、'text-overline-style'、'text-underline'、'text-underline-color'、'text-underline-mode'、'text-underline-position'、'text-underline-style'
• 文書の格子: 'layout-grid'、'layout-grid-char'、'layout-grid-line'、'layout-grid-mode'、'layout-grid-type'、
• 種々雑多:'punctuation-wrap'、'text-combine',

また、説明されるように以下に続くプロパティを修正もする。

• 'text-align'は、'start'および'end'という2つの値を持っている。
• 'text-decoration'は、CSS2の振る舞いに加えて以下に続くプロパティの簡略表記法のプロパティになる。'text-line-through'、'text-overline'、'text-underline'。
• 'vertical-align'は、'auto'という一つの新しい値を持っていて、その初期値を'auto'に変えさせる。
• 'word-spacing'は、'none'という新しい値を持っている。

15. 用語集

"Bopomofo"

中国語において、特に北京官話において、音声体系として用いられる37の文字と4つの語調の印。

"ハングル"

韓国語の文書体系のサブセット。

"Hanja"

中国の文書体系から借りられたり、あるいは取り入れられた表意文字を利用する朝鮮語の文書体系のサブセット。

"ひらがな"

日本語の単語を表現するための表音文字からなっている日本語の文書体系のサブセット。カタカナも見よ。

表意文字

個々の単語や熟語ではなく、物事または考えを表現する中国(あるいは概して東アジア)の文書体系における文字。

"かな"

もっぱら外国の単語を書くために、あるいは漢字との組み合わせの中でのみ用いられることができる文書の日本語の文字体系の音節を表すサブセット

"漢字"

中国語の文書から借りられたり、あるいは取り入れられた表意文字を利用する日本語の文書体系のサブセット。Hanjaも見よ。

"Kashida"

アラビア語の延長の文字

"カタカナ"

ローマ字の単語を表現するために用いられる表音文字からなっている日本語の文書体系のサブセット。カタカナも見よ。

"禁則"

行分けの制限のセットに対する日本語の条件。

"組み文字"

大きさにおいて減らされ、そしてたった一つの文字の空間の中に合うように結合される5つまでの文字からなる合成の文字。

Logograph, Logogram

全体の単語を表現する中国語(あるいは概して東アジア)の文書体系における文字。

ルビ

テキストの別の流れの近くに現れ、そしてそのテキストのための記注か発音の指針として役に立つテキストの流れ。

"縦中横"

縦のテキストの段の内部の横のテキストの流れ。年のようなある数を表示するために東アジアの文書の中でしばしば用いられる。

"割注"

等しい高さと長さの二つの行としてテキストの行の内部に現れる、減らされたフォントの大きさであるテキストの流れ。

付録 A:CSSのプロパティに関する縦のレイアウトの効果

Note that the contents of this section are currently under discussion among the XSL, CSS&FP and I18N Working Groups.

In general, the existing [CSS2] properties that imply directionality or position are absolute, i.e. "left" means "left" and "top" means "top" regardless of the writing mode of the page. The purpose of this appendix however is to list the exceptions to that rule and clarify ambiguities. If a property does not appear in this list, it is intended to be interpreted as absolute, i.e. it does not rotate when the layout mode changes.

Editor's note: Clear and float are two properties where the name of the values are really misnomer. 'top' and 'bottom' which have been proposed are pretty much meaningless in a vertical flow. Interpreting them in a relative meaning is also problematic. The editor is suggesting to:

• add 'start' and 'end' values to the float and clear properties

• do not add 'top' and 'bottom'

• say that the behavior of 'left' and 'right' is UA dependent in vertical inline progression

• 'left' and 'right' are deprecated, 'start' and 'end' should be used instead.

• see the description of the text-align property as the problem and the solution are very similar.

付録 B:基準線の整列の使用(知識を与えるもの)

The following appendix shows some examples of baseline alignment, exercising the related properties .

A simple example of alignment is shown in the following figure. The figure shows the presentation of two inline elements, one inside the other. These inline elements make up the content of a line in a block where the writing-mode is "lr-tb" and the font is "Helvetica". The structure of the example is as follows:

<p><span class="outer">Apex <span class="inner">Top</span></span></p>

with the style being defined as:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }

The other baseline alignment initial values apply. Since a horizontal writing-mode is in use, the dominant-baseline-identifier is set to "alphabetic" and the baseline-table is taken from the nominal-font for the block in which the line appears, which, in this case, is Helvetica.

In the figure, the positions of the baselines relative to the current font size are shown as red (staff) lines. These lines are labeled with abbreviations of the names of the baselines (e.g., TBE for "text-before-edge"). The baseline identified by the dominant-baseline-identifier (A) is shown in blue. There is a break in the staff lines to separately show the inner inline element. This is not necessary for this example, but this distinction will become important in subsequent examples.

The "alignment-baseline" property is the primary control on the positioning of an inner element with respect to its parent. The initial value of the "alignment-baseline" property is "baseline". This aligns the dominant-baseline of the inner inline element with the dominant baseline of the outer inline element. This is shown by the short blue line that connects the two separated staffs (A) in the figure.

The glyphs that are in the content of the two elements are aligned based on the script to which the glyph belongs. Since this example only has Latin glyphs, they are aligned to the "alphabetic" baseline.

In the next figure, the content of the inner inline element is in Gurmukhi, the script of the Punjabi language. The Gurmukhi syllables are read as, "guru". Rather than use Unicode values for these characters, they are symbolized by placing the Latin transliteration in italic type. The structure of the example becomes (assuming the same style):

<p><span class="outer">Apex <span class="inner">guru</span></span></p>

The only change from the previous example is that the glyphs of the Gurmukhi script are aligned to the "hanging" baseline of the inner inline element. The alignment of that element itself, with respect to the outer inline element, is unchanged. The "hanging" baseline position is computed from the font-table part of the dominant-baseline set of the parent element (in this case the outer inline element which is getting itself the set from its parent, the block element).

In the next figure, fragments of the text of the previous examples make up the content of the outer inline element. The inner inline element has a change of font-size, however. The structure is:

<p><span class="outer">Apguru <span class="inner">Exji</span></span></p>

with the following style:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }
span.inner { font-size: .75em; }

In this example, the alignment of the inner inline element itself does not change, nor does the alignment of the smaller glyphs inside the inner element. The Latin glyphs are still aligned to the "alphabetic" baseline and the Gurmukhi glyphs, which are pronounced "ji" are aligned to the "hanging" baseline. Note also that just changing the "font-size" property did not change the baseline-table in effect in the inner inline element.

The next figure is equivalent to the previous example with the Gurmukhi character replaced by ideographic characters. These are aligned to the "ideographic" baseline.

To change the scaling of the lines of the baseline table, it is necessary to use the "dominant-baseline" property on the inner inline element. The value of "reset-size" causes the baseline-table font-size to be reset from the font-size of the element on which the "dominant-baseline" property appears. The next figure shows the effect of this, using the structure:

<p><span class="outer">Apguru <span class="inner">Exji</span></span></p>

with the following style:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }
span.inner { font-size: .75em; dominant-baseline: reset-size; }

The alignment of the inner inline element, with respect to the outer inline element, is still determined by aligning the dominant baselines (alphabetic). But, the baseline-table of the inner inline element has been rescaled to the font-size of the inner inline element. Hence the smaller glyphs align with each other.

But, what if it is more important that the small Gurmukhi glyphs align with the large Gurmukhi glyphs than having the Latin glyphs align. There are at least two ways to achieve this. The structure:

<p><span class="outer">Apguru <span class="inner">Exji</span></span></p>

with the following style:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }
span.outer {dominant-baseline: hanging }
span.inner { font-size: .75em; dominant-baseline: reset-size; }

is illustrated in the next figure. The "hanging" baseline becomes the dominant baseline and the initial value of the "alignment-baseline" property causes the (newly) dominant "hanging" baselines to be aligned as is shown by the connection of the blue baselines.

It is also possible to achieve the effect of the above figure without changing the dominant baseline. Instead it is sufficient to explicitly specify that the inner inline element is aligned on its "hanging" baseline. This is done by:

<p><span class="outer">Apguru <span class="inner">Exji</span></span></p>

with the following style:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }
span.inner { font-size: .75em; dominant-baseline: reset-size; alignment-baseline: hanging; }

The only change this approach would make in the above figure is to color the "hanging" baseline red and keep the "alphabetic" baseline as the (blue) dominant baseline. This baseline in the inner inline element would not (as it does not in the above figure) align with the "alphabetic" baseline in the outer inline element.

Another baseline alignment property is the "baseline-shift" property. Like the properties other than the "dominant-baseline" property, this property does not change the baseline-table or the baseline-table font-size. It does shift the whole baseline table of the parent element so that when an inner inline element is aligned to one of the parents baselines, the position of the inner inline element is shifted. This is illustrated in the next figure. The structure which creates this figure is:

<p><span class="outer">Apex <span class="inner">1ji</span></span></p>

with the following style:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }
span.inner { baseline-shift: super; }

Because the whole set of baseline-table staff lines are shifted to the position of the superscript baseline: it does not matter to which baseline the glyphs in the superscript are aligned. The European number "1" is aligned to the "alphabetic" baseline and the Gurmukhi syllable "ji" is aligned to the "hanging" baseline.

It is more common for the font-size of the superscript text to be smaller than the font-size of the text to which it is appended. Consider:

<p><span class="outer">Apex <span class="inner">1ji</span></span></p>

with the following style:

p { writing-mode: lr-tb; font: Helvetica; }
span { alignment-baseline: auto-script; }
span.inner { baseline-shift: super; font-size: .75em; }

Because changing the font-size on a superscript (or subscript) is common, this is the one case where changing the font-size does cause the baseline-table font-size to be reset when the "dominant-baseline" property has its initial value. After the rescaling, the default alignment to the dominant baseline positions the inline element for the superscript to the dominant baseline position in the shifted baseline-table of the parent element.

謝辞

この仕様書は、

Ayman Aldahleh, Stephen Deach, Martin Dürst, Laurie Anna Edlund, Ben Errez, Yaniv Feinberg, Arye Gittelman, Richard Ishida, Koji Ishii, Masayasu Ishikawa, Michael Jochimsen, Eric LeVine, Chris Pratley, Rahul Sonnad, Frank Tang, Chris Thrasher, Masafumi Yabe.

のかたがたの手助けがなければ考えられなかったであろう。

参考文献

[CSS2]

Cascading Style Sheets, level 2 (CSS2) Specification, W3C Recommendation

Bert Bos, Håkon Wium Lie, Chris Lilley and Ian Jacobs, 12 May 1998
Available at: http://www.w3.org/TR/REC-CSS2

[HTML4]

HTML 4.0 Specification, W3C Recommendation

Dave Raggett, Arnaud Le Hors and Ian Jacobs, 18 December 1997, latest revised 24 December 1999
Available at: http://www.w3.org/TR/REC-html40

[ISO 15924]

International Organization for Standardization. ISO 15924:1998. Code for the representation of names of scripts. Draft International Standard.

[SVG 1.0]

Scalable Vector Graphics (SVG) 1.0 Specification

John Ferraiolo, 03 March 2000
Available at: http://www.w3.org/TR/SVG/

[UNICODE]

The Unicode Standard Version 3.0

The Unicode Consortium, Addison-Wesley, 2000. ISBN 0-201-61633-5
Additional technical reports (including TR#14) available at: http://www.unicode.org/

[JIS]

Line composition rules for Japanese documents

JIS X 4051-1995, Japanese Standards Association, 1995 (in Japanese)

[RUBY]

Ruby Annotation, W3C Working Draft

Masayasu Ishikawa (and others), 17 December 1999
Available at: http://www.w3.org/TR/ruby

[XSL]

Extensible Stylesheet Language (XSL) Specification, W3C Working Draft

Stephen Deach, 27 March 2000
Available at: http://www.w3.org/TR/xsl

前の策定中の草案からの変更