top»misc»

Elastic Layout

Elastic Layout

いろいろな手法で、スタイルは設計されますが、最も簡単で、コストのかからないスタイルの設計を、明確に出来る人は少ない。

スタイルの指定は、ブラウザ毎にそれぞれ、汎用的な手法だけでは、対応がつかないことも良くあり、CSShackと呼ばれるブラウザのバグ等を頼りにした対症療法が行われる為だ。

CSS2 附属書A HTML4.0のスタイルシート例等W3Cのスタイルシートなどを、見てみても、見慣れたリキッドレイアウト用のパーセント指定や、固定レイアウトの時によく使うpx単位は、それほど使われていない。

多いのはemという単位。ベースフォントの幅、高さに対して、相対的な幅、高さを表す単位だが、htmlの外部スタイルシートなどで指定されるケースはそれほど多くはない。、と思う。

htmlは、その製作過程において、画像等を多用する。画像は、一般的にはpxで表現する為、互換性のないemなどの単位による指定は、面倒だからだ。

視覚的な表現全般には、pxが用いられるが、htmlそれ自体は、文書のマークアップであるから、文字の大きさや、文字数に直結する表現が使われるということだろうと思う。

px単位をベースにした場合の問題点

また、ディスプレイがWindowsの96dpiのほかにも、72dpiもある。閲覧環境や、読み手の好みもある。画像等と異なり、文章の場合は、読みさすさへの配慮が求められる。

pxに変わるものとして、リキッドデザインが考えられた。

%指定を多用するリキッドデザインは、レイアウトや、文字列も含めて画面幅に合わせて、レイアウトが変化する。したがって、文字列の大きさを変化させても、比較的レイアウトが崩れにくいという特徴を持つ。

しかし、想定外のディスプレイなどで表現された場合には、やはりレイアウトが破綻すると言っていい程度の場合もある。現在では、ブラウザ側の実装も、widthだけしか指定が出来なかったりしたものも、最小width、最大widthといった指定が可能になってきている。許容可能な幅を指定することで、見易さを損なわない工夫が可能になりつつある。

文字列が、画面幅いっぱいに広がっているだけで、読みやすいデザインといえるのだろうか？機能的に優れている事だけで、デザインの完全さが保証されるわけはない。
私たちは、夕暮れ時の長く陰を伸ばしたありきたりの光景に、たそがれ気分になったりするような、感性を持っている。
そんな事を引き合いに出すまでもなく、ページ全体が拡縮するのは、自然な形だろう。

しかし、つまるところ、ディスプレイや画像の視覚系と、ドキュメントの文字列に望まれる単位系が別々という現実が、htmlドキュメントの制作をより困難なものにしているといえる。

画像等のmediaを扱う場合のpxと、文字列を扱うemの相互変換が出来ない理由。

UAは、基準になるフォントサイズを持っているが、全てのブラウザ共通のサイズではない。基準になるフォントサイズが異なっている場合％やemなど相対的な値では、それぞれのブラウザで表示がばらついてしまう。

エラスティックレイアウトは、基準になるサイズの差を、ドキュメントがズームするようにして、吸収しながら、全体としてレイアウト崩れのない表現を行う。

しかし、現実に適用していこうとした場合。レイアウト上の避けられない問題が発生する。

端的な例として、活版印刷で作られた本の背景画像の様子をブラウザの表示フォントサイズを変えながら画像サイズの変化を確認して欲しい。恐らく背景画像のサイズは、フォントサイズの変化に追従していない事が確認できると思う。

背景は、動的な画像を使うなどしない限り、html側でサイズのコントロールはできないと思う。pxで指定しているときには、ごく当たり前の事だが、リキッドレイアウトでは、文字列がそれこそリキッドなのに、背景はソリッド。画像と背景を、複雑に使い分けるようなテクニックで違和感を消すケースが良く見られる。エラスティックレイアウトは、いわゆるズームのように文字列とレイアウト枠が同期するので、違和感のない画面作りをする為には、更に高いテクニックが要求される可能性がある。

ウノウラボで紹介されているcssZENgardenは、巧みに作成されたhtmlですが、cssZENgardenのロゴや、草むらの背景画像のサイズは、変化していない事がわかると思う。

アクセシビリティや、複数UAへの対応を考えると、相対的な単位を使う事には、意味がある。でも、なぜリキッドレイアウトの%をベースにしたレイアウトではいけないのか、または、他の単位系に手を出す理由は何か？

私の思い込みかもしれないが、%指定は、あるときには、基準フォントサイズであったり、あるときには、ディスプレイサイズであったり、テーブルセル幅だったりと状況に依存して変化する。ある種の不安定さだと私は思っている。

エラスティックレイアウトで使うemは、常にベースフォントサイズで、emが基準にしているのは、ベースフォントサイズで、そこからの計算値であるという点で%による相対指定と異なり少しは期待が出来るかなと考えている。

em と　px を友達にする方法

エラスティックレイアウトの要は、スタイルの初期化だと考える。

理由は、それぞれのブラウザは、それぞれデフォルトスタイルを持っていて、それは、誰かが強制しているものではなく。12pxとか14pxとか、smallとか、「それは、俺の勝手だ。」という世界があるからに他ならない。ドキュメントタイプスイッチによって変化する事もあるかもしれない。

試した事
全称セレクタなどを使わずに、文字列を書き出して、実際に表示してみた。程よくそろえたところで、下の、外部スタイルを書き出した。初期化用スクリプトのぐちゃぐちゃさは、いわば足跡みたいなものなので、そのまま載せている。気に入らない人は、私のサイトにcsstidyを置いてあるので、使ってください。

この作業をした上であれば、emと、pxの近似値も算出できる。

このようなことから、13pxベースで　1000px=約76em、実際にhtmlを試してみた。

私は、CSSのお勉強をしてりるときに、1.2倍構成になっているんだ。ということを知って、こんな事を思った。

もし、640pxでエラスティックレイアウトを設計したら、文字を一段大きくすると、768px　次は　921と、VGA SVGA XGA と解像度別にズーム可能なページが出来てしまうじゃないか。

もちろん、そんな事やるなら、PDFのapiサービスで、htmlをPDF化したほうがいいんじゃないの。という人もいるだろう。便利なサービスは、とても多いけれど、まだ、「htmlをさようなら」とまで言える人は少ないだろう。それほど難しい作業でなければ、htmlだってまだいろいろ試していいはず。

私は、本当は、こんな作業にまみれないで、手間をかけずにhtmlを作りたいと思っています。どうやったら簡単に、出来るのかを勉強していますが、htmlは、結構八方美人で、人が見る為のドキュメントであったり、コンピュータが理解できるような、構造が必要だったり、特定のプログラムに依存しちゃいけなかったり。あちらのUAを立てれば、こちらが怒る。標準化団体の意見も勉強しながら、作んなきゃいけない。でも、そんなことに埋没していると、ホントは何の為にhtmlを書き始めたのか忘れてしまう。

簡単で、思いついたときにさっと書けるhtmlがいいですね。出来れば、あなたが、読んでガッカリしていなければいいと思っていますけど、どうでしたか？

2007 4月

webmaster@tenman.info

htmlドキュメント

CSSの主な修正点

最終的には、いろいろ書き込んでしまいましたが、以下のスタイル指定が、始まりでした。

試作したエラスティックレイアウト