ここはページのトップになります

親愛なるT氏に宛てた私信

ウェブスタンダードって何やねん？

ホーム　>　コラム・エッセイ　>　ウェブスタンダードとは

このコンテンツは、私の友人であるT氏に宛てたものである。数日前、彼とメールのやりとりをしていた、そこで「ウェブスタンダードとは何か？」という彼の質問に対して、回答すると約束した。しかし、そこで考えたウェブスタンダードを語るには、メールで送信するには、あまりにも長文になってしまう。そこで思い直し「Webコンテンツとして発表する」と約束を変更した。そして、書きあがった内容を読み返すと、親愛なるT氏以外にも、多くの人に読んでもらいたくなった。

このコンテンツは、そういったいきさつで書かれたものである。

はじめに

親愛なるT。最近「ウェブスタンダード」という言葉をよく耳にする。あるいは「Webの標準化」とか…。ちょっと気になって調べてみた。すると、それはまさしく僕が取り組んでいる事柄のことであった。その言葉の意味を理解し、最近は自分自身も「ウェブスタンダード」という言葉を発する機会が増えている。

「最近、森川さんは何をしているのですか」という質問には「Webスタンダードですわ」と答えることにしている。こういう回答をする前は、こう言っていた。
「テーブルタグを使わないで、CSSだけでデザインレイアウトを行って、コーディングはXHTMLでやってます。なぜかというと、それはアクセシビリティに準拠していて、さらに将来的にXMLによるパブリッシングの可能性を持っていて…、え、アクセシビリティですか？アクセシビリティとは、すべての人が平等に情報を…（中略）…それに、何よりも、こういった手法はクリエイターとして新しい発見があるわけで、それが自分にとって『萌え』であるわけで…」みたいに長い長い説明になってしまっていたのである。

しかし、考えてみればもっと簡単に説明もできる。
「XHTML＋CSSだけでWebサイトを構築すること」…と。

このメールでは、「ウェブスタンダードが産まれた背景」「その必要性」みたいなものを順を追って書いていこうと思っています。少し長文になるけど（かなり長文になるかな…）我慢して読んでください。

ウェブスタンダードなもの

まず、そのウェブスタンダードである、XHTML＋CSSというものを使って作成された事例を見るのが手っ取り早いと思うので、そのサイトを幾つか紹介します。まずは、今、君が見ているこのサイト。シリコンカフェそのものがウェブスタンダードとしてサイト全体を構築しています(笑)。自分で言うのも照れくさいですが、もちろんまだまだ発展途上でもあります。個人サイトとして実験も含めてできることをやっている…って感じかな。
その他には、以下のようなサイトを見てください。

http://www.macromedia.com/

http://www.wired.com

どうですか？マクロメディアもワイアードも初めて見るサイトじゃないだろうから、ちょっと拍子抜けしたかもしれません。「ウェブスタンダード」というと、何か特別なことのように思うかもしれませんが、そんなことはないです。なんせスタンダードですから。フツーのことをフツーにやっているだけのことであります。
※ちなみに、マクロメディアは日本のサイトもXHTMLで記述されていますが、日本のワイアードはテーブルタグデザインのままです。

では、これらのサイトは従来のサイトとどう違うのでしょうか？もし、君がWindowsでInternet Explorerを使っているなら、以下のサイトにアクセスして、「ス切リボ」プログラムをダウンロードし、インストールしてください。

http://pmakino.jp/soft/sukibo/

このページを「ス切リボ」でスタイルシートをオフにした状態このス切リボとは、Internet Explorerのプラグイン。閲覧しているWebページに対して、スタイルシートをオフにする機能を持っています。

このシリコンカフェをはじめとして、紹介したサイトで「ス切リボ」を使ってスタイルシートをオフにすると、最初に見ていた画面とは全く異なったものとして表示されるはずです。あまりの表示の違いにびっくりするでしょう。私もそうでした。こうして見えている状態がスタイルシートを切った状態。つまりHTMLそのまんまの状態であるわけです。

構造と表示を分離する

このスタイルシートを切った画面を見ていて、何か思い出すことがありませんか？私はこの画面を見ていて、インターネットに初めて接続した頃、1995年当時にあった多くのホームページというものを思い出しました。
…多くのホームページという表現はちょっと間違っていますね。当時はそんなにホームページがありませんでした。Yahoo! Japanもない時代です。毎日「NTTの新着情報」というサイトから、新しくできたサイトを見て回っていた頃です。当時、使用していたブラウザはNetscape Navigator 2でしたよね。当時はそれほど企業のサイトが多くない頃で、日本ではまだ大学とか一部の公共機関のサイトばかりの時代。そう、あの頃です。

こうしてスタイルシートを切ったブラウザ画面を見ていると、なんだかタイムスリップしたような気分になります。そして、あることを感じます。実はホームページとは本来こういったものではなかったのか…と。

インターネットとは…世界が冷戦の頃、合衆国が防衛のために作ったネットワークだったんだよ。インターネットは冷戦が終わり、残ったネットワークを学術的に共有して行こう…という動きからスタートしたんだぜ。
…なんてインターネットマガジンで覚えたことを、自慢そうに語っていた時代。そうしたネットワークが前提であるから、学術的な論文であるとかを伝えるためにHTMLというマークアップ言語が生まれ、ブラウザが作られたわけです。もともとは文書情報を伝えるためのものだったのです（もっと遡るとSGMLなんてのがありますが、あまり昔話ばかりしても仕方がないので割愛します）。

文書として情報を伝えるには、決まりごとがありますよね。まあ、それが付箋に書いたメモとか、ノートの切れっぱしとか、スケッチブックに書いたサムネールなら別ですが、他者に情報を伝えるには、それなりの書式が必要です。例えば、見出しをつけるとか、本文は段落で分けて読みやすくするとか、箇条書きにする項目は、分かりやすく先頭に記号をつけるとか…。
そういったHTMLの書き方を「構造化されている」とか言ったりします。

そういう意味で、例えばこのサイト。シリコンカフェの場合どうでしょうか？ページの中で大きな見出しがあり、次に中見出し、小見出しなどが階層状態になっていますね。また文章も段落として分割して読みやすくしています。さらに、リンクのボタンになっている部分は、ある意味「箇条書き」なのでリストとして書かれているはずです。そういう意味では、このページのHTMLとしての記述は正しく構造化されているのです。そして、そういった構造の上に、CSSによって装飾を施している。

HTMLとCSSの関係は建物で言うと鉄骨と、内装および外装。人間で言うなら肉体と衣服みたいな感覚です。内装や外装は時々、リフォームによって姿を変えます。ペンキを塗りなおすだけでも随分印象変わるし。人間に至っては、洋服を変えるなんて日常でしょ。CSSとHTMLの関係ってのは、そういうものです。

ウェブスタンダードと呼ばれるものの手法が、こうしたXHTMLとCSSによるものなのですが、なぜこれらが「スタンダード」と言うのでしょうか？理由は簡単です。それは「正しい行い」であるからです。そして普通のことであるべきものなのです。さらに言ってしまうと、将来ホームページの構造は、かならずこういった形状になっていくと思います。

では、スタンダードでないものが世の中のWebサイトの多くを占めている理由はなぜでしょう？それを説明するには、この10年くらいの動きを考えてみる必要がありそうです。

以下に示す事柄は、インターネットでの10年間の流れです。かなりざっくりしたものですが、当時のことを思い出して、自分自身に重ねて眺めてください。

むかしむかし…

私がインターネットを始めたのは1995年。阪神大震災の年でした。被災者である私は、兵庫県と通産省にデジタル復興支援を提案し、それは「デジタルクリエート工房」としてスタートしました。ここには当時は高額で個人では導入することのできない専用線が引かれていました。1995年の後半くらいからホームページを作り始めて、1996年には多くの企業サイトを仕事として請け負っていました。当時の環境はNetscape Navigatorが2から3になる頃。HTMLｎバージョンも2から3くらいの間。

企業サイトとして、画像を使うことが他社との差別化の時代でした。はじめて購入した「タグ辞典」なる書籍では、見出しの付け方とか、リストの書き方とかが書かれていました。そして、当時はNetscape Navigator王国の時代で、そろそろInternet Explorerとのブラウザ戦争が勃発する時代。その二社が、それぞれのシェアを拡大するために、ブラウザ独自のタグを作って公開していた時代でした。

冒頭に書いた、本来「情報を伝えるために文書を構造化する」って行為は、この頃から失われはじめていました。なぜなら、企業サイトの仕事を請け負うには、他社よりもビジュアル面で優れていなくてはならないからです。本来、文書の見出しは、見出しとしてタグ付けをしなくてはなりません。しかし、大見出しである<h1>を使うと、やたら巨大で太い文字で表示され、センスのかけらもないページになってしまうのです。そのためにPhotoshopで画像ファイルを作成し、それを見出しとして挿入していました。

さらに、印刷物と比較すると、ブラウザってのはワープロのように上から順に文書を流し込むだけ。DTPのような段組のレイアウトを行うことができません。そのためデザイナーは本来「表組」を表現するためのテーブルタグを使って、テーブルのセルの中に文字や画像を流し込み、さらにテーブルのボーダー（仕切り線）の表示を非表示にして、印刷物のような表現をブラウザでも実現できることを目指したのです。言ってみれば、みかん箱を勉強机代わりにして学習に励む…みたいなイメージです。（ちょっと美しく解釈しすぎ？）…いわゆる日本のWebの黎明期と言われる時代です。

そんな時代に、バコバコと企業のWebサイトを作っていた私は、前記の年表にある事柄なんてあまり知りませんでした。今自分が作っているHTMLが、どのバージョンに準拠しているのか…なんて全く気にしません。W3Cという組織があることは知っていましたが、何をしているかあまりよく知りませんでした。なんせ英語のサイトですから、読む気がしないわけです。つか「読めない」というのが正しい言い方です。そんなことより作ったホームページがちゃんと「ブラウザで表示される」ことの方が大切でした。

まあ、そうこうしているうちにインターネット人口も増え、Windows98とかが爆発して、Macintoshユーザーはますます肩身の狭い思いをしはじめ、Netscape NavigatorとInternet Explorerでの表示の違いよりも、Netscape NavigatorのMacintosh版とWindows版での表示の違いの方が気になっていた時代でした。

懐かしいですね。Netscape 4.7の起動画面です実は、この頃がブラウザ戦争と言われるピーク時であったわけで、それぞれが独自のタグやスクリプトを連発し、混乱しまくっている時代でした。それを終結させる意味もあった…のかどうかはワカリマセンが、1996年にCSS1が勧告され、1997年に中途半端にCSSに対応したNetscape Navigator4がリリース。1998年にはHTML4.0の最終版が勧告されています。このHTML4.0の仕様書では、WebページはCSSを使って情報と装飾は分離することが望ましい…なんて事が書かれていたそうですが、そんなことはちっとも知りませんでした。つか、そんなもの知らなくても、仕事はバンバンやってくるし、何の問題もなかったわけです。

さらに、1998年にはマクロメディアよりFireworksがリリースされます。私にとっても、おそらく多くのWebデザイナーにとっても、これは大きな事件だったのではないでしょうか？

Fireworksが残したもの

さて、Fireworksと私の関係は今更言うまでもないですよね。世界で一番早くFireworksの使い方をWebで公開して以来、テクニカル本の執筆や雑誌の連載、そしてマクロメディア主催のイベントや、独自で企画した「デスマッチセミナー」。以前に、Fireworksに関して、どれだけのオーディエンスの前で、このソフトについて語ってきたのか…をカウントすると、なんと二万人にも及んでおりました。

私にとってはじめての著書「Fireworks徹底解析」当時の私にとって、Webグラフィックを作成するツールとしてFireworksは画期的なアプリケーションだったのですが、なかでも「これはすごい！」と感じたのは、スライス機能です。デザイナーはWebブラウザ上でのデザインをFireworksで作成し、あとはスライスオブジェクトを配置して書き出しを行う。すると、Fireworksはスライス指定によって、画像を分割し、さらに分割した画像をテーブルタグによって組み立てているHTMLファイルを生成する。この機能は、Fireworks以外にもPhotoshopにも採用され、グラフィックソフトがWeb画像を作成するための機能として、多くのアプリケーションに採用されました。

そして、その機能の素晴らしさを、私は二万人の前で語り、さらにFireworksの解説本を執筆し、まさに「Fireworksマンセー」と叫んでおったわけです。「見栄え」の都合によって、画像をぶつ切りにして書き出しを行う。それを無理やりテーブルタグを使って組み立てるのですから、本当はかなり凶悪なソースコードを書いているのですが、スライスの魅力に取り付かれた私にとっては、そんなことはどうでもよかったのです。

さらに、Fireworksと密接な関係である、HTMLエディタであるDreamweaverに関しても、多くのセミナーを担当したり、雑誌の記事を書いたりしてきました。
Dreamweaverの素晴らしいところは、ソースコードを見なくても、WYSIWIGライクにデザインプレビューモードでレイアウトを行えることでした。その割には綺麗なソースコードを書き出すため、「もうタグを手打ちする時代は終わった。手打ちなんて『蕎麦屋』だけで十分だ」とか、「ソースにこだわる時代じゃない、そんなにソースにこだわるのなら、洋食屋にでもなればいい」などと、暴言を吐きまくっていました。

確かに、コードを自動生成するアプリケーションとしてはDreamweaverは素晴らしかったのですが、結局「論理的な構造」を理解していない限り、めちゃくちゃなソースコードを組み立てをしてしまうことになります。テーブルの中に、さらにテーブルを配置するなどという邪悪なマークアップも、ブラウザで表示されれば、それでオッケーという時代であったわけです。

もっとも、W3Cの仕様に従ってHTMLはテーブルタグを使わずにマークアップし、レイアウトを含めた装飾的表現は、ずべてCSSに依存する…という考え方がなかったわけではありません。しかし、本当の意味でCSSをきっちり解釈してくれるブラウザである、Navigator6（でも完璧ではない）が登場するのは2000年。
実は、この段階でもNetscape Navigatorは100％完璧ではなく、HTML＋CSSだけで、レイアウトやデザインを行う…というのは、実用的ではない時代でした。

というか、実は私もこの段階で、まだCSSでレイアウトを行う…なんてことは夢物語であると思っていました。仮に、その手法を知っていたとしても、大好きなFireworksのスライス機能から離れることがイヤだったのだろう…なんて思います。

アクセシビリティとの関係

Webも2000年に突入すると、もう片手間な時代ではなくなり、企業によってはビジネスの中心的なツールとして機能する役割を担うようになります。2000年にはSIPSなんて観念が出てきて、Webが本格的にビジネスの中心になる動きがいっそう活発になります。さらにFlashに関しても、バキバキと刺激的なサイトが誕生し、HTMLでの表現のショボさに飽きたクリエイターが、どんどんFlashへ走り始めました。そして、かつてメインであったNetscape Navigator4は過去の遺物となり、テーブルスライスにしても当時デフォルトであったInternet Explorer5とは表示が異なる場合が多く、クライアントは、すべてのブラウザで同じように表示されることを望んでいました。

その一方で2000年の11月にはW3C がWCAG 1を勧告しました。WCAGとは「ウェブ・コンテンツ・アクセシビリティ・ガイドライン」で、その翌月（12月）には米国で「リハビリテーション法・508条」が公示されます。いわゆるWebアクセシビリティへの標準化です。

この508条は、米国内のウエブサイトをアクセシブルにすることを定めた法案で、違反するサイトに対して（つまりアクセシブルではないサイト）訴訟を起こすことができるのです。実際に過去に於いて訴訟まではいきませんが、その前段階である「警告」というモードには、アメリカの巨大コンピュータ会社と、巨大プロバイダが警告を受けています。それ以降、一気にアクセシビリティが標準になりつつあるようです。

この508条には具体的に制作者に対して「ああしろ、こうしろ」とは言っていません。しかしがら、508条のベースにもなっているといわれているWCAGでは、細かい制作上の指摘が書かれています。その中に「ページの構造化には、最新のHTMLを使用し、装飾や表示に関する情報はCSSを使って、構造と表示を分離するべきである」と言っています。当時の最新のHTMLのバージョンは4.1。ちなみに、508条公示の翌月にW3CがXHTML1.0を勧告しています。

しかしながら、まだまだ世の中はテーブルレイアウトが花盛りの時代。それどころか、見出しには画像を使うことが当然で、ロールオーバーボタンにはJavaScriptを使って、どれだけグラフィカルなサイトを提案できるかがビジネスのキモだったと思います。

しかしながら、アクセシビリティという「情報を多くの人につたえる」ための本質を問われるような動きが出てきてたことも事実ですし、この時期には「ユーザビリティ」なんて言葉もビジネス寄りの部分から出てきて、サイトの集客、訪問者にとって使いやすいサイト…みたいなことが、まじめに考えられ、それらがビジネスメリットへ結びつき多くの仕事が発生した頃でした。

そして、その頃にはWebバブルもはじけ、制作会社はクリエイターの工数を正確に把握して、シビアに利益を出す時代へと変わっていきます。また2002年のNavigator7の登場によってブラウザは、ほぼ完璧にCSSをレンダリングする時代になってきたことも、Webデザインの作業環境が変わることを予測するような出来事であったと思います。

構造化なんて興味が無かった

さて、長い長い解説ですいません。ここまででちょっとおさらいをします。

HTMLを記述する上において、論理的な構造を持たなくてはならない…ということは基本。しかし、企業サイトで担当者のリクエストを受け付ける工程や、デザイナーが、そのデザイン力で生活していくために、論理的な構造を保つことはデザイン的に満たされないことことが判明した。だから論理的な構造を無視して、「見栄え」を優先させることになった。

その「見栄え」のためには邪悪なソースコードを書くことも辞さなかった。本来見出しとして定義される文書には、FireworksやPhotoshopで作成されたイメージソースが配置され、小見出しとして定義する部分には、単にボールドとフォントカラーという装飾的なマークアップしか行わなくなった。行間を整えるために<br>タグを何度も繰り返して挿入し、音声ブラウザでは読み上げる順番がおかしくなることなんて気にしないで、テーブルタグを使ってレイアウトを行い、さらに都合が悪くなると、テーブルのセルの中にテーブルを挿入し、さらにテーブルを…なんて劣悪なコードを書いても、なんとも思わない状況になった。

そういった、本来やってはいけないことを回避するためにHTMLの構造化とCSSによる装飾条件の変更などが行えるにも関わらず、ブラウザが非対応であるため、なかなか現実的にコンテンツとデザインの分離は実現できなかった。

しかしながら、Webアクセシビリティに準拠することの重要性（ソーシャルな意味でもビジネスメリットとしても）や、ブラウザの対応、さらにDreamweaverなどのバージョンアップによる制作環境の整備によって、CSSを使ったレイアウトが一般的になってきはじめている。

特に日本においては2004年6月にJIS-X-8341が公示されたことも、ウェブスタンダードへ準拠しようとする方向への後押しになってきているように思う。

昨年から徐々に変化がはじまっている？

こうした変化は、2003年くらいから始まりました。昨年の春にワイアード（米国）が、CSS＋XHTMLを実装し、その年の夏にはマクロメディアが同じく対応しました。

CSSだけに注目すれば、今年のアテネオリンピックのサイトや、米国のYahoo!もCSSだけでレイアウトを行っています（ただし、これらはCSSだけに注目したリニューアルで、ソースコードはけっこうジャンクです。とくにYahoo!は酷いなあ…って思っています）。

目先の仕事に追われていたWebデザイナーも、徐々に変化を始めています。昨年の秋以降から注目されているブログも、CSSへの興味を増大させることになっている。そして多くの雑誌がCSSの特集を組み、書店に並ぶ専門書もCSSオンパレードなのです。

いつの時代でも新しい技術とか仕様が公開され、それが一般に広く受け入れられるのは3年くらい経過してからですね。そういった意味ではアクセシビリティなんてのは、かなり一般的になりつつあるし、まさにCSSレイアウトっては、これからどか～ん！と爆発するんじゃないでしょうか。そして、それは単に流行とかブームでなく、アクセシビリティにしても、ウェブスタンダードにしても、この先の必須項目だと思うからです。

おそらく、この先にかつてのブラウザ戦争のような混沌とした時代はやってこないと思います。何を信じていいのか分からない時代ではなく、明らかにWebはあっち（どっち？）の方向へ向かうだろうと予測ができます。

この先にCSSとXHTMLに変わるスタンダードが現れるとか考えにくい。もちろんCSSはさらにバージョンアップするし、XHTMLもバージョンアップするでしょう（ちなみにHTMLは4.1にて開発終了）。しかしそれは、根本的な仕様を変更するものではなく、拡張という意味になってくると思います。

特にXHTMLはXMLへの拡張性の高さを受け入れるだろうし、ブラウザ環境もそれに合わせてくる。おそらくマイクロソフトが独自の拡張を考えるようなことは考えられないでしょう。（とはいえ、ゲイツのことなんで、何がどうなるか分からないですが、もしも、今後MSがスタンダードから外れると、それは帝國の崩壊につながると思います）。

世界のWebサイトのほとんどは、ウェブスタンダードに準拠していなません。たぶん90%くらいは前世紀のWebデザインのアプローチのままです。しかし今から1年前は99%くらいの確率で準拠していなかったわけで、そういう意味では、徐々に実装が開始されてきていると思います。

また、同様にWebデザイナーのほとんどはウェブスタンダードを実現するためのスキルを実装していないと思います。これからはクリエイターにとって大変な時代になるんじゃないかな？

しかし、世の中の目指す方向が、ウェブスタンダードであれば、企業がリニューアルを行う際には、この条件が必須になってくるだろう。なぜならウェブスタンダードを実装することについて、「都合の悪いこと」が見当たらないから。もっとも引き受けるデザイナーにとっては、ウェブスタンダードを実現できるスキルを身につけていない場合は、彼にとって「都合の悪いこと」になってしまうのだが。

ウェブスタンダードを導入することによって、どんなメリットがあるのか。簡単に書いてみよう。

まあ、こんなとこですか。

これからのWebクリエイター

実際に、これからWebクリエイターは大変だと思う。ウェブスタンダードに準拠すること。つまり構造的なHTMLを書き、CSSだけを使ってデザインやレイアウトを行うことは、従来のテーブルタグと1ピクセル透明スペーサーを使ってレイアウトしてきたスキルとは無関係だ。

従来のスキルは、まったく役に立たない。コーディングを行う人間にとって、テーブルタグの不都合をブラウザでチェックするより、見出しやリストでコンテンツを構造化することに大いに悩むだろう。さらにCSSだけでレイアウトするためのテクニックは大筋を理解するために、けっこうな時間を消費する。

だからといって、クライアントはクリエイターの勉強に対してコストを支払う義務はないし、ウェブスタンダードに準拠できない制作会社には案件を発注する必然もない。

自分自身、大好きなFireworksでスライスしたHTMLを使えなくなったことは、けっこうショックだった。自分自身として、大切に育てて売り物にしてきたスキルが全く役に立たないのである。

しかし、かつて大勢の人にFireworksのスライスHTMLの素晴らしさを説き、多くのスライステクニックを執筆してきた私にとって、おこなうべきことは「まじすまんかった」と謝ることではなく、正しいウェブスタンダードへのワークフローなどを公開することだと思っています。なので、あえて言います。

「5年前、これは素晴らしい！と絶賛したFireworksのスライスHTMLの書き出しによるサイトデザイン、サイト構築は、もう過去の遺物です。この先Webを制作していこうと思っているクリエイターや、個人や発注側の方々へ…。いま取り組まないとえらいことになります。」

…なんか、最後は妙な懺悔で終わってしまったが、およそ「ウェブスタンダードを取り巻く状況」ってのは、こんな感じ。参考になったかな。また分からないことがあれば、あるいは納得できないことがあれば、メールくれ。追記でどんどん説明していきます。