Google I/O 2021 での WebGL を利用したマップ機能のベータ版リリースの発表に備え、Google Maps Platform チームは、2012 年からの Google Cloud パートナーである Ubilabs と協力して、3D レンダリングを地図に導入すると実現できることをデベロッパーに紹介するためのデモを作成しました。最初のデモ「Google Maps Platform WebGL-powered Maps Features（Google Maps Platform WebGL を利用したマップ機能）」は、各 WebGL 機能とそれらを効果的に使用する方法をデベロッパー向けに詳しく紹介しています。
デベロッパー向けのデモでは、WebGL を利用したマップ機能の活用方法を Google Maps Platform デベロッパーに紹介しています。
2 番目のデモ「Travel with Next Generation Maps（次世代マップを活用した旅行）」では、架空の旅行アプリを例にして、Google Maps Platform の新しい 3D 機能でマッピング エクスペリエンスがどのように変容するかを全体像として見ることができます。
このプロジェクトに携わった Ubilabs のソフトウェア エンジニアである Martin Schuhfuss 氏は、2019 年の Google I/O で Google Maps Platform エンジニアリング リードの Travis McPhail と話したことを覚えています。その内容は、Google Maps Platform チームが一部の API で検討している変更と、ベクトル地図や 3D コンテンツをサポートするための取り組みについてでした。そして 2021 年。Schuhfuss 氏は Google I/O 2021 向けに Google Maps Platform の新しい WebGL 機能を紹介するデモの作成に向けて、Google Maps Platform チームとの打ち合わせに参加することになりました。信頼できる Google Cloud パートナーとして、Ubilabs はそれら機能の初期ユーザーに任命されていました。初期段階にある機能の常として、開発プロセスが進行する中、デバッグや初期ドキュメントの作成が必要になる可能性がありました。
Ubilabs の共同創業者かつ開発責任者であり、Google Maps Platform の Google Developer Expert である Martin Kleppe 氏も、プロジェクト マネージャーやデザイナー、その他 3 名のデベロッパーとともにプロジェクトに取り組みました。
Schuhfuss 氏は次のように語っています。「私たちはインターネットでの地図のユースケース、特に 3D のシーンで興味深いものを探しました。小規模なテスト版を作成し、自分たちに何ができるかを試していました。しかし、当時はドキュメントすら存在しませんでした。」
Ubilabs はデモのうち 1 つをデベロッパー向けとし、新しい機能について順を追って説明するとともに、コードサンプルを盛り込んで使用方法を紹介することにしました。2 番目のデモである旅行アプリは、航空便での移動、タクシー乗車、ホテルの検索、旅先での食事という場面に当てはめて新しい機能を紹介しています。Schuhfuss 氏は、WebGL ベータ版機能の初期ユーザーとして学んだすべてを効果的に要約した、ユーザー向けのデモ案内文を作成しました。そのテキストの大半は、機能を初めて試す他のユーザー向けにドキュメントにまとめられました。
Schuhfuss 氏は次のように語っています。「各機能について、できるようになったこと、そしてそれがどのように表示されるのかを示すのに最適な Google Maps Platform の使い方は何か。チーム内で自問を繰り返しました。そして、ある都市を訪れる旅の過程を、初めから終わりまで表現する旅行デモを作成することにしました。」
デベロッパーは真上から見下ろした、北が上になった 2D の地図表示に慣れています。そのため、Schuhfuss 氏は、どんな場面でも 3 次元機能を利用してカメラを動かし、地図に情報を追加できる仕組みの紹介に力を入れました。たとえば、以下のスクリーンショットでは、地図にシンプルな傾斜と回転を追加するだけで、エクスペリエンス全体がいかに変化するかがわかります。
Kleppe 氏は次のように説明します。「WebGL 機能の基盤をなすテクノロジーは、GPU による高速レンダリング サービスを使用します。ユーザーはマシンのグラフィック カードを使って建物を 3D レンダリングし、3D オブジェクトを空間に配置できます。以前は追加のレイヤとして地図上にデータを表示できるだけでしたが、現在では新たなレベルの制御が可能になりました。これにより、街の景色を見るような没入型エクスペリエンスを実現できます。」
まず、チームは小規模なデモを作成し、次にそれらをクリックして詳細を見られる大規模なデモに組み込みました。意図したとおりに機能しないものがあると、Ubilabs はトラブルシューティングを試み、Google Maps Platform エンジニア チームと協力して問題を修正しました。あるケースでは、Schuhfuss 氏が 3 つの異なるオブジェクトをあるシーンに追加すると、3 番目のオブジェクトは常に数秒後に消え、2 番目のオブジェクトはさらに数秒後に消えました。Ubilabs は、この問題に関するフィードバックを Google Maps Platform エンジニア チームと共有しました。同チームは次のリリースで問題を解決し、このサービスをユーザー向けに改善できました。
Schuhfuss 氏は次のように述べています。「私はデバッグに時間をかけ、起きている現象を把握しようとしました。建物の背後に隠れるようにレンダリングするものをオクルージョン（手前にある物体が背後にある物体を隠す状態）できるようにするには、WebGL コンテキストを共有する必要があります。WebGL はグラフィック カードと通信でき、小さな状態の変化の影響を受けやすいインターフェースです。」
Schuhfuss 氏は、緯度と経度による座標の把握と算出とは別に、かなりシンプルな Three.js 機能が残りの開発に必要であることがわかりました。同チームは Google Maps Platform チームと定期的に連絡を取り、進捗状況を確認し合いし、技術的な問題や更新に対処しました。
Ubilabs は各デモの締めくくりに、デベロッパーが WebGL 機能で作成できるものとして、目を引く機能を紹介しました。
「旅行デモの最後のページは一番のお気に入りです」と Schuhfuss 氏は言います。氏は Google I/O の数日前にそのページを完全に再構築しました。「私が気に入っているのは、カメラを回転させたときのテキストラベルの動作と、建物が隠れるとテキストの下に小さなステムが表示されることです。」
デベロッパー向けのデモの最後のページでは、ユーザーに「地図を再定義する」ことを推奨しており、埋め込みの動画や花火が表示されます。
Schuhfuss 氏は次のように語ります。「次に気に入っているのは花火です。動画を埋め込むことができ、どこかに表示したくて港にビデオウォールを構築しました。開発の途中では、リック・アストリーの曲も再生されていたようです。」
「通りが表示された基本地図と、ビジネス情報を描画するレイヤ、ルートを計算するための追加 API など、さまざまなデータソースを組み合わせることができます。さらに、その上に独自の情報を配置できます。API のデータセットだけではありません。自分のデータを世界の抽象的なビューにいつでも自由に統合できます。」
さらに、Schuhfuss 氏は、slack ワークスペースの Three.js コミュニティも運営しており、オンラインで驚きの声が多数寄せられたことに加えて、「ユーザーによるこうした機能のユースケースを見るのを本当に楽しみにしています。」とも述べています。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。
以下の変更は、7 つのフェーズに分け、オリジン トライアルのフィードバックを待ちながら、時間をかけて徐々にロールアウトする予定です。
削減の準備
フェーズ 1: Chrome 92 から（2021 年 7 月 20 日）推奨される対応（CTA）: サイトの使用方法を監査し、移行が必要になる可能性がある箇所を把握してください。 M92 より、navigator.userAgent、navigator.appVersion、navigator.platform へのアクセスに関する警告を DevTools に表示します。
navigator.userAgent
navigator.appVersion
navigator.platform
削減のロールアウト
フェーズ 5: Chrome 107CTA: サイトで削減版のデスクトップ UA 文字列と関連する JS API との互換性を確保してください。確保できない場合は、UA Client Hints に移行します。 削減版のデスクトップ UA 文字列と関連する JS API（navigator.userAgent、navigator.appVersion、navigator.platform）のロールアウトを開始します。これがロールアウトされると、デスクトップのオペレーティング システムで、デプリケーション トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。
削減の完了
Google Cloud Next（2021 年 10 月 12～14 日）の開催まであと 1 か月を切りました。この無料のフラッグシップ イベントで皆様にお会いできるのを心待ちにしております。イベントの全カタログを公開いたしましたので、ご自身にぴったりのコンテンツをお探しください。エキスパートによるライブ Q＆A をはじめ、ブレイクアウト セッション、没入型のデモ、Google Cloud の実際のユースケースをご覧いただけます。今年は、カスタム再生リストを作成して、視聴するセッションをパーソナライズすることや、見逃さないようにリマインダーやカレンダー通知を設定することもできます。
Next '21 に参加して、クラウドの現在と未来に関する情報を入手しましょう。業界をリードするデータや分析から、最適化、モダナイゼーション、セキュリティ、サステナビリティまで、Google Cloud をさらにオープンかつ高速で、柔軟性と信頼性の高いものにするために、Google が世界最大のプライベート ネットワークをどのように拡張しているかをご覧ください。11 のトラックにわたる 130 以上のセッションは、トラックやカテゴリなどでフィルタしたり、お気に入りのセッションをブックマークして後から視聴したりすることができます。
毎日、Google Cloud CEO の Thomas Kurian や Google Cloud 技術インフラストラクチャ部門シニア バイス プレジデント Urs Hölzle などの業界リーダーによるライブ配信と基調講演をご覧いただけます。一部のセッションをご紹介します。
Google Cloud の Twitter で、クラウドのエキスパートやエグゼクティブが作成した個人的な再生リストを紹介していますのでぜひチェックしてください。また、再生リスト作成ツールを使って、ご自身で作成した再生リストを知り合いや同僚と共有しましょう。
情報を入手し、刺激を受けて、専門知識を広げるために、ぜひご参加ください。今すぐ登録して、あなただけの Next '21 を計画しましょう。
Google は、 スタートアップを対象としたオンライン アクセラレーター プログラム「Google for Startups Accelerator Class 4 」を実施します。2021 年 9 月 16 日（木）より参加スタートアップの応募を開始し、2022 年 2 月 よりプログラムを開始いたします。詳細なスケジュールについては プログラムのウェブサイトをご確認ください。
Google for Startups Accelerator では、SDGsに沿った持続可能な産業化の促進、AIやIoTなどの技術を活用することで、経済発展と社会的課題の解決を実現するスタートアップを支援しています。
過去に日本のアクセラレーター プログラムに参加した Eco-Pork は、養豚とテクノロジーを繋ぐことで、養豚生産者の労働生産性の向上と共に、透明性の高い安心な食糧供給を統合的に支援しています。 また、同じく過去の ヨーロッパのアクセラレーターに参加した mDoc は、慢性疾患のある人々がアプリを通じて治療を受けられるように支援することで、医療と健康の分野に取り組んでいます。
このプログラムは、すでに商品またはサービスを市場に投入し、市場的価値が見込まれ、スケールする将来性があるスタートアップを対象に、これからの成長に備えるためのサポートを提供します。テクノロジーを活用した社会、経済、環境といった様々な分野の問題解決への取り組みを加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。
ぜひご応募ください。
Serverless Expeditions がお送りする動画ミニシリーズ Serverless Migration Station は、Google Cloud で実行しているアプリケーションを最新化し、サーバーレス コンピューティング プラットフォームに移行するデベロッパーをサポートすることを目的としています。これまでのエピソードでは、従来の古い App Engine（標準環境）サービスを、Cloud Datastore などの Google Cloud の新しい同等なスタンドアロン機能に移行する方法を紹介しました。今回のエピソードは、App Engine から完全に移行し、アプリをコンテナ化して Cloud Run で実行するという点で少し異なります。
ここ 10 年ほどで、業界がアプリケーションのデプロイ メカニズムとしてコンテナ化に向かっていることに、疑問の余地はほとんどありません。しかし、初期の App Engine デベロッパーは、のちに柔軟な環境が利用できるようになるまで、Docker やコンテナを使うことはできませんでした。現在のデベロッパーは、ますますオープンになっている Google Cloud からさまざまな選択肢を選択できます。Google は App Engine の長期サポートを表明しており、ユーザーにとってアプリのコンテナ化は必須ではないので、この移行は任意です。そのため、主にアプリのデプロイ戦略にコンテナ化を追加し、明示的に Cloud Run への移行を考えているデベロッパー向けの内容になります。
アプリのコンテナ化について考えている方のために、動画ではその主な理由について説明しています。開発言語やバイナリの利用など、従来のサーバーレスの制約を受けることはありません（柔軟性）。コード、依存関係、コンテナのビルドとデプロイの手順が変わらなければ、同じイメージを確実に再作成できます（再現性）。必要に応じて、アプリケーションを他の場所にデプロイしたり、動作していた以前のイメージにロールバックしたりすることができます（再利用性）。さらに、アプリをホストする場所には、さまざまな選択肢があります（移植性）。
従来の App Engine サービスは、バンドルされた一連の独自 API を通して利用します。ご想像どおり、このサービスは Cloud Run では利用できません。そのため、アプリをコンテナ化して Cloud Run で実行するには、その準備が整っている必要があります。これは、Google Cloud の同等なスタンドアロン機能か、他のサードパーティの代替機能に移行された状態を指します。たとえば、最近のエピソードでは、Datastore にアクセスするために、App Engine の ndb を Cloud NDB に移行する方法について説明しています。
このような移行の動画を公開し始めたのは最近のことですが、デベロッパーはすでにコードサンプルや Codelab チュートリアルにアクセスできるようになっており、さまざまな移行が行われています。今回の動画では、従来のサービスから切り離され、Cloud Run でコンテナ化する準備が整った Python 2 と 3 のサンプルアプリを紹介します。Datastore にアクセスする Python 2 App Engine アプリでは Cloud NDB を、Python 3 ユーザーは Cloud Datastore を使うことになるでしょう。これが移行の開始点になります。
ここで行うのは実行プラットフォームの切り替え「だけ」であるため、アプリケーション コード自体は変更しません。必要になる移行は、アプリの設定を App Engine から Cloud Run に変更することだけです。具体的には、app.yaml、appengine_config.py、lib フォルダなどの App Engine アーティファクトは、Cloud Run で使うことはないため、削除します。また、コンテナをビルドするため、Dockerfile を導入します。app.yaml ファイルでこれよりも複雑な設定が行われているアプリでは、Cloud Run で同等の機能を持つ service.yaml ファイルが必要になります。この場合、app.yaml を service.yaml に変換するツールを使うと便利です。ベスト プラクティスに従うなら、.dockerignore ファイルも追加します。
app.yaml
appengine_config.py
lib
Dockerfile
service.yaml
.dockerignore
App Engine と Cloud Functions はアウトソーシングのようなもので、Google Cloud が自動的に gunicorn などのデフォルトの HTTP サーバーを提供します。Cloud Run では、ユーザーがコンテナ イメージを提供してサーバーにバンドルしなければならないので、もう少し自作度が高くなります。この場合、下のスクリーンショットのように、明示的に gunicorn が選択され、既存の requirements.txt に記載された必須パッケージ ファイルの最上部に追加されます。また、最後のステップとして gunicorn を起動してアプリのサービスを開始する Dockerfile も示しています。Python 2 の Dockerfile との唯一の違いは、a）Cloud Datastore ではなく Cloud NDB パッケージ（google-cloud-ndb）が必須である点と、b）Python 2 ベースイメージから始める点です。
gunicorn
requirements.txt
google-cloud-ndb
Python 3 の requirements.txt と Dockerfile
デベロッパーの皆さんに移行手順を説明するため、動作するアプリ（START）から始めて、必要なアップデートをし、最終的に動作するアプリ（FINISH）を完成させます。今回の移行では、Python 2 サンプルアプリの START は Module 2a のコードで、FINISH は Module 4a のコードになります。同じように、Python 3 アプリの START は Module 3b のコードで、FINISH は Module 4b のコードです。このようにすれば、移行がうまくいかなくても、いつでも START にロールバックしたり、自分のソリューションと FINISH を比較したりできます。自分のアプリケーションでこの移行を検討している方には、サンプルアプリで試してから、自分のアプリについて検討することをお勧めします。動画に加えて、順を追ってこのエクササイズについて説明する Codelab もあるので、ガイダンスとしてお使いください。
すべての移行モジュール、動画（公開されている場合）、Codelab チュートリアル、START と FINISH のコードなどは、移行リポジトリにあります。近いうちに、Java 8 などの以前のランタイムについても説明したいと考えているので、ご期待ください。Module 5 でも、引き続き App Engine から Cloud Run への移行について説明しますが、コンテナ、Docker、Dockerfile についての知識がなくても大丈夫です。開発ワークフローを最新化し、コンテナと CI/CD パイプライン作成などのベスト プラクティスを活用することは、常に単純とは限りません。このようなコンテンツが、その方向に進む皆さんのお役に立つことを願っています。
Google は、ウェブでユーザーの個人情報を守るために、アプリやサービスへのログインをデフォルトで安全なものにする取り組みを続けています。先日は、その実現に向けて、Identity API ファミリーの新たな一員である Google Identity Services についてお知らせしました。これは、複数の ID サービスを 1 つのソフトウェア開発キット（SDK）にまとめたものです。今回は、ログイン方法を減らし、ユーザー エクスペリエンスをシンプルにする取り組みの一環として、ウェブアプリ向けに提供していた JavaScript ベースの Google プラットフォーム ライブラリのサポートを 2023 年 3 月 31 日をもって完全に終了することをお知らせします。
サポートの終了は、Google Sign-in JavaScript ライブラリを使っているウェブアプリにのみ影響します。現在のウェブページで Google プラットフォーム ライブラリ（apis.google.com/js/platform.js）を読み込んでいる場合は、影響を受けるので、新しい Sign In With Google クライアント ライブラリに移行する必要があります。
apis.google.com/js/platform.js
アプリやプラットフォームでは、Google プラットフォーム ライブラリを使ってユーザーのログイン認証のみのフロー、データ共有のための認可フロー（ユーザーのカレンダーや写真の共有など）、またはその両方を同時にサポートできます。今回の移行は、認証フローと認可フローの両方が対象になります。
アプリやプラットフォームでは、Google が提供する複数の認証方法と認可方法を使うこともできます。以下は、今回のサポートの終了のお知らせには影響されません。
ユーザーのログインを改善するという継続的な取り組みの一環として、Sign In With Google 用の新たな JavaScript ライブラリをリリースしました。これまでの認証や認可の機能に加えて、ユーザーの視認性や信頼性を向上させ、ログインの手間を減らすことができる新たなユーザー エクスペリエンスも提供します。
新しい JavaScript ライブラリへの移行にはたくさんのメリットがありますが、その一部を紹介します。
ユーザーには次のように表示されます。
詳細は、Google Identity Services のプロダクトのお知らせをご覧ください。
詳しい情報は、デベロッパー サイトに掲載されています。技術サポートを受けたい方は、Stack Overflow で google-signin タグを確認してください。提案やフィードバックは、gis-migration-feedback@google.com にお送りください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 8 月 26 日の時点で Chrome 94 はベータ版です。
既存のメディア API（HTMLMediaElement、Media Source Extensions、WebAudio、MediaRecorder、WebRTC）は高レベルで、特定の用途に特化しています。低レベルのコーデック API は、遅延の影響を受けやすいゲームのストリーミング、クライアント側のエフェクトやコード変換、ポリフィル対応のメディア コンテナのサポートなど、新たな用途に適しています。JavaScript や WebAssembly によるコーデック実装のように、ネットワークや CPU のコストが増加することはありません。
HTMLMediaElement
WebAudio
MediaRecorder
WebCodecs API は、すでにブラウザに組み込まれているメディア コンポーネントをプログラマーが利用できるようにすることで、このような不足を解消します。具体的には、次のような内容です。
この機能は Chrome 93 でオリジン トライアルを終えており、現在はデフォルトで有効です。詳しくは、WebCodecs による動画処理をご覧ください。
WebGPU API は、ウェブ用の WebGL と WebGL2 グラフィックス API の後継です。「GPU コンピュート」などの最新機能や、GPU ハードウェアへの低オーバヘッド アクセス、パフォーマンスや予測可能性の向上などが導入されています。既存の WebGL インターフェースはイメージの描画用に設計されたもので、かなりの労力をかけなければ他の用途の計算は行えませんでしたが、その点が改善されています。
WebGPU は、Direct3D 12、Metal、Vulkan といった最新のコンピュータ グラフィックス機能を公開し、グラフィックス プロセッシング ユニット（GPU）で行われるレンダリングや計算の操作をします。以前のテクノロジーと比べた場合の WebGPU の利点は以下のとおりです。
この機能は、Chrome 99 での導入を目指して、Chrome 94 からオリジン トライアルが始まります。詳しくは、WebGPU で最新の GPU 機能にアクセスするをご覧ください。
ユーザーの操作に的確に応答し、時間が経っても応答性が低下しないウェブアプリを構築するのは困難です。応答性を阻害する主な原因の 1 つがスクリプトです。インクリメンタル サーチ機能について考えてみてください。この機能を搭載したアプリは、ユーザーの入力に追いつきつつ、結果をフェッチして表示する必要があります。その際、アニメーションなど、ページで起きていることは考慮されませんが、アニメーションはスムーズにレンダリングする必要があります。
通常この問題には、メインスレッドの作業を分割してスケジュールすることで対処できます。具体的には、適切なタイミングで作業を非同期的に実行します。しかし、このアプローチ自体にも問題があります。たとえば、デベロッパーがどのように優先度を設定しようと、メインスレッドでは時間の奪い合いが生じています。メインスレッドはデベロッパーが設定した優先度を認識しないだけでなく、fetch() 操作やガベージ コレクションといったブラウザのタスクも行っているからです。
fetch()
scheduler.postTask() メソッドを使うと、デベロッパーが OS のブラウザのスケジューラで 3 段階の優先度（user-blocking、user-visible、background）を指定してタスク（JavaScript のコールバック）をスケジュールできるようになるので、このスケジュールのジレンマを解消できます。また、動的にタスクをキャンセルしたり、優先度を変更したりできる TaskController インターフェースも公開されます。
scheduler.postTask()
TaskController
この機能は Chrome 93 でオリジン トライアルを終えており、現在の Chrome ではデフォルトで有効です。その他の新しいオリジン トライアルや完了したオリジン トライアルの一覧については、以下のオリジン トライアルのセクションをご覧ください。
このバージョンの Chrome には、以上の項目の他に、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
Chrome では、新しい HTTP ステータス コードである 103 Early Hints のテストが行われています。これは、早い段階でサブリソースをプリロードするためのものです。 <link rel=preload> などの link ヘッダーを含む 103 レスポンスを受け取ると、Chromium は最終的なレスポンスを受け取る前に、指定されたリソースのプリロード（またはプリコネクトやプリフェッチ、あるいはそのすべて）を試みます。ウェブ デベロッパーはこの方法を使って、アプリやサイト、ページを最適化できます。
<link rel=preload>
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
このアップデートにより、CanvasRenderingContext2D オブジェクトと ImageData オブジェクトのデフォルトのカラースペースが sRGB であることが正式に明文化されます。そのため、CanvasRenderingContext2D インターフェースが完全にカラー マネジメントされる（すべての入力が描画キャンバスのカラースペースに変換される）ことが明確になります。これまでは、上記の動作は慣習上のものであり、明文化はされていませんでした。今回のアップデートで、以下の点が変更されます。
CanvasRenderingContext2D
ImageData
現在、CanvasRenderingContext2D で表示されるコンテンツは、sRGB カラースペースに限定されていますが、このカラースペースには最新のディスプレイやカメラほどの機能はありません。今回の機能で、Display P3 カラースペースを使用する CanvasRenderingContext2D オブジェクトを作成できるようになります。さらに、CanvasRenderingContext2D の色の動作に関して、いくつかの曖昧だった点が明確になります。
VirtualKeyboard インターフェースには、仮想キーボードの表示や非表示のタイミングをコントロールするメソッドやプロパティが含まれています。また、仮想キーボードがページのコンテンツを遮ると、仮想キーボードのサイズを含むイベントが発行されます。仮想キーボードは画面に表示されるキーボードで、ハードウェア キーボードが利用できない場合の入力に使います。
VirtualKeyboard
ハードウェア キーボードとは異なり、仮想キーボードは想定される入力に合わせて形状を変えることができます。デベロッパーは、inputmode 属性によって仮想キーボードの表示形状をコントロールできますが、仮想キーボードの表示や非表示のタイミングのコントロールには制限がありました。
inputmode
transform-style: preserve-3d と perspective プロパティが仕様に準拠します。preserve-3d プロパティを使うと、子要素を親の 3D シーンに追加できます。また、perspective プロパティは子要素に透視変換を適用します。この変更が行われる前の Chromium は、両方の効果を DOM ツリーではなく内包するブロック階層に基づいて適用し、変換関連のプロパティがない要素にも効果を拡張できるようになっていました。
Chrome は、flex-basis プロパティと flex 省略記法の値として、キーワード content、min-content、max-content、fit-content をサポートします。content キーワードを使うと、flex-basis と優先されるサイズ プロパティ（width または height）の両方が auto である場合のように、flex のベースサイズがデフォルトのサイズ計算ルールを使用します。flex-basis が auto の場合、メインの軸の長さとして指定された width や height は、すべて無視されます。その他のキーワードは通常と同じで、flex のベースサイズを細かく指定できます。
flex-basis
flex
content
min-content
max-content
fit-content
width
height
auto
これまでは、レスポンシブ レイアウトでコンテナに対して display:flex を追加または削除する場合、個々の項目で値を追加または削除しなければならない場合がありました。content の導入により、それが不要になることもあります。
display:flex
scrollbar-gutter プロパティは、スクロールバーのガター（スクロールバーを表示するために予約されている領域）の有無をコントロールします。これにより、コンテンツが増加した場合にレイアウトが変わることを防ぎつつ、スクロールが不要な場合に余分な領域が表示されないようにすることができます。 スクロールバーの有無自体は、overflow プロパティによって決まる点に注意してください。従来型のスクロールバーを使うかオーバーレイ スクロールバーを使うかを決めるのは、ユーザー エージェントです。デベロッパーは、このプロパティを使うことで、ブラウザが提供するスクロールバーとレイアウトとの相互作用を細かくコントロールできます。
scrollbar-gutter
overflow
この API を使うと、MediaStreamTracks によってローメディアを操作できます。操作できるのは、カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力などです。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。サンプルのユースケースとして、おかしな帽子、物体のリアルタイム検出や注釈付けがあります。
MediaStreamTracks
Flash が削除されたことで、navigator.plugins と navigator.mimeTypes から何かを返す必要はなくなりました。この API は、主に以下の目的で使われていました。
navigator.plugins
navigator.mimeTypes
この API を使って PDF ビューアのサポートを確認しているサイトもあります。今回の変更により、この配列は PDF ビューア プラグインの標準リストを含む固定のリストを返すようになります。
これによって API が削除または変更されることはありません。2 つの既存 API で固定の配列が返されるようになるだけです。
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.4 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Chrome がウェブ公開サンプリング プロファイラをサポートし、クライアント JavaScript の実行時間を計測できるようになります。実際のユーザーから JavaScript のプロファイルを収集すると、パフォーマンスの低下が観測された場合のデバッグに役立てることができます。面倒な手動インストルメンテーションをする必要はありません。
このバージョンの Chrome では、以下のサポートの終了機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
サードパーティ コンテキストでの WebSQL が非推奨となります。この機能の削除は、Chrome 97 で行われる予定です。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web Storage や Indexed Database を推奨しています。
デベロッパーは、WebSQL 自体が非推奨であり、利用率が十分低くなった際に削除される予定であることを想定する必要があります。
サブリソースのプライベート ネットワーク リクエストは、セキュア コンテキストからのみ開始できます。プライベート ネットワーク リクエストとは、パブリック ネットワークで開始され、プライベート ネットワークを対象とするリクエストです。これには、インターネットから イントラネット へのリクエストや、イントラネット ループバックなどが含まれます。
今回の対応は、プライベート ネットワーク アクセスの完全実装に向けた最初の一歩です。ローカル ネットワーク内やユーザーのデバイス上で実行されているサーバーは、ウェブに充実した機能を公開しますが、これは危険な場合もあります。プライベート ネットワーク アクセスで提唱されている一連の変更は、サーバーに外部エンティティとの通信をオプトインさせることで、このようなサーバーへのリクエストによる影響を制限します。
このオプトインが意味を持つためには、クライアントのオリジンが認証されていることをサーバーが確認できなければなりません。これを実現するため、セキュア コンテキストのみに外部リクエストの実行を許可します。
ExtensionFeedItemService
AdGroupExtensionSettingService
CampaignExtensionSettingService
CustomerExtensionSettingService
FeedService
FeedItemService
FeedMappingService
AdGroupFeedService
CampaignFeedService
CustomerFeedService
GoogleAdsService
BatchJobService
