Step1　過去の変遷とともにWeb標準について考える

本連載では、古い手法で作成されたサイトを「Web標準的」な指針に沿ってリデザインするためのプロセスを解説していきます。たとえば、文書構造を意識したマークアップやテーブルデザインをCSSデザインに再構築するといった作業などを取り上げていく予定です。HTMLやCSSには仕様書がありますが、実際のサイト作りにどう適用するかは、プロジェクトの方針や実利的な判断によってさまざまです。この連載では、ある程度の解釈を許容できるように教科書的な解説よりも、世界の“Web標準的なサイト”がどういう解釈でHTMLとCSSを採用しているのかを参考にしながら進めていきます。

今回は、過去の歴史を振り返りながら「Web標準」の捉え方について考えてみます。

「Web標準的なもの」をイメージするには、過去の経緯を知っておくとよいでしょう。まずは、CSS2がW3C（World Wide Web Consortium）によって勧告された1998年頃のお話をしましょう。CSS1が勧告されたのが1996年ですが、CSS関連の書籍が出てくるのは2年後です。

この頃から「次世代の技術」と称してCSSのセミナーなどが開催されるようになりました。ただし、当時のブラウザではCSSの機能を十分に試すことができず、どうしても概念中心の話になってしまうため、実践的ではないセミナーになっていました。この頃は、table要素を使った高度なレイアウト技法（いわゆるテーブルレイアウト）も確立されておらず、1ピクセル透過GIFを水平、垂直に伸ばしてテキスト間、画像間の余白を確保するというテクニックが主流でした。

Webデザインの実践的なセミナーでは、いかに印刷メディアのクオリティに近づけるかを競っていたのですから、「HTML文書は構造化ドキュメントである」なんて話はまったく理解しにくいものだったわけです。結局、CSSを扱ったカリキュラムでは参加者が集まらず、セミナーのラインナップからも消えていきました。

CSSが広まらなかった理由のひとつとして、（前述した通り）当時のWebブラウザが関連しています。Netscape Communications社とMicrosoft社による自社製品のシェア争いによって、独自拡張を搭載したブラウザが流通し、大変混乱した時期がありました。「ブラウザ戦争」と呼ばれており、1995年前後に勃発し、2000年頃に終結したといわれています。ブラウザに搭載されていた拡張タグの一部を列挙してみましょう。

・blink要素（テキストを点滅させる）
・marquee要素（テキストをスクロールさせる）
・bgsound要素（音楽を再生する）
・multicol要素（ページの段組みを指定する）
・spacer要素（余白を指定する）

CSSの実装は不完全でしたが、HTMLを独自に拡張することで視覚表現力を向上させていたのです。当然、難解とされていたCSSよりも容易に扱える拡張タグの方が注目されます。ところが、ブラウザの互換性が保証されておらず、Internet Explorerでは機能するが、Netscape Navigatorではまったく動作しないという大きな問題が露呈してきたのです。

ブラウザ戦争が激化していた1998年、「WaSP（The Web Standards Project）」という組織が設立されました。当時は、本来行うべき論理マークアップが広まらず、多くのWeb制作者は文書構造を考えずにブラウザのデフォルト表示だけを見ていました。たとえば、引用のマークアップとして使われるblockquote要素をインデント（字下げ）として扱ったり、段落のp要素を1行空けの表現に使っていました。

このような行為を広めてしまったのが、当時のブラウザだったと考えてよいでしょう。論理マークアップの重要性を啓蒙していた人たちには、「HTMLやCSSを正しく実装したブラウザが流通しない限り、Web制作者の意識も変わらない」という危機感がありました。

WaSPは、Web制作者に正しいマークアップを即し「特定のブラウザに依存しない柔軟性の高いWebサイト」作りが多くの利点を持つことを説き、ブラウザベンダーに対してはW3Cが勧告する技術標準に沿った実装を行い、独自拡張仕様のサポートを控えるよう意見してきました。このような活動に力を発揮したのが「Web Standards」というkeywordだったといえるでしょう。この言葉の強さと魅力は、現在でも廃れていません。

本連載では、HTMLおよびCSSを技術標準文書に沿った内容で解説していきますが、「標準準拠」が目的化されないように注意したいと思います。1998年にWaSPが発信した「特定のブラウザに依存しない柔軟性の高いWebサイト」というメッセージを、「どのような環境でも等しく情報提供できる柔軟性の高いWebサイト」といったように広げて、本連載の指針としていきたいと思います。

ただし、「どのような環境でも等しく～」というのは、どのブラウザでも見た目を同じにするピクセルパーフェクトのデザインを意味しているわけではありません。異なった環境でも伝えたい情報が欠けることなく提供できるか、という考え方です。

「標準準拠」の目的化を避けるという点についても触れておきましょう。一例としてブラウザのバグなどに対する特別なテクニックがあります。たとえば、普及が進むInternet Explorer 7のページズーム問題（ページズーム使用時にのみ発生するレイアウトの崩れ）の解決策として、独自拡張のzoomプロパティが使われています。当然ながらzoomはMicrosoft社の独自拡張仕様ですからW3Cのバリデーターではエラーとなります。

さて、ここでWeb制作者の行動が分かれていきます。実利的な判断を優先して独自拡張やCSSハックを採用する人、あくまで暫定処置として使用する人（条件付きコメントを使ってバリデーションをクリアする等）。独自拡張を使用しなくても表現可能な設計を行う人など、さまざまです。

冒頭で「Web標準」はあらゆる解釈を許容すると書きました。重要なのは、携わるプロジェクトの指針であり、目的を明確化するための情報共有だと考えます。Web標準に準拠するメリットとして以下の点が強調されています。

・特定の環境に依存しない柔軟性の高いサイト作りが可能
・実績のある仕様を採用することで作業を効率化しやすい
・ノウハウや知識の共有化促進、教育継続性の利点など

これらのメリットは計画的に採用することで得られるものですが、プロジェクトのスケールによっては利点にならない場合もあります。Web制作の現場で「あちら立てればこちら立たず、こちら立てればあちらが立たず」というトレードオフを経験した人ならイメージできると思いますが、単純に「あちらは間違い、こちらが正解」などと言い切れない難しさがあります。仕様に沿ったリファレンス学習だけでは実践的なCSSデザインは困難というのが現状であり、裏技的な対処法や流行も見据えた上で進めなければならないのがWebサイト作りのややこしいところです。

Web標準とは～である！といった歯切れのよい話にはなりませんでしたが、ご安心ください。世界の動向をみることで「今、自分が取り組みべきWeb標準」の判断が容易になります。

次回は、「事例から学ぶWeb標準準拠のサイト・デザイン」と題して、海外の企業サイトなどが技術標準をどのように取り込んでいるのかを見ていきます。CSSの使い方にもバリエーションがあり、とても参考になると思います。第3回からXHTML＆CSSによるサイト制作の実践がスタートしますが、次回は事前学習として捉えてください。

1996年頃に流行った視覚表現テクニック。テキストと画像の間に1x1ピクセル透過GIF画像を挿入し、幅と高さを変更して余白を作る

最上位の見出しにはh1要素を使うなど、文書の構造を意識したマークアップのこと。
一方、b要素、i要素、font要素などによるブラウザ上の視覚表現を目的としたマークアップのことを「物理マークアップ」と呼ぶ。 物理マークアップによるサイトのほうが圧倒的に多い。ただし、論理マークアップを採用したブログサービスなどの影響で、文書構造を意識したサイトも急速に増えている。

どのブラウザでも見栄えを統一するために単位をピクセルで指定するなど視覚表現の優先度が高いデザイン方針

WebページをIE 7の「ページズーム」機能で拡大表示するとテキストやフォームコントロールなどが重なって表示されてしまう等の不具合（zoomプロパティで解決できる）

文法的妥当性をチェックするためのプログラム。「The W3C Markup Validation Service」などがある