古いブラウザーの不足機能をポリフィルで補い、補完後を含む対応状態を判定する。その判定は互換処理に加え、GitHub.comからバックエンド監視へ送るエラーや統計の条件にも使われる。
不足する小規模な機能をポリフィルで補う
GitHubが公開するブラウザー互換ライブラリの@github/browser-supportは、新しい機能を実装していない古いブラウザーとWebサイトの互換性を維持するためのソフトウェアだ。新しいブラウザー機能を一括して代替するのではなく、小規模な機能をポリフィルで補う。
ポリフィルは、ブラウザーに存在しない機能をWebサイト側で利用可能にする。この補完によって、標準実装だけでは必要な機能がそろわないブラウザーも、後段の対応判定へ進められる。
標準実装と補完機能をまとめて判定する
isSupported()は、ブラウザーが所定の機能セットを利用できるかを判定する。判定にはブラウザーが標準で実装する機能だけでなく、ポリフィルによって利用可能になる機能も含まれる。
したがって、対応状態を決める基準は個々の機能の標準実装の有無ではなく、標準実装とポリフィルを合わせて必要な機能セットがそろうかどうかになる。同じ判定関数を、補完処理の前後で利用できる構成だ。
非対応の判定から適用後の確認までをつなぐ
公開コード例は、最初にisSupported()を実行し、偽が返った場合にapply()を呼び出す。機能セットの不足が検出されると、その結果がポリフィル適用の条件になる。
apply()の実行後、コード例はisSupported()とisPolyfilled()がともに真であることを確認する。前者が必要な機能セットの成立を、後者がポリフィル適用状態を表し、補完結果を二つの状態として確認できる。
対応判定をバックエンド監視の送信条件にする
GitHubは、@github/browser-supportが提供するすべてのポリフィルをGitHub.comで使用している。さらにisSupported()を使い、アクセスしたブラウザーがGitHub.comの求める最低限の機能セットを満たすか判定する。
判定が偽となるブラウザーは、エラーや統計をバックエンド監視へ送信しない。互換性の判定結果が、ページを動かすための補完処理だけでなく、監視データを送るブラウザーの範囲にも反映される。
標準化段階と基本対応条件でポリフィルを管理する
追加するポリフィルは、ECMAScriptのStage 4に達した機能またはすでに仕様化された機能に限られる。Stage 3以下の機能は追加対象にしないため、標準化の途中にある機能を先行して補う構成ではない。
既存のポリフィルを削除する場合は、GitHubの@github/web-systemsと協議する。削除する機能を対応条件として残す必要があれば、その機能の検出を基本対応条件のbaseSupportへ加える方針が示されている。