HTML5 / CSS3 の機能対応チェック

機能

• 60 項目以上を4グループで検査：HTML 要素と属性、CSS の機能、ブラウザ API、メディア形式
• CSS は `CSS.supports()` で実測 —— 「要素を作ってスタイルを読む」方式より確実です（既定値が同じだと誤判定します）
• メディア形式は `canPlayType()` で実測し、戻り値（probably / maybe）も表示します
• WebGL 2 はレンダラーのバージョンも併記します
• 未対応のみに絞り込めます —— 環境の切り分けでは、それで全部です
• プレーンテキストのレポートをワンクリックでコピー（末尾に UA。真っ先に聞かれる情報です）
• 未対応の項目には、その検査が何を見ているかの説明がつきます
• すべて手元で完結：リクエストも cookie も使いません

使い方

1. ページを開くと検査が自動で走ります
2. 上部の数字をご覧ください —— この端末で対応している割合です
3. 「非対応のみ」に切り替えると、対応が必要な項目だけが残ります
4. 「レポートをコピー」でチケットやチャットに貼れます

よくある質問

互換表を見るのではだめなのですか？

表は別の質問に答えているからです。表が示すのは「バージョン X から対応」ですが、実際の対応は次のものにも左右されます：OS（同じブラウザの版でもプラットフォームで能力が違います）、端末（低スペック機では API が無効化されます）、利用者の設定（省電力・プライバシー・企業ポリシー）、そして置かれた文脈（`crypto.subtle` は HTTPS でしか存在せず、Service Worker も同様です）。表は計画向きで、「いまこの端末で動くか」は実測するしかありません。両者は対立しませんが、片方を他方の代わりにはできません。

この結果を互換性の根拠にできますか？

できますし、表より正確です —— ただしこの端末のこのブラウザに限ります。このツールの使い方は「採用するかどうかの判断」ではなく、コードに機能検出を書くことです（`if (CSS.supports(...))`、`if ("showPopover" in HTMLElement.prototype)`）。そうすれば各ブラウザが自分の経路を選びます。ツールの価値は、どの経路に備えが必要かを事前に知ることと、「なぜここでは効かないのか」の切り分けにあります。

ブラウザ名とバージョンが出ないのはなぜですか？

名前とバージョンから能力を判断するのは誤りだからです。UA 文字列は偽装できますし、同じ版でも OS によって能力が異なり、バージョン番号と機能の間に対応関係はありません。正しいのは能力そのものを検出すること（このツールがやっていること）で、身元を検出することではありません —— これが「UA sniffing より機能検出」という原則の技術的な理由です。レポートに UA を載せるのは、その結果がどこから来たかを示すためだけです。

非対応と出たのに、対応しているはずだと思うのですが？

まずその行の説明をお読みください。よくある原因：HTTPS が必要（`crypto.subtle`、Service Worker、カメラとマイク、クリップボードへの書き込み）、許可が必要（位置情報、通知）、特定のプラットフォーム限定（File System Access API は Chromium 系のみ）、設定やポリシーで無効（シークレットモードでのストレージ、企業ポリシー下の WebGL）。いずれも「ブラウザができない」ではなく「いまここでは使えない」で、判断も対処も別物です。