hamashun.com

関連リンク

そろそろCSSハックの良し悪しについて考えてみる（書式編）

そろそろCSSハックの良し悪しについて考えてみる（管理編） おまけ付き

Re:CSS の用途をわざわざ (X)HTML に限ることはない

スターハックに端を発するアレコレ

スターハックに端を発するアレコレ まとめ編

前回のそろそろCSSハックの良し悪しについて考えてみる（書式編）では、正しい書式である事に重点を置いて考えてみました。

しかし、実際の業務、それも複数人が関わる際には、そればかりを重視してもいられないというのが実情だと思います。
そこで今回は、管理のしやすさを中心に考えてみます。
なお、今回もハックと呼ぶと違和感を感じる部分があるかもしれません。
ブラウザ実装の差異に対する技術、といった意味合いで、この記事でもハックで統一しています。

ルールセット単位で使用する

まず思いつくのがセレクタに対して指定する、ルールセット（規則）単位で独立しているハックです。
アンダースコアハックや!importantハックなど、プロパティに対して指定するハックでは可視性に劣るからですね。
書式編でも登場した、子セレクタを利用したハックなどがこの条件をクリアーします。

とは言えバリデータは通したい

管理のしやすさを優先するとは言っても、何でもありという訳にはいかないと思います。
最低限、バリデータは通過させたいところです。
* html .hoge {～}と記述する、いわゆるスターハックはこの条件をクリアーします。

ハックを使用するのは不具合を起こしているブラウザ

更に条件を重ねるなら、ハックは不具合を起こしているブラウザに対して使用したいところです。
例えば遥か未来、IE6をターゲットブラウザから外す日が来たとします。 そうなれば不要になるIE6用のハックは、CSSファイルから一掃する事になるでしょう。
その際に子セレクタハックなど正しい動作をしているブラウザに対して指定するタイプのハックを使用していると、その判別に手間がかかる事があります。
ちょっと解りにくいと思うので、サンプルコードを用意してみました。

.hoge {
 color: blue;
}
html>body .hoge {
 color: red;
}

パッと見で、どちらが正しいと思うでしょうか。
ハックに詳しい人ならば、「先にIE6用の指定をして、後から新しいブラウザ用の指定で上書きしているな」と解るかもしれません。
しかし、余り詳しくない人は「なんか変な記号が付いてるから、後者の方を削除しちゃえ」と思うかもしれません。
（ちょっと乱暴ですが、あくまで例え話です）
こういった事故を減らすために、不具合が起きているブラウザに対して使用するハックが理想だと言えるでしょう。
スターハックは、この条件もクリアーします。

書式上の正しさも欲張りたい

ここまで来たら、正しい書式である事も考えたいですね。
書式編の条件も全てクリアーしていれば、正にそれが良いハックと呼べるのではないでしょうか。

これらの条件を満たす書式上正しいハックは？

上記の条件を全てクリアーするハックを探してみると・・・・・・。
意外と見つかりません。
スターハックは書式上で完璧とは言いにくいですし、子セレクタハックは正しいブラウザに対して指定するタイプです。
!importantはプロパティ単位で指定しますし、IEに対してルールセット単位で指定できるhtml*.hoge {～}というハックはバリデータを通りません。

ちょっと妥協してみる

さすがに、書式の正しさと管理のしやすさの、両方を完璧に求める事は難しいようです。
そこで条件を少し緩め、バリデータを通過してルールセット単位で指定でき、不具合を起こしているブラウザに対して指定するハックを探してみます。

スターハック

* html .hoge {
 color: blue;
}

WinIE6以下とMacIE5のみ読み込みます。

IE7用ハック（通称不明）

*+html .hoge {
 color: blue;
}

IE7のみ読み込みます（と、よく紹介されていますが、うちの環境だとWinIE5.0も読み込みました。 スタンドアローン版だからかも？）。
これはどのように呼ぶのがスマートでしょうか。 ユニバーサル兄弟ハック？ IE7兄弟ハック？
ユニバーサルブラザーハックとか書いたら、何やら凄くピースフルな感じに（センス無さすぎ）。

これだけ？ もっとないの？

ここで一度、最初に戻って考えてみます。 今回の目的は管理のしやすさです。
となると、例えば一つ目の条件である『ルールセット単位で使用する』をクリアーできていなくても、結果的に管理がしやすければ良いとも言えます。
そこで、コメントを活用する方法を提案してみます。

決められたキーワードを含める

まず、ハックを使用した際には必ずコメントを書くようにします。 それも、（少なくとも）同じCSSファイル内では統一したキーワードを含むコメントにします。
更に、CSSファイルの冒頭に目次や更新履歴をメモする方は多いと思いますが、合わせてそのキーワードをサーチキーとして記述しておきます。

サーチキー？

サーチキーという言い方が一般的か（そして適切か）は分からないんですが、簡単に言うとファイル内検索を助ける為のキーワードの事です。
例えば、ハックのコメントに/* =hack IE6用のハック */や/* =hack MacIE5用のハック */と書いたとします。
そして冒頭にも/* css hack search key =hack */などと書いておけば、「=hack」でファイル内検索をする事で、ハックの部分を探すのが容易になります。

なぜ=を付けるかというと、万が一億が一/* これはhackではありません */などというコメントがあった場合の混同を避ける為です（第三者が書き込まないという保障はありません）。
また、重要度が高いコメントを示す目印として=が使われる事もあるようです。
その場合には、コメントの境界を示す為には/*======*/とはせず、/*------*/などとする必要があるでしょう。

サーチキーを含めるコメントを付ける事によって

ファイル内検索でサクサクとハックの箇所を発見できるため、可視性の問題は（妥協案ではありますが）解決しました。
そして、例え新しいブラウザに対してのハックを使用していたとしても、その旨をコメントに書く事で、他者が見た時でも把握しやすくなります。

管理編のまとめ

今回は前回の書式編と比べると、実際に仕事で使う際に、いかに管理しやすいか、見やすいかといった事に重点を置いて考えてみました。
ただ、管理のしやすさや見やすさの基準というのは、慣れや個人差による部分が大きいので、この記事が完璧とは言えないと思います。
もし「もっとこんな手法やハックはどうだろう？」というご意見があったら、是非学びたいと思っています。
コメント、トラバは大歓迎です。

前回と今回を踏まえた、CSSハックの良し悪しのまとめ

.hoge {
 color: blue;/* =hack IE6以下用の値 */
}
html>body .hoge {
 color: red;/* 新しいブラウザ用の正しい値 */
}

書式編で掲載した書式上で正しいハックと、このサーチキーを併用した物が良いハックの一つの形と言えるかもしれません。

おまけ

IEの独自拡張に、Conditional Comments（条件付コメント）という物があります。
これはIEの指定したバージョンにのみ、該当の外部CSSファイルを読み込ませる技術で、独自拡張です。
HTML側にコメントとして記述する為に、独自拡張でありながらバリデータを通過します。

これに関しても意見が分かれるところです。
メリットとデメリットの両方があるので、結論はケースバイケースといったところでしょうか。
Conditional Commentsについても、近い内に記事にしたいと思っています。