「同じCSSを書いたのに、ブラウザによって表示がぜんぜん違う…」WEB制作を25年ほどやってきた私ですが、昔はこれで何度も頭を抱えました。当時のブラウザは本当に気まぐれで、思いどおりに表示させるだけでもひと苦労だったのです。
そんなブラウザごとの表示のズレを、無理やりにでも吸収するために編み出されたのが、今回のテーマである「CSSハック」というテクニックです。かつてはWEB制作に欠かせない必須スキルでしたが、Internet Explorerの引退とともに、その多くは静かに役目を終えつつあります。
この記事では、そもそもCSSハックとは何なのかという基本から、なぜ今ではあまり使われなくなったのか、そして現在のブラウザ差異とはどう付き合えばいいのかまでを、初心者の方にも分かるようにかみくだいて解説していきます。
「昔のCSSでたまに見かける、アンダースコアやアスタリスクの謎の記号。あれって一体何なの？」という長年の疑問も、読み終えるころには解消できるはずです。
CSSハックという言葉だけ聞くと、なんだか高度でこわそうな響きがあるかもしれません。でも中身を知ってしまえば、「ああ、ブラウザのご機嫌取りのための小ワザね」と、案外あっさり受け止められると思います。
そして何より知っておいてほしいのは、今はそうした小ワザに頼らなくても、ずっとスッキリとCSSが書けるようになったということです。昔の苦労話も交えながら、その変化を一緒に見ていきましょう。
そもそもCSSハックとは？
CSSハックとは、ブラウザごとのCSSの解釈の違いやバグを逆手に取り、特定のブラウザだけにスタイルを適用するためのテクニックのことです。
もう少しかみくだくと、「このブラウザだけ表示が崩れるから、そのブラウザにだけこっそり別のCSSを効かせる」ための小ワザ、とイメージするとわかりやすいと思います。
その正体は、特定のブラウザだけが解釈する（あるいは無視する）記述ミスすれすれの書き方を、あえて利用するというものでした。つまり仕様の「すき間」を突いた、ちょっと裏ワザ的な手法だったわけです。
そのため見た目はどこか不格好で、知らない人が見ると「これはタイプミス？」と勘違いしてしまうような、独特の記号が並ぶことも多くありました。
CSSハックが大活躍していた時代
かつてのWeb制作では、ブラウザごとの仕様の差がとても大きく、CSSハックは日常的に使われていました。なかでも私を悩ませ続けたのが、当時の主役だったInternet Explorer（IE）です。
IEはバージョンが変わるたびに表示の挙動が変わり、「IE6では崩れるけどIE7では平気」といったことが当たり前のように起きていました。そのため、IEのバージョンごとに別々のCSSを書き分ける、という今では考えられない作業が必要だったのです。
具体的には、次のような表示トラブルがよく起こっていました。
- ボックスモデル（要素の幅や高さの計算方法）の解釈の違い
- floatを使った段組みレイアウトの崩れ
- marginやpaddingが意図せず二重になるなどの余白バグ
- positionによる要素の配置のズレ
こうしたクセを一つひとつ吸収するために、ブラウザごとにCSSを出し分けるハックが数多く生み出されていきました。
関連記事：【CSS】floatしたリスト(li要素)をIEで表示すると崩れてしまう場合の解決方法
昔よく使われていたCSSハック一覧
今ではほとんど出番がありませんが、当時よく使われていた代表的なCSSハックをいくつか紹介します。古いサイトのソースを読むときの「解読のヒント」として知っておくと便利です。
アンダースコアハック（IE6向け）
プロパティ名の先頭にアンダースコア（_）を付ける書き方です。本来は無効な記述ですが、IE6だけがこれを読み取って適用してしまう、という性質を利用しています。
.box {
_color: #ffffff;
}アスタリスクハック（IE7以前向け）
プロパティ名の前にアスタリスク（*）を付ける書き方です。IE7以前だけがこの記述を解釈し、ほかのブラウザは無視します。
.box {
*color: #ffffff;
}バックスラッシュ9ハック（IE8以前向け）
値の末尾に「\9」を付け足す書き方で、IE8以前にだけスタイルを効かせるために使われました。
.box {
color: #ffffff\9;
}これらはいずれもIEのCSS解析のクセを利用したもので、IEが完全に引退した今となっては、新しく作るサイトで使う場面はまずありません。あくまで「昔はこういう書き方があった」という歴史として押さえておけば十分です。
関連記事：CSSハックを使わずに「min-height」「min-width」をIEで実現する最も簡単な方法
Internet Explorerはもう引退しています
CSSハックの多くが不要になった一番の理由は、長年の悩みの種だったInternet Explorerが、すでに役目を終えたことにあります。
Microsoftの公式情報によると、Internet Explorer 11のデスクトップアプリは2022年6月15日にサポートを終了しました。約27年の歴史に、ついに幕が下りたわけです。長く付き合ってきた身としては、少しだけ寂しい気もします。
現在の標準ブラウザはMicrosoft Edgeで、業務用の古いサイト向けに「IEモード」という互換機能が用意されています。このIEモードも、Microsoftは少なくとも2029年まではサポートすると表明しています。
とはいえ、一般的なWebサイトの制作でIE本体の表示を細かく気にする必要は、もうほとんどなくなったと言ってよいでしょう。
参考: Microsoft Learn（Lifecycle FAQ） / Windows Experience Blog
今どきのブラウザ差異への対処法
では、IEがいなくなった今、ブラウザごとの差はどう扱えばよいのでしょうか。結論から言うと、昔ながらのCSSハックに頼る必要はほとんどなくなり、標準的な仕組みやツールで対応するのが主流になっています。
代表的なアプローチは次のとおりです。
- リセットCSS（normalize.cssなど）でブラウザ初期スタイルの差をならす
- FlexboxやGridといった標準のレイアウト機能を使う
- 後述する @supports で「機能の有無」を基準に分岐する
- Autoprefixerでベンダープレフィックスを自動的に付与する
とくにベンダープレフィックス（-webkit- や -moz- といった接頭辞）は、かつて手書きで延々と書き並べていたものですが、今は事情が変わりました。
AutoprefixerはCan I Useのデータをもとに、対応が必要なプレフィックスだけを自動で付けてくれるツールです。私たちは接頭辞なしのシンプルなCSSを書くだけでよく、面倒なブラウザ対応はツール側にまかせられる時代になっています。
どのブラウザを対象にするかは「Browserslist」という設定で指定でき、プロジェクト全体で対応ブラウザの基準をそろえられるのも便利なところです。
参考: Autoprefixer（GitHub） / autoprefixer（npm）
関連記事：user agent stylesheetとは？ブラウザのデフォルトスタイルを理解しよう
主役は @supports（フィーチャークエリ）
今のモダンなCSS対応で主役と言えるのが、@supports（フィーチャークエリ）です。これは「ブラウザ名」ではなく「その機能に対応しているかどうか」を基準にスタイルを切り替える仕組みです。
たとえば、CSS Gridに対応しているブラウザにだけGridのレイアウトを適用したい、という場合は次のように書きます。
@supports (display: grid) {
.layout { display: grid; }
}逆に「対応していない場合」を not で指定したり、and や or で複数条件を組み合わせたりすることもできます。ブラウザの名前を当てにいくのではなく、機能の有無で素直に分岐できるのが大きな利点です。
MDNによれば、この @supports は2015年9月以降、主要なブラウザで広く使えるようになっています。つまり、もうじゅうぶん安心して使える「枯れた」機能だと考えてよいということです。
ブラウザ名を狙い撃ちする昔のハックと違い、機能ベースで判断するため、新しいブラウザが登場しても破綻しにくく、将来の互換性も保ちやすくなっています。
参考: MDN（@supports） / MDN（フィーチャークエリの使用）
まとめ：ハックに頼る前に、まず標準仕様で
ここまで、CSSハックの正体から、IEの引退、そして今どきの対処法までを見てきました。最後に大切な考え方を整理しておきます。
CSSハックは確かに便利な小ワザですが、使いすぎるとCSSが複雑になり、あとから自分でも読めなくなってメンテナンスに苦しむ原因になります。だからこそ、問題が起きたら次の順番で考えるのがおすすめです。
- まずHTMLの構造そのものを見直してみる
- 標準的なCSSの仕様で解決できないか確認する
- @supports など機能ベースの分岐で対応できないか試す
- それでも無理なときの最終手段としてだけハックを検討する
現在のブラウザ環境では、CSSハックの出番はほとんどなくなりました。まずは標準仕様での解決を第一に考え、ハックはあくまで「最後の切り札」として引き出しの奥にしまっておくのが、いちばん安全で長持ちする付き合い方です。
振り返ってみると、ブラウザのクセに振り回され、記号だらけのハックと格闘していた時代は、それはそれで大変ながらも妙な達成感がありました。とはいえ、当時を知る身としては、ハックなしで素直にCSSが書けるようになった今の環境は、本当にありがたいものだなとしみじみ感じています。
もし古いサイトの保守でハックに出くわしても、この記事で正体さえ分かっていれば、もう必要以上にこわがることはありません。新しく作るものは標準仕様で、古いものは理解したうえで整理していく。そんなふうに使い分けていけば大丈夫です。
古いハックの正体を押さえておけば、これからは標準仕様を軸に、落ち着いてブラウザ差異と付き合っていけます。
