2023年5月に開催されたGoogle I/Oにて発表されたBaseline。これはブラウザ間での互換性がサポートされているAPIを分かりやすく表示するというものです。MDNやweb.devなどのドキュメントで、ブラウザ互換性がある場合にBaselineのマークが付きます。

このBaselineがもたらしくれる効果、そして注意しなければならない点を解説します。

ブラウザごとにマークが付きます

Baselineでは以下のようなブラウザのアイコンが表示されます。今のところ、英語表示の場合のみ表示されます。

これがある場合、各ブラウザでの互換性が保証されます。

Baselineのメリット

フロントエンド開発において、ブラウザの互換性は常に問題になります。そして、開発時には特定のブラウザを使って開発を進めるでしょう。その結果、実際にリリースすると別なブラウザで動かないことに気付かされます。

APIがない場合はもちろん、メソッドレベルの互換性に問題がある場合もあるでしょう。Baselineにロゴがあることで、ブラウザ間の互換性のが保証されるので、安心して利用できます。

注意点

実行環境の違い

Baselineで問題になるのはデスクトップとスマートフォンなどで動作差異が発生することです。デスクトップでは使えても、スマートフォンのブラウザでは使えない機能もあります。特にiPhoneではレンダリングエンジンをwkWebViewにしなければならず、Chromeといっても実際の中身はSafariに近いものになります。

同様にSafariで使っているレンダリングエンジンとwkWebViewの違いもあります。多くの機能差があり、Safariでは使えてもChromeでは使えない機能があります。

Can I useでも調べられる

デスクトップやモバイル単位の互換性を調べる場合にはMDN、またはCan I useを使いましょう。Can I useではバージョンも明記され、ブラウザのシェアレベルでどれくらい利用できるかも確認できるので便利です。

ハード系APIはChromeのみ

Web BluetoothやWeb USB、シリアル通信などハードウェアが絡むものはGoogle Chromeのみ（かつ実験的機能）になります。Safariは提供しないことを明らかにしているため、利用できるケースは限定的になるでしょう。

このようにAPI単位と言うよりも、カテゴリーとして互換性が期待できないAPIも存在します。

WebAssemblyも若干異なる

WebAssembly（以下WASM）については、WASMという中でも実装レベルが異なることがあるので注意が必要です。GCについてはChromeなどで実装されているものの、Safariでは実装に着手したというレベルです。

WASMは実行環境なので、より細かく実装状態を調べる必要があるでしょう。

セキュリティ・プライバシーに対する取り組みが違う

APIレベルはBaselineで確認できますが、セキュリティやプライバシーの取り組みはブラウザによって異なるので注意しましょう。特にサードパーティーCookieの扱いはChromeとSafari、Firebaseで異なります。

CookieというAPIレベルではブラウザ互換性がありますが、サードパーティーが有効かどうかで動作が変わることもあるでしょう。

ストレージの違い

ブラウザで使えるストレージ（localStorage、IndexedDB、Cache API、Cookieなど）の最大サイズはブラウザによって異なります。データが存在すると思ってアクセスしたら消えていた…という場合もあるので、ブラウザやデバイスによる差異に注意が必要です。

まとめ

かつてのHTML4の時ほどブラウザによって実装差異がある訳ではありませんが、それでもAPI単位での互換性は存在します。ブラウザベンダーの考え方によっても実装が変わってきます。

Baselineの登場によって、各ベンダーが互換性を意識するようになれば、実装差異を気にしなくて済むようになりそうです。Baselineは今後、どんどん広まっていくことを期待したい指標です。

Baseline