「Selectivizr.jsって今でも使えるの？」「古い記事で見かけたけど、まだ入れる必要はあるの？」古いCSSの解説を読んでいて、こんな疑問にぶつかった方もいると思います。
結論から先にお伝えします。Selectivizr.jsは、もう導入する必要のないツールです。かつてIE6〜8でCSS3のセレクタを使えるようにしてくれた便利なライブラリでしたが、その前提だった古いInternet Explorerそのものが、すでに役目を終えているからです。
私はWEB制作を長年やってきましたが、当時はこの手の「IEを今どきのブラウザに近づけるためのおまじない」を、頭を抱えながらいくつも仕込んでいました。Selectivizrもそのひとつで、納品先のIE8でレイアウトが崩れないか、ヒヤヒヤしながらサーバーにアップしていたのをよく覚えています。
この記事では、そもそもSelectivizr.jsが何をするものだったのかという基本から、なぜ今は不要になったのか、そしてIEが消えた今のブラウザ互換はどう考えればいいのかまでを、順を追って整理していきます。
具体的には、現代のCSS互換の主役である@supports（フィーチャークエリ）、ベンダープレフィックスを自動で付けてくれるAutoprefixer、そして全体を貫く「プログレッシブエンハンスメント」という考え方を取り上げます。
昔の苦労話を交えつつ、「あの頃こういうハックが必要だった理由」と「今はもう要らない理由」をセットで押さえていきましょう。古い記事を見て不安になった方も、読み終えるころには安心して手を動かせるはずです。
Selectivizr.jsとは何だったのか
Selectivizr.jsは、Internet Explorer 6〜8に対して、本来は対応していないCSS3のセレクタや属性セレクタを使えるようにしてくれたJavaScriptライブラリです。
当時のIE6〜8は、:nth-child() や :last-child、属性セレクタといった便利な書き方にほとんど対応していませんでした。そこでSelectivizrを読み込ませると、jQueryなどのライブラリと連携して、これらのセレクタをIEでも解釈できるよう肩代わりしてくれたのです。
つまりSelectivizrは、古いIEに「今どきのCSSの読み方」を後付けで教えるための、いわばポリフィル（不足機能の穴埋め）でした。
使い方自体はシンプルで、IE向けの条件付きコメントの中でスクリプトを読み込むだけ。古い解説では、次のような記述をよく見かけたはずです。
<!--[if (gte IE 6)&(lte IE 8)]>
<script src="selectivizr.js"></script>
<![endif]-->ちなみにSelectivizrはサーバーにアップしないと動かないという落とし穴があり、ローカルで確認して「動かない…」と悩む人が続出していました。私も一度これにハマって、原因に気づくまでだいぶ時間を溶かした記憶があります。
結論：Selectivizr.jsはもう使わなくていい
では本題です。今となっては、Selectivizr.jsを新しく導入する理由はありません。大きな理由は2つあります。
1つ目は、そもそも対象だったInternet Explorerが、すでにサポートを終了していること。Selectivizrは「古いIEを救う」ためのツールなので、救う相手がいなくなった以上、出番もなくなりました。
2つ目は、Selectivizr自体が開発の止まった過去のツールであること。配布元だった公式サイトも今ではアクセスできない状態で、新しいプロジェクトに組み込むには無理があります。
もし古いサイトの保守でSelectivizrの読み込みコードを見つけたとしても、それはIE時代の名残です。基本的には削除しても問題ないケースがほとんどで、無理に残しておく必要はありません。
関連記事：CSSハックとは？今はもう不要？IE終了後のモダンなブラウザ差異対処法
前提が消えた理由：Internet Explorerの終了
Selectivizrが不要になった一番の理由は、長年WEB制作者を悩ませ続けたInternet Explorerが、もう現役ではないことです。
Microsoftの公式情報によると、Internet Explorer 11のデスクトップアプリは2022年6月15日にサポートを終了しました。さらに対象OSでは、IE11デスクトップアプリが恒久的に無効化される措置も取られています。約27年続いたブラウザの歴史に、ここで一区切りがついた形です。
つまり、SelectivizrがターゲットにしていたIE6〜8どころか、最後のIE11まで含めて、IEそのものが第一線を退いたということです。
現在の標準ブラウザはMicrosoft Edgeで、業務用の古い社内システム向けには「IEモード」という互換機能が用意されています。MicrosoftはこのIEモードを少なくとも2029年まではサポートすると表明していますが、これはあくまで企業の特殊な事情に向けた仕組みです。
一般的なWebサイトの制作で、IE本体の表示を細かく作り込む必要は、もうほとんどなくなったと考えてよいでしょう。
参考： Microsoft Learn（Internet ExplorerとMicrosoft EdgeのLifecycle FAQ）
今どきのCSS互換の土台：プログレッシブエンハンスメント
IEがいなくなった今、ブラウザの違いはどう扱えばいいのでしょうか。その土台になる考え方が「プログレッシブエンハンスメント（段階的な機能向上）」です。
これは、まずどんなブラウザでもきちんと使える土台をつくり、その上で新しい機能に対応したブラウザには、より良い見た目や体験を上乗せしていく、という設計方針です。
Selectivizrのように「古いブラウザを新しいブラウザに無理やり合わせる」のではなく、対応している機能だけを素直に上乗せしていく、という逆の発想だと考えると分かりやすいと思います。
たとえば、まずは普通に読めるシンプルなレイアウトを用意しておき、Gridに対応したブラウザではより凝った配置にする、といった具合です。こうしておけば、たとえ未対応のブラウザがあっても「崩れて読めない」という最悪の事態は避けられます。
ブラウザの名前を狙い撃ちするハックと違い、機能の有無を基準にするので、新しいブラウザが登場しても破綻しにくいのが利点です。この考え方を支える具体的な道具が、次に紹介する@supportsとAutoprefixerです。
主役は @supports（フィーチャークエリ）
現代のCSS互換で主役と言えるのが、@supports（フィーチャークエリ）です。これは「ブラウザ名」ではなく「その機能に対応しているかどうか」を基準にスタイルを切り替える仕組みです。
かつてSelectivizrやCSSハックがやろうとしていた「ブラウザによる出し分け」を、CSS標準の機能だけでスマートに実現できる、と考えると分かりやすいと思います。
たとえば、CSS Gridに対応しているブラウザにだけGridレイアウトを適用したい場合は、次のように書きます。
@supports (display: grid) {
.layout {
display: grid;
}
}逆に「対応していない場合」を not で指定したり、and や or で複数の条件を組み合わせたりもできます。JavaScript側からも CSS.supports() で同じ判定ができるので、状況に応じて使い分けられます。
MDNによれば、この@supportsは2015年9月以降、主要なブラウザで広く使えるようになっています。すでにじゅうぶん枯れて安定した機能なので、安心して使ってよい段階に入っています。
ブラウザ名に頼らず機能ベースで判断するため、未知の新ブラウザが出てきても素直に対応できます。これは、IEのクセを当てにしていた昔のハックとは正反対の、未来に強いやり方です。
ベンダープレフィックスはAutoprefixerにまかせる
ブラウザ互換の話でもうひとつ外せないのが、ベンダープレフィックス（-webkit- や -moz- といった接頭辞）の扱いです。
昔は、新しいCSSプロパティを使うたびに、ブラウザごとの接頭辞付きを手書きで延々と並べる必要がありました。書き忘れれば一部のブラウザだけ効かない、という地味なトラブルの温床でもありました。
今はこの作業を、Autoprefixerというツールに自動でまかせられます。AutoprefixerはCan I Useのデータをもとに、対応が必要なプレフィックスだけを自動で付けてくれるPostCSSのプラグインです。
私たちは接頭辞なしのシンプルなCSSを書くだけでよく、面倒なブラウザ対応はツール側に任せられる時代になりました。これだけでもコードがぐっと読みやすくなります。
どのブラウザを対象にするかは「Browserslist」という設定で指定でき、プロジェクト全体で対応ブラウザの基準をそろえられるのも便利なところです。Autoprefixerは現在も活発に更新が続いていて、安心して使えます。
それでもポリフィルが必要になったら
IEが消え、@supportsやAutoprefixerが整った今でも、ごくまれに「この機能は一部のブラウザがまだ未対応」という場面はあります。そんなときに登場するのが、Selectivizrと同じ系統の「ポリフィル」です。
ポリフィルとは、ブラウザにまだ備わっていない機能を、JavaScriptなどで擬似的に補うコードのことです。Selectivizrも「IEにCSS3セレクタを足す」ためのポリフィルでしたが、今のポリフィルの考え方は当時とは少し変わっています。
現代では、ポリフィルはあくまで「本当に必要なときだけ、必要なブラウザにだけ読み込む最終手段」という位置づけです。すべての利用者に一律で重いライブラリを読み込ませるのは、表示速度の面で得策ではありません。
実際には、まず@supportsで機能の有無を判定し、未対応のときにだけ別の手段を用意する、といった形が基本になります。多くの新しいCSS機能は主要ブラウザがすでに対応しているので、ポリフィルの出番は昔よりずっと少なくなりました。
関連記事：min-heightとmin-widthの正しい使い方｜IE終了後の現代CSS
まとめ：Selectivizrは歴史として知っておけば十分
ここまで、Selectivizr.jsとは何だったのか、そしてなぜ今はもう不要なのかを、IEの終了と現代のCSS互換の考え方とあわせて見てきました。最後に要点を整理しておきます。
まず一番大事な結論として、SelectivizrはIE6〜8という前提が消えた今、新しく導入する必要のないツールです。古いサイトの保守で見かけても、IE時代の名残として理解しておけば十分で、基本的には外して問題ありません。
そして、IEがいなくなった現代のブラウザ互換は、次のような道具立てで考えるのが主流になっています。
- プログレッシブエンハンスメントを土台に、対応機能だけを上乗せする
@supportsで「ブラウザ名」ではなく「機能の有無」で分岐する- ベンダープレフィックスはAutoprefixerに自動で任せる
- ポリフィルは本当に必要なときだけの最終手段として使う
振り返ると、SelectivizrのようなツールでIEのご機嫌を取っていた時代は、それはそれで大変ながらも、なんとか動かせたときの達成感がありました。とはいえ、当時を知る身としては、こうした小細工なしで素直にCSSが書けるようになった今の環境は、本当にありがたいものだとしみじみ感じます。
古い解説記事でSelectivizrを見かけても、もう身構える必要はありません。新しく作るものは標準仕様とモダンなツールで、古いものは正体を理解したうえで整理していく。その線引きさえできていれば、ブラウザ互換はもう昔ほど怖いものではないはずです。
