Hebikuzure's Tech Memo

2009年6月20日

CSS コーナー: writing-mode

Filed under: Internet Explorer — hebikuzure @ 11:15 AM

The CSS Corner: writing-mode
http://blogs.msdn.com/ie/archive/2009/05/29/the-css-corner-writing-mode.aspx


ちょっと遅れ気味ですが、IE Blog の試訳を続けています。

以下の文章は IE Blog の 5/29 の記事 The CSS Corner: writing-mode を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


CSS コーナー: writing-mode

はじめに

writing-mode プロパティは日本語やアラビア語のような非ラテン言語のテキスト レイアウトを可能にします。このプロパティは IE 5.5 からサポートされていますが、IE8 で大幅に更新されています。この分野での目標は:

  • 開発者にとってより予測しやすい動作にする
  • shrink-to-fit サイズ変更のような新しい相対的な CSS のコンセプトに則る
  • 初期的な実装を提供する事により CSS3 Text Layout を促進する

この記事では新しい実装とその背景について、実地に試すのに必要な基本を一通り解説したいと思います。皆さんのフィードバックをお待ちしています!

基本事項プロパティと値

writing-mode は CSS3 Text Layout で定義されていますが、手短に言えば ‘direction (書字方向)’ と ‘block-progression (ブロック進行方向)’ のプロパティです。書字方向は行内での文字の流れと考える事ができ、ブロック進行方向は行の流れの方向と考える事ができます。以下の表は (多くは仕様から借用しています) 取る事が可能な 8 つの値を示しています。

writing-mode direction block-progression 一般的な使用方法:
lr-tb ltr Tb ラテン語基本、ギリシャ語、キリル語書字体系(およびその他多数)
rl-tb rtl Tb アラビア語、ヘブライ語書字体系
tb-rl ltr Rl 縦書きの東アジア書字体系
bt-rl rtl Rl 東アジアの縦書きテキストに引用されて埋め込まれたアラビア文字
tb-lr ltr Lr モンゴル語書字体系
bt-lr rtl Lr モンゴル文字ドキュメントに引用されて埋め込まれたアラビア文字
lr-bt ltr Bt 存在しない
rl-bt rtl Bt 存在しない

(最後の 2 行は世界中のどの文字や言語でも使用されていないため現在未定義の組み合わせを参照しています。完璧を求めるため IE8 ではこれらも実装されています)

縦書きのテキスト レイアウトについて理解する上で、述語としての幅 (width) と高さ (height) の意味は文脈によって変化すると同意する事は重要です。私たちは幅や高さを、幅は常に水平方向で高さは常に垂直方向であるというように、常に物理的なプロパティとして扱っています。さらに 左 (left)、上 (top)、右 (right)、下 (bottom) も物理的と考えています。

writing-mode と縦書きテキストについて理解する最良の方法は、事例を通じる事です。以下のシンプルなサンプルが、サイズとオーバーフロー、テーブルについて理解する手助けになると思います。

ブロック範囲

縦書きのサイズのアルゴリズムでは、計算上幅と高さが入れ替わるので、横書きレイアウトで幅に使われていたアルゴリズムが、縦書きレイアウトでは高さに使われます。
このサンプルについて検討してみましょう:

ここでは二つの div 要素に幅と高さが設定されていません。最初の div 要素は親の body に対して平行しており、二番目は writing-mode が tb-lr に設定されているため直交しています。

最初の div はビューポートと同じ幅になり、高さはそのコンテンツにフィットしている事に注目してください。これは通常の CSS ルールに従っています。

二番目の div のサイズは高さと幅を入れ替えた状態に正確に相似しています – height (高さ) はビューポートのそれと同じとなり、幅はそのコンテンツにフィットしています。

この例ではビューポートが使われていますが、 body の高さが明示されている場合は、その値が期待される自動的な高さを計算するために使用されます。この動作の背景には、ユーザーは垂直のコンテンツへ (もし最初の水平の div が非常に長ければ) スクロールでき、すべてのコンテンツがビューポートの垂直方向にフィットしていれば水平スクロールを行う事ができるという理由があります。

このサンプルでは相対サイズ持つ二番目の直交するdiv を追加して、より興味深くなっています。

二番目の垂直な div は幅を 50% に設定されています; 物理的な幅はビューポート (body) の 50% になる事に注目してください。

最後のブロックが直前のブロックのに表示されるのは、 (body) のブロック フローが上から下へとなっているためである事にも注目してください。要素の writing-mode はエレメント自体のブロック進行方向にも影響すると考えるのは自然のように見えますが、それは事実ではありません。body のブロック進行方向を LR に変更すると、ブロックは横に並んで表示されるでしょう。さらに BODY 要素が水平にオーバーフローするのであれば、それは親要素の書字方向に従って行われるでしょう。この場合、HTML 要素が LR-TB であるので、オーバーフローは右向きになり、コンテンツの最初の部分が隠されます。これは微妙ですが非常に重要な点です。と言うのも多くのユーザーはオーバーフローに関わらずオリジン ポイント (コンテンツの一文字目が表示される場所) は常に表示される物だと考えているからです。その理由は、左と上へのオーバーフロー (LR-TB の指定があるとすれば) はスクロール可能ではなく、切り抜き可能な領域だからです (次のセクションを参照してください) 。

垂直方向のレイアウトでのオーバーフロー

垂直方向のレイアウトでのオーバーフローの取り扱い方は、いまだ議論の上にあります。IE8 はオーバーフローの方向に従ってスクロールバーを配置します。例えばコンテンツが要素の左側へオーバーフローするなら、垂直スクロールバーは左側に表示されます。

writing-mode:bt-rl が指定されていてオーバーフローするコンテンツを含む固定サイズの要素があるサンプルについて検討しましょう。

スクロールバーの位置とその初期状態に注目してください。コンテンツの開始位置は要素の物理的な最下部なので、それが垂直スクロールバーの初期位置になります。

別の興味深い事例は、要素がウィンドウに対して幅広過ぎてビューポートにスクロールバーが表示される場合です:

テキストの開始位置はスクリーンの外で、ユーザーはそれを表示するために右スクロールしなければなりません。さらに垂直スクロールバーはユーザーが右スクロールするとアクセスできなくなります。これは奇妙に思えますが、親要素 (body) の direction が LR-TB であるための期待される結果です。モードを混在させたページを開発する場合、オーバーフローの効果を考慮してください。

垂直のレイアウトとテーブル

垂直のテーブルの場合、行は垂直に、列は水平になります。次のマークアップを利用すると…

<body writing-mode=”??-??”>
     ABCDEF
     <table>
          <tr> 
              <td> 1 </td> <td> 2 </td> <td> 3 </td>
          </tr>
          <tr>
              <td> 4 </td> <td> 5 </td> <td> 6 </td>
          </tr>
          <tr>
              <td> 7 </td> <td> 8 </td> <td> 9 </td>
          </tr>
     </table>
</body>

…8 つのモデル全部の結果は以下の通りです:

テーブルのサイズはボックスのサイズと同じ原則に従います: 高さと幅の計算は入れ替わります。セルの幅 / 列の幅 / テーブルの幅の計算アルゴリズムが高さの値に使われます。セルの高さ / 行の高さ / テーブルの高さの計算アルゴリズムが幅の値に使われます。

パディング、マージン (余白) 、パーセント値

Web サイトのデザインに CSS を利用している Web 製作者のほとんどが、マージン相殺を理解するのに時間がかかる事を知っています。これは私たちが複数の書字方向を実装するにあたって、マージン相殺のロジックにいかなる複雑さも追加されないように制限する事を目標にした理由の一つです。本質的に、マージン相殺は CSS 2.1 – 8.3.1 と同じ規則に従っています。唯一の違いは、マージンがブロック進行方向に相殺される事です。その理由は、直交する方向の変更 (水平と垂直をひっくり返す) が起きた時、要素の方向の変更は ブロック整形コンテキスト (Block Formatting Context) に見合うからです。そのためネストした要素 (垂直のもの) のマージンは相殺されません。これを次のサンプルで示しています – ボーダーを持っていないコンテナであっても、ネストしたブロックのマージはコンテナ (ダーク ブルーのブロック) に相殺されていない事に注目してください。

パディングとマージンに使うパーセント値は論理的な幅に基づいて計算されます。親要素が水平のブロック進行方向の場合の計算された値はで、親要素が垂直のブロック進行方向の場合計算された値は高さです。

お読みいただいてありがとうございました。皆さんのコメントを注目しており、お聞かせいただくのを楽しみにしています。

Saloni Mira Rai – プログラム マネージャーと
Rossen Atanassov – ソフトウェア開発担当

広告

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。