おいしい情報ばかりだと信用できないという健全な方々へ。
2002-03-05
従来は「HTML によるデザインテクニック」というものがまかり通っていました。
これはしかし、たまたま Mosaic が採用した見た目を Netscape が踏襲し、これを IE が踏襲し、これを、、、ということがくり返されたから可能だっただけの話でして、HTML の見た目は本来ブラウザによってマチマチなのです。HTML にはその見た目を規定する“本当の基準”がありませんから。
携帯電話やテキストブラウザや SATURN 用のブラウザでは、一般的な GUI の PC と同じ見た目を再現することができません。これは、こうしたブラウザのバグでも実装を間違っているわけでもなくて、ごく当たり前のことなのです。たまたま Netscape と IE がメジャーになったり、たまたま IE が市場を独占しただけのことです。
HTML でも見た目のコントロールがある程度できますが、これはたまたま似たような見た目を実装しているブラウザしか手元にないからそう思えるだけなのです。（逆に知っててパソコン用の一部のブラウザの実装に依存して、それを推奨ブラウザと称して強制するのは、本当は WWW 的にはおかしな話です。）
本当の意味で見た目の基準を考えることができるようになるのは、CSS の登場を待たなくてはなりません。これは HTML と違って内容を記述するためのものではなく、純粋に見た目を決定するための道具です。
さて、現在の Web の“標準”的な流れは HTML で意味を、CSS で見た目を（正しくは CSS は見た目以外にも音声に関してもコントロールできるのですが）記述するという分業方式です。ブラウザはこの両方のデータを扱える場合はそのように適切な表示をし、HTML しか解釈しない設計であれば、その見た目は「ブラウザの実装によって適当に」設定されます。
ここで CSS 以前の Web をよく知っている人の中に問題が生じることがあります。
「自分は自分の作った Web をこういう風に見てほしいのに、そう見ていない人がいる」ということに気付くという問題です。
ブラウザには CSS をオフにしたり、ユーザーが自分で作ったスタイルシートでそのサイトの見た目をがらっと変えてしまうという機能が盛り込まれ、見た目を決めるための CSS を使ったがゆえに自分の期待する見た目で相手が見てくれないという、納得のいかない事態が発生してしまうのです。
もう一つは CSS 対応の半端なブラウザがまだまだ世の中に多いという事実です。CSS を使ったがゆえに今までそのブラウザで“正しく”表示できていたサイトがうまく表示できなくなってしまうということが起きてきます。
こうなると、ブラウザの独自拡張を批判していた歴史を下手に知っていようものなら、「また特定のブラウザでしか有効じゃないテクニックを使って…」と思われかねません。事実、新聞社やポータルサイトと呼ばれるところでは CSS を使わずに旧来の “HTML によるデザイン”を使うところがほとんどです。これは幅広いユーザーからのアクセスに応えるサイトの宿命で、ブラウザのバグと分かっていても、その新しい技術にともなうトラブルを避けなければいけないからです。商売なんですから当たり前です。そうしたサイトは、「最も”遅れて”いなければいけない」サイトなのです。
現在、CSS を最も頑張って使っているのは CSS に興味を持っている個人のサイトでしょう。個人サイトにはこうしたしがらみがありませんから。そして見た目については「別に伝わらなくても構わない」という割り切りができている人が多いように見受けられます。問題は情報であって見た目はその次である、と。
CSS を使うことのメリットは「スタイルシートに移行しよう」に書いてあるのでくり返しませんが、こうしたメリットと、ブラウザの対応、自分の期待通りに相手が見ないかもしれないデメリットを天秤にかけたうえで、メリットの方に重きを置いた人たちは CSS を採用します。（もちろん、単に技術的に面白そうだからという理由もあるでしょうが。）だからこそ割り切りもできるわけです。
逆に CSS を使わなくても CSS を使うメリットに近いことが可能で、なおかつ幅広いブラウザで動作の食い違いが起きないような配慮を必要とする人たちは CSS を採用しません。
例えばユーザーによって伝わるかどうか分からないという意味では CSS も画像も似た部分があります。CSS による見た目のコントロールがブラウザのバグによって“揺れて”しまうのであれば、逆に文字を画像にしてしまった方が安定した表現を配信することが可能です。ALT 属性の指定をしてあればテキストしか伝わらない環境の人にも情報は伝わるわけですから、あえて CSS にする必要はないわけです。（もちろん画像を使うと画面の解像度、色数などで制限ができますが。）
ただ、画像を作成する分、確実に CSS より手間は掛かります。今度は手間とメリットを天秤に掛けます。で、個人サイトでは手間を掛けるよりも CSS を採用するし、企業サイトではこの手間を省けるようなシステムを開発するなり、手間の分の制作費を確保して画像なんかを採用することが多い、というわけです。
（このように WWW という自由でインタラクティブなメディアは、経済活動と“プロのデザイナー”の手によって今は窮屈になってしまっています。もっとも、スクリーンの解像度の幅が広がっている現在、画像が完全に CSS の代わりになるわけではありません。みんながみんな SVGA 〜 XGA クラスの画面しか使っていなかった時代はとうに過去のものです。画像を使ったサイズ固定のサイトは徐々に苦しくなっていくでしょう。）
結局のところブラウザの対応と自分のメリット・デメリット、ユーザーのメリット・デメリットを考慮して決めなくちゃいかんちゅーことですな。ブラウザのデフォルトの見た目に依存した HTML デザインは PC ユーザーじゃない人のことを考えてないし、CSS で様々なプラットフォームに対応したデザインの場合はバグ持ちのブラウザのことを考慮しきれない。仕事でやっている人やスキルの高い人はサーバサイドプログラミングによって巧みにブラウザの問題を避けることができますが（と言ってもきちんと検証しきれているサイトはそれほど多くはないと思いますが）、趣味で Web を公開している人は、CSS 対応ブラウザが普及してきていることもあいまって、やはり CSS かなぁと思うわけです。
なんたって CSS を使った方が手作業の更新は断然楽です。（Another HTML-lint のような優れた CSS 文法チェッカが早く出回らないもんですかねぇ。）
2002.03.追記。
「スタイルシートに移行しよう」のリンクにもありますように、「W3C CSS Validation Service」というものがありますし、これを実際に自分もたまに使っています。また、これをローカルで動かすための方法が「CSS ValidatorをWindows 98/2000で動かす」にあります。こちらは残念ながら Java を動かすのが面倒でやってませんけど、ご参考までに。
情報の抜けをご指摘いただいた空母さんに感謝です<(..)>
もう静的な情報の表現ツールに関しては流行らないのか、なんかどうも HTML に比べるとスタイルシートの情報は少ないように感じます。それとも HTML のようにテクニックを編み出せないからダメなのか、あるいは HTML で意味を、CSS で表現効果を、という二段構えは分かりにくいのか、そもそも WYSIWYG のツールで CSS を書きやすいものがないからか、ライターが分かろうとしていないのか、CSS については非常に中途半端な情報が多くなっている気がします。
確かに CSS の情報が出始めたときにはまだせいぜい IE 4 レベルの、「あぁそんなこともできるのね」程度の効果しか目の当たりにすることができなかったのですが、IE 6, Netscape 6.1 以降くらいになればずいぶんと対応の度合いが違いますからね。もう少し本格的にオーサリングツールやライターがサポートしてくれてもいいような気がするのですが。
ひょっとしていちばん痛いのは FrontPage Express が対応していないから？ FrontPage Express が Windows に付属してこなくなかったから？
何にしても、仕様書に取り組む気力のある人じゃないとなかなか全容がつかめないのはどうにかならないもんでしょうか。ブラウザによって見た目が変わりかねないから効果を説明しにくいのかな。
この際はっきり Netscape 4.x は CSS には対応していない、あれは JSS だ、こうした対応しているようで対応していないブラウザにはスタイルシートの効果が誤って適用されないようにうまくかわし、IE 5 以降、Netscape 6 以降（というかできれば Mozilla の Milestone build）を使うように、まぁ譲って iCab も許そう、くらいの気持ちで言ってもいいような気がするんですけど、やっぱダメでしょうか。どうせ初心者はかなりいいマシンを使っていることが多いんだし。（乱暴）
うーん、脱線。
それとも「とほほのWWW入門」がCSSに積極的でないからか？（笑←笑いごとじゃねーなぁ）
また、これまですでに CSS を使わずに Web を作っていた場合、HTML の書き換えがめちゃくちゃ面倒くさく感じます。
これはいっそ新しいサイトを作るときに CSS を採用することにして、従来のサイトは従来通りのやり方をするようにしましょう。その方が簡単です。古い作り方のものはそのまま放置しましょう。
ただ、新しく作る前に実験はした方がよいと思います。案外思う通りにいきません(^^; TABLE が普及し始めたとき、フレームが普及し始めたとき、JavaScript が普及し始めたときも同じようなことが起きましたが、要するにちゃんとした対応をしていないブラウザをどうやって避けるかのテクニックの問題です。
これはしかし、現在でも十分にこうしたブラウザを避けるテクニックが浸透しています。要はそれが「とほほのWWW入門」のような形でまとまっていないだけで。「スタイルシートに移行しよう」にたくさんリンクを用意したので参考にしてください。
ようやくスタイルシートを使う段階にたどり着いた。長かった。
実際に CSS を使うには、スタイルシートファイルを外部に持つ方が断然いいです。しかしそうなると、作るときに絶えず「表現効果の“意味”」を問い続けなければいけなくなります。そして、表現効果と意味は案外直結していません。
このため、これこれの表現効果を使いたいと思ったときにそれを素直にタグに反映しにくくなります。スタイルシートによる表現のコントロールを念頭に置きつつ、それを反映するためのクラス名や ID をどうやって設定するか。そして似ているけれども異なる効果、似ているけれども異なる意味を持つ場合はどうするのか。
こうした問題は個人サイトによくある、徐々に内容が増えてくるサイトではけっこう深刻な問題だと思います。サイトに、そして1ページの中のデザイン、構造に一貫性がないからです。
しかしこれはとても有益な悩みです。
ホームページってのは欲張らなければ本当に簡単に作れます。これは確かにすごくいいことです。でも、見る側が見やすい、あるいは使いやすいページ、サイトになっているかどうかは非常に疑問です。みんな素人ですから当たり前なんですけど、読み手を本当に意識することは実に大変です。外部スタイルシートを使うことで、これをかなり意識しやすくなります。
スタイルシートを使うと、構造、デザインについて実に考えさせられます。いや、目先の表現効果に飛びつくだけっていうのもアリですけど、外部スタイルシートを持つようにすると途端にそれは難しくなります。なにしろその場限りの派手な表現を使ってばかりだと外部スタイルシートの中の記述がすごく冗長で無駄だらけになってしまうからです。例えて言うなら1ページ1ページで全部違うボタン画像を使っているようなものです。それはさすがに今さらいやでしょ。
そこでサイト全体、1ページ内の表現についてその構造をしっかりと意識するっていう、まどろっこしいアプローチが大事になります。まどろっこしいって言うか、本格的なアプローチですね。
サイト全体でどのようなコンテンツをどのように配置するのか、何が共通する表現か。1ページの中でどのような内容をどのように配置するのか、どのようにデザインに一貫性を持たせたいのか。こうしたことを考えることが、無駄の少ないスタイルシートデザインのための近道になります。
こうしたアプローチは情報を適切な単位に分割し、適切な表現で伝えることに繋がります。
逆に言うと内容が決まってないうちはスタイルシートは導入しにくいものです。作りながら考えているうちはスタイルシートの導入を焦る必要はないと思います。ま、そもそもそんなことのために焦る必要は全然ありませんけど。大事なのはスタイルシートそのものじゃないわけですから。
当たり前ですが、表現を高度にコントロールしようとすればするほど、意味との遊離が問題になってきます。何しろ目的が表現の場合、それに完全にマッチする意味があるとは限らないのです。表現効果には「間（ま）」などの微妙なものがたくさんあります。こうしたものをすべて意味を記述するための HTML の中に埋め込むのは、容易なことではありません。
これにはたくさんの経験が必要になるでしょう。自分が表現していることがなんなのか、はっきりと分かることは表現し始めたばかりの頃にはなかなか難しいのです。これは文章表現だろうがイラストだろうが写真だろうが舞台だろうが同じことです。
こればっかりは一朝一夕にはなんともなりません。
Web デザインにはインターフェイスという考え方がすでに定着しています。一つのアプリケーションとしての Web サイト、という考え方ですね。
このインターフェイスのデザインは主にフレームと TABLE で行われてきました。フレームによってナビゲーションと本文を分離することが、TABLE によってグリッドに沿ったレイアウトが可能になりました。
CSS を使うと、こうした視覚表現だけに限らないインターフェイスの設計が可能になります。多少1ページのデータとしては冗長ではありますが、ブラウザごとに完全に違うページを作成するのとどっちがいいかですね。
具体的には @media 規則を使います。 screen が一般的の PC の画面、projection, tv はスクロール機構なんかのない、あまり解像度の高くない画面、print は紙ベース、aural が音声ブラウザです。
例えば紙ベースのときにはそもそもリンク機構というものは存在しないので、印刷したときにはナビゲーション用のリンクテキストが表示される必要はありません。projection や tv の場合は文字サイズを PC の画面よりも少し大き目にするなり、フォントのアンチエイリアスなどが効かないことを前提にするなどの工夫が必要でしょう。音声の場合は目で見る場合よりも情報の取捨選択がしにくいですから、ABBR 属性なんかをうまく使いつつ不必要な視覚的効果を排除していくように CSS を記述していくと親切でしょう。
でも、これは面倒です(;_;)
そのうえ、確認できない環境がまだまだ多いです。まだまだこの辺のノウハウがいまいち表に出てきていないので、欲張らずにノウハウが蓄積、公開されるのを待つべきでしょうか。
安定したインターフェイスを提供するという意味では FLASH などのプラグインは有効です。プラグインをインストールするという手間はあるものの、“その段階”さえなんとかなれば“揺れ”のないインターフェイスを実現できます。でもまさに“その段階”がいちばんの問題となります。けっきょく二重に内容を作りこんでいかなきゃいけないかもしれません。