インライン要素に対してpaddingを<percentage>で指定した場合にのみ、 text-decorationがおかしくなるという問題。
このバグで報告者の方とやりとりしてテストケースを追加してもらっているが、 私たちBugzilla-jpスタッフにとって都合の良いテストケースの作り方をここでリストアップしてみよう。
まずこれが一番大切。
いろんな小物を一枚の絵に描くと、何が中心になっているのか分からない、なんていうことがある。 それと一緒で、テストケースはできる限りシンプルである必要がある。 自分の書いた複雑なソースは他人にとっては倍以上見にくいものであるということを意識しなくてはいけない。
また、様々な余計なものとの因果関係を考えなくて済むものを作成するということが重要だ。
例えばCSSのバグだと、div要素やspan要素で再現させるのが最も良い。 なぜならこれらの要素が最もシンプルだからだ。
特殊な例を除き、1024×768ピクセルの環境下で一画面に収まるぐらいのテストケースになることが望ましい。 (あまりこだわりすぎることも無いが)
たとえば今回のケースでは<percentage>を使う場合と使わない場合でひとつが必要だったわけだ。
これは報告者の方が添付してくれたおかげで今回は助けられた。
この件ではunderlineとoverlineとline-throughのそれぞれの症状をtest case 2として一覧にしている。 当初の報告はunderlineのみであったが、当然、似た問題を他の値も抱えていると予想された。 そこで、このテストケースが必要になったわけだ。
テストケースでの挙動から開発者がバグの発生している箇所を検討できることがベストだ。 原因の特定ができれば修正は一気に早まるからである。 (だから発生日が特定できるregressionバグはすぐに修正してもらえる)
だが、これを意識しすぎて一番目の項目を忘れると、見るのもうんざりするテストケースになってしまうので注意が必要だ。 今回のケースでは2つに分割されていることでかなり見やすくなっている。
これもかなり重要。
最終的に提出してもらったテストケースを本家への報告に使えるかどうかはここで決まってしまう。 もし、日本語の説明文があると、本家への報告の際に新たにテストケースを作り直す必要が出てしまうからである。
とはいえ、テストケースを用意してもらえるだけでありがたい。 もし、あなたがHTMLかCSSのバグを発見した場合、 私たちにとって完璧ではないテストケースでも添付してもらえるだけで十分に助かるのだ。
pswfさんにWindows95でのテストをお願いしたところ、 テストしてもらえた。
だが、結果は症状が他のWindowsと変わらないようだ。 これはこのバグの原因の予測が外れたということであり、再びふりだしに戻ったということである。
誰かこのバグをソースコードから検証してくれる人の助けが欲しい。 技術と暇のある方は、是非この問題の解決に力を貸して欲しい。 このバグの修正を待ち望んでいる人はどうも多いようだ。
ちなみにこちらのバグもATOKユーザには重要な問題であるが、放置されている。 こちらもhackできる方がいれば是非協力してもらいたい。
また、本家へvoteして、ATOKユーザにとって重要な問題であることを訴える必要もあると思う。 詳しくはComment 11に書いたのでそちらを参考にして欲しい。
報告者のReimyさん以外で再現される方はいませんか?
あまりに長期間、放置されているのでBugzilla-jpにも登録。
実際に印刷してみたわけではないが、修正されたようだ。
しかし、どうしてアメリカは未だにinchとかmileとか独自の単位を使っているのだろう。 日本で言えば、尺とか寸とか里を使っているようなものだと思うのだが。
そういえば未だにブラウン管、液晶のサイズ表記には日本でもinchを使っているなぁ。 なんでなんだろう。
1.7bのフリーズ直前なのでチェックインを1.8aに見送られかけたが、 議論の結果、1.7bフリーズ前にチェックインされた。
明日以降のSuiteビルドをできる限り多くのテスターにテストしてもらいたい。 tableの重要性は説明するまでも無いだろう。
Firefox 1.0はMozilla 1.7のGeckoエンジンを用いる予定であることから、 この修正が非常に重要な意味を持っていることを理解してもらえるかと思う。 もし、この修正によるバグが山積したままMozilla 1.7がリリースされてしまうことになると、 Firefox 1.0は0.8と同様、ユーザから不満の多いものになるだろう。 つまり、この問題はFirefoxを常用している人の方が深刻であることに注意してもらいたい。 FirefoxはSuiteとは異なり、Geckoエンジンのバージョンアップペースが異なるからである。
Firefoxを常用しているテスタは是非、明日以降のSuiteビルドのテストに参加してもらいたい。
Comment 10に書いたように、 QuirksモードではMacIEにあわせて背景色が常に tr要素経由でtbody要素(もしくはthead、tfoot要素)から継承するようになっている。
この問題はやはり「何でそんなことをしているんだ」という意見が出ていて、 1.8aでは修正される可能性がある。
とりあえず今のところ、副作用は特に見られない。 大規模なパッチだったので、できる限り多くの目で確認してもらいたい。
要約の通りの問題。
何故か一緒に修正されていなかったので新たにバグを登録した。
修正された。
登録した。
だいぶ前からだが、サブメニューが表示されている場合にはこのバグは発生しない。 この状況からバグを修正できないものだろうか。
そもそもXUL、Javascript、C++、いったいどのレイヤーのバグなのかも分からない。
このバグもよく分からない。
Firefoxでは問題無いのにMozillaではバグったままである。 ブックマークのクリック時の処理はC++によるNativeコードであるが、 この様に差が出るということはXULに問題があるのだろうか。
Firefoxでは再現しないことから、簡単に修正できそうにおもえるのだが……
MacやLinuxでは再現していない不思議なバグ。 例によって、読み込み速度に関係がある模様。
例の問題かとヒヤリとしたが、 発症したビルドが11日以降のものなので別のregressionのようである。
テーブルのセンタリングに失敗するので、他にも同様の問題が発生するサイトがありそうにも思えるが、 再現する人はいないだろうか? もしいたら、連絡をいただきたい。
最近、ずっとこれにかかりっきりだった。
こんな低レベルでIMEを制御するのは初めてだったのでかなり苦労したが、 これで問題無いだろう。
だが、中国等のIMEがATOKと似たようなバグを持っていないのか、それは気になるところだ。
comment 4にも書いた通り、 この仕様はCSS2で既に暗示されていたことで、CSS3仕様ではWDの段階でようやく明言されたにすぎない。