Baseline から考えるブラウザサポート

続々とリリースされる新機能の使い方を理解しながら、各種ブラウザのサポート状況に配慮することは、ウェブ開発者にとって尽きることのない悩みの種です。

本記事では、従来型のブラウザサポートの考え方を脱却して、Baseline から考えるブラウザサポートのアプローチによって、この課題について検討していきます。

従来型のブラウザサポートのアプローチでは、まず「エバーグリーンブラウザ」かどうか（Safari か否か）で大きく分類します。

エバーグリーンブラウザは、約 4 週間という短いサイクルでリリースされるブラウザを指し、Google Chrome や Microsoft Edge、Firefox が該当します。この場合には、具体的なバージョンではなく「最新版」とするか、例えば「最新バージョンとその 2 つ前まで」のように定めることが多いと思われます。

これに対し、Safari はリリースサイクルが比較的長く、ブラウザのバージョンが OS に依存するため、エバーグリーンとは呼ばれません。この場合には、具体的なバージョンを示すか、もしくは「最新バージョンとその 2 つ前のメジャーリリースまで」のように定めます。

ただ、エバーグリーンブラウザが「最新版」であることはあくまでも仮定であり、ユーザが即座に最新版を使用しているとは限りません。安定性を重視してアップデートの間隔が長いエンタープライズ版を使用していたり、OS が最新版をサポートしていないために、古いバージョンをやむを得ず使用しているケースも考えられます¹²。

一方、Safari において具体的なバージョンを指定する場合、ユーザデータによる裏付けがなければ根拠は弱くなります。加えて、継続的に開発する場合には、定期的にサポートするバージョンの見直しも必要になります。

このように、リリースサイクルの早いエバーグリーンブラウザと、OS に依存する Safari、それぞれに生まれる不確実性に対して、相互運用性を確保しつつ、どのように新しい機能を取り入れていくかが課題となっています。

Baseline は、W3C の WebDX Community Group が主導する、ウェブプラットフォームの機能を安全に使用できるように、主要なブラウザでのサポート状況を明確にし、相互運用性を高めるための取り組みです。

Baseline としては「Newly available」と「Widely available」の 2 つのステータスに分類され、それに満たない機能は「Limited availability」とされます。

Widely available

すべての主要なブラウザでサポート（30 ヶ月以上）

Newly available

すべての主要なブラウザでサポート（30 ヶ月未満）

Limited availability

限定的なサポート

このステータスにより、特定の機能がすべての主要なブラウザでサポートされているか、サポートされてから十分な期間が経過しているかを確認することができます。

対象となる主要なブラウザ（コアブラウザ）のセットは以下のとおりです。

• Safari（macOS、iOS）
• Google Chrome（デスクトップ、Android）
• Microsoft Edge（デスクトップ）
• Firefox（デスクトップ、Android）

注意する点としては、Baseline はブラウザがその機能をサポートした日付を起点とするだけなので、依然としてブラウザ特有の問題が残っているケースも考えられます。また、スクリーンリーダなどの支援技術のサポートに関しては対象外なので、例えば WAI-ARIA の機能を使用する場合には、別途サポート状況を調べる必要があります。

Baseline をブラウザサポートとして定義するには、まずは、プロジェクトの性質や達成する目標に応じてターゲットを選ぶことになります。

web.dev の記事「How to choose your Baseline target」では、Baseline ターゲットを以下の 2 つのタイプに分類しています。

• Moving Targets（移動するターゲット）
• Fixed Targets（固定されたターゲット）

Moving Targets は、時間の経過とともにステータスが変化する、Widely available と Newly available が対象になります。その時々の状況に応じて柔軟に対応できる反面、流動的であるため、一貫性や安定性には欠けます。

これに対し、Fixed Targets は特定の年を指定することになります。例えば「Baseline 2022」を基準とする場合には、その年までに Baseline に含まれている機能をターゲットとします。変化がないので予測しやすく安定性は高いですが、定期的にターゲットの見直しが求められます。

UK のデザインスタジオ Clearleft では、ブラウザサポートを Baseline に定義しています。

• Browser support | Clearleft （外部リンクを開く）

基本的には Widely available をターゲットとし、Newly available の機能を使用する際には、Progressive Enhance­ment（プログレッシブエンハンスメント）であるかどうかで判断します。

同社の共同創業者である Jeremy Keith 氏のウェブ書籍『Resilient Web Design』から引用すると、Progressive Enhance­ment は、以下のステップで進めることで実現できます。

1. Identify core functionality.
2. Make that functionality available using the simplest possible technology.
3. Enhance!

まず、コア機能を特定し、次に、その機能を多くの環境で利用できるようにシンプルな方法で実装し、そのうえで、機能を強化していくアプローチです。

この考え方を Newly available に適用すると、その機能が使用できない状況でも、コア機能が提供できるかどうかが 1 つの評価基準になります。

たとえば、CSS のネスト（CSS Nesting）は、2025 年 6 月時点では Newly available ですが、非対応の環境でレイアウトが大幅に崩れる場合には Progressive Enhance­ment ではないと考えられるため、そのままでは使用できません。

このように、基本的には Widely available とし（すなわち、主要なブラウザでサポートされてから十分な時間が経過している機能を使用し）、Newly available な機能は Progressive Enhance­ment であれば使用可能という二段構えになっており、合理的かつ堅牢な手法だといえそうです。

一方で、Progressive Enhance­ment かどうかは、その機能を使用する文脈によって変わることがあるため、判断が属人的になる点には課題が残ります。

ここまでの内容を踏まえて、Baesline ターゲットを決めていきます。

まずは、実態に則しているのはアクセスログ解析などによるユーザデータの活用です。Google Analytics Baseline Checker では、Google Analytics のログデータから、Baseline のレポートを作成することができます。

ユーザデータを使用できない場合には、Akamai が運営する RUM Archive プロジェクト内の RUM Insights のデータを参考にすることができます。

「Baseline Support」セクションの「All countries」から「Japan」を選択することで、日本国内の Baseline イヤーの傾向を確認できます。

これらのデータを踏まえたうえで、Moving Targets か、それとも Fixed Targets か、後者の場合には、何年の Baseline をターゲットにするのかを決めていきます。

Baseline は、MDN や Can I Use をはじめ、最近では Visual Studio Code でも確認できるようになりましたが⁴、ここでは以下の 2 つのウェブサービスを紹介します。

Web Platform Status では、Baseline のデータを網羅的に確認することができます。年や期間、ステータスなど、詳細に絞り込むことができ、CSV 形式で出力することも可能です。

Web platform features explorer では、同様に Baseline のデータが確認できるのですが、特に最新情報を取得するのに向いています。また、RSS リーダーに登録しておくことで、月次レポートを受け取ることができます。

Baseline を開発に取り入れるには、まずは Browserslist に組み込むことが考えられます。ただ、筆者はまだ試せていないので、以下のページを紹介するにとどめます。

• Use Baseline with Browserslist | web.dev （外部リンクを開く）

Browserslist を経由しなくても、Stylelint のプラグインとしても使用できるのですが、こちらは少しだけ試しました。

このように、指定した Baseline ターゲットに含まれない機能を使用した場合にエラーを表示することができます。

ただ、Progressive Enhancement な実装であるため、使用を認めるようなケースでは、どのようにエラーを無視させるかが課題です。オプションで設定するのか、それともコード上のコメントで制御するのという選択が、開発時の負担になりそうな気がしています。

Baseline のカタログデータは web-features から取得できます。

こちらも少しだけ試しましたが、機能ごとの Baseline や各ブラウザのサポート状況、機能の概要、仕様書の URL、ブラウザのバージョンごとのリリース日などのデータが利用できます。

この記事では、従来型のブラウザサポートの課題から出発して、Baseline から考えるブラウザサポートのアプローチを見てきました。

Clearleft 社の例では、Widely available を基本とし、Newly available な機能は Progressive Enhance­ment であれば使用可能という、柔軟性と堅牢性をあわせ持つ手法ですが、Progressive Enhance­ment かどうかの判断基準が課題となりそうです。

また、その機能が Baseline に到達していたとしても、ブラウザ特有の問題が残っている場合もあるので、これまでどおり実機での検証は欠かせないでしょう。加えて、アクセシビリティに関しては Baseline の対象外のため、支援技術のサポート状況は別途確認しておく必要があります。

本記事の作成にあたり、以下のウェブページやウェブ書籍を参考にしました。

• What is Baseline? | Baseline （外部リンクを開く）
• How to think about Baseline and polyfills | web.dev （外部リンクを開く）
• How to choose your Baseline target | web.dev （外部リンクを開く）
• Browser support | Clearleft （外部リンクを開く）
• Resilient Web Design （外部リンクを開く）
• Building a robust frontend using Progressive Enhance­ment | GOV.UK （外部リンクを開く）

脚注

1. “Evergreen” Does Not Mean Immediately Available | CSS-Tricks ↩

2. Chromium 系のブラウザでは バージョン 139 から、macOS 11 が対象外になる予定です（Chrome Platform Status）。 ↩

3. First catalog of web features completed by the WebDX Community Group | W3C ↩

4. Visual Studio Code now supports Baseline | web.dev ↩