じたばたはてななこと
&mozilla.from;
（続き）
Fx3RC1の話。実はFx2はスキップした口なので時代遅れな話が紛れ込んでいる可能性があります。
メニューバー≠ツールバー (Chrome)
とりあえずデフォテーマをベースに微修正。といってもXP臭いのっぺりpopupとかは無いので以前に比べればずいぶん少なくて済む。
menubar, #toolbar-menubar {
background-color: Menu;
}
toolbox {
border:none !important;
}
floatなdivが勝手に縮む
などと言われるであろう仕様差。要ははてなの管理画面がことあるごとに縮む対策。
div#main{
width: -moz-available;
}互換性的には少なくともQuirksには入っていても良さそうなもんではあるけど、仕様的にどっちが正しいのか確証が無い →080620追記: どちらかというと仕様の範囲外の気がしてきた。そしてCSSの範囲内で妥当な互換性を確保できる可搬な方法が無い。下の方に書き足しました。
marginがfloatにぶつからない
IE6のポカバグで有名なfloat自体のmarginのことではなくて、floatでwrapされる方のmarginの話。よくよく調べてみるとCSS仕様には確かにそう書いてあって、これは今までの動作の方が間違いであることに疑念の余地は無い。無いのだが・・・これ困るんだよなあ。端的に言うと float:left のwrap範囲内に <UL> とかのlist類がくると一発で破綻するわけで、こういうのは仕様バグというんじゃないの。ぶー。
-moz-float-edge: content-box | padding-box | border-box | margin-box | inherit
問題はだ、margin-box で衝突させれば確かにfloat相手でもmarginは残るのだけど・・・今度は残りすぎで全くcollapseしない。いやまあ確かに調べてみるとfloatのmarginは絶対にcollapseしないと仕様には書いてあるわけで以下略。ともあれ指定しただけでは以前と同じ動作というわけにはいかないので要注意である。とりあえずmarginにまとめていたのをpaddingとcollapseすべきmarginに分離した上で指定を padding-box に変更してworkaround。まあ論理的には最初からこうしていた方が正しかったのかもしれない。
<INPUT type=file> が全てのstyleを無視する — ただしcolorを除く
styleを無視すること自体はおそらく見た目ごまかしてファイル盗もうとする系のやつへの対応のつもりなんだろうと想像がつくけれど・・・なんでcolorだけ通ってしまうのさ。backgroundも通さないくせにcolorだけ通すとか意味がわからん。
所感
コードの改善なのか単にPGOの産物なのかはよくわからないものの、とりあえずスクリプトの動作速度はなかなか圧巻である。が、それはいいんだが・・・拡大縮小を伴う画像の取り扱いが前より悪化しているのは気のせいなんだろか。この日記では max-width 頼みで手抜きな貼り付け方をしているわけで、そこかしこで恐ろしく引っかかるのが少々気持ち悪い。あと透明合成の真ん中はいいんだけど縁の処理が何か恐ろしく時間食い過ぎているような。これだけの年月を費やしてようやく技術的に正しい方向に進み始めたのだから、こういうつまらないことで躓いてほしくはないものである。あと気になるといえば不細工なカーソルとかIMEで変換中の表示とか、Cairoのせいだーで終わりにしないで直してほしいなあ。
そいえば実際に使ってみるまでは半信半疑だったけれど、awesomebar（＝ただのアドレスバー）は本当にawesomeだった。誰だ今までサイドバーとかゴタゴタ作っていた奴は、これ一つあれば何もいらないじゃないか! 決して邪魔にはならず、それでいて必要なときに必要な仕事を確実にしてくれる。まあ使う人間の方がうっかりawesomeの存在を忘れていて、ついいつもの癖で www. から入力して損をした気分になるのはお約束だけど、ともあれこれこそは間違いなく正しい進化というものだ。
ColorTableはとりあえずそのままで動いているようなので、少なくとも髪型追加が入るまでは放置する予定。まあ見つかったglitchもあるのだけど・・・どうしたもんかなこれは。至極微妙にバグを踏んだ気もするわけで、今の時点で対症療法を入れるべきか悩ましい。
080620追記
floatな width:auto の話。対症療法が shrink-to-fit 絡みなので、そこの仕様解釈の問題かと思いがちだけど。
そもそもfloatなboxのwidthでは、親から降りてくる計算ではmarginの外にfloatでないものを流し込む幅の分の自由度が必ず残るので、指定widthがautoである限り computed width は必ず中の子依存である。よってその中の子がwidth指定に%値を使うというのは火を見るより明らかな循環依存であって、この条件下では仕様にも書いてあるとおり動作は堂々と未定義である。
If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS 2.1.
つまり div#main の幅の最大化を中の子での width:100% に頼っているのがそもそもの間違いの始まりであって、準拠仕様云々が直接の原因では無い、ように私には思えるのだけど・・・初出時に確証が無いと書いたのはそういう理由。
ちなみに子の100%の指定でIE6が素直に動いてしまうのは、単にinheritと100%で違う計算をする（%値指定の場合は一旦 available-width 基準で仮計算してしまう）といういかにもIE臭いバカっぷりの副作用であって、準拠仕様上 shrink-to-fit でないのが理由では無い。いちおう今回の状況下でinheritと100%が等価であるべきことを説明しておくと、
the same computed value as the property for the element's parent
calculated with respect to the width of the generated box's containing block
floatな親divの中に入っている子boxにおいて、containing block のwidthとはつまり親divの content-box のwidthであり、これは親divのpadding等が0である限り親divの computed width に等しくなる、はず。・・・たぶんね。
ついでに言うならば rv:1.8 系でそれほどズレることがなかったのは、あまり賢くないtableの width:100% が available-width を容赦なく食い尽くしていたせいであって、厳密に言えば table.table-config が無く普通のinlineの折り返しだけが支え棒になっていたページ（configwordとかdeleteとか）では rv:1.8 系でも既にズレは生じていたと思うのだけど・・・ええともしかして誰も気付いてなかったんかいな →080621追記参照。
ともあれ個人的な趣味でいえば div#sidebar と div#main の両方がfloatという時点で正気を疑いたいわけで、片方は normal flow で流しておいてmarginで隙間あけてfloatはめるのが筋なんじゃないのかと。floatとmarginの衝突仕様の差なんてこういう用途であれば外形widthを0にする方向で安全に吸収できるし、ていうか現に既に不必要に0にしてあるじゃん。何やってんだコレ。行き当たりばったりにも程がある。
080621追記
configwordとかdeleteとかの件。よくよく見たらいつの間にか超対症療法が追加されてました。というわけで過去形は実のところひどい大過去です。はうわあ。生モノを相手に確認もせずに記憶で書いてはいけませんね。
ええと念のため書き直しておきますが、問題のtableの100%は例によって循環依存で仕様の範囲外なので、仕様上の話であるところの shrink-to-fit に関係あるはずがありません。ここまでの解釈は間違っていないはずです。その意味ではGeckoは大昔から shrink-to-fit っぽい動作であって、ただそれが今まではtableの扱いがあまり賢くなかったのに負けていたという話でしょうな。
しかしそれにしても .table-config 使ってないページだけ対症療法ってどういう神経・・・。論理的に正しく書いてもどうせ全てのUAが論理的に正しく動いてくれるわけではない、というのは確かに悲しい現実ではあるけれど、論理的に正しく書けば動くものまでデタラメに書き殴って良いという免罪符にはなりませんよ。それは単に程度の低い言い逃れです。・・・ってどっかで聞いたような台詞だと思ったらこのへんか。まあ当然ですよねー。
つまり要約すると仕様云々は関係無く一方的にはてなが悪い。まる。
080625追記
対症療法そのまんまかよ!
