ブラウザー上で動作するアプリケーションの動作環境を「XHTML 1.0 と CSS 2.1 と DOM Level 2 と ECMAScript 言語仕様第 3 版に準拠したブラウザー」のように指定できない理由は、実装が標準仕様に追いついていないからと、標準仕様が実装に追いついていないからの両方です。最近の標準仕様の作業草稿を見ると、両方の問題点を改善することを目指しているようです。
今では掲示板やオンラインショッピングやウェブメールなど、いろいろなアプリケーションがブラウザー上で動きます。サーバーサイドのプログラムだけで動くものは別として、少し凝ったことをしようとするとクライアントサイドスクリプトも必要になることが多いです。その場合、アプリケーションの動作環境は、普通「IE 6/7 または Firefox 2」のようにブラウザーとそのバージョンを指定して記述します。でも、世の中には様々なブラウザーの様々なバージョンが混在しているし、新しいブラウザーや新しいバージョンが次々に生まれているので、特定のブラウザーを要求するのはできれば避けたいです。「XHTML 1.0 と CSS 2.1 と DOM Level 2 と ECMAScript 言語仕様第 3 版に準拠したブラウザー」のようにブラウザーが準拠するべき標準仕様を指定する方が美しいと思います (もちろんそれに加えて「IE 7 で動作を確認しました」のように書くことに問題はないのですが)。
ブラウザーの標準仕様だけに依拠してアプリケーションを作ることができれば、ブラウザーの対応状況と見比べることによってこのアプリケーションがどのブラウザーで動作するかがわかります。また、未知のブラウザーでもアプリケーションが動作する可能性が高くなります。
だから、本来ならアプリケーションは動作環境として仕様を指定するべきです。それも標準仕様をです (仕様を自分で作るのは大変だし、仮にブラウザーが満たすべき仕様を書き上げたところで、そのようなカスタムな仕様に特定のブラウザーが準拠しているかどうかを確認するのも大変なので、標準でない仕様はあまり使えません)。
でも、このような指定をするには今のところ問題が二つあります。
一つ目は、実装が標準仕様に追いついていないことです。例えば、現実には CSS 2 なり 2.1 なりに完全に準拠したブラウザーなんてありません。だから、「CSS 2 (あるいは 2.1) に準拠したブラウザーなら正しく動作します」と書いても絵に描いた餅です。
でも、これはもう少し考えてみると、仕様の切り方が今の目的に合っていないと見ることもできます。 CSS 1 ではなく CSS 2 なり 2.1 なりを要求する必要があるのは、 CSS 1 にない機能を使いたい場合です。例えば CSS の cursor プロパティーは CSS 2 で初めて出てきたのだから、このプロパティーを使おうと思ったら CSS 1 では足りません。ところが、 CSS 2 を要求すれば準拠したブラウザーがなくなってしまうというジレンマがあるのです。
こう考えると、正確な問題点は、今のアプリケーションに必要な機能と不要な機能が一つの仕様の中に入ってしまっていることです。だから、仕様の必要十分なサブセットを定義して、それに準拠したブラウザーと指定すれば、この問題は解決します。ただし、仕様のサブセットを不整合なく定義するのは、仕様を定義するのと同じくらいの慎重さが求められる作業だと思います。僕はやりたくありません。
二つ目は、標準仕様が実装に追いついていないことです。
などと書くと、「標準仕様から外れた独自拡張を使ってプログラムを書くな」と言う人もいるかもしれません。でも、これはなにも変わった機能を使うアプリケーションに限った話ではありません。例えばブラウザーが DOM Level 2 に対応しているといっても、現在ブラウザーで開いている文書の Document オブジェクトに「document」という名前でアクセスできることを保証する標準仕様はありません。でも、この動作に拠らずにクライアントサイドのスクリプトを書くのはまず無理です。
アプリケーションを書くのに必要な仕様が標準化されていない、と言い換えてもいいのだと思います。ただし、ここでいう「標準化」は、単に既存の仕様のどれかを選んできて「これが標準です」と宣言するだけの意味ではありません。そんなのでよいのなら、マイクロソフトなり Mozilla なり Apple なりが出している自社ブラウザーの仕様の中から良さそうなものを選んできて「このアプリケーションの動作には、○○社の××の仕様のうち□□の部分に準拠したブラウザーが必要です」と書けばよいだけのことです。なぜそれでは駄目かというと、ベンダーが出している仕様は割といい加減で、未定義の概念が参照されていたり、何が規定されているのか今一つ不明確だったりすることが多いからです。結局、まずはきちっとした仕様を作る必要があります。「標準化」と書いた中にはそういう大変な作業を含みます。やっぱり自分でやる気は起きません。
標準仕様は相互運用性を確保するために重要な役割を果たしていますが、アプリケーションの動作環境を指定するのに標準仕様が使えないのでは、どうももったいないように感じます。この状況は近い将来改善するかもしれません。
一つ目の問題については、 CSS 3 のように仕様をモジュール化して一つ一つのモジュールの独立性を高めておけば、仕様のサブセットを指定するのが容易になることが期待されます。モジュールの境界では不十分で、モジュールのサブセットを作る必要があったとしても、巨大な仕様全体を見て整合性をチェックするよりはずっと楽になるのではないかと思います。
また、二つ目の問題は、標準に値する仕様がまだ書かれていないのだから頑張って書けばよいわけで、例として挙げた「document」を含む window オブジェクトの内容については W3C による最初の作業草稿が公開されました。とりあえずこれが標準になれば、かなりのことが標準にのみ依拠して書けるようになるのではないかと期待しています。 (ところで、最近はやりの AJAX の基本部品である XMLHttpRequest については意外なことに 2006 年 4 月から作業草稿が出ていました。現在も標準化作業中です。)
標準仕様はアプリケーションの相互運用性を高めるために重要な役割を果たしていますが、少なくともブラウザー上で動くアプリケーションの動作環境を記述するために使うには、現在の標準仕様は二つの意味で不十分です。でも、最近の動きを見ていると、そう遠くない将来にこれら二つの問題点は改善するのではないかという期待が持てます。
当たり前の話ですが標準仕様だって人が作ったものであって、使えるところでうまく使うのが最善だと思います。そして、実際に仕様を作る人たちはなるべくいろいろな場面で使えるような仕様を目指して努力しているように見えます。その方向性は素晴らしいと思いますし、ぜひ成功してほしいです。
2007 年 5 月 1 日公開。著者: fcp / このサイトについて