この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
月曜日、Mountain ViewからSan Joseにバスで移動する時に、席がひとつしか空いてなくて、たまたま座ったその席の隣に座ってたのがTantekだと分かってびっくりでした。
もっとも、直接、私の専門とかぶってるところがない人なので、横に座ってた間は、名前聞いたことあるけど、誰だったかなーという感じだったんですが、なんかもったいないことしました、はい。
それにしても、この辺の人達若いですね。なんか自分が無駄に歳食ってると実感します。もっとハードワークしないとですね。
先日修正したこのバグ、ひとまず、Fx5からはバックアウトすることにしました。
Bug-org 647421が修正されなくては、将来のWebブラウザとの互換性に問題が生じることが分かっているのと、Fx5にむけたスケジュールがイレギュラーで時間がなさ過ぎることがその理由です。
WebPのサポートは、wontfixとなりました。
詳しい理由はJeff Muizelaar: WebPに書かれています。
ざっくりとまとめると、一点目は、現在、デファクトスタンダードとなっているJPEGを置き換えるには非力なフォーマットであるということのようです。例えば、現在のところ、JPEGの持つ機能のサブセットしか提供できておらず、YCrCb 4:2:0以外の色空間もサポートしていないし(JPEGは4:4:4やCMYK等の他の色空間もサポートしている)、EXIF情報やICC色プロファイルのサポートも欠けていて、さらに、JPEGがサポートしていない、アルファチャンネルのサポートを難しくないにも関わらず行っていない、ということが挙げられています。
また二点目に実装上の問題が挙げられています。実装して普及しだすと、永遠にそれをサポートしなくてはいけないものの、このコスト面でも他の画像フォーマットと比較して別に有利ではない、と主張しています。なぜなら、プログレッシブなデコードをする必要から、WebMのデコーダを再利用できず、別のライブラリが必要になるため、セキュリティリスクが増えてしまうとのこと。(その後にある、
This gives additional security risk but also eliminates much of the benefit of having bitstream compatibility with WebM. It makes me wonder, why not just change the bitstream so that it's more suitable for a still image codec?
は意味がよく分かりませんでした。)
さらに、三点目としてニーズと合っていないという点も挙げられています。例え、WebPが明らかに圧縮効率が良かったとしても、FlickrやFacebookのような巨大なサイトでも、libjpegで高画質(very good quality)に推奨している75を上回る96と85という品質で圧縮していることから、転送容量の削減はWebでは求められていないと主張しています。
最後に、JPEGは素晴らしいフォーマットとは言えないが、これを置き換えるフォーマットも未だに無いのではないか、と結んでいます。
元々このバグは、windowlessモードのFlashのプラグインでドイツ語のキーボードレイアウトを使っても、一部のOEMキーでは本来の文字とは異なるものが入力される、というものでした。
Bug 6302の修正でキーボードのネイティブイベントを無加工でプラグインに伝達できるように修正してからGecko側では修正が終わっていましたが、なかなか、対応したバージョンのFlash Playerが出ませんでした。そのため、バグを閉じ忘れていた間にすぐに似たようなバグが再発し、このバグ上で対応することになりました。
新しいバグは、AltGrを使うと入力できない、というもので、また、IMEも未確定文字列が表示できなくなっていました。
原因を調べると、Bug 6302で追加したGecko内部イベントのプラグインイベントが、常にウインドウ最上位のXULのドキュメントに届いていて、コンテンツのプラグインには届いていませんでした。どうも、widget-removalによって、今までは必要のなかった、フォーカスを持つドキュメントへのリダイレクトが新たに必要になっているようです。
このため、一行のみのパッチでシンプルに修正できたので、これからFirefox 5や、Firefox 4でも修正できないか、ドライバに交渉してみる予定です。
Fennecでは、エディタがフォーカスを得ると自動でソフトウェアキーボードを開きますが、スクリプトによってフォーカスが移動した場合に自動で開くのは鬱陶しいので、ユーザがキーボードかマウスから移動した場合にのみ開くようにしよう、というバグです。
レビュアーとして参加し、既にパッチはmozilla-centralに入りましたが、いくつか問題も分かっています。例えば、スクリプトで既にフォーカスが移動してしまったエディタをクリックしても、bug-org 507987で、キーボードは開かないと思われます。また、エディタからエディタへTabキーでフォーカスが移動した場合(Tabキーがあるのかどうかは知りません)、一瞬ソフトウェアキーボードが非表示になった後、またすぐに表示されると思うのですが、これで果たしてユーザは正しくフォーカスが移動したことを認識できるのか、というのが気になります。
-moz-text-decoration-style: -moz-none;が機能せずに、実線で描画されていた、というバグです。
-moz-noneは内部処理の都合上、存在しているだけの値(実際に内部でも使用していない)で、実装時にレビューの終盤で突如追加されたため、テストを怠ってしまっていました。
fantasaiからの指摘で発覚したバグで、-moz-text-decoration-colorと-moz-text-decoration-styleはtext-decorationを後から指定した場合にリセットすべきだ、というものです。
CSS3では、text-decorationはロングハンドから、ショートハンドに変更され、text-decoration-lineプロパティ、text-decoration-styleプロパティ、text-decoration-colorプロパティ、それからblink値が列挙されることになります。このため、これらのサブプロパティの値は全て、text-decoration: underline;といった指定があった場合にリセットされなくてはいけません。この修正が間に合わなかったのが、Firefox 5からはバックアウトされた理由です。
このバグの修正で、-moz-text-decoration-lineを実装しました。ただし、値は、underline、overline、line-throughのみで、cancel-*は実装していません。これらの値はCSS 2.1に準拠したtext-decorationの描画を実装しなくては不可能だからです(GeckoもWebKitもCSS2準拠で、CSS2.1の描画方法にはまだ未対応)。
また、blink値をショートハンドプロパティに直接指定する、というイレギュラーな仕様はそのままではGeckoは実装できないので、既にCSS3では没になったプロパティをそのままプレフィックス付きで実装しました。-moz-text-blinkで、noneとblinkをその値にとります。
つまり、text-decorationプロパティはGeckoでは、-moz-text-decoration-line、-moz-text-decoration-style、-moz-text-decoration-color、そして-moz-text-blinkのショートハンドプロパティになりました。
ただし、いくつか、仕様に反した挙動をとることで他のブラウザとの互換性を維持しているので、安心してください。
まず、text-decorationは、-moz-text-decoration-styleと-moz-text-decoration-colorの値を指定していても無視します。というか、指定されていると不正な値と見なし、その宣言自体が無かったことになります。バグのサマリにあるように、単にこれらの値はtext-decorationプロパティの宣言があると、その時点で一旦リセットされるだけです。
次に、text-decoration: none noneや、text-decoration: underline none、text-decoration: none blink等といった、none指定時に他の値がある場合には引き続き、無効な値として扱っています。つまり、Webデザイナから見れば、text-decorationは引き続き、-moz-text-decoration-lineと、-moz-text-blinkのショートハンドプロパティには見えません。
最後に、getComputedStyle()を利用してtext-decorationの算出値を取得する場合、本来であればショートハンドプロパティは常に空の文字列を返すべきなのですが、互換性のために今までと同じように、underline、overline、line-through、blinkの組み合わせか、noneを返します。これは明確な仕様違反ですが、おそらく、仕様の方が変更になるのではないかと思います。ただし、
-moz-text-decoration-styleや、-moz-text-decoration-colorを使用し、初期値とは異なる値が指定されていた場合、その作者はCSS3のtext-decorationを理解していることになりますので、この場合には算出値は仕様通り、空の文字列を返すことになります。
最後の一文は、serializeの部分の動作の仕様でした。ただ、懸念があるのでdbaronと相談してみます。
というわけで、CSS3 text-decorationはFirefox 5からのバックアウトが決定し、既に実行されました。