昨日のキーノートでMicrosoftは誇らしげにIE 10のプラットフォームプレビュー版を初めて披露した。その性能の改善ぶりは喝采を受けたが、もっと大きな議題には触れられなかった。つまり、“ネイティブHTML5”とは一体何を意味するのか、ということだ。単にハードウエアアクセラレーションのことなのか。私たちは違うと思う。
IEブログに掲載されたこの発表に合わせたプレスリリースには標準についてたくさんのことが書かれている。しかし、最初の3つの段落で長期的な方向性についてのヒントもいくつか含まれている。
本日ダウンロードができるようになったIE10プラットフォームプレビュー1はこれから来るネイティブなHTML5サポートの波を推し進める始めの一歩です。ウェブサイトとHTML5はOSや利用しているデバイスに対して最適化するブラウザ上でネイティブに実行されたとき、最も優れたものになります。
私たちはIE9を最初から作り直しました。HTML5とWindowsによって最もネイティブなHTML5の体験を提供し、Windows上での最高のウェブ体験を提供するためです。IE10はIE9の進む道を引き継ぎ、Windowsが提供する機能を直接使い、ウェブサイトを遅くするようなライブラリや抽象化レイヤを使いません。
現時点ではWindows 7とIE9の組み合わせだけがウェブとHTML5のネイティブな経験を提供してくれます。IE9はOSが提供する利点を利用しています。例えば、ネイティブのグラフィックスタックを利用したり、シェルのジャンプリストを利用できます。こうしたことは性能や利便性、信頼性を最高にします。私たちは4週間前、全世界の顧客とビジネスに対して、素早くてきれいで信頼性と相互運用性を持つIE9を提供しました。目的はHTML5の最高の体験を提供することです。最高のHTML5はOSに対してネイティブです。なので、ウェブサイトが通過するレイヤはほとんどありません。最高のHTML5はサイトを作るのに、どのブラウザでも同じマークアップ、同じHTML、CSS、スクリプトを使うことができます。最高のHTML5は開発者の時間を尊重し、不安定な技術でない、HTML5を使うことで同じマークアップを実現できるのです。
ジャンプリストがハードウエアアクセラレーションや性能改善とは無関係なのは明らかだ。実際に進められているのは、WindowsのネイティブアプリケーションをHTML5で構築しようとする試みだ。ジャンプリストは氷山の一角であり、完成までの幾度も繰り返されるだろう試みの最初のひとつに過ぎない。
次の見通しを立てるには、“ネイティブ”アプリケーションとウェブアプリケーションの違いを見ることから始める必要がある。そして、そこからHTML5標準でサポートされているものを取り除くのだ。例えば、ウェブでの文書エディタに必要なのは、
- テキストの編集
- 書式
- フォント
- ローカル/ネットワークドライブへのファイルのロード/保存
- ウェブでのファイルのロード/保存
- スペルと文法のチェック
- 最近利用した項目のサポート
- スタートメニューからの起動
- ネットワーク接続なしでの実行
最初のふたつは既に確立されている。CSS 3のフォントモジュールは3番目を満たすだろう。4番目が最初の候補だ。ローカル/ネットワークドライブへファイルを保存するのは簡単だが、開くのは大変だ。単に文書をダブルクリックすればブラウザがその文書をロードして描画してくれるウェブサイトを表示するというわけにはいかない。ウェブアプリにファイルタイプを関連付ける機能が足りていない機能のひとつ目だ。
リストに戻る。ウェブでファイルをロードしたり保存したりするのは簡単だ。スペルと文法のチェックを即座に行うには、HTML5 Web Workersのマルチスレッド機能が必要だろう。最近使った項目のサポートは次の候補だ。皆がこの機能を使うわけではないが、この動的なリストが最新で最新を保持しなかったらとてもイライラするだろう。
スタートメニューからの起動はすべてのアプリケーションで利用できるようになる見込みだ。IE 9のウェブサイトはショートカットをドラッグすることでスタートメニューに“はりつけ”られる。噂が本当なら、Windows 8にはこの作業をさらに簡単にするAppXと呼ばれる新しい配布パッケージスキームが提供される。Long Zheng氏によれば、AppXを使うことでコンパイルされたアプリケーションではなく、ウェブサイトをターゲットとして記述できるようだ。
最後の項目が最大の難点だ。ネイティブアプリケーションの“性能、安定性。信頼性”を提供するにはウェブアプリケーションはサーバにアクセスしなくても動作しなくてはならない。これを実現するための試みはいくつもなされてたが、サーバサイドの処理への依存し過ぎや不規則なブラウザのキャッシュなど、多くの理由で失敗した。しかし、現在のJavaScriptの性能と高い能力を使うことで、サーバサイドの処理の多くをクライアントへ移行できる。ブラウザのキャッシュについては“インストールされたウェブアプリ”が早期に除去されてしまうのを防ぐように調整されるはずだ。
つまり、下記の機能リストが出来上がる。
- ウェブアプリへのファイルタイプの関連づけ
- 最近使った項目
- スタートメニュー統合
- ウェブアプリのキャッシュの永続化
Microsoftがこのような具体的な機能をいつ実装するのか、そもそも実装するのかどうかすらわからない。様々なタイプのアプリケーションがネイティブアプリケーションのような外観と操作性を持つのに必要な特徴には他にどんなものがあるのか、知っている人がいるかどうかも分からない。しかし、Microsoftが“ネイティブなHTML5”の提供に成功するには、ウェブサイト開発者の賛同を得なければならないのは明らかだ。これは簡単には実現できない。開発者は実際に自分の作っているサイトで試してみる必要があるが、他のブラウザベンダはWindows中心の機能など興味を示さないのは当たり前なので、ウェブ開発者はこれをIEユーザのためだけにすることになるだろう。
しかし、幸運にもいいニュースもある。この戦略にはすべてとは言わないまでもHTML 5とCSS 3のほとんどをサポートする必要があるので、Windowsを全く気にしないウェブ開発者も恩恵を受ける。IEは標準として承認され次第、これらの機能を実装するだろう。そして、他のブラウザはIEに遅れをとるのが許されるとは考えてもいないだろう。