IE6に助けられたりするとは

久々にCSSカテで記事を書こう。
@importで外部スタイルシートを読み込もうとしたら、読み込まなかった。書式はこんな感じ。

@import {url(hoge.css;)}

ぶっしゃけ書式覚えてなかったんで（というかスタイル宣言関係はあんまり覚えてない）、調べてその通りにしたんですが、うまくなかった。
こうすると読んでくれました。

@import "hoge.css";

で、Firefoxでレンダリング確認しながコーディングしてたんですが、終わってからIEで確認すると、なぜかIE6だけ読み込まれてないスタイルシートがある。

「またIEか！（゜д゜）」と思ったんですが、読み込んでるスタイルシートもあるわけで、謎。
色々調べたら、一部のスタイルシートを別の文字コードで保存していたことが判明。てへっ☆

コーディングにはサクラエディタを使っているんですが、こいつの保存時の初期文字コードがShift_JISなんですよ。
で、通常UTF-8でコーディングしてるわけです。
当然冒頭に「@charset "UTF-8";」と宣言しちゃってるわけで、IE6はこれに忠実に従ったわけですね。
IE6ワルクナイ（；´д｀）

いやいや、他のブラウザはちゃんと表示した！
冗長性が……いやなんかもうホントすみませんでした。

遅ればせながらっ

google Chrome入れてみたよ。
知らん間にverが2になってたよ。

「すげー速い」
「これぞブラウザのあるべき姿だ」
などなど、ググると喜びの声が多数。
多少のバグ報告はあるものの、「大問題になるようなバグはない」と「chrome」でググると出てきます。
――まあ、googleだしな。
さてではどれだけのものか拝見しよう、とインストール。
インストーラーがめちゃくちゃ軽くて、本体インストールもさっくさく。
起動も素早くこれはいい……のか？　と思いつつ、コーディング中のページを立ち上げてレンダリング結果を見てみたわけだ。

……うん、表示崩れ無し。
firefox、opera、safariでデバッグしてるので（IE？　あれは仕様に沿ったら崩れるブラウザなんだぜ？）、これで崩れない＝致命的なレンダリングバグはほぼ無い　でいいと思います。

……見るだけ、なら。

リンクに下線を引いていて、マウスオーバーで下線が消えるように指定してたんですが（a:hover{text-decoration:none;}という指定）、何故かヘッダーのリンクだけ下線が消えない。
text-decoration:none;の部分を、適当にcolor:red;に変えると、テキストの色自体は変わるが下線の色がそのまま。

つまり、下線部分がリレンダリングされていない。

逆に、通常時に下線無し、マウスオーバー時に下線有りにすると、今度は下線が出てこない。
前述の通り、colorの記述がunderlineに反映されていないということは、これは明らかに仕様じゃなくてバグです。

でも、なんでヘッダーだけ？

調査の結果、どうやらフォントサイズに原因があるようです。
見かけ上ですが、Chromeもデフォルトのフォントサイズは16pxらしいので、それで計算すると、フォントサイズの指定が0.75em（12ｐｘ）だとこのバグは出ず、0.625em（10ｐｘ）を切るとバグが出るようでした。

……これ、もうどうしようもなくね？
もしかしたらちゃんと動くようにする方法があるのかもしれませんが、今のところ対策は「フォントサイズを10ｐｘ以下にしない」しかないような。
でもさあ……8ｐｘとかならともかく、10ｐｘが必要な時ってあるだろ……。

あと、フォントサイズをユーザー側で上げた時の挙動を見ようと思って拡大すると、画面全体が拡大されました。
まあこれはfirefoxでもそうなので、「おお、フォントサイズのみ拡大にしないといけないな」と思って設定を探すも……

ね……ねぇ……（；´д｀）

有無を言わさず拡大されるんよ……。

外側に全体包括のブロック要素でも入れてwidthを指定して無い限り、floatしてるボックスがこの拡大で崩れる……もう……どうにでもして……OTL

せめて、文字サイズのみ拡大は入れるべきだと思うんだ、うん。

IETesterとpng表示バグ

昨日の日記でも書いたんですが、IE8をインストールしました。
というか、windows updateで自動的にアップグレードされちゃうので、どうしようも（；´д｀）
いや、任意で止めること自体は可能ですが、自動的にアップグレードされちゃうということは、少なくとも私と同等の環境を持つユーザーは、ほぼもれなくアップグレードされちゃうだろう、ということなんですね。
もしかしたらIE7よりシェア確保のスピードが速いかもしれない。
なので、こっちとしたら、どちらにせよIE8のデバッグ環境は取り急ぎ整えないといけないわけで……しょうがないのでインストール。
まあいいんだけどね、デフォルトのブラウザはfirefoxにしてあるし。

さて、そこで問題になるのが旧バージョンIEのデバッグ環境をどう確保するか。
これまではMultiple IEで確認していたんですが、現行バージョンだとIE6までしか対応して無いんですよね。
最低でもIE6と7の環境は欲しいので、これではダメ。
んで、他にもいくつか試してみたんですが、起動はするもののマトモに動作してくれなかったり……。
最終的にIETesterが一番マシであろう、ということで落ち着きましたが。
ただ、これしばらく起動させておくと100％クラッシュして落ちるんですよ（；´д｀）
どうもメモリエラーみたいなんですが……原因は不明。
IE8がインストールされてる環境と相性が悪いのかもしれませんが、ちょっと調べてみないとなぁ。
まあ、都度起動させれば、レンダリング結果の確認くらいは出来るので、騙し騙し使うしかないか。

さてさて、以前から気になっていたバグ（？）があるんですよ。
もちろんIE（嗚呼素晴ラシキばぐぶらうざ）。
どうもIEで確認すると、他のブラウザに比べてpng画像の色が濃いんですよね。
単体のボタンとかならそれでもいいんですが、他のボックスと地続きで色を揃える必要がある時とかにエラい目立つわけで。
「何でだろうなぁ（´・ω・｀）」と思ってたんですが、IE8でもバッチリそのバグは残ってましたヽ（・∀・）ノ
さすが予想を裏切らないぜ。
で、いくら何でもこれは困るだろう、ということで調べると、どうやら原因は……ガンマ値らしい！

Photoshopでpng画像を作成すると、ファイル情報にガンマ値が埋め込まれます。
ブラウザはこのガンマ値を参照して、どの環境でも同じような色になるように調整してレンダリングしてくれるわけなんですが、なぜかIEだけはブラウザのガンマ値を優先するらしいです。
この辺がよくわからんのですが（あまり詳しくないんですYO）、想像で書いてみると。

web用ファイルは色んな環境があるので、ガンマ値が低いMacに合わせて低いガンマ値を埋め込む　→　普通のブラウザは埋め込まれたガンマ値に合わせて色を作るが、IEは「windows基準がグローバルスタンダードなんだぜ」的にガンマ値2.2でレンダリングする　→　明るい側に合わせるので当然レンダリング結果が暗くなる　→　色が違う！（；´д｀）

なんじゃないかなぁ。
対策としては、ファイルに埋め込まれたガンマ値を削除するのが一番手っ取り早いらしいです。
……で、どうやって削除すんねん、となったので、頑張ってソフト探しました。
一番手軽なのはTweakPNGですかね。
英語のソフトなんで多少とっつきづらいかと思ったんですが、ぶっちゃけガンマ値削除するだけならあんまり関係無いし。

しかし……ホントに……IEって……OTL

条件付コメント文の誤算

悪夢で目が覚めた、んぼです。
ブロック要素が何故かインライン要素みたいな挙動になってウネウネ動くっていう悪夢でした。

DD_belatedPNG.jsの導入に伴って、またひとつIE7のバグを覚えました。
もうやだこんなブラウザ……OTL

IEの独自拡張の中で唯一GJと思ってた条件付コメント文（なにしろIE専用の対応が必須なので、IEだけでも簡単に切り分け出来るのはありがたい。ちょっと情けないアレですがね！）ですが、スタンドアローン版のIE7だとイマイチちゃんと動作してくれないっぽいですｗ
たとえば、

<!--[if IE 6]>～<![endif]-->

とした条件付コメント文があったとしたら、本来ならIE6以外ではコメントとして処理される部分がスタンドアローン版IE7だと実行されてしまいます（；´д｀）

ちなみに、スタンドアローン版IE7とOS組み込み型IE7でも（自分が確認した限りでは）一部挙動が異なり、スタンドアローン版で意図通り表示されていてもOS組み込み型ではレイアウトが崩れたりしていました。
厄介なのはこれに対処するCSSハックが難しい　ってことですね。

通常、IE6への対応にはスターハックを使っている自分ですが、IE7への対応には*:first-child+htmlっていうハック（名前はあるんだろうけど知らないｗ）を使っています。
これは当然スタンドアローン版だろうがOS組み込み型だろうが効いてしまうので、これに対応しようと思うと、上の「スタンドアローン版IE7では条件付コメントがIE6限定であっても通ってしまう」っていうバグを利用するしかないわけですよ。

まずOS組み込み型IE7への対応を指定して……

*:first-child+html #selecta{ ～:～;]

次に条件付コメントでスタンドアローン型向けのスタイルを別ファイルで指定して……

<!--[if IE 6]><link rel="stylesheet" type="text/css" href="xxx.css" /><![endif]-->

間違ってIE6に適用されないようにIE7用ハックを使う、とｗ

*:first-child+html #selecta[ ～:～;]

やってられるかー！（゜д゜）

そんなきたねぇソース書きたくないよ俺！
まあ今のトコ、XHTMLの構文だけで対処出来てますが……この先IE8が本格的に浸透してきたらどうしたらいいんでしょうか。
気分は（´゜д゜｀）

DD_belatedPNG.jsの不具合

昨日コーディング中に判明した不具合やら何やら、忘れないように覚書しておくよ！

不具合が出る条件（゜д゜）

1.table要素あるいはul要素（多分ol要素も）自体、あるいはそれを包含する要素でPNGファイルの表示を行い、
2.その要素を絶対配置（多分相対配置もアウト）する。

絶対配置した時点で、左上にPNGを表示させた要素「だけ」が固定され、そこからテコでも動いてくれなくなります。
（包含する要素は正しい場所に表示される）

さて、では解決策だよ！

たとえば次のような構造だとします。

<ul id="xxx" class="pngfix">
    <li>aaa</li>
    <li>bbb</li>
    <li>ccc</li>
</ul>

.pngfixがPNGファイルの表示をさせるクラスです。
ここでul要素を絶対配置するとレイアウトが崩れます。
そこで、ul要素の内側にdiv要素を入れて、そこにPNGファイルを表示してやります。

<ul id="xxx">
    <div id="xxxBugFix" class="pngfix">
        <li>aaa</li>
        <li>bbb</li>
        <li>ccc</li>
    </div>
</ul>

そして、この例で言えば#xxxで表示させていたbackground-imageを、ここでは表示せずに#xxxBugFixに表示してやるようにします。
もちろんこのままではwidthやheightが正しくないので、#xxxと同じだけのwidthやheightを与えてやります。
これで解決！（｀・ω・´）
絶対配置されているのはul要素で、その内側のdiv要素自体は通常配置なので、DD_belatedPNG.jsのバグに引っかかりません。
ul要素自体にはPNGファイルを貼っていないので、ul要素が変な場所に行くこともないです。
絶対配置するtable要素にPNGを貼る場合、この方法は上手く行かないと思われるので、

<div id="xxx">    <!--この要素を絶対配置-->
    <table class="pngfix">
        .
        .
        .
    </table>
</div>

これで多分クリア出来ます。
（ただし、これだと絶対配置した要素が左上に残るので、レイアウト上問題を与えないようにサイズを変えておくとかした方がいいかもなんだぜ）

ul要素or table要素を含む要素を絶対配置する場合も対処は同じ。

<div id="xxx">    <!--この要素を絶対配置-->
    <div id="xxxBugFix" class="pngfix">
        <ul>
            <li>aaa</li>
            <li>bbb</li>
            <li>ccc</li>
        </ul>
    </div>
</div>

とりあえず、対処のポイントとしては、表示崩れの原因となる要素自体だったり含んだりする場合、PNGを貼る要素が絶対配置にならないようにする、でいいと思います。

どこ調べても対応策どころかこのバグ自体が書いて無いので、一応書き残しておいたよ（´・ω・｀）
疲れた……。