WebAssembly のおかげで実現できた新機能はたくさんありますが、1 つのブログ投稿を丸ごと使ってその一部を紹介しています。

その中には、さまざまな理由で標準プロセスを通過できなかった機能も含まれています。また、現在標準化が進行中で、さまざまなブラウザで実装が進められているものもあります。

• Wasm 版 FFMPEG は、ウェブアプリで効率的に動画を扱えるようにします。標準化されている WebCodecs でも同じようなエンコードやデコードが可能ですが、対応ブラウザはまだ限られています。

• WebAssembly は、Google Meet のビデオ通話の背景ぼかしに使われており、この機能に関する専用の標準提案が行われています。

• Web SQL は標準化され、何年も前から Chrome に搭載されていますが、多くのブラウザでサポートされることはありませんでした。Wasm 版 SQLite は Web SQL に替わる機能です。Web SQL は、今後 Chrome から削除される予定です。

• Universal Scene Descriptor（USD）は Safari に搭載されていますが、他のブラウザでは利用できません。
  
  

標準化と承認を経なくても機能を公開できるので、イテレーション サイクルが年単位から日単位、場合によっては時間単位にまで短縮できます。オリジン トライアルなどのアプローチを使えば、多くの試験運用を行うことはできますが、それでも週単位や月単位のイテレーションが必要になります。イテレーションの速度を変えるということは、その対象自体を抜本的に変革するということです。

機械学習などの分野は進展が速いので、標準ベースのアプローチではついていくことができません。設計が標準化を経てクロスブラウザ実装に移ったころには、すでに新たな進展があり、プロセス全体をやり直さなければならなくなってしまいます。

とは言うものの、標準化が不可欠なことも多い点は変わりません（後述のデメリットのセクションを参照）。標準化が適している場合は、当然標準化を試みる必要があります。

さまざまなブラウザをすぐにサポート

wasm はさまざまなブラウザでサポートされているので、これを使って構築した機能もすべてのブラウザですぐに動作します。機能の相互運用性とクロスブラウザ実装は、デベロッパーにとって最大の悩みです。機能を低レベルプリミティブに移行することで、この懸念の大半を解消できます。

この機能は厳格なセキュリティ サンドボックスがベースになっているため、ネイティブ実装された API よりも格段にセキュリティが向上します。たとえば、Flash がウェブから削除された大きな理由は、複雑なプラグインのセキュリティを十分に強化するのが難しすぎたためです。しかし、今は Flash を WebAssembly で実行でき、セキュリティの懸念の大半が解消されています。

複雑な問題に対するあらゆる新しいソリューションと同じく、WebAssembly にもデメリットや制限がないわけではありません。その中には、仕組み的に避けられないものもあれば、有望なソリューションが存在するものもあります。

WebAssembly は JavaScript の代替ではなく、JavaScript が時代遅れになるわけでもありません。どちらかというと、WebAssembly は JavaScript の機能を拡張するものです。

ユーザーランドに移動するロジックや機能が増えることで、ページのサイズも増大します。バンドルサイズの縮小は優れたユーザー エクスペリエンスにとって最重要なので、これは大きな問題になります。そのため、この機能を使ってバンドルサイズを肥大化させる前に、慎重に検討する必要があります。この点は、小さな e コマースやブログのサイトよりも、大型のウェブアプリで問題になる可能性があります。JavaScript を多用するフレームワークでも、これが長いこと問題になっています。この状況を改善するため、さまざまなソリューションが考えられるかもしれません。

WebAssembly などのプリミティブは、ほとんどが計算メカニズムであり、OS やデバイス自体にシステムのルート権限でアクセスする機能は一切提供されていません。ハードウェア アクセス（USB や Bluetooth）、画面やウインドウの管理、入力コントロール、ファイル システム、クリップボードなどの機能にアクセスする場合は、今後もプラットフォーム レベルの API が必要になります。Chromium の Fugu プロジェクトは、Chromium ベースのブラウザでこれらのすべての事例を実現しようとするものですが、他のブラウザでの実装も必要になります。

WebAssembly は、すでにブラウザの新機能実現に活用されていますが、それ以上に、根本的に新しい方法で機能の開発方法にアプローチします。何かを改善する最善の方法は、その改善方法を改善することです。すると、2 次曲線的な成長を遂げることができます。どのような新しいパラダイムにもメリットとデメリットがあります。しかし、総合的に見れば、WebAssembly は、あらゆるブラウザとデベロッパーにとって新しいアプローチであると言えます。これを使って皆さんとともに開発を進めていくのが楽しみでなりません。

変更事項

以前、Google Ads API の画像と住所の自動移行を 2023 年 4 月 3 日に開始することをお知らせしましたが、この自動移行を延期することになりました。新しい日程は近日中にブログ投稿でお知らせします。

画像と住所のアセットは、自動移行が始まるまで、引き続きテスト アカウントで利用できます。

何をする必要がありますか？

すぐに何かの対応を行う必要はありません。

自動移行の準備として、Google Ads API の v13 にアップグレードすることをおすすめします。

ご質問などございましたら、フォーラムからご連絡ください。

この変更に関して質問がある方は、GitHub の Issue に直接コメントを入力してください。

特に記載のない限り、下記の変更は Android、ChromeOS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2023 年 3 月 9 日の時点で Chrome 112 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

# CSS

# CSS のネスト

CSS のスタイルルールの中に別のスタイルルールをネストできるようになります。外側のセレクタと内側のルールを組み合わせることができるので、スタイルシートのモジュール性と保守性が向上します。詳しくは、CSS のネストに関するこちらの記事をご覧ください。

# CSS animation-composition プロパティ

animation-composition プロパティを使うと、複数のアニメーションが同時に同じプロパティに影響を与える場合に、使用する複合操作を指定することができます。このデモの例をご覧ください。  

# ウェブ API

# トップレベルのフレームが権限の変更を監視している場合に [Reload this page] 情報バーを非表示

トップレベルのフレームが PermissionStatus の onchange イベントをサブスクライブしている場合、[Reload this page] 情報バーが抑制されます。このサブスクライブにより、ページ情報ダイアログで行われたカメラやマイクの権限変更に対して、アプリケーションが動的に反応することが示されます。イベント リスナーが存在するかどうかにかかわらず、権限が取り消されるとメディア ストリームが直ちに終了するという既存の動作は変わりません。

# FormData コンストラクタにオプションの submitter パラメータを追加

FormData コンストラクタに送信ボタンを渡せるようになります。ボタンに名前がある場合、またはボタンがイメージボタンである場合は、フォームのデータセットに影響します。これにより、ボタンによってトリガーされる通常のフォーム送信と同じデータセットを持つ FormData オブジェクトを作成できるようになります。

# 集合表記と文字列プロパティに対応する正規表現の v フラグ

正規表現の文字クラスに、集合演算、文字列リテラル、ネストクラス、文字列の unicode プロパティを追加します。集合演算と文字列の unicode プロパティにより、特定の unicode 文字を含む正規表現のマッチ文字列を簡単に作れるようになります。

たとえば、 /[\p{Script_Extensions=Greek}&&\p{Letter}]/v はすべてのギリシャ文字にマッチします。

# <dialog> の初期フォーカス アルゴリズムの更新

<dialog> 要素が開いたときフォーカスを受け取る要素の選択に関して、いくつかの変更が行われます。 

• ダイアログのフォーカス設定手順で、フォーカスが可能なすべての要素ではなく、キーボードによるフォーカスが可能な要素が参照されます。
• autofocus 属性が設定されている場合は、dialog 要素自体がフォーカスを受け取ります。
• フォーカスが body 要素に「リセット」されるのではなく、フォールバックとして dialog 要素自体がフォーカスを受け取ります。

# WebAssembly の末尾呼び出し

WebAssembly に明示的末尾呼び出しと間接末尾呼び出しのオペコードを追加します。

# Web Worker の WebGLContextEvent

WebGLContextEvent 型は、Khronos の WebGL 仕様で何年も前から定義されていますが、Blink でこの型が Web Worker に公開されていなかったことは最近までわかりませんでした。

ほとんどのアプリケーションは、イベント リスナーを追加してこの型を受け取っているだけで、グローバル スコープでプロトタイプを探しません。この変更は Blink で WebGLContextEvent の Web IDL を修正しただけの簡単なものですが、ウェブに公開されます。

# Service Worker が no-op フェッチ ハンドラをスキップ

この機能により、no-op Service Worker フェッチ ハンドラがスキップされるため、これが設定されているページのナビゲーションが高速になります。

サイトによっては、no-op（何もしない）フェッチ リスナー（例 : onfetch = () => {}）が設定されている場合があります。フェッチ リスナーを設定することはプログレッシブ ウェブアプリ（PWA）要件の 1 つだったので、これはサイトを PWA として認識させるための措置だったと考えられます。ただしこれは、Service Worker を起動して no-op リスナーを実行する負荷を増やすだけであり、コードが何もしないので、キャッシュやオフライン機能といった機能的なメリットがもたらされることはありません。

このようなページへのナビゲーションを高速にするため、Chrome 112 以降では、ユーザー エージェントにより Service Worker のすべてのフェッチ リスナーが no-op であると判断された場合に、ナビゲーションのクリティカル パスから Service Worker の起動とリスナーのディスパッチを省略します。

この変更の一環として、Service Worker のすべてのフェッチ リスナーが no-op であった場合、デベロッパーに無用なフェッチリスナーを削除してもらうために、Chromium がコンソールに警告を表示するようになります。無用なフェッチ リスナーが使用されなくなり、将来的にこの機能のサポートを終了できることを期待しています。

# WebView の HTTPS コネクションの Accept-encoding: br（Brotli）

Brotli（content-encoding type: br）は汎用ロスレス圧縮アルゴリズムで、現在利用できる最高の汎用圧縮手法よりも高い圧縮率とスピードを提供します（詳しくは、google/brotli と RFC 7932 をご覧ください）。 

Brotli（Accept-Encoding: br）の HTTP content-encoding type は バージョン 50 以降の Chrome でサポートされていますが、これまで WebView では有効になっていませんでした。安定性を確保するため、この機能は段階的にロールアウトされ、WebView ベータ版の 50% で利用できるようになる予定です。

# 進行中のオリジン トライアル

Chrome 112 では、以下のオリジン トライアルにオプトインできます。

# FedCM: 自動再認証 API

最新バージョンの FedCM には、自動再認証機能のオプトインが含まれています。これにより、最初に FedCM を使って認証を行ったユーザーが再度アクセスしたときに、ユーザーを自動的に再認証できるようになります。

現在、ユーザーが FedCM を通して IdP（ID プロバイダ）のある RP（リライング パーティ）でフェデレーション アカウントを作成すると、ウェブサイトに次回アクセスするときに、ユーザー インターフェースで同じ手順を実行しなければなりません。つまり、ログインフローを再開するには、明示的に確認して再認証する必要があります。FedCM の主な目的の 1 つは密かなトラッキングを防ぐことなので、ユーザーがフェデレーション アカウントを作成する前であれば、このユーザー エクスペリエンス（UX）が妥当です。しかし、ユーザーがこの手順を行った後では、不要で面倒な手続きになります。そこで Chrome は、再アクセスするユーザー用にさらに効率的な UX を導入し、RP がそれを選択できるようにします。

FedCM 自動再認証オリジン トライアルに登録する

# 逆トライアル

RTCPeerConnection の getStats() メソッドは、type == "track" または "stream" の統計オブジェクトを返さなくなります。この機能は Chrome 112 で削除されますが、このトライアルにオプトインすると、必要な変更を行うための時間を増やすことができます。

この逆トライアルに登録する

# WebView の X-Requested-With のサポート終了

この逆オリジン トライアルでは、X-Requested-With ヘッダーを使用するサービスを呼び出す際に、クロスオリジン事前有効化をサポートします。このオプションは、Chrome 112 以降の WebView で利用可能です。この機能の使用方法については、オリジン トライアルの設定手順をご覧ください。

WebView の X-Requested-With 逆トライアルに登録する

# サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。サポートの終了が予定されている機能、現在サポートが終了している機能、以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

今回の Chrome のリリースでは、1 つの機能のサポートが終了します。

# document.domain セッターのサポート終了

document.domain セッターを使うと、デベロッパーが同一オリジン ポリシーを緩和できますが、これによって私たちが維持しようとしている根本的なセキュリティ境界が複雑になり、Spectre 後の Chromium のプロセスモデル変更の障害にもなります。現在、これは Origin-keyed エージェント クラスタを通してオプトインできます。

今回の Chrome のリリースでは、1 つの機能が削除されます。

# RTCPeerConnection の getStats() メソッドから統計オブジェクト track と stream を削除

RTCPeerConnection の getStats() メソッドは、type == "track" または "stream" の統計オブジェクトを返さなくなります。Chrome 112 で削除されますが、逆トライアル（前述）によってこれらの指標の利用期間を Chrome 115 まで延長できます。