公開日: 2024 年 1 月 15 日
特に明記しない限り、以下の変更は Android、ChromeOS、Linux、macOS、Windows 版の最新の Chrome ベータ版チャネル リリースに適用されます。ここに記載されている機能について詳しくは、記載されているリンク先または ChromeStatus.com のリストをご覧ください。Chrome 133 は 2024 年 1 月 15 日時点でベータ版です。最新バージョンは、パソコンの Google.com または Android の Google Play ストアからダウンロードできます。
CSS と UI
このリリースでは、CSS と UI に 7 つの新機能を追加しました。
CSS の高度な attr() 関数
CSS レベル 5 で指定されている attr() の拡張を実装します。これにより、<string> 以外の型が許可され、すべての CSS プロパティで使用できるようになります(疑似要素 content の既存のサポートに加えて)。
詳しくは、CSS attr() のアップグレードをご覧ください。
CSS :open 疑似クラス
:open 疑似クラスは、開いている状態の <dialog> と <details> に一致し、選択ツールがあり、選択ツールが表示されているモードでは <select> と <input> に一致します。
CSS スクロール状態コンテナのクエリ
コンテナクエリを使用して、スクロール状態に基づいてコンテナの子孫にスタイルを適用します。
クエリ コンテナは、スクロール コンテナ、またはスクロール コンテナのスクロール位置の影響を受ける要素です。クエリ可能な状態は次のとおりです。
stuck: スティッキーに配置されたコンテナがスクロール ボックスのいずれかの端に固定されています。snapped: スクロール スナップが適用されたコンテナが、現在水平方向または垂直方向にスナップされています。scrollable: スクロール コンテナをクエリされた方向にスクロールできるかどうか。
新しい container-type: scroll-state により、コンテナをクエリできるようになりました。
#sticky {
position: sticky;
container-type: scroll-state;
}
@container scroll-state(stuck: top) {
#sticky-child {
font-size: 75%;
}
}
詳しくは、CSS scroll-state() をご覧ください。
CSS text-box、text-box-trim、text-box-edge
テキスト コンテンツの最適なバランスを実現するために、text-box-trim プロパティと text-box-edge プロパティを text-box ショートカット プロパティとともに使用すると、テキストの縦方向の配置をより細かく制御できます。
text-box-trim プロパティは、トリミングする側(上または下)を指定し、text-box-edge プロパティはエッジのトリミング方法を指定します。
これらのプロパティを使用すると、フォント メトリックを使用して垂直方向の間隔を正確に制御できます。詳しくは、CSS text-box-trim をご覧ください。
popover 属性の hint 値
Popover API は、popover 属性の 2 つの値(auto と manual)の動作を指定します。この特徴は、3 番目の値 popover=hint を記述します。ヒントは、ほとんどの場合「ツールチップ」タイプの動作に関連付けられますが、動作が若干異なります。主な違いは、ネストされたポップオーバーのスタックを開くときに、hint が auto に従属することです。そのため、既存の auto ポップオーバーのスタックが開いたまま、無関係な hint ポップオーバーを開くことができます。
典型的な例は、<select> 選択ツールが開いている(popover=auto)状態で、ホバーによってトリガーされるツールチップ(popover=hint)が表示されている場合です。この操作で <select> 選択ツールは閉じません。
ポップオーバーのトリガー要素とアンカー要素の配置を改善
popover.showPopover({source}) を使用して、ポップオーバー間のトリガー要素の関係を設定するための命令型の方法を追加します。トリガー要素の関係により、暗黙的なアンカー要素の参照を作成できるようにします。
呼び出し元内にネストされたポップオーバーを再び呼び出さない
次のケースでは、ボタンをクリックするとポップオーバーが適切にアクティブになりますが、その後ポップオーバー自体をクリックしてもポップオーバーが閉じないようにする必要があります。
<button popovertarget=foo>Activate
<div popover id=foo>Clicking me shouldn't close me</div>
</button>
以前は、ポップオーバーのクリックが <button> にバブルし、呼び出し元がアクティブになり、ポップオーバーが閉じられました。この動作は、想定どおりに変更されました。
ウェブ API
Animation.overallProgress
タイムラインの性質に関係なく、反復処理全体でアニメーションがどの程度進んでいるかを、デベロッパーが便利で一貫した方法で把握できるようにします。overallProgress プロパティがない場合、アニメーションの反復回数と、アニメーションの currentTime が合計時間の割合(スクロール駆動アニメーションの場合)か絶対時間量(時間駆動アニメーションの場合)かを考慮して、アニメーションがどの程度進んだかを手動で計算する必要があります。
Atomics オブジェクトの pause() メソッド
pause() メソッドを Atomics 名前空間オブジェクトに追加し、現在のコードがスピンロックを実行していることを CPU にヒントします。
スクリプトの CSP ハッシュ レポート
複雑なウェブ アプリケーションでは、セキュリティ上の理由から、ダウンロードしたサブリソースを追跡することがよくあります。
特に、今後の業界標準とベスト プラクティス(PCI-DSS v4 など)では、ウェブ アプリケーションがダウンロードして実行するすべてのスクリプトのインベントリを保持することが義務付けられています。
この機能は CSP と Reporting API を基盤として、ドキュメントが読み込むすべてのスクリプト リソースの URL とハッシュ(CORS/同一オリジン用)を報告します。
DOM の状態を保持した移動
要素の状態をリセットせずに DOM ツリー内で要素を移動できる DOM プリミティブ(Node.prototype.moveBefore)を追加します。
削除と挿入ではなく移動する場合、次のような状態が保持されます。
<iframe>要素は読み込まれたままになります。- アクティブな要素はフォーカスされたままになります。
- ポップオーバー、全画面、モーダル ダイアログは開いたままになります。
- CSS の遷移とアニメーションは続行されます。
<area> で attributionsrc 属性を公開
<area> の attributionsrc 属性の公開を、属性が公開されていなかった場合でも、属性の既存の処理動作に合わせます。
また、<area> はファーストクラスのナビゲーション サーフェスであり、Chrome ではすでに <a> と window.open の他のサーフェスでサポートされているため、<area> でこの属性をサポートすることは理にかなっています。
要素のタイミングと LCP で、粗いクロスオリジン renderTime を公開する(Timing-Allow-Origin に関係なく)
要素のタイミングと LCP のエントリには、画像またはテキストがペイントされた最初のフレームに合わせて renderTime 属性が設定されています。
現在、この属性は、画像リソースに Timing-Allow-Origin ヘッダーを要求することで、クロスオリジン画像に対して保護されています。ただし、この制限は簡単に回避できます(同じフレームに同一オリジンとクロスオリジンの画像を表示するなど)。
この制限が混乱の原因となっているため、この制限を削除し、ドキュメントがクロスオリジン分離されていない場合は、すべてのレンダリング時間を 4 ms ずつ粗くすることを予定しています。これは、クロスオリジン画像に関する有用なデコード時間情報を漏洩させないようにするには十分な粗さです。
responseStart を元に戻し、firstResponseHeadersStart を導入
103 早期ヒントが有効になっている場合、レスポンスには 2 つのタイムスタンプがあります。
- 早期ヒントが届いたとき(103)
- 最終的なヘッダーが届いたとき(200 など)
Chrome 115 で firstInterimResponseStart がリリースされ、これらの 2 つのタイムスタンプを測定できるようになった際、responseStart(Time to First Byte(TTFB) で使用)の意味も「最終的なヘッダー」に変更されました。これにより、この一般的な指標に同様の変更を加えなかったブラウザやツールでウェブ互換性の問題が発生しました。
Chrome 133 では、この互換性の問題を解決するために、この responseStart の変更を元に戻し、代わりに firstResponseHeadersStart を導入して、TTFB の元の定義を維持しながら、サイトが最終ヘッダーまでの時間を測定できるようにしました。
FileSystemObserver インターフェース
FileSystemObserver インターフェースは、ファイルシステムの変更をウェブサイトに通知します。サイトは、ユーザーが以前に権限を付与したファイルとディレクトリの変更を、ユーザーのローカル デバイスまたはバケット ファイル システム(オリジンの非公開ファイル システム)で検出し、変更タイプなどの基本的な変更情報を通知します。
省エネモードでのフリーズ
省エネモードが有効になっている場合、Chrome は、非表示でサイレントの状態が 5 分を超えている「ブラウジング コンテキスト グループ」をフリーズします。ただし、そのグループ内の同じオリジンのフレームのいずれかのサブグループが CPU 使用率しきい値を超えている場合を除きます。
- 音声またはビデオ会議機能が提供されているタブ(マイク、カメラ、画面/ウィンドウ/タブのキャプチャ、またはオープンな RTCDataChannel かライブの MediaStreamTrack を含む RTCPeerConnection によって検出)。
- 外部デバイスを制御します(WebUSB、Web Bluetooth、WebHID、Web Serial を使用して検出)。
- バージョン アップデートまたは別の接続のトランザクションをブロックする Web ロックまたは IndexedDB 接続を保持します。
フリーズは実行の一時停止です。これは、Page Lifecycle API で正式に定義されています。
CPU 使用率のしきい値は、省エネモードが有効になっているときにバックグラウンド タブの約 10% をフリーズするように調整されます。
複数のインポート マップ
現在、インポート マップは ES モジュールの前に読み込む必要があり、ドキュメントごとに 1 つのインポート マップしか使用できません。そのため、実世界のシナリオでは脆弱で、使用に時間がかかりやすくなります。それより前に読み込まれたモジュールはアプリ全体を破壊します。また、モジュールが多いアプリでは、考えられるすべてのモジュールのマップ全体を最初に読み込む必要があるため、大きなブロック リソースになります。
この機能を使用すると、ドキュメントごとに複数のインポート マップを、一貫した確定的な方法で統合できます。
ストレージ アクセス ヘッダー
認証済みの埋め込みがパーティショニングされていない Cookie をオプトインするための代替方法を提供します。これらのヘッダーは、パーティショニングされていない Cookie が特定のネットワーク リクエストに含まれているかどうか(または含まれている可能性があるかどうか)を示し、サーバーがすでに付与されている「ストレージ アクセス」権限を有効にできるようにします。「storage-access」権限を有効にする別の方法を提供すると、iframe 以外のリソースで使用できるようになります。また、認証済みの埋め込みのレイテンシを短縮できます。
Promise<DOMString> による ClipboardItem の作成をサポート
非同期クリップボード write() メソッドへの入力である ClipboardItem が、コンストラクタで Blob に加えて文字列値を受け入れるようになりました。ClipboardItemData は、Blob、文字列、または Blob または文字列に解決される Promise です。
WebAssembly Memory64
memory64 プロポーザルでは、2^32 ビットを超えるサイズのリニア WebAssembly メモリのサポートが追加されます。新しい命令は提供されませんが、既存の命令が拡張され、メモリとテーブルの 64 ビット インデックスが許可されます。
Web Authentication API: PublicKeyCredential getClientCapabilities() メソッド
PublicKeyCredential getClientCapabilities() メソッドを使用すると、ユーザーのクライアントでサポートされている WebAuthn 機能を特定できます。このメソッドは、サポートされている機能のリストを返します。これにより、デベロッパーはクライアントの特定の機能に基づいて認証エクスペリエンスとワークフローを調整できます。
WebGPU: 1 コンポーネントの頂点形式(および unorm8x4-bgra)
サポートされていないか、古い macOS バージョン(どのブラウザでもサポートされていない)が原因で、WebGPU の最初のリリースには含まれていなかった頂点形式を追加しました。1 コンポーネントの頂点形式では、アプリケーションは必要なデータのみをリクエストできます。以前は、8 ビットおよび 16 ビットのデータ型で 2 倍以上リクエストする必要がありました。unorm8x4-bgra 形式を使用すると、同じシェーダーを維持しながら BGRA エンコードの頂点カラーを読み込むのが少し便利になります。
Web Cryptography API の X25519 アルゴリズム
「X25519」アルゴリズムには、[RFC7748] で指定されている X25519 関数を使用して鍵交換を実行するツールが用意されています。「X25519」アルゴリズム識別子は、SubtleCrypto インターフェースで、実装されたオペレーション(generateKey、importKey、exportKey、deriveKey、deriveBits)にアクセスするために使用できます。
新しいオリジン トライアル
Chrome 133 では、次の新しいオリジン トライアルを有効にできます。
省エネモードでのフリーズをオプトアウトする
このオプトアウト トライアルでは、Chrome 133 でリリースされる省エネモードでのフリーズ動作をサイトがオプトアウトできます。
非推奨と削除
このバージョンの Chrome では、以下の非推奨と削除が行われます。予定されている非推奨化、現在の非推奨化、過去の削除の一覧については、ChromeStatus.com をご覧ください。
このリリースの Chrome では、1 つの機能のサポートが終了します。
WebGPU の maxInterStageShaderComponents の上限を非推奨にする
maxInterStageShaderComponents limit は、複数の要因により非推奨になりました。Chrome 135 での削除予定日。
maxInterStageShaderVariablesでの冗長性: この上限はすでに同様の目的を果たしており、シェーダー ステージ間で渡されるデータの量を制御しています。- わずかな差異: 2 つの上限の計算方法には若干の違いがありますが、この差異は小さく、
maxInterStageShaderVariablesの上限内で効果的に管理できます。 - 簡素化:
maxInterStageShaderComponentsを削除すると、シェーダー インターフェースが効率化され、デベロッパーの複雑さが軽減されます。わずかな違いがある 2 つの個別の上限を管理する代わりに、より適切な名前の包括的なmaxInterStageShaderVariablesに集中できます。
このリリースの Chrome では、2 つの機能が削除されます。
<link rel=prefetch> 5 分ルールを削除
以前は、<link rel=prefetch> を使用してリソースがプリフェッチされた場合、Chrome は再フェッチを回避するために、5 分以内の最初の使用でキャッシュ セマンティクス(max-age と no-cache)を無視していました。Chrome では、この特殊なケースを削除し、通常の HTTP キャッシュ セマンティクスを使用します。
つまり、ウェブ デベロッパーは、<link rel=prefetch> のメリットを享受するには、適切なキャッシュ ヘッダー(Cache-Control または Expires)を含める必要があります。
これは非標準の <link rel=prerender> にも影響します。
初期設定の初回実行タブを介した Chrome ウェルカム ページのトリガーを削除
initial_preferences ファイルの first_run_tabs プロパティに chrome://welcome を含めても、何も起こらないようになりました。このページは、パソコン プラットフォームでトリガーされる初回起動時の動作と重複するため、削除されました。