AppleInsider: なぜ Apple は HTML 5 に賭けているのか： ウェブの歴史 [Page 2]
原文： Why Apple is betting on HTML 5: a web history [Page 2]
HTML 3： よりどりみどりの標準
1995 年 W3C は HTML 3 の草案を提案した。これは、数学や科学ドキュメントのニーズをサポートすることなど、登場しつつあったさまざまな機能を正式なものとすることを目指していた。 HTML 3 に含まれた新機能のなかには、使用する複雑な文書のなかで表データを取り扱いたいという合衆国海軍からのリクエストに沿って、表のサポートが含まれていた。
HTML 3 が、ほとんど全員のニーズを満たすために枝分かれしたため、リソースが限られたブラウザーベンダーらは、仕様のなかから自分たちが実装できそうな要素を選り好みしはじめた。 これが結果的に、異なるブラウザー間で異なる「標準」サブセットがサポートされることになり、さらに加えて、彼らは独自の非標準機能を勝手に付け加えてもいった。
一方、ブラウザー市場における Netscape の覇権は Microsoft によって脅かされていた。同社は 1995 年に、Mosiac のオリジナルコードのライセンスを受け、PC オペレーティングシステム市場から Microsoft の掌握権をもぎ取って既得権益を保護したい企業グループによってウェブが定義されてしまわないよう、新たな方向へと Mosaic をフォークしはじめた。
Microsoft にリードを奪われまいとする Netscape は、HTML に独自のプロプライエタリーな拡張を施し続けた。 そのひとつの例として、HTML フレームというコンセプトがある。これは、ブラウザーが独立した複数のウェブページを同じ画面内に表示できるようにするものだ。 Netscape は自社の Navigator ブラウザーにフレーム機能を追加し、実質的にこのアイデアやその実装メリットやについてコミュニティーが議論できないようにして、HTML の仕様に盛り込むべくこのアイデアを提出した。
1996 年末までに Microsoft は、一年のうちに 3 度目という、ウェブの将来を Windows につなぎ止めようとするなりふり構わない姿勢でもって、Internet Explorer のメジャーリリースを慌ただしく発表した。 IE 3.0 には ActiveX のサポートが加えられていた。これは、ウェブページ内に複雑なインターフェースコントロールを組み込む手法で、Windows でのみでしか動作しなかった。 Netscape は ActiveX を独自に実装し、JavaScript という名称のスクリプト言語を追加した。これに対し IE は独自の互換策として JScript で応えた。
Netscape と Microsoft が独自機能でもってお互いに競い合っているなか、相互運用可能な標準としての HTML をどう実装するかという氷河のごとく遅々としたプロセスは、暗礁に乗り上げはじめた。 その最たるものが、Netscape の BLINK タグで、これに対抗して Microsoft が持ち出してきたのは、独自の MARQUEE タグという馬鹿げた代物だった。どちらも HTML を真剣なドキュメント提示を実現するという目標から、ウェブで歓楽街のけばけばしいネオンサインを再現しようという暴挙へと引きずり込んでいった。
一方の IETF は、自らの HTML 2 仕様の作業を続け、国際文字、表、画像マップといった機能を加えていった。 最低限の公式標準を定義するという挑戦は、急速な独自発展と、誰もが合意できる将来に向けたロードマップの可能性という両方を可能にしたものの、ほとんど不可能な努力のように見え始めていた。
HTML 4： 同じページを手に入れる
ところが WC3 は、新しい HTML Editorial Review Board に招かれた Netscape、Microsoft、Sun およびその他関係団体の代表者たちの間で開催された一連の定期会合のなかで、重要な項目についてのハイレベルなコンセンサスをなんとか仲介した。
そこで確立された共通の基盤は、公式の HTML 仕様から BLINK および MARQUEE タグを除外し、CSS（Cascading Style Sheets）を利用することを優先して Netscape による表示マークアップ機能へのサポートを解除する計画だった。CSS とは、純粋に記述的な HTML 要素からウェブ表示を切り離すものだ。
CSS を利用すれば、ウェブ作者は、画面で表示したり、印刷をターゲットにしたり、画面読み上げ機能で読み上げたり、それ以外にもさまざまな方法で解釈できる HTML ドキュメントを作成できる。 そこには二つの問題があった。 ひとつは、Netscape によるタグで、ほとんどの既存のウェブページで、すでに表示と記述マークアップをごちゃ混ぜにしていたこと。二つ目は、HTML に加えて CSS へのサポートをブラウザーに加える必要があったことだった。
CSS 1 は、HTML ドキュメントが、特定の表示（「helvetica bold 16 pt」）ではなく、与えられたスタイル（例えば「heading」）に従って要素を記述できるようにする方法を提供した。 CSS ファイルで、表示の詳細を提供し、ユーザーあるいはブラウザーは、ことなるタイプフェースを利用したり、異なる音声でテキストを読み上げるといったように、自らの必要に応じて置き換えることが可能になった。 CSS 1 ではまた、テキスト、画像、そしてテーブルのアラインメントのためのスタイリングも可能にした。
HTML 4 が 1997 年にリリースされた既存の HTML 3.2 仕様から後腐れなく飛び立てるようにするために、新しい HTML 4 では、サポートが解除されたタグのような以前の慣習も許された「transitional」ページと、記述を表示詳細から切り離すという CSS のアプローチを厳守した新しい「strict」ページが許されることになった。 HTML 4 は 1997 年末に立ち上げられ、1999 年末の HTML 4.01 によって明確化された。
W3C の HTML 4 は、記述と表示を切り離したことに加え、ウェブドキュメントの手続き面を体系化しクライアントサイドのインタラクティブ性を可能にする JavaScript 言語と、HTML 内で記述されたオブジェクトを表示・やり取りできるようにするための DOM（Document Object Model）の両方を標準化した。 この「HTML 4.01 strict」仕様はその後、2000 年に ISO 標準として発表された。
Microsoft は実際のところ、こうした新しい HTML、CSS、そして JavaScript ウェブ標準のサポートでは先陣を切っていた。その理由の大半は、Windows に IE をバンドルすることで、すでに Netscape の息の根を止めてしまっていたからだった。 一から新しいブラウザーを開発するにあたって必要とされる膨大な作業量は、新しいライバルが参入する際に大きな壁となって立ちはだかり、あまねく存在した IE のために、誰かが挑戦に値するような市場ベースの発奮材料はまったくないかのように見えた。
90 年代全般にわたって矢継ぎ早の開発をした後、ほぼ 10 年間にわたって HTML における実際的な進歩は全くなさそうだったのだ。
XHTML 1： 完璧な失敗におわった仕様
W3C は 1998 年から、HTML 4 を XHTML 1.0 で 新しい方向 へと発展させようと決定した。 この新しい仕様は SGML の一形態としてではなく、HTML を XML（extensible Markup Language）というより厳格なサブセットへと押し込めることで、必要とされるセマンティックの変更は比較的小規模だった。
既存の HTML ドキュメントの描画は、HTML の柔軟性に富んだ曖昧性によって極度なまでに複雑化していた。 HTML ドキュメントに XML フォーマットという厳格なルールを当てはめることで、W3C は二つの目標を達成したいと考えていた。 ひとつ目は、XML ツールを利用して HTML ドキュメントを生成、変更、描画する能力だった。既存の HTML は、HTML につきものの数多の例外を考慮できるような、非常に複雑な描画エンジンのないマシーンでは充分な信頼性を持って解析できないほどの代物だったのだ。
XML へと移行する二つ目の利点は、特殊化したマークアップをモジュール化できる可能性で、それによって HTML 仕様から特殊な数学・科学コンテンツのマークアップ方法の定義を切り離すことができる点だった。そうすれば、MathML のような専用の XML 文法を利用して、独立したかたちで定義することができるようになるからだ。 XHTML ドキュメントは単に、そうしたコンテンツの部分をマークアップするために、外部定義を参照するだけで良くなる。
ところが、HTML 4.01 から XHTML 1 への移行は、誰も克服する理由が見つからない新たな問題を招くことになった。 加えて Microsoft は今や、ブラウザー市場で効果的な競争にいっさい直面しなくなっていたため、CSS 2 といった、より実際的な新機能を加えたり、ActiveX を急いで市場に送り出したことによる深刻なセキュリティー危機を解決したりするのとは違い、IE を XHTML に準拠させるために投資する理由がほとんどなかったのだ。
ほとんどの人が使っているブラウザーで XHTML がサポートされていないとなると、ほとんどのウェブ開発者にとって、新しい標準をサポートするように自分のサイトのアップデートする理由はほとんどなくなってしまう。 XHTML への移行を目指した試みは、ほとんど現実的な利点がないままに、新しい複雑な問題を引き起こすことが多く、そのため、ほとんどのウェブ開発者らは HTML 4.01 へと戻っていくことになった。
XHTML 2.0： 誰のためでもない標準
IE とその 90% というブラウザー市場におけるシェアが XHTML をサポートしないという現実に直面した W3C は、2002 年になると、HTML 4 や XHTML 1 との後方互換性という要求をすべて廃した、新しい XHTML 2.0 仕様の草案を発表しはじめた。 これはプロジェクトの範囲を大幅に簡素化したものだったが、この新しい作業をほとんど誰にとっても意味のないものにもしてしまっていた。
W3C がこの方向性で進み続ける中、競争面で劇的な変化が起こりつつあった。 Netscape が Mozilla として生まれ変わり、その新しい Firefox ブラウザーが、2001 年に IE 6 をリリースして以降ほとんど自社のウェブブラウザーを見捨てたかのような Microsoft に不満を抱いていたユーザーを獲得しはじめたのだ。
2006 年末に IE 7 が投入される頃までには、Firefox は PC において現実的で人気の代替ブラウザーとなっており、Apple の新しい Safari ブラウザーもウェブを重用視する Mac プラットフォームから IE を完全に追いやっていた。 Opera も同様に、モバイルブラウザーという特殊なニッチで勢いを伸ばしていた。この分野は、Microsoft のひどい Pocket IE のおかげで、代替ブラウザーの草狩り場になっていたのだ。
Apple、Mozilla そして Opera に率いられた、ウェブ上でますます存在感を示しつつあったプレーヤーたちによる不確定要素が大きくなることで、当時の既存のウェブの状勢を追認するのではなく、オープンでベンダーに依存しない、標準ベースの代替をサポートする方向に、どうウェブ標準が進んでいけるのか、という点が着目されるようになってきた。その当時の状況とはつまり、プロプライエタリーな Flash コンテンツ によってますます占領されつつあった状況であり、ウェブを描画するために別個のプラグインに依存し、実質的にオープンなウェブを AOL が 80 年代後半にしてしまったようなプロプライエタリーなシステムへと後戻りさせてしまうようなものだったのだ。 それは、閉鎖的で、バグに溢れ、そして遅かった。
ウェブは決して効果的には XML へと移行できないと確信した Mozilla と Opera は、W3C がその XHTML に向けた努力を放棄してリッチなウェブアプリにフォーカスし、XML の利用を RSS のような新しいテクノロジーに限定するという、より実際的な新しい方向へと HTML 4 を拡張することを支持した。 「我々は、Web Application が重要な分野となると考えているが、この分野は既存のテクノロジーでは十分に対処できない分野でもある」と両社は ポジションペーパー に記している。 「仕様を共同開発する以前に、この問題に対処する単一ベンダーによるソリューションという脅威が表れつつある。」 W3C のメンバーはこの XHTML 2.0 というアイデアを投票で却下した。
ページ 3 / 3： HTML 5 とその将来.
前のページへ