フルードグリッド、それはグリッドに基づきつつも、どんなユーザーのブラウジング習慣にも柔軟に対応できるフルードなレイアウトを可能にします。実際にどのように作ることができるか、一緒に見て行きましょう。

# 279

フルードグリッド

昨年のはじめ、私はかなりコンテンツのボリュームあるサイトを手がけた。デザインに関する要望はそれほど多くはなかった:クライアントが要望したのは、現ロゴを用いることと、混みいったタイポグラフィーを改善して読みやすくすることだった。なのでデザインの初期段階で、私達は相当な時間を、きちんと定義されたグリッドを作るのに費やした。

ここ最近の数年間、このような考え方はより一般になってきている。Mark BoultonKhoi Vinhやその他の唱道により、タイポグラフィーグリッドや、それをどうやってウェブで使うかということに関する興味がまた復活してきているのがわかる。カジュアルにいえば、それらはスマッシュヒットであった。いくつ もの CSS フレームワークが生まれ、さまざまな ツールで補うことで、グリッドベースでつくるデザインはアベレージデザイナーにも広まってきている。なぜか?数分考えてみれば、それは明らかだ。デザイナーはより合理的で、コンテンツを整理するための構造的なフレームワークが得られ、ユーザーはより整理され読みやすいサイトを得られるからだ。

しかしながら、そのクライアントは心臓を止まらせるような要望を最後にひとつ持っていた:デザインはフルードデザインで、ブラウザウィンドウによってリサイズされること、というものだ。通常、このような要望を聞くと私はとてもやかましく呆れるほど喜んでしまう。フルードレイアウトは、その価値に値する評価を得られていない、ウェブデザインにとってとても有用なものである。フルードレイアウトを使うと、ユーザーの手と彼らのブラウジング習慣がデザインをコントロールする。そして同様に、フルードデザインは、ウェブデザイナーが想像していることを理解することが全くできない。

Minimum screen resolution (最小画面解像度): 小さな優しい嘘

フレキシブルなウェブデザインを追い求めるかわりに、私達は次の「優しい嘘」に依存してしまっている;minimum screen resolution である。この3つの言葉はパワフルな魔法を持っていて、fixed-width(固定幅)レイアウトを私達が次々と大量生産しているのに乗じて、きっとデザインを何年かごとに再考し、問題無いとみなせばその値をつりあげているのだ。“minimum screen resolution”のせいで私達は、その創作物は神とフォトショップが意図したもの、とみなす不自然なユーザーたちのためにデザインしてしまっている。このユーザーはいつも最大値の1024 x 768ウィンドウでブラウジングし、絶対にOLPCラップトップなんてものは使わないだろうし、少なくとも4年も前のモニターではネットを見ない。もしユーザーが“minimum screen resolution”以下のスペックしか持っていなくても、まぁ、彼らにはスクロールバーというものがあるでしょう?といった具合だ。

もちろん、私がそのサイトをコーディングしていた時は、fixed-widthレイアウトの害悪についてこきおろしを書いている余裕なんてなかった。そのかわり、より冷静な事実だけが残っていた:クライアントの要求に答えるためかなり複雑なグリッドをデザインしていたとき、そのクライアントーーそれはつまりクライアントのユーザーも含めてーーはフルードレイアウトを要求した、という事実。その時私が考えた殆どすべてのグリッドベースのデザインは、厳格なfixed-widthであり、私にはやっかいな疑問だけ残されていた:つまり、「どうやって フルードグリッド をつくればいいのか?」ということだ。

結果的に、それはたんにコンテクストの問題だった。

IEに感謝しないといけない?

乗り越えられそうにない問題にぶちあたり、私は一番得意なことをした:つまり全てを避けたのだ。fixedでないレイアウトのように動くグリッドをどうやって作るか、という課題を一時的に脇へ置き、自分が知ってるものをコーディングしたのだ:まず色や背景のため、そしてタイプに関するスタイルを。

あなたはInternet Explorerの、ピクセルベースのフォントをリサイズに関する問題ーーというより徹底的なリサイズ拒否ーーについて既にご存知かもしれない。もしパラグラフを16px Georgiaに設定したら、どれだけユーザーがテキストサイズを変えようとしても、IEではそれは16pxのままになる。IE7以上では、ページ全体で拡大縮小はできるようになるが、ピクセルベースのフォントの単純なリサイズは禁止されている。なのでユーザーに柔軟さを与えようと思ったら、我々スタンダードに精通したデザイナーたちは、通常ピクセルを全面回避して、相対単位で文字のサイズを扱う、たとえばそれはキーワード, パーセント, または私のお気に入り emである。

もし今までemのような相対単位を使用したことがあるなら、あなたはそれがコンテキストに基づくと知っているだろう。言い換えれば、要素のemの実際のサイズは、その親要素のfont-sizeに相対的に計算される。例えば、次のheaderデザインカンプを手がけているとしよう。

styled text
ピクセルを使った基本的なテキストの一例

何も特別なことはない。ある段落が16pxのHelveticaで設定され、ulが少し小さく14px、そして上部のh1が24pxのGerogiaだ。魅力的でしょう?

もっと魅力的なことは、たったひとつのシンプルなルールがこれを最大限に利用させてくれることだ。つまり:

body {
    font: normal 100% Helvetica, Arial, sans-serif;
}

font-size100%であることで、ページの全ての要素がブラウザのデフォルトタイプサイズ=大抵は16pxに対して相対的になる。ブラウザのデフォルトスタイルシートのおかげで、h1はbigでboldで美しく、きちんとHelveticaになってはいるが、だいぶ大きすぎている。font-familyでHelveticaの問題を修正するのは簡単だけれども、その一方でどうやってテキストサイズを24pxにすればいいのか?そして正確にリストのサイズを減らすには?

emを使えば、それは簡単だ。各要素のピクセルでのfont-sizeをtarget(ターゲット値)とし、そのcontainer(つまりそのコンテキスト=context)のfont-sizeで割るのだ。

target ÷ context = result

もしbodyのデフォルトタイプ・サイズが16pxであると仮定したら、知りたいfont-sizeをこの計算式に入れればいいのだ。なのでこのheaderをカンプにならう場合、ターゲット値のfont-size 24pxをcontainerのfont-size 16pxで割る。

24 ÷ 16 = 1.5

なのでheaderはデフォルトのサイズより1.5倍であり、1.5emとスタイルシートに書けば良い。

h1 {
    font-family: Georgia, serif;
    font-size: 1.5em;        /* 24px / 16px = 1.5em */
}

リストも14pxでem形式にするには、同じ計算式を使えば良い。同じようにbodyfont-sizeが16pxと仮定して、ただターゲット値をコンテキストで割るのだ。

14 ÷ 16 = 0.875

答えは0.875emとなるので、それをまたCSSに入れれば良い。

ul {
    font-size: 0.875em;      /* 14px / 16px = 0.875em */
}

これら2つのルールにより、サンプルページはよりカンプに近づいて、あと少しのクリーンアップで、ピクセル的にもほぼ完璧同然になる。この「ターゲット値 ÷ コンテキスト = 結果」の計算式のおかげだ。

こういった、相対的なタイプのクリーンアップをこのクライアントのために数時間やったのち、私はふと気づいたのだ。もしフォントサイズをピクセルでなくcontainerに対する比率で扱うことができるなら、同じことをグリッド上に敷き詰められる違う要素にも使えるのじゃないか、と。

結局それは「黄金ピクセル」ではないのだ

同じように、魅力的でない普通なレイアウトから初めてみよう。

たしかに、我々の「デザイン」はとても控えめなものだろう。しかしこのシンプルなスタイルもしっかりと定義されたグリッド上に置かれたものなのだ。挙げてみると、それぞれ124pxの7つのカラムと、それを分ける幅20pxのガターで、全体の幅が988pxだ。だけどここいらの面倒なピクセルのことは忘れよう。「比率」が次の流行だろう?フルードになろうじゃないか!

始めるには、fixed(固定)でもフルードでもまずカンプを扱うことだ、。コーディングを始める前に、デザインを見てみて、違うコンテンツ範囲を調べてみよう。ありがたいことにそのコンテンツインベントリ量はとても少ない。

一番上には、タイトルがトップにあり、コンテンツが6カラムにまたがり、そして文脈的情報が一番左のカラムにある。ここから、骨組みのマークアップに肉付けして構造的そして意味的に調整していく。

<div id="page">
    <h1>The Ratio Revolution Will Not Be Televised</h1>
    <div class="entry">
        <h2>Anyone else tired of Helvetica?</h2>
        <h3 class="info">A <a href="#">Blog</a> Entry:</h3>
        <div class="content">
            <div class="main">
                <p>Main content goes here. Lorem ipsum etc., etc.</p>
            </div><!-- /end .content -->
            <div class="meta">
                <p>Posted on etc., etc.</p>
            </div><!-- /end .meta -->
        </div><!-- /end .main -->
    </div><!-- /end .entry -->
</div><!-- /end #page -->

いくつかのタイプに関するルールのおかげで、一応ちゃんとした感じのスタートとなっているように見える。しかし#page containerは制約をなにも持たないため、このコンテンツはブラウザウィンドウの幅にマッチして伸びようとする。この長さに制御をかけてみよう。

#page {
    margin: 40px auto;
    padding: 0 1em;
    max-width: 61.75em;      /* 988px / 16px = 61.75em */
}

marginとpaddingでデザインをゆったりさせ、ウィンドウとデザインの間にもガターを作った。最後の行では、さっきのfont-size計算式の変形を使って、デザインの最大幅を定義した。カンプの幅 988pxをベースのfont-sizeの16pxで割り、max-widthをemで設定することで、モックアップであったピクセルベースの幅の値に近づけて988pxの値を超えないようにしたのだ。emで最大値を設定したことで、ユーザーがブラウザのテキストサイズを大きくすればmax-widthも大きくなる。このステキなテクニックは、IEの古いバージョンでもちょっとしたCSSパッチを使えば可能だ。

ではデザイン全体が適切に定義されたので、コンテンツインベントリからそれぞれの要素を見ていこう。はじめはページタイトルだ。カンプでは5カラムと4つのガターにまたがっていて、幅は700pxだ。そして、左の端からみて1カラムと1ガター分つまり144px分、離されている。もしfixed-widthのデザインだったら、この仕事はとってもシンプルなものになっただろう。

h1 {
    margin-left: 144px;
    width: 700px;
}

これがフルードコンテキストだからといって、固定のサイズを完璧に切り離すわけではない。そして相対的なフォントサイズを扱っていたまさにその時が、私がそれにひらめいた瞬間だった:グリッドのそれぞれの面ーーそしてグリッド上の各要素ーーはcontainerに対して相対比率で表現することができる。言い換えれば、タイプのリサイズエクササイズをしていた時、私達は要素のサイズだけを見ていただけではなくて、要素のcontainerに対するサイズの関係も見ていたのだ。この理論のおかげで、私達は自分たちのデザインのピクセルベースの幅をパーセンテージに変え、グリッドの比率をリサイズされてもそっくりそのままキープすることができるのだ。

要するに、フルードグリッドというものを作ることは可能なのだ。

全ての古いものがまた新しく生まれ変わった

では、どのように始めよう?

target ÷ context = result

そのとおり。先ほどの頼れる計算式の再来だ。ピクセルベースのカラム幅をパーセンテージベースのフレキシブルな寸法へと変えるため、同様の比率計算を使うことができる。ターゲット値が700pxで、988pxの囲いに入ったページタイトルから始めよう。

the title area
ピクセルベースのタイトルをパーセンテージに変える

結果として、単純に700px(ターゲット値)を988px(コンテクスト)で割れば良い。

700 ÷ 988 = 0.7085

結果が0.7085でそれは70.85%のwidthになり、スタイルシートにそのまま入れればよい。

h1 {
    width: 70.85%;           /* 700px / 988px = 0.7085 */
}

同様なことをターゲットmarginの144pxにもできるかって?そういった誘導尋問はとても好きだ。

144 ÷ 988 = 0.14575

同様に、0.14575つまり14.575%をタイトルのmargin-leftのスタイルとして加えれば良い。

h1 {
    margin-left: 14.575%;    /* 144px / 988px = 0.14575 */
    width: 70.85%;           /* 700px / 988px = 0.7085 */
}

ジャジャーン!タイトルのmarginとwidthをそのcontainerとの割合から測ることで、グリッドからの比率を、CSSフレンドリーなパーセンテージ表現に変えることができた。ブラウザウィンドウのサイズが変わったときですらタイトルの比率は常にそのままだ。

コンテンツ部分で同様にこの単純な割り算をしてみよう。カンプで844pxの大きさで124pxの左marginだ。

844 ÷ 988 = 0.85425

そして情報用のカラムには

124 ÷ 988 = 0.12551

これらのすぐできる計算により、スタイルシートに挿入できるパーセンテージが算出でき、レイアウトの肉付きを増してくれる。

.entry h2,
.entry .content {
    float: right;
    width: 85.425%;          /* 844px / 988px = 0.85425 */
}.entry .info {
    float: left;
    width: 12.551%;          /* 124px / 988px = 0.12551 */
}

こうしてフルードグリッドはもっと形づいていく

コンテクストを変える

これまでに、大きなコンテンツ部分を整理してきたが、まだその内部は触っていなかった。現在、ブログの.entryのメイン部分と.content内の文脈的情報は幅が.entryの全域にまたがっていて、上下に重なっている状態だ。しかしもとのカンプでは、ブログの.entryのメイン部分は5カラムにだけまたがっていて、補足情報は右端のカラムにのみ置かれていた。

頭の良い読者なら、現在.entryの幅がタイトルと同じ幅(700px)にされていて、marginも先ほど指定した左端のカラムと同じ幅(124px)になっていることに気づいただろう。しかし前に計算したのと同じ寸法を扱っていても、同じ計算式を使うことはできない。なぜならコンテキストが変わったからだ。

main entry area
新しい囲みの中にいるため、その幅を新しいコンテキストとして使う必要がある

前はパーセンテージを988pxの幅の#pageに対して計算すればよかったが、今は.entry .content内にいるので、これは明らかに先ほどより小さい。なので結果として、新しいコンテキストを定義する必要があり、.entry .contentの幅を基点としなくてはならない。.mainの幅をパーセンテージベースで定義するためには、その幅700pxを844pxで割る必要がある。

700 ÷ 844 = 0.82938

そして右側の124pxのカラムも同様だ:

124 ÷ 844 = 0.14692

そしてこれを私達のCSSに挿入する。

.entry .main {
    float: left;
    width: 82.938%;          /* 700px / 844px = 0.82938 */
}.entry .meta {
    float: right;
    width: 14.692%;          /* 124px / 844px = 0.14692 */
}

これにより、私達のフルードデザインは完成だ。

端数に関するメモ

上記のテクニックでは、CSSパッチが足りないので、あなたが予想してるかもしれないとおりクロスブラウザに関する問題が少しだけあるかもしれない。なのでJohn ResigによるCSSのサブピクセルに関する問題内の素晴らしい記事を読むことを是非オススメする。それぞれのブラウザがどのようにパーセンテージベースの幅を扱い、またサブピクセルの寸法をどうやって扱うかの構造がそこで説明されている。

Johnが記事内で説明するとおり、もしモダンブラウザが4つの25%幅の要素を50px幅のcontainerに与えられた場合、その要素を12.5pxで表示することはできず、替わりにほとんどのブラウザはカラムの端数を切り捨てるか繰り上げるかして、そのレイアウトに最適にフィットするようにする。Internet Explorerだけは、単純に全てのサブピクセル値を繰り上げるため、レイアウトを壊してしまう。

もし十分に余裕あるmarginをグリッド内で使っているならこれは問題にはならないだろう。けれどもしIEがあなたのパーセンテージベースのカラムにひどい問題をおこすようなら、ターゲット値を1px減らすことで解決するだろう。なのでたとえば、左のmarginがIEにとって大きすぎたなら、計算式をこのようなものから:

124 ÷ 988 = 0.12551

123pxに変えてみよう:

123 ÷ 988 = 0.12449

この12.449%というwidthをIE専用のスタイルシートに入れれば、このレイアウト問題はすぐ解決するだろう。

万能なグリッド

上記はもちろんスターティングポイントである。他にもリキッドウェブデザイナーが直面する無数の課題があり、ほとんどはfixedコンテンツ(例えば画像やFlashなんてもの)をフルードフレームワークに挿入しようとしたときに起こる。可能な解決策を私のブログ上で公開してるが、より良い回避策も他に沢山あるだろう。

そして最後に、私はfixedであろうがフルードであろうが、デザインが簡単だなんて言わない。しかし私達が過去数年の間に、スタンダードを自分たちの会社や業界で伝道し、より高いレベルのブラウザと同業者を要求してきたことが達成できたと仮定して、”minimum screen resolution”への依存を少しは壊せているのではないか、と願っている。どっちにしろ、ユーザーのブラウジング習慣は、我々のカンプが期待するほどいつも固定されているわけではない。フルードグリッドがあなたの想像力を促進してくれることを願っているし、あなたがどうやってこのテクニックを進歩させてくれるか見るのが楽しみだ。ユーザーたちももちろんそうだろう。

追加の読み物

私の序盤の余談から、私の2つのパッションはフルードウェブデザインと、良く考えられたグリッドの重要性であるということがわかると思う。全てではないが、これら2つのパッションは次の読み物たちから焚き付けられている。

そして、この前の8月のフルードグリッドのデザインについての講演で、だれかがフルード960 グリッドシステムについて指摘してくれた。もしあなたが960 Grid SystemなんていうCSSフレームワークをすでに使っているのなら、こちらも興味ぶかいかもしれない。