長年の悩みがこれで解決！ CSSで機能を組み合わせたときにブラウザがサポートしているか検出できる新機能「@supports named-feature()」
Post on:2026年10月1日
sponsorsr
CSSの@supportsはブラウザがその機能をサポートしているか検出するのに便利ですが、単独の機能しか検出ができません。
たとえば、gapは現在はflexboxでサポートされていますが、当初はCSS Gridのみでした。そのため、@supports (display: flex) and (gap: 1em) のように記述しても、flexboxでgapを使えるかではなく、それぞれflexboxが使えるとgapが使えることが検出できるだけです。
こういった機能の組み合わせで検出できる@supports named-feature()がまもなく全ブラウザでサポートされます。
“Undetectable” CSS Features with @supports named-feature()
by Bramus!
下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。
はじめに
CSSでは、@supportsを使用することで、セレクタやプロパティと値の組み合わせ、あるいはアットルールといった機能のサポート状況を検出できます。しかし、基盤となる実装の変更や既存の2つのプロパティが新たに連携して機能するようになった場合、どのように検出すればよいのでしょうか？
そこで登場したのが、ハック的な回避策に頼ることなく、こういった特定の機能を検出できるように設計されたのが@supports named-feature()です。
元祖ユースケース: Flexboxにおけるgap
昔のことですが（とは言っても2020年のことです）、ChromiumにFlexレイアウト向けのgapプロパティが導入されました。このプロパティはそれ以前にCSS Gridのグリッドレイアウトでは機能していましたが、Flexレイアウトでもこのプロパティが有効になり始めた頃でした。
時系列で見てみると、このgapプロパティは2015年にgrid-gap（grid-row-gapおよびgrid-column-gapの省略形）として登場し、当初はCSS Gridのグリッドレイアウトのみで機能していました。その後、2017年にデベロッパーからの要望を受けてCSSワーキンググループは、アイテム間のスペース調整がすべてのレイアウト方式で有用であると判断しました。そしてgrid-というプレフィックスを削除し、グリッドレイアウトとFlexレイアウトの両方に使用できる省略形のgapプロパティを作成しました。
|
1 2 |
- grid-gap: 2em; + gap: 2em; |
Chromium以外の各プラウ座もこれに追随し、grid-gapを新設されたgapプロパティの別名として扱うようになりました。しかし、ここが重要な点です、だからといってすべてのブラウザ上でFlexレイアウトでgapが機能するようになったわけではありません。grid-gapをgapのエイリアスにすることは迅速かつ容易でしたが、Flexレイアウトで機能するように仕様が定められたことと、ブラウザが実際にFlexbox gapをサポートすることの間には、文字通りギャップが存在していました（ダジャレです 🥁）。
この混迷期においては、ブラウザがFlexbox gapをサポートしているかを確実に判断する方法はありませんでした。
たとえば、@supports (gap: 1em)を記述しても、ブラウザは「はい、サポートしています！」（Grid用として）と答えてしまうからです。
また、@supports (display: flex)を記述しても、やはりブラウザは「はい、サポートしています！」と答えてしまいます。
さらに、@supports (display: flex) and (gap: 1em)と組み合わせても、ブラウザは「はい、サポートしています！（ただし、単独でね）」と答えてしまいます。
なぜなら、ブラウザは渡された<supports-condition>を解析できるかどうかをチェックするだけで、それらを組み合わせた結果として機能するかまでは判断しないからです。
|
1 2 3 4 |
/* CSSがこれらの宣言を機能するるか個別に確認するだけで、組み合わせて機能するかを確認するものではありません */ @supports (display: flex) and (gap: 1em) { … } |
そこで、2020年にChromiumがFlexbox Gapを実装した直後、私はCSSワーキンググループに、Flexboxと互換性を保ちつつgapを適切に機能検出する方法について提出しました（w3c/csswg-drafts#5062）。
ところが、すでに検討対象になっていたようで、私のリクエストは2019年に提出された、より一般的な表現のw3c/csswg-drafts#3559（「部分的な実装におけるプロパティと値のサポートのテスト」に関するもの）と重複扱いとなりました。
CSSの新機能「named-feature()」
w3c/csswg-drafts#3559での議論はやがて沈静化しましたが、2023年末にブラウザがdisplay: block;のコンテナに対してalign-contentが効果を発揮するようになると、この議論は再び大きな注目を集めるようになりました。
それから2ヵ月後、ワーキンググループはこの問題を解決するためのDavid Baron氏の提案を承認しました。私はこの問題の解決に向けたDavid Baron氏の提案の趣旨を非常に気に入っています。
重要だと判断した場合には、特定の機能に特化したその場しのぎ的な解決策を追加することも妥当な選択肢かもしれません。ただし、それらはCSSに新たなキーワードを追加する価値があるほど重要な機能であり、デベロッパーがその実装の必要性を見逃すことがなく、かつ展開が問題なく進むよう結果を綿密に検証・監視するためのWebプラットフォームテストを作成する価値があるものでなければなりません。また、キーワード名についてもある程度冗長なものを選んでも許容されるでしょう。
この趣旨によって生まれたのが、named-feature()です。
これは従来の@supportsでは検出できない、非常に具体的な機能や機能の変化を検出できる関数です。この関数は引数としてキーワードを必要とし、使用可能なキーワードのリストは仕様であらかじめ定義されています。
|
1 2 3 |
@supports named-feature(some-specific-behavior) { /* some-specific-behaviorをサポートするブラウザ向けのCSSを記述 */ } |
使用可能なキーワードは、機能検出が強く求められているもの、CSSの他の組み合わせでは実現不可能な、ごく一部の扱いにくいエッジケースに限られています。
実際のユースケース
2026年現在、CSSワーキンググループはnamed-feature()用のキーワードを2つ規定しています。これらは私が以前提案したものなので、個人的にとても嬉しく思います 🙂
トランスフォームを考慮したAnchor Positioning
CSS Anchor Positioningは当初、トランスフォーム（変形）を考慮せずに実装されていました。しかし、デベロッパーからの要望が非常に大きかったため仕様が更新され、このユースケースにサポートされるようになりました。この変更はChrome 144で実装され、近日リリース予定のSafari 27にも含まれており、Firefoxではプロトタイプ開発が進められています。
Anchor Positioningの機能自体は以前から@supportsで検出できましたが、ブラウザがアンカー要素のトランスフォームを検出することはできませんでした。
この問題を解決するために、w3c/csswg-drafts#13678で決定されたキーワード「anchor-position-follows-transforms」を使用できます。
|
1 2 3 |
@supports named-feature(anchor-position-follows-transforms) { /* ✅ ブラウザは、トランスフォームを考慮したアンカー配置に対応しています */ } |
Safari 27では当初、このトランスフォームを考慮したAnchor Positioningは含まれていませんでしたが、私はSafariチームに連絡を取り、named-feature(anchor-position-follows-transforms) のサポートを追加するように依頼したところ、8月初めにそのプルリクエストがマージされました。Firefoxｋも現在、「Transform-Aware Anchor Positioning」のプロトタイプを進めており、named-feature()も同時にリリースすると発表しています。
単一軸のスクロールコンテナ
@supportsだけでは検出できないもう一つの例は、コンテナを単一軸のみのスクロールコンテナとして扱えるようにした最近の変更です。これはCSS sticky per axis（翻訳記事）で解説したように、ある軸でのposition: sticky;が別の軸にある無関係なスクロール領域によって阻害されてしまうという長年の問題を解決するものです。
大量のJavaScriptを使用すれば単一軸スクロールコンテナの機能検出は可能ですが、CSSだけでは無理でした。しかし、w3c/csswg-drafts#13677の提案が採用されたおかげで@supports named-feature(single-axis-scroll-container)という形でsingle-axis-scroll-containerキーワードを利用できるようになりました。
|
1 2 3 |
@supports named-feature(single-axis-scroll-container) { /* ✅ 単一軸のスクロールコンテナがサポートされているため、軸ごとのスティッキー（固定）は機能します！ */ } |
ブラウザのサポート状況
named-feature()のサポート状況は以下の通りです。
| ブラウザ | サポート状況 |
|---|---|
| Chromium (Blink) | Chrome 150からサポート |
| Firefox (Gecko) | Firefox 156でサポート予定 |
| Safari (WebKit) | Safari TPでサポート済み |
anchor-position-follows-transformsのサポート状況は以下の通りです。
| ブラウザ | サポート状況 |
|---|---|
| Chromium (Blink) | Chrome 150からサポート |
| Firefox (Gecko) | Firefox 156でサポート予定 |
| Safari (WebKit) | Safari TPでサポート済み |
single-axis-scroll-containerのサポート状況は以下の通りです。
| ブラウザ | サポート状況 |
|---|---|
| Chromium (Blink) | Chrome 153でサポート予定 |
| Firefox (Gecko) | サポート対象外。バグチケットもまだ作成されていません。 |
| Safari (WebKit) | サポート対象外。バグチケットもまだ作成されていません。 |
他の機能もサポートされますか？
ここで触れた機能やキーワード以外が設定されていない理由について気になっている人のために、その点について説明します。
display: flex;でのgapプロパティ
この機能は現在では、すべてのブラウザがサポートしています。この機能が実装されてから、そしてnamed-feature()による検出機能が利用可能になってからすでにかなりの時間が経過しています。
display: block;に対するalign-contentの影響について
Chromeチームは入念な調査をおこない、主要なWebサイトを対象に（内部的な）テストを実施しました。その結果、顕著な不具合として確認されたのはNetflixのケースだけでした（メディアクエリによってblockからflexに切り替わる要素にalign-contentが設定されていたことが原因）。これについてはNetflixに個別に連絡をしてCSSを対応していただきました。
スタイルクエリ
これについては以前、w3c/csswg-drafts#13975としてIssueを提出しました。ただ、難しいのはChromeが2023年3月に、Safariが2024年9月にこの機能を実装してからかなりの年月が経っていることです。そのため、今この検出機能を実装すると、多くの誤検知が発生してしまいます。さらに、スタイルクエリの機能検出をおこなうための回避策（翻訳版）も存在します。
念のため補足しておくと、@propertyなどの他のアットルールについても、at-rule()で機能検出が可能です。
sponsors
