この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2007年11月)

2007年11月22日

世の中のかなりの数のウェブサイトはFirefoxのレンダリングのテストには向かなくなってきた
初回投稿日時: 2007年11月22日05時19分05秒
最終更新日時: 2007年11月22日05時27分04秒
カテゴリ: CSS Firefox 雑談
SNS: (list)

先日、KOF 2007の会場で雑談の中で挙げたことなのですが、Firefoxが抱えている悩ましい問題を紹介しておきます。

おかげさまでFirefoxは世界ではなかなかの、日本でもそれなりのシェアを獲得できています。このことはつまり、多くのWebデザイナにFirefoxでのレンダリングを意識してもらえるということです。これは私も含め、ユーザにとっては短期的にはとても良いことです。なぜならユーザが(シェアNo.1の)WinIEと同様(もしくはそれ以上)のレンダリング結果が得られる可能性が高いからです。もちろん、Firefoxではテストを行わずに公開するサイトもまだまだ多いとは思いますが、それでも、職業としてデザインされている方には有名なGeckoのバグに関するノウハウは蓄積されていく訳で、テストを行わなくてもデザインする段階でFirefoxのバグを回避してくれていることが期待できます。

ですが、ここに非常に大きな落とし穴があります。仮に、世の中の5割のウェブページがFirefoxでも表示の確認を行って制作されたとします。この場合、Firefoxのユーザ、テスタはこの5割のサイトでGeckoのバグを発見することはほとんど無くなってしまいます。つまり、今までと同じように日々、ブラウザを利用しているだけでレンダリングのテストができる、という日々は既に終わってしまっているのかもしれません。

もちろん、trunkの開発にあたっては、単にブラウジングしているだけでもregressionのテストにはなります。しかし、ここ最近、Mozillaはregressionの発生を未然に防ぐために多くの自動テストをチェックイン時に行うようになっています。ですので、人の手によって発見されるregressionはゼロに近づいて行くことになります。

つまり、私たちが今後、能動的にレンダリングのテストを行う場合、より難しい作業が必要になってきます。例えば私がこのもずはっく日記(WebStudio)で行っている、サイトのデザインを仕様に基づいて行い、脳内レンダリングとの差分を見つけていくという、割と困難な作業になってしまいます。というか実際問題、ほとんど不可能に近いでしょう。

こうなってくると、私たちが最後に頼みの綱となるのはWebデザイナの方々です。仕事中に発見されたGeckoのバグ(もしくはバグかもしれない現象)をBugzilla-jpに登録してくれるのが理想です。しかし、昔から何度も私がこの日記で書いているとおり、Bugzilla-jpの利用は決して簡単なものではありません。これはBugzillaの仕様や性質の問題と、マンパワー不足からくる理由の双方があり、解決可能なものであるとは私は考えていません。現実的な解は、これも何度もここで書いているように、Bugzilla-jpよりも簡単、気軽に報告可能なワンクッションが必要でしょう。

一般的なバグに関してはすでにもじら組のとおやまさんの多大な貢献により、問題報告センターが運営されています。ですが、残念ながら現在の報告センターのUIではGeckoエンジンの(特に複雑な)バグ報告には耐えられないと考えています。例えばファイルのアップロードができないため、まだ存在しないページでのバグ(つまり、制作中のページでのバグ)を報告しにくいのではないかと思います。また、仕事で制作中のソースを公開された場にそのままアップロードするという訳にもいかないと思います。

Webデザイナの方々で、気軽に報告したいんだけど……、という人がいらっしゃれば、是非その報告ツールに求められる簡単さ、オープンであるべきではない点、というのを指摘してくだされば、検討材料としたいので提案(メールをくださるか、あなたのblogで)してもらえると助かります。

以下、メモ。

  • 報告者に意図の確認を行うことは絶対にありえるので完全匿名はありえない。
  • 報告のInvalidの率が高いとスタッフのマンパワーが破綻するのである程度のフィルタリングは必要。
  • CSSに無駄な項目が多くても、DOM Inspectorで要素ごとに適用されたスタイルを確認できるので、その辺の報告者の手間はスタッフ側で吸収可能なはず。
  • 私はJavascriptについては仕様も挙動もバグ管理のノウハウもほとんど無いので詳しいスタッフが最低一人は必要。
  • 非公開のファイルアップロードができたとしてもソースコードをそのままアップロードする訳にはいかない?

関連するかもしれないエントリ

関連するかもしれないエントリを発見できませんでしたが、無いとは限りません。