Webプラットフォームの現状

私のコラムでは、これまでにも何回かHTML5やCSS 2.1/3についてその目的や現状を紹介しています。今回も簡単にですが、HTML5とCSSに関して簡単に昨年からの動きを振り返ってみようと思います。

問題解決のプロセスが機能し始めたHTML5

まず、W3Cが新しいHTML WGの設立を発表してから3年が経過しました。当初はHTML5について知っている人はそれほど多くない印象でしたが、昨年から急激に注目を集めはじめています。

そんなHTML5ですが、これまでHTML WGには問題解決の仕組みがなく、メーリングリストでただゴールなく延々と議論がつづく、あまりヘルシーでない状態がつづいていました。この状態を打破したのが、昨年秋ころから整備され始めている意思決定のためのプロセス Decision Policy です。Decision Policyでプロセスや責任が明確になったことにより、議論から仕様変更の提案・決定が迅速に行えるようになりました。

もちろん、コミュニケーションの齟齬や意見が合わないこともあります。しかし、すべての人の意見を取り入れることはもちろんできませんから、着地点をうまく見つけ妥協する必要があります。「妥協」と書くと消極的な印象も受けますが、積極的であれ消極的であれ、標準化には必要なタスクになります。

アクセシビリティへの取り組みも活発に

さて、Decision Policyのほかにも進歩があります。アクセシビリティについて議論するタスクフォースが設立されたことです。HTML5ではアクセシビリティがかかわる機能について議論が白熱することが多いのですが、アクセシビリティに関心の高い参加者やエキスパートがタスクフォースに入り、そこでまず案を出すプロセスが生まれたことから、コミュニケーションを含め仕様の見直しが効率的に行なえるようになります。

現在は<canvas>要素のアクセシビリティ対応や<video>の字幕対応など、新しい機能とアクセシビリティの関連について協議している最中です。

APIの分離で仕様を

HTML5はWebアプリケーションのためのAPIも多く備えていますが、それらをHTML5仕様から分離して個別に策定することも盛んに行なわれています。

W3Cの仕様が勧告されるにはその仕様が実装されなければならないため、機能を減らすことが早期の勧告につながります。また、分離された仕様はHTML5と独立して進行が可能なことから、実装者にとっても利点があります。

とはいえなんでもかんでも分離すると、かえって仕様の進行に影響が出ることもあります。ほかの機能にあまり依存しないものを慎重に選んで、分離を進めている最中です。

CSS 2.1は最後の一歩、実装はCSS3へ注力

CSSについては一昨年のコラムで当時の状況に触れていますが、まずベースとなるCSS 2.1は実装のテストを行なう段階に達しました。

仕様の問題も報告されてはいるのですが、基本的にはテストを経たあとに勧告への最終調整が行なわれるようになっています。テストのスケジュールにもよりますが、今年中の勧告も不思議ではないところまできています。

CSS3はどうでしょうか。まだまだ「次の技術」として捉えられがちですが、一部の機能もCSS 2.1と同じくらい安定している段階にあります。また、ここ1〜2年で実装が一気に進んだCSS3の機能もあります。つい先日発表されたInternet Explorer 9でも要望の大きいプロパティへの対応が行なわれることが発表されましたし、いよいよ「次」が来たのではないでしょうか。

制作の変化も起こる？

とはいえ、こういった新しい技術については「IE6が…」といった、古いブラウザーへの対応から利用に消極的なコメントがつきものです。しかし、そういった制作に対する考えも今年は変化していくのではないかと考えています。

そう考えるようになった理由は、昨年よりIE6, IE7のマーケットシェアが急激に低下していることにあります。今年1月のNet Applicationsの調査では、すでにIE8のシェアがIE6を逆転し、IE7に至ってはFirefoxに抜かれています。

もちろんこれは平均的なデータですから、これを鵜呑みにするのではなく、サイトごとの実態を調査してから適切な対応をとることが必要です。しかし、その「対応」が「すべてのブラウザーで同じ見た目を」といったものである必要性についても、考え直すタイミングが来ているようにも感じます。

新しい技術を「待つ」ことから「使う」フェーズに入りつつある今、コンテンツ提供者、利用者にとって「どう使うか」がこれからの制作者に求められているのかなと感じます。