公開日: 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
Namespace オブジェクトに追加し、現在のコードがスピンロックを実行していることを 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 を使用して検出)。
- バージョンの更新や別の接続でのトランザクションをブロックするウェブロックまたは 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
を含めても効果はありません。このページは、パソコン プラットフォームでトリガーされる初回実行エクスペリエンスと重複するため、削除されます。