❧
私は最近、ある Mozilla の開発者が 標準の策定における葛藤 についてこう述べているのを目にした。
実装と仕様は、繊細なステップを踏みながら踊り続けないといけないんだ。仕様が安定する前に実装が始まって欲しくないというあなたの気持ちは分かる。そんな未完成の実装に人々が依存しはじめて、それがあとあと仕様そのものにも影響することを怖れているのだろう。でも、仕様が実装や制作者が試す前に固まってしまうのも考え物だろう。それは、仕様にはフィードバックが必要だからだ。両者の間には常に葛藤があって、僕らはその間でなんとかやっていくしかないんだ。
この言葉を心にとどめておいてほしい。では、なぜ我々が HTML5 に至ったのかを話そうじゃないか。
❧
この本は HTML5 についての本で、前のバージョンの HTML や XHTML についてのものではない。ただ、HTML5 の歴史や背景、その目的を理解するにはいくつかの技術的な概念を知っておく必要がある。特に必要なのが、MIME タイプと呼ばれるものだ。
Web ブラウザがページをリクエストすると、サーバは実際のページを渡す前に「ヘッダ」というものを送信する。ヘッダは通常見えないが、Web 開発ツールの多くはそれらを表示する事ができるので気になるなら確かめてみればよい。さて、目には見えないが、ヘッダは重要だ。なぜなら、ヘッダには、後に続くマークアップをどう解釈すればよいかをブラウザに伝える働きがあるからだ。中でも Content-Type というヘッダは何よりも重要だ。
Content-Type: text/html
この “text/html” がページの “content type” もしくは「MIME タイプ」と呼ばれるものだ。このヘッダは、リソースが実際に何なのかを記す唯一のもので、つまりこのヘッダによってリソースがどう描画されるかが決定される。たとえば、画像には画像の MIME タイプがある (JPEG には image/jpeg が、PNG には image/png がある)。また、JavaScript には JavaScript の MIME タイプがある。CSS スタイルシートにも専用の MIME タイプがある。すべてのものに MIME タイプがある。Web は MIME タイプの上に成り立っているのだ。
もちろん、現実というのはもう少し厄介なものだ。最初期 (1993 年頃) の Web サーバは Content-Type ヘッダを送信していなかった。その時はまだ、このヘッダそのものが存在していなかったのだ。 (Content-Type の登場は 1994 年のことになる。) そういった 1993 年のサーバとの互換性のため、いくつかの大きな Web ブラウザは特定の条件下で Content-Type を無視するようにした。(これは “content sniffing” と呼ばれる。) しかし、一般的なルールとして、Web にあるすべてのもの ― HTML ページ、画像、スクリプト、ビデオ、PDF など URL を持つものすべてが、それぞれの MIME タイプを Content-Type ヘッダから送信している。
このことも頭の片隅にとどめておこう。あとでまた、MIME について触れることになる。
❧
「どうして <img> 要素なんてものがあるんだい?」なんて質問を聞くことはそうないだろう。もちろん、<img> 要素があるのは誰かが生み出したからに他ならない。何もないところから、突然わいて出てきたわけではないのだ。すべての要素、すべての属性、あなたが使ったことのある HTML の機能のすべては、誰かが生み出し、どのように機能するかを決め、書き出したものだ。彼らは神ではないし、完璧でもない。ただの人だ。もちろん賢くはあるが、ただの人なのだ。
オープンな策定が行われている標準の素晴らしいところは、先ほどのような質問に過去をあたって答えられるところにある。議論はメーリングリストで行われ、それらはたいていアーカイブされており検索が可能だ。というわけで、少しばかりメールを発掘して「なぜ <img> 要素があるのか」という質問に答えてみよう。それには、W3C (World Wide Web Consortium) という団体が設立されるよりもさらに前までさかのぼる必要がある。どれくらい前かというと、それは Web が始まった頃、つまり Web サーバを両手で数えられるくらいまで前になる。足の指もすこし必要かもしれないが。
(引用したメールの中には誤字や脱字、表記揺れがあるが、正確性のためそれらはそのままにしている。)
1993 年 2 月 25 日に投稿された Marc Andreessen のメッセージ には、こんなことが書かれている。
新しい HTML タグを提案したいんだ。
名前: IMG
必須属性:
SRC="url"このタグはビットマップやピクセルマップファイルがあることをブラウザに伝える。ブラウザはネットワークからファイルを取得し、それを画像として解釈し、タグがあった場所に埋め込む。
こんな感じに書ける。
<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">(終了タグはなくて、スタンドアローンなタグだ。)
このタグはアンカーの中にも埋め込める。アンカーの中に入れると、それはテキストのアンカーと同じように実行できるアイコンとして機能する。
どの画像フォーマットをサポートするかはブラウザの自由だ。たとえば、Xbm や Xpm がいいフォーマットじゃないかな。ブラウザがそのフォーマットをサポートしていないときは、やりたいようにすればいいと思う (ちなみに、X Mosaic はデフォルトのビットマップをプレースホルダとしてポップアップするようになっている)。
このタグは X Mosaic に必要なんだ。すでに動くものを作っているし、少なくとも X Mosaic 内部で使うつもりだ。でも、このタグがどう HTML でどう処理されるか、意見を聞かせてほしい。もしこれよりいいアイデアがあったら、ぜひ教えてほしい。画像フォーマットは難しいところだけど、「ブラウザがやりたいようにすればいい」っていう以外に、うまい言い方を思いつかないんだ。それに、完璧な解決法が見つかるかもしれないし、待ってみようと思う (MIME? そうかもね)。
この Xbm と Xpm というのは、Unix システムで広く使われていた画像フォーマットだ。
“Mosaic” はもっとも古い Web ブラウザのひとつだ (“X Mosaic” というのは、Unix システム上で動くバージョンのことだ)。このメッセージが書かれた 1993 年初め、まだ Marc Andreessen は Mosaic Communications Corporation の設立も、そしてその主力製品である “Mosaic Netscape” の開発も始めていなかった (これらの名前にピンとこない人は、後々の名前 “Netscape Corporation” と “Netscape Navigator” といえばおわかりだろうか)。
「MIME? そうかもね」というのは content negotiation を指している。これは HTTP の機能で、クライアント (ブラウザなど) がサーバ (Web サーバなど) にどのようなリソースをサポートしているか (image/jpeg など) を伝えることで、サーバがクライアントに適切なフォーマットを返せるという仕組みだ。1991 年に定義された最初の HTTP (1993 年 2 月時点で実装されていた唯一のバージョンになる) では、クライアントがサーバにどの画像形式をサポートしているかを伝える手段がなかった。このため、Marc はこのジレンマに直面していたのだ。
数時間後、Tony Johnson のメッセージ が返ってきた。
僕もこれに似たものを Midas 2.0 (ここ SLAC で使われていて、あと数週でリリースされる) に搭載している。ただ、名前は全部違っていて、
NAME="name"という引数も持っている。書き方はきみのIMGとほぼ同じで、こう書く。
<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
nameパラメータの意図は、ブラウザが「ビルトイン」の画像を持てるようにすることだ。指定した値が「ビルトイン」画像にマッチすると、画像の代わりにそっちを読み出す。nameは “line mode” ブラウザに対して、画像の代わりに読み出すシンボルのヒントにもなる。僕はタグやパラメータの名前にそこまでこだわらないけど、同じ名前を使った方がいいと思う。
IMAGE=とかSOURCE=ではなく略語を使うことにもこだわらない。でも、何となくIMAGEは小さめの画像を表しているように聞こえるから、ICONの方がよいかな。でも、ICONだと極端かな?
Midas はもう一つのもっとも古いブラウザで、X Mosaic の競合だ。Midas はクロスプラットフォームで、Unix と VMS 上で動いた。“SLAC” というのは、Stanford Linear Accelerator Center (スタンフォード線形加速器センター) のことで、現在は SLAC National Accelerator Laboratory (SLAC 国立加速器研究所) と呼ばれている。SLAC はアメリカ合衆国最初の Web サーバ をホストしていた機関だった (このサーバは ヨーロッパの外に置かれた初めてのサーバでもあった)。Tony がこのメッセージを投稿していたこのときすでに、SLAC は 自身の Web サーバ上に 5 つのページ をなんと 441 日間もホストしていたという、相当な古参だったんだ。
Tony はこう続ける。
新しいタグのことについて話してるから、僕が Midas 2.0 でサポートを考えている別のタグの話をさせてくれ。そのタグは今のと似ていて、こんな感じで書く。
<INCLUDE HREF="...">このタグの目的は、タグで指定した別の文書がタグがある部分に読み込まれるというものだ。指定した文書はなんでもいいけど、主な目的は画像 (任意の大きさ) を文書内に埋め込むことだ。もちろん HTTP2 が来たら、呼び出された文書のフォーマットは別のネゴシエーションを経ることになるだろうね。
“HTTP2” というのは Basic HTTP as defined in 1992 を指す。1993 年初頭でも、この規格はほとんどが実装されていなかった。“HTTP2” として呼ばれたこの草案はその後 “HTTP 1.0” として標準化されている (とはいえ、さらに 3 年後の出来事 にはなるが)。HTTP 1.0 は content negotiation のためのリクエストヘッダ を定義していた。さっき言った「MIME? そうかもね」だ。
Tony はさらにこう言っている。
ただ、こっちの方ががいいかなとも考えている。
<A HREF="..." INCLUDE>See photo</A>あまり
<A>タグに別の機能をこれ以上追加したくないというのはある。ただ、こう書ければINCLUDEパラメータを理解しないブラウザと互換性を保つことができる利点がある。こうするとINCLUDEを理解するブラウザでは、アンカーテキスト (この場合は “See photo”) が指定した文書 (画像など) で置き換えられ、古かったりしょうのないブラウザではINCLUDEが完全に無視されることになる。
この提案が実装されることはなかったが、画像がない場合にテキストを提供するという考えは アクセシビリティにおいて重要なテクニック になる。そしてこの仕組みは、Marc の提案した <IMG> では考えられていなかった。数年後、この機能は <img alt> として組み込まれ、すぐに Netscape によって ツールチップで表示するという間違った実装 が行われてしまった。
Tony のメッセージの数時間後に、Tim Berners-Lee のメッセージ がやってきた。
図表は次のように表現できないだろうかと考えたことがある。
<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>キーワードの意味はこうだ。
EMBED 埋め込んで表示する PRESENT もとの文書が表示された時に表示するキーワードには様々な組み合わせが考えられる。そして、ブラウザがキーワードを知らなくても、この仕組みは破綻しない。
この仕組みをアイコンを選択する方法として利用すると、アンカーが入れ子になるのは分かっている。うーむ。ただ、特別なタグは欲しくはなかったんだ。
この提案も実装されることはなかったが、rel 属性は 今も存在している。
この提案に Jim Davis が次のように付け加えている。
Content type を指定出来る方法があるといいんじゃないかな。たとえば、こんなのはどうだろう。
<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>ただ、僕は content type はファイルの拡張子で指定するっていう仕組みでも全く問題ないよ。
この提案が実装されることもなかった。が、後に Netscape はメディアオブジェクトを埋め込む仕組みを <embed> 要素として導入している。
WWW ブラウザが対応して欲しいメディアのトップに画像はある。けれど、メディアごとに固有のフックを追加すべきではないと思う。MIME タイプによる仕組みの啓蒙はどうなるんだ?
これは MIME の代わりに使われる標準ドキュメントメカニズムというわけじゃないよ。MIME とは別に必要なシンプルな機能を提供するだけだ。
MIME が問題を分かりにくくしてるようだから、いったん忘れよう。僕が反対しているのは、「様々なメディアオブジェクトの埋め込みをどうサポートするか」という方向ではなく、「どうやって埋め込み画像をサポートするか」に進んでいる議論の方向なんだ。
だってそうだろう。もしかしたら誰かが来週、音声のために「
<AUD SRC="file://foobar.com/foo/bar/blargh.snd">っていうタグを追加しよう」なんて言うかもしれないじゃないか。何かの一般化に、大きなコストをかけるべきではないよ。
今となって思えば、この Jay の懸念は鋭かった。翌週ということにはならなかったが、HTML5 ではついに <video> と <audio> が追加される。
さて、Jay の最初のメッセージに返答するかたちで Dave Raggett が次のメッセージを寄せている。
その通り! フォーマットのやりとりに関しては多くの画像/ラインアート形式を考えるようにしたい。Tim が書いた画像中のクリッカブルエリアについても重要なトピックだ。
1993 年の後半、Dave Raggett は HTML+ を HTML 標準の進化形として提案した。この提案は実装されることはなく、また HTML 2.0 に上書きされた。HTML 2.0 は “retro-spec”, つまり広く使われていた機能を規格にしたものだった。仕様書には「この仕様は様々な機能をまとめ、詳細を明確にし、規格化したもの で、機能は 1994 年 6 月以前に広く使われていた HTML のものだ」とある。
Dave はその後、HTML+ をもとに HTML 3.0 を書いた。しかし W3C のリファレンス実装である Arena を除き HTML 3.0 もまた実装されることがなく、また “retro-spec” である HTML 3.2 に上書きされてしまった。HTML 3.2 仕様書には「HTML 3.2 は広く使われている機能を追加している。たとえばテーブル、アプレット、画像に回り込むテキストがそうだ。また、HTML 2.0 など既存の標準とも後方互換性を保っている」と書かれていた。
Dave はさらにその後 HTML 4.0 を共同で執筆し、HTML Tidy を開発した。HTML 4.0 以降は XHTML, XForms, MathML, その他のモダンな W3C 関連仕様に貢献している。
話を 1993 年に戻そう。Marc は Dave にこう返している。
僕らは任意のハイパーリンクをアイコンや画像、テキストなどに埋め込める、汎用的な手続き型グラフィック言語について考えるべきかもしれない。誰か Intermedia がこういう事をできるか知ってる人はいない?
Intermedia は Brown University のハイパーテキストプロジェクトだった。Intermedia は 1985 から 1991 年にかけて開発され、A/UX という初期の Macintosh の Unix ライクな OS で動作していた。
この「汎用的な手続き型グラフィック言語」はその後広がりをみせることになる。モダンブラウザが SVG (埋め込みスクリプトつきの宣言的マークアップ言語) と <canvas> (手続き型ダイレクトモードグラフィックス API) の両方をサポートしたのだ。とはいえ、後者については WHATWG によって “retro-spec” になる以前から 独自拡張 として存在していたのだが。
他のシステムだけど Andrew と Slate がこの機能 (とても価値のある) を持っているよ。Andrew は _insets_ というものからできていて、それぞれの inset はテキストやビットマップ、ドローイング、アニメーション、メッセージ、スプレッドシートなんていった面白い型を持っている。任意の再帰埋め込みもあるから、埋め込みに対応したものにならどこにでも inset を埋め込める。たとえば、inset はテキストウィジェットのテキストや、ドローイングウィジェットにある矩形、スプレッドシートのセルとか、どこにでも埋め込める。
“Andrew” とは Andrew User Interface System を指す (しかしこの当時はただ Andrew Project として知られていた)。
僕が思うに、WWW で画像を表示する最良の方法は MIME を使うことだ。postscript なら MIME で使えるサブタイプになっているし、テキストとグラフィックスの混在はお手の物だ。
クリッカブルじゃないって? 確かに。ただ、display postscript には何か解決法があるんじゃないかな。それが無かったとしても、postscript の標準に機能を追加することは必要ないかもしれない。URL を指定して、現在のパスをボタンのための領域として利用するアンカーコマンドを定義すればいい。postscript はパスととても愛称がいいから、任意のボタンシェイプは問題ないよ。
Display Postscript は Adobe と NeXT が開発したスクリーン上に描画する技術のことだ。
この提案が実装されることはなかった。しかし、HTML を直す一番良い方法は何かと完全に置き換えることだという考えは、今でもときどき現れる。
さて、1993 年 3 月 2 日に Tim Berners-Lee がこんなメッセージを送った。
HTTP2 では登録された MIME 型だけではなく、ユーザが処理できるといったものであればどんな型であっても文書に埋め込めるようになる。そう、postscript とハイパーテキストという状態もあるだろう。ただ、display postscript が充分かどうかは分からない。Adobe が postscript ベースの “PDF” を実現しようとしているのを知っているが、それはリンクを持ち、彼らのプロプライエタリなビューアで表示できるようになるだろう。
アンカーのための汎用的なオーバーレイ言語 (Hytime ベースかな?) があれば、ハイパーテキストとグラフィックス/ビデオの標準がそれぞれ独立して進化できるようになる。その方がお互いのためにも良いだろう。
IMGタグはINCLUDEに名前を変えて、任意の文書型を参照できるようにしよう。INCLUDEという名前が cpp の include のように、SGML ソースコードをインラインでパースするものとして受け取られるのであれば、EMBEDもよいだろう。
HyTime は 初期の SGML ベースなハイパーテキスト文書システムだった。そして、初期の HTML に関する議論や、その後の XML に関する議論でも大きな影響を与えたものだった。
Tim の <INCLUDE> タグという提案も実装されることはなかった。しかし、その影響が <object>, <embed>, <iframe> 要素に反映されていることはおわかりだろう。
そして 1993 年 3 月 12 日、Marc Andreessen が舞い戻り、こんなメッセージを投稿した。
やあ。もうすぐ Mosaic v0.10 をリリースできるかなっていう段階なんだけど、そのバージョンではこないだ言ったとおりインラインの GIF と XBM 画像/ビットマップをサポートするよ。…
今のところ、
INCLUDE/EMBEDをサポートしようとは考えていない。… たぶん<IMG SRC="url">のままいくことになる (すべてのインライン画像をアイコンと呼ぶのは無理があるから、ICONという名前でもない)。当分の間、インライン画像が明示的に content-type を持つことはないだろうから、そのうちサポートしようと思う (MIME の普及も待って、それもサポートするよ)。というか、僕らが使ってる画像の取得ルーチンは画像形式をオンザフライで判別するから、ファイル名にある拡張子もそこまで重要じゃないんだ。
❧
私はこの、公開されたほぼすべてのページで使われていると言っても過言ではない、ある HTML の要素の誕生につながった、もうそろそろ 17 年にもなるこの議論のひとつひとつに惹きつけられてやまない。考えてもみてくれ。
しかしこれらの事実は、「どうして <img> 要素が存在するのか」という疑問の答えにはなっていない。なぜ <icon> 要素ではなかったのか、<include> 要素ではなかったのか。もしくはハイパーリンクに include 属性をつける、あるいは rel 属性の値の組み合わせで表現する方法はどうして実現されなかったのか。いったい、なぜ <img> 要素なのだろうか。答えはとても簡単だ。Marc Andreessen が <img> 要素を実装して、それをリリースしたからだ。
しかし、すべての実装が勝つというわけではない。Andrew や Intermedia, HyTime にも実装があった。実装は必要だが、それだけでは成功しない。また、私は標準に先行した実装が最良の方法だと言いたいわけではない。Marc の <img> 要素は画像フォーマットを指定しなかった。テキストがどう回り込むかも定義しなかった。代替テキストや古いブラウザのフォールバックもサポートしていなかった。17 年たった今でも、私たちは content sniffing に苦慮している。それは 厄介なセキュリティ脆弱性の温床になってもいる。そしてそれは、ブラウザ戦争 よりも前、17 年前の 1993 年 2 月 25 日に Marc Andreessen が言った「MIME? そうかもね」という言葉と、それを反映した実装がリリースしたときまで遡るのだ。
実装されたものが勝つのだ。
❧
1997 年 12 月、World Wide Web Consortium (W3C) は HTML 4.0 を公開し、HTML Working Group をクローズした。それから2ヶ月も経たないうちに、別の W3C Working Group が XML 1.0 を公開した。さらにそれから3ヶ月ほど経過したとき、W3C の運営者は “Shaping the Future of HTML” HTML の将来について考えるというワークショップを開催した。ここで、W3C は HTML を諦めたのかという疑問が出てくるだろう。彼らの答えはこうだ。
議論のなかで、HTML 4.0 をさらに拡張するのは難しいという見解が一致した。4.0 を XML アプリケーションに変換する必要があるからだ。このような制約を振り払う方法は、次世代の HTML を XML タグセットのもと新しく始めることにある。
W3C はその「XML タグセット」をつくるため、HTML Working Group をふたたび設立した。彼らの最初の仕事は 1998 年 12 月に、新しく要素や属性を追加せず、HTML を XML で再構成した 暫定仕様の草案だった。これが後に “XHTML 1.0” となる。この仕様は XHTML 文書のために新しく用意された MIME 型 application/xhtml+xml を定義していた。しかし、既存の HTML 4 ページからの移行を容易なものとするため、仕様には Appendix C という付録も含まれていた。そこには XHTML 文書を既存の HTML UA で表示させたいという製作者のためのガイドラインが記されていた。Appendix C では、製作者が “XHTML” なページを作り、それを text/html MIME 型で提供してもよいしていたのだ。
彼らの次の仕事はフォームだった。1999 年 8 月、同グループは XHTML Extended Forms という仕様の草案を公開した。その 冒頭 に、グループの期待がこう記されている。
検討の結果、HTML Working Group は次世代フォーム仕様のゴールと、以前の HTML 用に作られたブラウザとの後方互換性を保つことが相容れないという結論に達した。私たちの目的はよく定義された要件のもと、新しくクリーンなフォームモデル (“XHTML Extended Forms”) を提供することにある。この文書で紹介する要件は、数多くのフォームアプリケーションにおける経験を基とする。
数ヶ月後に “XHTML Extended Forms” は “XForms” と名を変え、その策定を行う Working Group が組織された。このグループは HTML Working Group と並行して作業を進め、そして 2003 年 10 月に XForms 1.0 の first edition が公開された。
XML への移行が完了するなか、HTML Working Group は「次世代 HTML」の策定に目を向けていた。2001 年 5 月、彼らは XHTML 1.1 の first edition を公開した。XHTML 1.1 は XHTML 1.0 に 追加された機能はほんの少し だったが、一方で “Appendix C” という抜け穴を封じてもいた。バージョン 1.1 以降の XHTML で書かれた文書は、application/xhtml+xml MIME 型で提供されることになった。
❧
さて、MIME 型はなぜ重要なのだろうか。先程からしつこくこれに触れている理由は、draconian error handling にある。ブラウザは HTML にいつも寛容だ。たとえ </head> タグのない HTML ページを作ったとしても、ふつうに表示してくれる。(いくつかのタグは <head> の終了と <body> の開始を示唆するのだ。) タグは段階をふまえネストする、つまり互い違いに閉じてはならないのだが、たとえば <b><i></b></i> と書いてしまったとしても、ブラウザはただ (どうやってか) 対処してしまうのだ。エラーメッセージが出ることもない。
その「壊れた」 HTML が Web ブラウザで動作してしまうことで、製作者は多くの壊れた HTML ページを作り続けてしまうことは想像に難くないだろう。ある推定によると、Web 上の 99% もの HTML ページにひとつ以上のエラーがあるらしい。しかしそのようなエラーに対しブラウザがエラーメッセージを出すことはないので、誰もその間違いを直さない。
W3C はこれを Web の根本的な問題ととらえ、それに対処しようとした。1997 年に公開された XML はそのような寛容なクライアントという伝統を壊し、XML を消費するすべてのプログラムは「整形式」に関するエラーをfatalと扱わせた。最初のエラーでfailするという概念はギリシアの支配者である Draco が法にほんの少しでも触れたものに対しても極刑を課したことに通じたことから、“draconian error handling” と呼ばれるようになった。W3C が HTML を XML ボキャブラリとして再構成した際、彼らはすべての文書が application/xhtml+xml MIME 型で処理されなければならないとした。これが draconian error handling だ。XHTML ページに整形式エラー、たとえば </head> を忘れたり互い違いにタグを閉じてしまったものがひとつでもあると、ブラウザは処理をそこで中断しエラーメッセージをエンドユーザに表示しなければならないのだ。
この考え方が常に評価されるわけではなかった。99% のエラー率を持つ Web においてエラーをエンドユーザに表示することと、XHTML 1.0 や 1.1 の提供するわずかな新機能を天秤にかけたとき、製作者はただという選択をした。しかし、彼らは XHTML をも無視したわけではない。そんなことはするはずない。XHTML 1.0 仕様が製作者のために掘った「XHTML に似た構文を使って書いて、text/html MIME 型で提供する」Appendix C という抜け穴だ。これがとても多くの Web 開発者が行ったことだ。彼らは XHTML 構文に「アップグレード」したが、文書は text/html MIME で提供し続けたのだ。
今日でも、非常に多くの Web ページが自身を XHTML と主張している。XHTML の DOCTYPE を1行目で宣言し、小文字でタグを書く。属性は引用符で必ず括り、空要素の最後にはスラッシュをつけ <br /> や <hr /> などと書くのだ。しかし、ほんとうにごく僅かのページだけが XML の draconian error handling を発生させうる application/xhtml+xml MIME 型でページを配信するのだ。text/html MIME 型で配信されたページは、DOCTYPE, 構文、コーディングスタイルに関わらず、「寛容な」 HTML パーサで処理される。ページが壊れていたとしても、なおマークアップエラーを無視し、エンドユーザにそれを伝えることもない。
XHTML 1.0 はこの抜け穴を提供していたが、XHTML 1.1 では塞がれた。そして完成することのなかった XHTML 2.0 もまた draconian error handling を課す伝統を引き継いだ。これが Web に何十億という XHTML 1.0 と宣言したページがある一方で、XHTML 1.1 (あるいは XHTML 2.0) と宣言されたページが数えるほどしかない理由だ。ではあなたはどうだろう。本当に XHTML を利用しているだろうか。MIME 型を確かめてみよう。(もしどの MIME 型を使っているか知らないなら、使っているのは text/html で間違いないと言えよう。) ページを application/xhtml+xml MIME 型で提供しない限り、あなたの “XHTML” は名前だけの XML でしかないのだ。
❧
2004 年 6 月、W3C は Workshop on Web Applications and Compound Documents という Web アプリケーションと複合文書に関するワークショップを開催した。ワークショップには 3 つのブラウザベンダ、Web 開発会社、そして他の W3C 会員が参加していた。Mozilla Foundation, Opera Software の人物が Web の将来について異なるビジョンを提案した。HTML 4 を拡張し、Web アプリケーション開発のための新しい機能を提供する というものだ。
私たちは以下の 7 つの原則を、この Web アプリケーション用 HTML の拡張作業において何よりも重要な要件だと考えている。
- 後方互換性と明確な移行パス
- Web アプリケーション技術は、HTML, CSS, DOM, JavaScript と、製作者に馴染みのあるものを基礎とするべきである。
- 基礎的な Web アプリケーションの機能は、IE6 のビヘイビア、スクリプティング、スタイルシートで実装可能なものとすべきである。こうすることで、製作者に統合における明確な方針を提供できる。現在高いマーケットシェアを持つ UA において、バイナリプラグインなしに実現可能でない解決方法は、実現する可能性が低いと考えられる。
- 詳細なエラー処理の定義
- Web アプリケーションのエラー処理は、UA それぞれが固有の処理機構を提供することや、他の UA の処理をリバースエンジニアリングにより解析する必要がないよう、詳細に定義されなければならない。
- オーサリングエラーがユーザーに示されるべきではない
- 仕様は起こりうるエラーについて、そこから復旧する正確な挙動を記さなければならない。エラー処理はほとんどの場合において、XML のようにひどい扱いをするのではなく、CSS のように寛容であるべきだ。
- 実践的なユースケース
- Web Applications 仕様に取り込まれる機能は、実践的なユースケースの有無で判断されなければならない。また、その反対は常に正ではない。すべてのユースケースが、新しい機能にによって実現される必要はない。
- ユースケースは製作者がこれまで実際の Web サイト開発において、ワークアラウンドで苦しく解決していた方法を基とするべきである。
- スクリプトはそのまま
- しかしながら、マークアップで解決できる便利な機能が用意される場合には避けるべきである。
- デバイス固有のやり方にない (XBL に含まれていない) 場合を除き、スクリプトはデバイス非依存・視覚表現に非依存であるべきだ。
- デバイス固有のプロファイルは避けるべきだ
- 製作者の使う機能が、同じ UA のデスクトップ版とモバイル版で実装されていることを保証すべきだ。
- オープンな策定プロセス
- Web は開かれた環境で開発されたからこそ成功した。Web Applications 仕様は Web の中核となる仕様であり、オープンに開発されるべきだ。メーリングリスト、そのアーカイブ、仕様の草案は常に公開されるべきだ。
ワークショップ参加者は「W3C は成熟し洗練された OS レベル API の提供ではなく、宣言的な HTML と CSS の拡張と、命令的な DOM の拡張を行い、ミディアムレベルな Web アプリケーションの要件を解決すべきか」という、Opera Software (当時) の Ian Hickson による提案について投票を行った。賛成 8 に対し反対は 11 であった。ワークショップの サマリー において W3C は「現時点で、W3C は 現在の W3C Working Group が策定する技術の範囲外で HTML と CSS を拡張するためのリソースをつぎ込む予定はない」と答えている。
この決定を受け、HTML および HTML フォームの発展を提案したものに残された道は 2 つしかなかった。あきらめるか、W3C の外で HTML を行うかだ。彼らは後者を選び、whatwg.org というドメインを登録した。そして 2004 年 6 月、WHAT Working Group が誕生した のだ。
❧
WHAT Working Group とは一体ぜんたい何なのだろうか。彼らの説明 を聞こうじゃないか。
Web Hypertext Applications Technology Working Group は Web ブラウザメーカーと HTML の拡張に興味をもつ人間が集う、ゆるく非公式でオープンなフォーラムだ。グループの目的は相互運用可能な Web アプリケーションの普及を促進するよう、HTML と関連技術を基礎とした仕様の開発することだ。開発した仕様は標準化団体に提出することも考えている。提出した仕様は、標準化トラックにおいて HTML の拡張を公式に行う際の基礎として使われるだろう。
このフォーラムは、HTML や関連技術の仕様に関してかわされた、過去数ヶ月の間に個人的に交わされていたメールを発展させたものだ。これまでのトピックとして、既存の Web サイトとの後方互換性を損なわないかたちで HTML4 のフォームを拡張し、製作者が望んでいた機能をサポートすることがある。このグループが組織された理由は、それらの仕様の開発が今後オープンなメーリングリスト上で行われ、アーカイブも公開されるという、完全にオープンな状態で行われることを保証することにある。
ここで鍵となるのが「後方互換性を損なわない」というフレーズだ。(Appendix C という抜け穴を省いた) XHTML は HTML と後方互換ではなかった。XHTML は全く新しい MIME 型で提供される必要があり、またその MIME 型で提供されるコンテンツはすべて draconian error handling を必須としていた。XForms も HTML フォームと後方互換ではなかった。XForms は XHTML MIME 型で提供される文書内でしか使えなかったからだ。XHTML MIME 型を必要とすることはすなわち、draconian error handling が必須となる。すべては MIME に繋がるのだ。
WHAT Working Group は、10 年にもわたる HTML への注力を放棄し既存の Web サイトの 99% を使えなくするのではなく、異なるアプローチをとった。ブラウザが実際に使用している「寛容な」エラー処理アルゴリズムを記すことにしたのだ。Web ブラウザは HTML のエラーに対し寛容だったが、それをどうやっているかを実際に記すなんてことをするお人好しはいなかった。NCSA Mosaic は壊れたページを扱う独自のアルゴリズムを持っていて、Netscape はそれに沿うようにがんばった。それに続いて、Intenet Explorer が Netscape に沿うようにした。今度は、Opera と Firefox が Internet Explorer に沿うようにがんばった。そして Safari が Firefox に沿うようになって、その他が続いてという流れが今日まで続いている。開発者は何千時間という時間を、彼らの競合製品と互換性を持つようにがんばっていたのだ。
なんてばかげた仕事だと聞こえるかもしれない。実際、その通りだ。いや、その通りだった。5 年かかったが WHAT Working Group はついに既存の Web サイトと互換性のあるかたちで (すこしのエッジケースはあれど) HTML をパースするアルゴリズム を定義したのだ。もちろん、そのアルゴリズムにはどこにも、HTML の処理器が処理を止め、エラーメッセージをユーザーに見せるような処理は定義されていない。
このリバースエンジニアリング作業のかたわら、WHAT Working Group は他の作業も進めていた。ひとつは HTML フォームに新しいコントロールを追加する、もともと Web Forms 2.0 と呼ばれていた仕様だった。(フォームについては A Form of Madness でとりあげている。) もうひとつは ダイレクトモードの描画 API である Canvas や プラグインなしで音声や動画を再生する要素 を定義した “Web Applications 1.0” と呼ばれる仕様だった。
❧
2 年半もの間、W3C と WHAT Working Group は互いを無視しあっていた。WHAT Working Group がフォームと新しい HTML の機能に勤しんでいる間、W3C HTML Working Group は XHTML 2.0 の策定に忙しかった。しかし 2006 年 10 月の段階で、WHAT Working Group の方に勢いがあるのは明らかだった。XHTML 2 はまだ草案段階であり、主要なブラウザで実装されてもいなかった。そして 2006 年 10 月、W3C の創設者である Tim Berners-Lee が新しい HTML について W3C が WHAT Working Group と共同して策定する可能性を示唆した のだ。
過去数年を振り返って明らかになったことがある。HTML の段階的な拡張が必要ということだ。属性値を引用符で囲み、空タグにスラッシュを書き、名前空間を使うといった XML への移行は一気には進まなかった。HTML を利用する多くのものはそのまま HTML を使い続けた。ブラウザがエラーメッセージを出さなかった体。いくつかの大きなコミュニティは移行をし、整形式のシステムの恩恵を受けているが、すべてではない。整形式の世界への誘いも続け、さらなる注力も行うが、その一方で HTML の段階的なメンテナンスも重要だ。
計画としては、まったく新しい HTML グループを組織する。これまでとは異なり、このグループは HTML とともに xHTML に対しても段階的な拡張を行う目的が与えられるだろう。このグループの提案については、ブラウザメーカーを始め多くの人間から賛同を得ている。
フォームの拡張もあるだろう。フォームは複雑だ。HTML のフォームと XForms はどちらもフォーム言語だからだ。HTML フォームは広く普及しており、XForms にも多くの実装がある。Webforms の提案は HTML フォームに機能拡張を施すものだ。計画としては、Webforms を参考とし、HTML フォームを拡張する。
新しく設立された W3C HTML Working Group が行った最初の決議は、“Web Applications 1.0” を “HTML5” へと改称することだった。ここにようやく HTML5 が登場した。
❧
2009 年 10 月、W3C は XHTML 2 Working Group の活動を終了 させ、その 決定に関する声明 を発表した。
2007 年 3 月に、W3C は HTML Working Group と、XHTML 2 Working Group という、ふたつのグループを設立しました。この際、私達は XHTML 2 の市場価値などを見ながら、今後について検討すると表明していました。
私達は、何年にもわたる XHTML 2 Working Group の活動と貢献をとても評価しています。しかし、参加者と話した結果、W3C は、2009 年末で失効する XHTML2 WG の憲章を改正しないことを決定しました。
実装されたものが勝つのだ。
❧
❧
訳註：このページは Dive Into HTML5 の “How Did We Get Here?” の日本語訳です。
原文が公開されている Dive Into HTML5 というサイトは “HTML5: Up & Running” という名前で Google Press より出版、O’Reilly Media より発売されています。(ePub, Mobi, DRM-free PDF など紙以外の媒体でも販売されています。)
原著を購入したい方はぜひ 著者のアフィリエイトリンク から、もしくは O’Reilly より電子版を購入 してください。
訳註：“HTML5: Up & Running” の日本語訳はオライリー・ジャパンより「入門 HTML5」として発売されています。(本ページの訳者が監訳として関わっていますが、この翻訳文書は書籍と無関係です。)
Copyright MMIX–MMXI Mark Pilgrim
翻訳: Masataka Yakura