もずはっく日記

<meta http-equiv="Content-Style-Type" content="text/ccs"/>という指定があると、インラインのスタイル指定が無効になる、というバグ報告です。念のために説明しておくと、このHTMLドキュメントで使用されるスタイルシートの形式は、(別途指定がない限り)text/ccsという形式であると宣言しています。つまり、別途、指定することができないstyle属性に記述したスタイルシートはtext/ccsという、未知のスタイルシートであると宣言されています。もちろん、これはinvalidであるべきです。

報告文を見ると妙に報告者が興奮している様子です。その理由はセキュリティに関わるような内容が強調されないのが問題だ、ということのようですが、そういうのはHTMLで適切にマークアップしていればスタイルシート無しでもきちんと強調表示される訳で、全く以て的外れな指摘でしょう。CSSに頼った、見た目に依存したサイトを作るとこういうことになるという良い例です。

それにしてもこういうバグを見ると、さすがはGeckoだなぁと感じます。相変わらずこういう未来に禍根を残しかねない拡大解釈は行わない、こういう所はGeckoの美徳だと思います。ですが、厳格なだけじゃなく、ある程度は現実のWebサイトにも歩み寄っている部分もあり、そのバランスが絶妙なのが評価されているひとつの理由かと思います。

それに対してWebKitがCSSじゃないと明言しているものをCSSであるものとしてレンダリングしてしまっていることを非常に残念に思います。WebKitは仕様に厳格な方針だと思っていたので。もし、将来、text/ccsと名乗るスタイルシートが出現した時、現在のWebKitは知ったかぶりでレンダリングを試みてしまうことになります。

波線を引くときに、波線の中央を基準に上下方向の位置を決めていたのですが、それだと欧文のフォントでは重なりすぎて見にくい場合がある、というバグです。

波線の上端を通常の下線の上端に揃えることでこの重なってしまう問題はほぼ修正されるはずですが、それでは日本語フォントの場合にinput要素からはみ出してしまうことが多くなります(波線はTSFで多用されるので日本語にとっても重要)。

そこで、nsTextFrameThebesから選択範囲用の下線を描画する時には利用できるベースラインから、行の下端までの高さをヒントとして渡すことにしました。もし、フォントの下線指定位置に波線を描画しようとしてはみ出す場合は、最高で、ベースライン位置まで持ち上げるようにするためです。

しかし、ここにはひとつ問題があり、nsTextFrameThebesからは行の情報が正確には分かりません。行の詳しい情報はレイアウト中にのみ構築され、描画時には不要になっているのでデータは破棄されているためです。

ですが、それで正確な行の高さが分からないのは、vertical-alignが絡む、複雑なレイアウトをしている場合の話であって、多くの場合に問題となるinput要素やtextarea内では発生しない問題です。また、複雑なレイアウトを行っている場合、input要素に比べて余裕があるはずなので、HTMLエディタで問題が発生する状況は無いのではないか、という前提において、シンプルな行高推測を行って、ヒントとすることにしました。

line-height値を含めて行高を計算して、それが文字サイズに対して1倍以上ならそこから求められた高さをヒントとして利用します。それ以外の場合はどのみちはみ出してしまうので、1倍時の高さをヒントとして渡すように修正しています。

もしこの修正によってTSFモードで波線がはみ出してしまう場合を見つけたら、bugzilla-jpに報告をお願いします。

オートスクロールのマーカーが表示されるときに、メニューポップアップ時のシステム音が再生されてしまう、という問題です。Fx3.5でリリース後に発見された一発目の私のregressionでしようか。

現在はmenupopup要素をメニュー用のポップアップ、ツールチップならtooltip要素、それ以外ならpanel要素と、使い分けているのですが、少なくともmenupopupとpanelは昔は、popup要素という要素で兼用されていたようです。不確かなのは、それを明言しているところが見付からなかったためですが、XULのCSSファイルに残っているコメントや、MDCの状況からすると、こう推測されます。

そして互換性のためにpopup要素はmenupopup要素と同等に扱われますが、オートスクロールのマーカーはレガシーなpopup要素を使ってしまっているのがこのバグの原因のようです。ひとまず、panel要素を使うようにするパッチを提出しています。