この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
本家の方にパッチを出してますので、テストできる方は様々な言語でテストしてもらえると助かります。
ひとまず修正完了しました。1.9.0 branchに入れるかはtrunkで数日様子を見てから申請、となります。
思いつく限りのテストケースを乗り越えたパッチを提出中です。本家に持って行く前にテストできる方はテストお願いします。
HTMLのフレーム関連(iframe含む)やXULのタブのように独立したビュー(厳密にはwidget)が構築される場合に候補ウインドウの座標の原点が変わるので、この時にバグがある可能性大です(一応、ネストされていないiframeでのテストと、gamilのリッチエディタでのネストされたiframeはテストしました)。普段、よくテキストを入力するサイトでテストしてもらえると助かります。
img要素とbefore/after擬似要素の関係
初回投稿日時: 2008年07月20日01時43分15秒
ZDNetのcontentプロパティでコンテンツを追加する（2）：FirefoxとSafariのCSSにalt属性の値を画像のキャプションとして表示する
という記事がありますがCSS仕様の解釈が間違っていると思います。私も昔、同様に考えていたのですがIan Hicksonにこの考え方は間違いであると説明されたことがあります。
まず、before、after擬似要素とはどんなものかを正確に知らなくてはいけません。これらの擬似要素は、その要素の前後ではなく、内容の前後に新たな内容を追加するものです。つまり、
foo:before {
content: "before ";
}
foo:after {
content: " after";
}
<foo>content of foo element</foo>
このような例の場合、CSSによって擬似的に作られるHTMLのコードは
<foo> <foo:before>before </foo:before> content of foo element <foo:after> after</foo:after> </foo>
となります。つまり、これらの擬似要素は、指定した要素の擬似的な子要素となります。
そして、img要素やinput要素のような置換要素は、その要素の内容を画像等で置き換えるものです。つまり、これらの要素の内容である擬似要素も置換されてしまわなくてはいけません。
ただ、手元で少しだけテストしてみると、Geckoでも画像が無い場合(alt属性値がレンダリングされる時)にその前後にこれらの擬似要素が表示されてしまいました。これは修正されるべきではないかと思います。なぜなら、img要素の代替内容は置換されたものであって、img要素の本来の内容ではないからです(img要素は常に空要素)。画像が表示できない時のimg要素の内容をalt属性値のものにするのであれば、CSS3では(画像が読み込めなかった場合を示すセレクタはありませんが)、img { content: attr(alt); }と記述することが出来ます(この解説は正確ではありません。#2の内容を見てください)。ですが、現在のGeckoのレンダリング結果はこの記述と重大な矛盾が発生してしまうと思います。
img要素とbefore/after擬似要素の関係 #2
初回投稿日時: 2008年07月21日04時13分56秒
ああ、ボケボケでした。CSS3だとimg要素は次のように定義できてしまうではないですか(実際にはもうすこし複雑ですが)。
img[alt] {
content: attr(src, url), attr(alt);
}
ということは、これをスタイルシートで定義した場合と、現在のGeckoのalt属性値レンダリング時の挙動とには明確に矛盾が出てしまいます。
1.9.0 branchでも修正終わりました。Fx 3.0.2で修正されます。
あさんのパッチが1.9.0 branchにも入りました。Fx 3.0.2で修正されます。
私のregressionだったのですが、私が身動きとれない時期に代わりに検証とパッチ作成やってくださったので無茶苦茶助かりました。ありがとうございます。
Mac版のパッチが危なげなく動いているので、ひとまず分離してWin版よりも先行させることにしました。Bug-org 447635でパッチをレビューしてもらう予定です。
分離前のパッチでのビルドですが、テストビルド(Trunk)を用意しているので、テストできる方はよろしくお願いします。私の手元で確認済みなのは、
です。
時代の流れとしては正しい判断だと思うんですが、長音記号無しに慣れてしまってると、やっぱり気持ち悪いですね。
Firefox 3.1以降やThunderbird 3以降でどうなるのか、私は担当じゃないので分かりませんが、Windows版のためにこれに合わせるとLinux版では不自然、というジレンマが出てしまいますがどうなるんでしょう?
本家の方にjp側に出していたものよりも、よりシンプルなパッチを提出しました。gmailやFxの設定ダイアログでもちゃんと動いているのでたぶん大丈夫だとは思いますが、テスト出来る方はお願いします。
ひとまず位置ずれは修正できたので、LinuxのIMで候補ウインドウがブックマークダイアログで隠れてしまうものがあればbug 6149の方に連絡ください。