CSS完全対応のワナ

　W3Cでは、ウェブページの構造とデザイン(表示スタイル)の分離を推奨している。HTMLを、文書としての構造を表現することに特化するマークアップ言語とし、いわゆる"見た目"にあたるデザイン部分は、CSS(カスケーディングスタイルシート)の担当とし、役割を明確に分離するということだ。この方法は、誰でも同じルールで制作することができ、どのような環境からでもアクセスすることのできるウェブサイトを制作するための標準技術を目指している。

CSSによるデザインのメリットとは？

　これまで、ウェブデザインの現場では、<table>タグを使用してレイアウトしたり、<font>タグを使用して文字の色、大きさ、<b>タグを使用して太さを調整したりといった方法を用いてきたが、この方法では、文書の段落の構造や、引用文、リストやメニュー、果ては文書のタイトルなどといった、文書を読む上での重要な情報の表現を、意味ではなく見た目によって使い分けてしまうため、文書中のテキストの意味合いがチグハグになってしまうなどの問題があり、ウェブ制作業界では、W3Cの推奨する「CSSを用いたデザイン」を採用する方向で動きつつある。

　この他にも、CSSによってデザインされたウェブサイトには、こんなメリットもある。
　CSSは、HTMLタグの、表示上のルールをカスタマイズする技術で、たとえば、「<b>タグの色を常にグリーンにしたい」とした場合に、『b {color:#00ff00;}』といった記述をするだけで、全ての<b>タグが緑色になる。しかも、HTMLの外部の別のファイルに記述することができるため、同じルールを複数の異なるページに、いっぺんに適用することができるのだ。
　この性質を利用すると、「ページ全体の文字の色を変えたい」とか、「メニューとコンテンツのレイアウト関係を変更したい」とか、そういった修正を、CSS定義ファイルを書き換えるだけで反映させることができ、デザインやコーディングの作業工数を大幅に削減できるというのだ。

　まだある。文書構造と視覚的なデザインを分離することにより、視覚障害を持った人たちが使用する、音声読み上げ式のブラウザに対して、正確な情報を提供することができる(アクセシビリティ)。彼らにとっては、視覚的な美しさなどどうでもよく、とにかく文書の内容を正確に把握できればよいのだ。

　このように、一見完璧とも思えるCSSによるデザインだが、私はここに、いくつかの"ワナ"があるように思える。私が考える、CSSデザインの"ワナ"を、いくつか挙げてみる。

【ワナ1】自由度が高すぎる

　CSSは、「HTMLタグの表示上のルールをカスタマイズできる」と前述したが、実はもっと細かいことができる。classという識別情報をタグに追加し、class毎の設定が可能なのだ。
　classは、たとえば『.sample {color:#00ff00;}』といった具合に宣言する。この例では、「sample」というclass名でclassを宣言した。これを適用させる場合は、『<span class="sample">緑色</span>』のように、「 class="sample"」を指定したタグ全てに適用される。非常に便利なので、特によく使われる方法である。

　class名には、基本的には任意の名前がつけられ、無制限に量産することができる。その意味で、CSSは非常に自由度が高い。
　しかし、実はここが落とし穴のひとつなっていると私は思うのである。

　自由度が高いということは、場合によって、制作者によって、好き勝手なルールを設定できる。つまり、全てのサイト、全てのプロジェクトが、それぞれ違うルールでCSSを定義できてしまうのだ。そのため、プロジェクトに参加するスタッフは、膨大なスタイルシートの定義ファイルをプロジェクト毎に把握し、使い分けなければならない。これはかなりハードな作業になる上に、ルールの食い違いはミスの元にもなりかねない。

　この問題は、実作業にあたるスタッフにだけ降りかかるものではない。そもそもCSSを定義する段階で完璧な仕事をしておく必要がある。つまり、あらゆる文書の、あらゆるシーンを網羅した定義のことである。
　この作業が完璧になされていないと、作業中に、あらかじめ定義されたスタイルで表現しきれない新しいタイプの文書構造(表現)に遭遇した場合に、新しい定義をCSSに追加する必要が出てくる。この作業が発生してしまうと、プロジェクトに参加するすべてのスタッフに、この変更を把握しなおしてもらわなければならない。1度きりなら大したダメージはないが、度重なると現場に大混乱を招き、ディレクターは冷や汗をかくだろう。

　しかも、あらゆる文書のあらゆるシーンを網羅する「完璧」なCSS定義を完成させるという作業は、決して容易ではない。むしろ、そんなことは不可能かも知れない。文書構造を担当するHTMLが、すでに複雑な文書構造に対応できないと言われているくらいだから、CSSが早速お手上げになるのは当たり前のことである。

【ワナ2】オーサリングツールでのCSSの扱いが、まだまだ不便だ

　ウェブサイト構築の作業を効率化させるために、さまざまなオーサリングツールがリリースされている。MacromediaのDreamweaverや、Adobe GoLive、IBMのホームページビルダーなどがこれにあたる。
　これらのツールは、多くのウェブ制作者たちに愛用されているが、CSSを設定するインターフェイスは、まだまだ改良の余地がありそうだ。

　誤解を受けたくないのだが、「これらのオーサリングツールが使いにくい」と言っている訳ではない。「これらのオーサリングツールのインターフェイスでは、CSSのデザインより、従来のHTMLでのデザインの方が編集しやすい」ということだ。

　それぞれの機能について細かくは書かないが、使い慣れたオーサリングツールでCSSを挿入する際のストレスが高ければ、人は次第に使わなくなる。これでは「ウェブサイト制作の効率化」は図れないだろう。

　オーサリングツールのインターフェイスが今後どのように進化を遂げるか想像もできないが、現状、HTMLよりも扱いにくくなっている背景には、前述の「自由度の過剰な高さ」があるのではないだろうか。自由度が高ければ、インターフェイス(たとえば、テキストの入力欄とか)がいくつあっても対応しきれない。
　もしかしたら、オーサリングツールが、CSSの自由度をあえて制限するならば、もう少し明快なインターフェイスになるのかも知れないが、これは余談だ。

【ワナ3】ブラウザの対応状況が区々

　ウェブを閲覧するためのブラウザには、いろんな種類がある。もっとも多くのユーザに使われている「Internet Explorer」、かつてNo1シェアを誇った「Netscape」や「Mozilla」、最近ユーザを増やしつつある「Opera」、そのほか、実にさまざまなブラウザがリリースされている。
　残念なことに、CSSの実装状況は、ブラウザの種類や、OS、さらにバージョンによって違うのだ。しかも、W3Cが定義するとおりの、「完璧」なウェブブラウザは、どうやらまだ存在しない。

　W3Cの「標準」が複雑すぎるためか、開発が追いついていないという現状もあるようだ。そればかりか、実装したはずの機能にバグがあり、指定した通りの表示にならない場合もある。
　このようなことが起こると、ウェブ制作者は、その機能の使用を制限せざるを得なくなる。しかも、そのバグの程度や、発生頻度によって、「使ってもよいか、やめるべきか」の境界線が微妙な場合が多くある。サイト自体が、どのブラウザまでをサポートするかによっても、この境界線は変わってくる。やはり現場が混乱する元になる要因である。
　そもそも、最初に書いたとおり、W3Cの標準化の理想が「誰でも同じように制作することができ、どのような環境からでもアクセスすることのできるウェブサイト制作」であるならば、「対応するブラウザ」という概念を発生させてしまっていること自体、理想へはまだまだ遠いということを物語っている。

【ワナ4】CSSの仕様自体が難しい

　CSSは、視覚的デザインの部分を担う技術なのだから、これを使うのは当然デザイナである。しかし、デザイナには、コンピュータの使う言葉に疎い人が多い。プロのウェブデザイナの中にさえ、CSSの仕様は少々ハードルが高いと感じている人もいるのではないだろうか。増してや、ウェブのプロではない一般の人がサイトを作る場合にはなおさらである。

結論

　いかがだろうか。こんなことが理由で、私はCSSに完全対応したウェブサイトのデザインは、まだまだ現実的ではないのではないかと考えている。

　しかし、「CSSを使わない方がよい」とは思わない。では、どのようにCSSを活用するのが、もっともリスクが低く、メリットを引き出せるのだろうか。
　いきなりCSSに完全対応しようとすれば、ハードルが高すぎる。ならば、これまでのやり方から、少しずつシフトしてゆけばいいのだ。それは、われわれウェブ制作者にも、ブラウザの開発者にも、標準を提唱するW3Cにも言えることだろう。

　以下に、私なりに、CSSの入門的導入の方法を考えてみた。参考程度にどうぞ。

リスクの低いCSSの使い方を考えてみる

　なんだかんだ言っても、圧倒的多数のウェブユーザは、ただ、視覚的なデザインによってのみ情報を受け取るのであって、文書構造がどのようなタグで記述されているかを考たり、感じたりする必要や機会はまったくないと言える。つまり、結局は"見た目"が重要なのだ。

HTMLによるデザインのメリットも考えてみる

　CSSを使用したデザインのメリットは前述したとおりだが、純粋にHTMLだけでデザインを行った場合のメリットには、どのようなことが挙げられるだろうか。

　簡単に言えば、前述した「CSSのデメリット」にあたる部分は、HTMLにとってのメリットと言ってもよいのではないだろうか。

1. 自由度が低いため、誰でも同じルールで制作できる
2. オーサリングツールによる編集が容易
3. 近頃は、各ブラウザでの対応状況も、比較的安定している
4. 仕様が単純で、簡単である

　これらHTMLのメリットを損なわないように使えば、CSSのメリットを最大限に発揮できるのではないだろうか。

CSSには、必要最低限の記述だけを定義する

　全てを網羅しようとするから、無理が生じるのである。ごくごく一般的で、頻繁に使用するスタイルだけを定義するのであれば、さほど難儀ではないはずだ。

　たとえば、普通のテキストのスタイルを見てみよう。基本的には、文字の色と、大きさ。もうちょっと突っ込むならば、行間も。この程度にとどめる。
　普通のテキストの種類は、3つか4つ程度用意する。これは、普通の大きさ、1段階小さい、大きいなどの、基本的な応用パターンのみを用意する。

　リンクに関するスタイルも付け加える。これはHTMLではできない、簡単で、かつダイナミックな効果を生むことができる、CSSならではのテクニックだ。
　たとえば、『a:hover {color:#ff0000;}』という指定を、CSSの定義ファイルに書き込むと、リンクにマウスを乗せたときに色が変わるようになる。古いブラウザなどでは効果がない場合もあるが、効果がない程度で、悪さはしない。こういう機能はどんどん使おう。

　それから、基本的な文書構造を作るいくつかのタグ（<hn>タグ、<ul>タグ）も考慮しておこう。

　このレベルならば、大人数での作業でも、大きな混乱もなくまとめることができるだろう。

大枠の基本的なレイアウトは<table>タグで

　CSSによるレイアウトは、オーサリングツールでの編集が面倒だ。やはり、従来どおり<table>タグを使用する。
　表組みを作るという、<table>タグ本来の用途とは異なるが、こんなに便利なテクニックを使わない手はない。

そのほか、突発的な例外には、各自で対応

　「文中のここだけを赤い文字にして欲しい」などの突発的な要望には、<font>タグでも何でも使って対応する。この「ごくたまにしか発生しない書式」のために、新しいclassを定義するのでは、プロジェクト全体にかかるリスクの方が大きいからだ。
　もちろん、「文字を太くして欲しい」という要望があれば、これはつまり「目立たせたい」「強調したい」という意味なのだから、<b>タグではなく、強調を意味する<strong>タグを使用するなどの、最低限の配慮はあるに越したことはない。

- - -

　確かに、このような作り方では、前述した「音声読み上げ式ブラウザ」への対応など、アクセシビリティへの対応ができていない。
　しかし、不安定な新しい技術を持ってこの問題を解決しようとするよりも、むしろ、「音声読み上げ式ブラウザ向けページ」を別途用意する方が簡単なようにも感じるのだが・・・どうだろう？