Webブラウザ標準適合性のわなとAcidテストの正体

株式会社ピーデー 川俣晶 
2008/7/31

1つのWebページを開くだけで100項目のWebブラウザの標準適合性が検証できるAcidテスト。Acidテストの正体に踏み込む(編集部)

AcidテストとWebブラウザの互換性

 前回(Webブラウザ非互換性の温床となったのは何か)は、Webブラウザの歴史と大まかな仕組みを説明しました。そして、Webブラウザ間の非互換性が、ダイナミックHTMLという技術の普及を阻害したが、Webブラウザの種類の減少と非互換性の格差縮小によってダイナミックHTMLは息を吹き返し、Google MapsをはじめとするAjaxブームが起きたことを説明しました。

 しかし、Ajaxブームの影響か、Webブラウザの種類は再び増える傾向にあり、しかも非互換性は再度拡大傾向の気配も見られます。仮に、この傾向が続くとすれば、サービス提供者はWebブラウザの非互換性対策だけで大きな時間とコストを要求される可能性があり、本来なら提供されるはずの新機能が開発できなくなったり、零細サービス事業者は撤退を余儀なくされる可能性もあり得ます。それは、利用者側から見てもメリットのある結果とはいえません。

 Webブラウザの種類を増やすことは、利用者が自分で自分の首を絞めるのと同じです。つまり、どれほど優秀であろうと、みんなと違うWebブラウザを使う行為は、決して賢い行為ではないのです。

 しかしこの結論は、新しいWebブラウザを開発することは無意味だといっているに等しく、挑戦や変化といった価値を否定することにもつながります。それはそれで、好ましいことではありません。この問題に一石を投じるのが、Acidテストです。

 今回は、Acidテストの概要を説明することを通じて、Webブラウザの互換性という問題について、もっと踏み込んでいきます。

劣勢のソフトがアピールする戦略

 Acidテストのインパクトを説明するために、一時Webブラウザというテーマを離れ、パソコンソフト一般の話をしてみましょう。

 さて、パソコンソフトを開発して販売しようとする場合、大抵は先行するライバルソフトと対決することを意味します。その際、ライバルソフトよりも高い実用性を持ったソフトを提供できる場合は何ら問題ありません。それをアピールすれば、ユーザーは納得して買ってくれるでしょう。

 しかし、既存のライバルソフトよりも実用性が劣っている場合、どのように売り込んだらいいのでしょうか?

 典型的に見られるパターンは以下の点をアピールする方法です。

  • 高速性をアピールする
  • 標準への適合度をアピールする

 前者は、利用者にとって分かりやすい指標となります。使ってみたら反応が速いであるとか、ベンチマークでより速い数字をたたき出す、といったアピールは、利用者にも分かりやすく、大抵の場合好感を持たれます。

 しかしそう簡単に、手抜きせずに頑張っている先発ライバルソフトに対する高速性は得られるものでしょうか? それは可能です。その理由は以下のとおりです。

  • ユーザーから現に支持されている先行ライバル製品は、速度だけでなく、安全性、安定性、互換性などさまざまな問題のすべてに対処する必要があるため、高速化だけに集中できない
  • 新規ユーザーにアピールするだけなら、高速性は試用で使われる機能に絞って行えばいい。めったに使われない機能は驚くほど遅くても問題はない
  • ベンチマークテストなど、実行される定番が分かっていれば、それに対する専用の最適化を行うことができる

 最後の1つは特に重要です。この後の話の伏線にもなっています。例えば、プログラム言語の世界には、素数を計算するSieveという有名なベンチマークがありますが、このプログラムに限って高速に実行できるように作成された言語製品があるという話もあります。

 ここで注意すべきことは、この3つの理由がすべて、実用性を高めることではなく、利用者に高速だと納得させるための方策である点です。例えば、特定のベンチマークでのみ高速になるよう作られたソフトが実用的ではないことは容易に予測できるでしょう。

 さて、次は標準への適合度をアピールするという方法について説明します。これは、以下のような主張を行うことを意味します。

  • ISO/JIS/W3C等の標準では「AはB」と規定されているにもかかわらず、先行ライバル製品は「AはC」としてしまう。わが社の製品は「AはB」となるから標準適合度が高い

 さて、このようなアピールは成立するでしょうか? 先行ライバル製品には先行者ゆえの時間的ゆとりが与えられているので、標準との食い違いがあればすぐに修正できるように見えます。しかし、実際にはそうならないことも珍しくありません。なぜなら、ソフトの利用者は、大抵の場合「資産の継承性」という条件を突き付けるからです。ユーザーが「標準に違反した挙動」に依存するファイルを多数作って蓄積してしまったとすれば、ユーザーはその資産が意図どおりに利用できなくなることを望みません。

 このケースでは標準に適合することは望まないことになります。ですから、多数のユーザーを抱える先行ライバル製品は、標準に違反していると分かっていても、それを訂正できないことが珍しくありません。

 しかし、既存の製品の市場への食い込みを狙う挑戦者には、そのような継承すべき資産は存在しないか、あってもごくわずかです。たとえ過去の資産が継承できなくなったとしても、すぐに訂正して標準に合わせることができます。

 以上の理由により、新参のチャレンジャーは「高速性」と「標準への適合性」の2点について、既存ライバル製品よりも優れているとアピールできます。

標準への適合性のわな

 ここから話の核心に近づいていきます。

 チャレンジャーの語る「標準への適合」は本物なのでしょうか?

 例えば、以下のような主張があったとしましょう。このような主張は無条件で認めていいのでしょうか?

  • 市場シェア1位のAブラウザは「標準」に適合しないバグが多いが、わが社のBブラウザは標準に完全準拠している。例えば、CSSのXXはXXとレンダリングされねばならないのにAブラウザはそうなっていない。しかしBブラウザでは正しくレンダリングする。ほかにHTMLのYYや、JavaScriptのZZもBブラウザは「標準」どおりに機能する

 このような主張を信じた人は決して少数ではないでしょう。

 しかし、このような主張が正しくないと強烈にアピールしたのがAcidテスト、特にAcid2テストだったのではないかと思います。実際、このような主張を行っていたWebブラウザの多くはAcid2テストをパスせず、「標準に完全準拠している」という主張が正しくはないことを暴露してしまったのです。その後、多くのWebブラウザは、このテストをパスするために改修を行うことを余儀なくされています。

図1 標準適合性の罠

 しかし、なぜ多くの人が信じた「標準への完全準拠」が誤っていたのでしょう?

 Acidテストはどのようなトリックで、それを示したのでしょう?

 そして、Acidテストは信用していいものなのでしょうか? もしや、Acidテストも何か良からぬトリックを使っていたりしないでしょうか?

 これがこの記事の本題です。

前編へ 1/3

 関連記事

いまさら聞けない「Webブラウザ」超入門
いまさら聞けないリッチクライアント技術(11)
 
インターネットに接続するために、当然のように利用するWebブラウザ。Webサーバとのやりとりから、その仕組みを知っておこう
リッチクライアント & 帳票」フ ォーラム 2008/4/14

 INDEX
Webブラウザ標準適合性のわなとAcidテストの正体
Page1
AcidテストとWebブラウザの互換性
劣勢のソフトがアピールする戦略
標準への適合性のわな
  Page2
Acidテストの歴史
Acid1
Acid2
Acid3
  Page3
Acidテストの正体とは
Acidテストの成果
Acidテストの課題
積極的なAcidテスト対応
謝辞
リッチクライアント&帳票 全記事一覧へ


HTML5 + UX フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

HTML5+UX 記事ランキング

本日 月間