View Transition API を使用すると、1 つのステップで DOM を更新しながら、2 つの状態間のアニメーション遷移を生成できます。
このような移行は、私を含め、デベロッパーから頻繁にリクエストされていた機能です。適切なデフォルト設定と拡張性およびカスタマイズ性のバランスが取れた方法で実装できたと思います。大変そう思うようですが、デベロッパーのフィードバックがこの機能の設計の鍵となりました。この機能の以前のプロトタイプは柔軟性に欠けており、時間をかけてプロトタイプを試し、フィードバックを提供してくれた皆さんのおかげで、考えが一新されました。ありがとうございました
この機能の理解を深め、デモを試すには、こちらのガイドをご覧ください。ここに記載されていない情報がある場合は、Twitter、Mastodon、またはメールで私にご連絡ください。
現在、View Transition API は Chrome でのみご利用いただけますが、漸進的な機能強化として使用できます。このガイドには、複数のブラウザで使用できるヘルパー関数が含まれていますが、アニメーションが表示されるのはビュー遷移をサポートするブラウザのみです。
この機能は、他のブラウザ ベンダーや独立機関からの情報に基づき、CSS ワーキング グループ内で開発されました。他のブラウザでビュー切り替えが採用されるかどうかや、導入される時期は不明ですが、Mozilla の標準位置と WebKit の標準位置にご注意ください。
だが、まだ終わっていない！
Chrome 111 で導入される機能は最初のリリースにすぎません。すでにすべてのバグが発見されていることを願いますが、問題が見つかった場合は crbug.com で報告してください。その際はデモを縮小してください。ご不明な場合は、Twitter や Mastodon またはメールでご連絡ください。サポートさせていただきます。
このリリースは、全体像の小さな部分ですが、役立つことを期待しています。本日出荷する部品が将来にわたって互換性を持たせるため、この機能の拡張機能のいくつかはすでに描かれています。
ここでは、Google が検討している内容の一部をご紹介します。これらは優先順位の高い順ではありません（多くのユーザーにとって最も重要なのはおそらく最初の質問でしょう）。そのため、どの追加が特に重要かについてのフィードバックをお待ちしています。
ドキュメント間の移行
これは、ほとんどのデベロッパーが次の取り組みを望んでいると思いますが、幸いなことに、すでに取り組みを進めています。
View Transitions API は、同一オリジンのドキュメントで動作するように設計されています。唯一の違いは、startViewTransition が DOM 状態の変化を通知するのではなく、ナビゲーション自体がその変化を通知することです。
chrome://flags/#view-transition-on-navigation フラグの背後でのこのプロトタイプ。非常にシンプルなデモと複雑なデモをご覧ください。
これを進めるには、各ページがどのようにして移行にオプトインするかを把握する必要があります。現時点ではメタタグ <meta name="view-transition" content="same-origin"> を使用していますが、これには CSS のほうが適していると考えられます。また、できる限り JavaScript を記述しなくても、移行元のページの種類を簡単に把握できるようにしたいと考えています。
行うべき作業は山積みで、「迅速」ではなく「適切」なものにしたいと考えていますが、これは Google にとっての優先事項であることは間違いありません。
コンポジタ主導のアニメーション
カスタマイズがはるかに容易なため、遷移グループの幅と高さをデフォルトでアニメーション化しました。ただし、これはアニメーションがメインスレッドで実行されることを意味します。これは、特にページの読み込み中には最適とは言えません。
パフォーマンス向上のため、デフォルトのアニメーションと一般的なカスタマイズを検出して、それらをコンポジタ主導のアニメーションとして再解釈する予定です。
対象範囲別移行
現在のところ、SPA 移行のスコープはドキュメント全体であり、一度に 1 つの移行しか実行できません。そこで、複数のページ コンポーネントが個別に遷移を実行できるように、遷移のスコープを特定の要素に限定できる機能を導入します。
これにより、たとえば埋め込み動画プレーヤーで、埋め込みチャット ウィジェットと同時にビューの切り替えを使用できるようになります。
ネストされた移行グループ
現在、すべての ::view-transition-group は兄弟です。この方法を使用すると、あるコンテナから別のコンテナにビューを移行でき、クリッピングの心配もないため、通常は便利です。
ただし、親によってビューをクリップしたい場合もありますが、親が画面遷移に関与している可能性もあります。
特定の ::view-transition-group を別の ::view-transition-group 内に配置するオプトインについて調査します。
遷移のクラス
各 view-transition-name は一意である必要があります。これにより、特定の要素が、文字通り同じ要素でなくても、DOM の変化の両側において概念的に「同一」であることを確認できます。
ただし、view-transition-name が異なるものでも、同じ種類のアニメーションを使用しなければならない場合もあります。現時点では、すべての view-transition-name にセレクタルールを追加しています。
この制限を克服するために、遷移のクラスを作成する方法を追加したいと考えています。
画面外要素を無視する
要素に view-transition-name を指定すると、その要素は独自のグループとして遷移に関与します。これが望ましくない場合もあります。たとえば、ヘッダーに view-transition-name を指定して、2,000 ピクセル下へスクロールした状態からページ上部の状態に移動すると、ヘッダーは 2,000 ピクセル離れたところからアニメーション化されるため、タイミングが不正確になります。
代わりに、要素が無視されるオプトインを追加します。要素が完全にビューポートの外側にある場合、view-transition-name がない場合と同様です。
これは JavaScript ですでに style.viewTransitionName を動的に設定することで実現できますが、宣言型のソリューションが必要なように思えます。
requestAnimationFrame によるアニメーション
ウェブ アニメーション API を使用して、すでに JavaScript でビュー遷移アニメーションを作成できますが、requestAnimationFrame を使用してフレームごとに処理しなければならない場合もあります。
この操作はすでに可能ですが、少しややこしくなります。便利なヘルパーを使用したデモをご覧ください。そんなときは、
この作業は 2 つのパートに分けて行います。1 つ目は、アニメーションの完了を示す API を提供することです。2 つ目は、JavaScript で疑似要素にアクセスできるようにすることです。この 2 つ目の取り組みはかなり大きな仕事になるかもしれませんが、長期的には適切であるように感じます。
では、素晴らしいビュー遷移を作成してみましょう。
私と同じように、この機能の現在と未来が楽しみです。フィードバックがある場合や、作成したビュー遷移をスムーズで機能的にしたり、まったく 変したりしたい場合は、Twitter または Mastodon でご連絡ください。