CSS ビュー遷移 — CSS View Transitions Module Level 1

1.1. ~DOM更新と視覚的な遷移の分離-法

伝統的に， 2 つの文書~状態の間で視覚的な遷移を作成することには、 ~DOMにおいて両~状態が同時に在るような期間が要求されていた。 事実，それは、 通例的には，両~状態を表現し得る特有な~DOM構造を作成することを孕んでいた。 例えば，ある要素が容器から容器へ “移動する” 場合、 要素は，当の遷移を成す期間において［ どちらかの容器 または それらの先祖~要素【の限界域】で切取られるのを避ける ］ため［ 両~容器の外側に存在する必要がある ］ことが多い。 ◎ Traditionally, creating a visual transition between two document states required a period where both states were present in the DOM at the same time. In fact, it usually involved creating a specific DOM structure that could represent both states. For example, if one element was “moving” between containers, that element often needed to exist outside of either container for the period of the transition, to avoid clipping from either container or their ancestor elements.

この余分な途中-状態は、 ~UXと~accessibilityの課題になることが多い — ~DOMを成す構造が，純粋に視覚的な効果~用に譲歩させられるので。 ◎ This extra in-between state often resulted in UX and accessibility issues, as the structure of the DOM was compromised for a purely-visual effect.

`~view遷移$は、 次を許容することにより，この厄介な途中-状態を避ける： ~DOMを 2 つの状態の間で瞬時に切替えてから、 別の層において 2 つの状態の間で［ 旧-状態を成す静的な視覚的な捕捉, 新-状態を成す~liveな捕捉 ］を利用して，~custom化~可能な視覚的な遷移を遂行することにより。 これらの捕捉は、 `疑似要素$たちが成す~treeとして表現される （詳細は、 `§ ~view遷移~用の疑似要素＠#view-transition-pseudos$にて） — それは、［ 旧-, 新- ］両~視覚的な状態が共存するようにして，［ ~size, 位置 ］を旧-から新-へ~animateしている間に［ ~cross-fadeするなどの効果 ］を許容する。 ◎ View Transitions avoid this troublesome in-between state by allowing the DOM to switch between states instantaneously, then performing a customizable visual transition between the two states in another layer, using a static visual capture of the old state, and a live capture of the new state. These captures are represented as a tree of pseudo-elements (detailed in § 3.2 View Transition Pseudo-elements), where the old visual state co-exists with the new state, allowing effects such as cross-fading while animating from the old to new size and position.

1.2. ~view遷移の~custom化

`Document$I の `startViewTransition()$m は、 既定では，~page全般な`~view遷移$を作成する — それは、 2 つの~DOM状態の間で~cross-fadeすることからなる。 開発者は、 `view-transition-name$p ~CSS~propを利用して， どの要素が独立に捕捉されるかも選べる — それは、 要素が~pageを成す残りとは独立に~animateされることを許容する。 遷移-中な状態 （そこでは、旧-, 新- 両~視覚的な捕捉が存在する） は，疑似要素たちとして表現されるので、 開発者は，馴染みな特能 — `~CSS~animation＠~CSSANIM$cite, `~Web~animation＠~WANIM$cite など — を利用して各~遷移を~custom化できる。 ◎ By default, document.startViewTransition() creates a view transition consisting of a page-wide cross-fade between the two DOM states. Developers can also choose which elements are captured independently using the view-transition-name CSS property, allowing these to be animated independently of the rest of the page. Since the transitional state (where both old and new visual captures exist) is represented as pseudo-elements, developers can customize each transition using familiar features such as CSS Animations and Web Animations.

1.3. ~view遷移の~lifecycle

成功裡な`~view遷移$は、 順に，次に挙げる相を経ていく： ◎ A successful view transition goes through the following phases:

1. 開発者は、 document.`startViewTransition$m(`updateCallback$V) を~callする — それは、 ある `ViewTransition$I %~view遷移 を返す。 ◎ Developer calls document.startViewTransition(updateCallback), which returns a ViewTransition, viewTransition.
2. 現在の状態が “旧-” 状態として捕捉される。 ◎ Current state captured as the “old” state.
3. 描画は静止される。 ◎ Rendering paused.
4. 開発者から `updateCallback$V 関数が供された場合、 それが~callされる — それが，文書~状態を更新する。 ◎ Developer’s updateCallback function, if provided, is called, which updates the document state.
5. %~view遷移 の `updateCallbackDone$m が充足される。 ◎ viewTransition.updateCallbackDone fulfills.
6. 現在の状態が “新-” 状態 として捕捉される。 ◎ Current state captured as the “new” state.
7. 遷移~疑似要素たちが作成される。 これらが成す構造の概観は、 `§ ~view遷移~用の疑似要素＠#view-transition-pseudos$ を見よ。 ◎ Transition pseudo-elements created. See § 3.2 View Transition Pseudo-elements for an overview of this structure.
8. 描画は静止されなくなり，遷移~疑似要素が露呈される。 ◎ Rendering unpaused, revealing the transition pseudo-elements.
9. %~view遷移 の `ready$m が充足される。 ◎ viewTransition.ready fulfills.
10. 完遂するまで，疑似要素たちを~animateする。 ◎ Pseudo-elements animate until finished.
11. 遷移~疑似要素たちが除去される。 ◎ Transition pseudo-elements removed.
12. %~view遷移 の `finished$m が充足される。 ◎ viewTransition.finished fulfills.

1.4. 増補としての遷移

`~view遷移^cite ~APIの設計においては、［ ~animateされる遷移は、 下層の文書~状態~変化に対する視覚的な`増補^emである ］ことが要点を成す。 すなわち、 誤った環境設定や機器~拘束などに因り［ 視覚的な遷移を作成することに失敗して、 遷移~animationは起こり得ないことが事前に判明した場合 ］でも，開発者の `UpdateCallback$I は常に~callされる。 ◎ A key part of the View Transition API design is that an animated transition is a visual enhancement to an underlying document state change. That means a failure to create a visual transition, which can happen due to misconfiguration or device constraints, will not prevent the developer’s UpdateCallback being called, even if it’s known in advance that the transition animations cannot happen.

例えば，開発者が`~view遷移~lifecycle＠#lifecycle$の開始~時に `skipTransition()$m を~callした場合、 ~animateされる遷移に関係している段 — `~view遷移~tree$を作成するなど — は起こらなくなる。 しかしながら， `UpdateCallback$I は依然として~callされる — 飛ばされるのは、 下層の状態~変更ではなく，視覚的な遷移に限られる。 ◎ For example, if the developer calls skipTransition() at the start of the view transition lifecycle, the steps relating to the animated transition, such as creating the view transition tree, will not happen. However, the UpdateCallback will still be called. It’s only the visual transition that’s skipped, not the underlying state change.

注記： ~DOM変更も飛ばされるべきである場合、 別の特能により取扱われる必要がある。 `NavigateEvent$I の `signal$m は、 【！https://wicg.github.io/navigation-api/#navigateevent】 【！https://wicg.github.io/navigation-api/#ref-for-dom-navigateevent-signal①】 そのような特能の開発者が これを取扱うためにも利用できる例である。 ◎ Note: If the DOM change should also be skipped, then that needs to be handled by another feature. navigateEvent.signal is an example of a feature developers could use to handle this.

`~view遷移^cite ~APIは、［ `updateCallback$V を介して，~DOMを非同期的に変更する ］ことを許容するが，~DOM変更を［ 遷移~自身に必要な~schedule法 ］を超えて［ ~queueする／~scheduleする ］ことは担当しない。 非同期的な~DOM変更には、 同時並行に起こり得るものもあれば （例：それらが独立な~componentの中で起きている場合），［ 他を~queueする／先立つ変更を中止する ］必要があるものもある。 これは、 当の~appを より全体的に捉える［ 特能／~framework ］に委ねるのが最善である。 ◎ Although the View Transition API allows DOM changes to be asynchronous via the UpdateCallback, the API is not responsible for queuing or otherwise scheduling DOM changes beyond any scheduling needed for the transition itself. Some asynchronous DOM changes can happen concurrently (e.g if they’re happening within independent components), whereas others need to queue, or abort an earlier change. This is best left to a feature or framework that has a more holistic view of the application.

1.5. 描画~model

`~view遷移^cite ~APIは、 ~UAが生成した疑似要素を利用して， 所与の要素が描画される状態を【画像として】再現することにより働く。 ［ 要素, その子孫 ］に適用される［ 要素の描画を成す側面 ］ — 例えば［ `filter$p や `opacity$p 様な視覚的な効果／ `overflow$p や `clip-path$p による切取り ］ — は、 その`画像を捕捉する$中で画像を生成するときに適用される。 ◎ View Transition works by replicating an element’s rendered state using UA generated pseudo-elements. Aspects of the element’s rendering which apply to the element itself or its descendants, for example visual effects like filter or opacity and clipping from overflow or clip-path, are applied when generating its image in Capture the image.

しかしながら，そのように生成される画像には、 `mix-blend-mode$p の様な［ 要素が埋込まれたとき，それをどう描くかを定義する~prop ］は適用できない。 そのような~propは、 当の要素に対応している `view-transition-group()$pe 疑似要素 — 当の要素に等価な~boxを生成するよう意味された疑似要素 — に適用される。 ◎ However, properties like mix-blend-mode which define how the element draws when it is embedded can’t be applied to its image. Such properties are applied to the element’s corresponding ::view-transition-group() pseudo-element, which is meant to generate a box equivalent to the element.

`view-transition-group()$pe に対応している要素が “新-” 状態~内に在る場合、 ~browserは、 “新-” 状態~内にある~DOM要素との同期cを保つよう， 各~propを `view-transition-group()^pe へ複製する。 `view-transition-group()^pe に対応している要素が “旧-”, “新-” 両~状態~内に在って， 複製された~propは補間-可能な場合、 ~browserは，［ 当の~propを滑らかに~animateするための既定の~animation ］も設定しておくことになる。 ◎ If the ::view-transition-group() has a corresponding element in the "new" states, the browser keeps the properties copied over to the ::view-transition-group() in sync with the DOM element in the "new" state. If the ::view-transition-group() has a corresponding both in the "old" and "new" state, and the property being copied is interpolatable, the browser also sets up a default animation to animate the property smoothly.

1.6. 例

function spaNavigate(%data) {
  updateTheDOMSomehow(%data);
}

function spaNavigate(%data) {
  /* 
この~APIを~supportしない~browser用の~fallback：
◎
Fallback for browsers that don't support this API:
 */
  if (!document.startViewTransition) {
    updateTheDOMSomehow(%data);
    return;
  }

  /* 
遷移を伴わせる：
◎
With a transition:
 */
  document.startViewTransition(() => updateTheDOMSomehow(%data));
}

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 5s;
}

@keyframes fade-in {
  from { opacity: 0; }
}

@keyframes fade-out {
  to { opacity: 0; }
}

@keyframes slide-from-right {
  from { transform: translateX(30px); }
}

@keyframes slide-to-left {
  to { transform: translateX(-30px); }
}

::view-transition-old(root) {
  animation: 90ms cubic-bezier(0.4, 0, 1, 1) both fade-out,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-to-left;
}

::view-transition-new(root) {
  animation: 210ms cubic-bezier(0, 0, 0.2, 1) 90ms both fade-in,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-from-right;
}

.main-header {
  view-transition-name: main-header;
}

.main-header-text {
  view-transition-name: main-header-text;
  /* 
要素の~sizeを一貫させる
— ~textは変わらないと見做して：
◎
Give the element a consistent size, assuming identical text:
 */
  width: fit-content;
}

.sidebar {
  view-transition-name: sidebar;
}

@keyframes slide-to-right {
  to { transform: translateX(30px); }
}

/* 
~sidebarが内へ来る遷移
◎
Entry transition
 */
::view-transition-new(sidebar):only-child {
  animation: 300ms cubic-bezier(0, 0, 0.2, 1) both fade-in,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-from-right;
}

/* 
~sidebarが外へ出る遷移
◎
Exit transition
 */
::view-transition-old(sidebar):only-child {
  animation: 150ms cubic-bezier(0.4, 0, 1, 1) both fade-out,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-to-right;
}

::view-transition-image-pair(root) {
  isolation: auto;
}

::view-transition-old(root),
::view-transition-new(root) {
  animation: none;
  mix-blend-mode: normal;
}

/* 
最後の~click~eventを格納する
◎
Store the last click event
 */
let %lastClick;
addEventListener('click', %event => (%lastClick = %event));

function spaNavigate(%data) {
  /* 
この~APIを~supportしない~browser用の~fallback：
◎
Fallback for browsers that don't support this API:
 */
  if (!document.startViewTransition) {
    updateTheDOMSomehow(%data);
    return;
  }

  /* 
~click位置を取得する
— できない場合、~screenの真中に~fall-backする：
◎
Get the click position, or fallback to the middle of the screen
 */
  const %x = %lastClick?.clientX ?? window.innerWidth / 2;
  const %y = %lastClick?.clientY ?? window.innerHeight / 2;
  /* 
最も遠い隅までの距離を取得する：
◎
Get the distance to the furthest corner
 */
  const %endRadius = Math.hypot(
    Math.max(%x, innerWidth - %x),
    Math.max(%y, innerHeight - %y)
  );

  /* 
遷移を作成する：
◎
Create a transition:
 */
  const %transition = document.startViewTransition(() => {
    updateTheDOMSomehow(%data);
  });

  /* 
疑似要素たちが作成されるまで待機する：
◎
Wait for the pseudo-elements to be created:
 */
  %transition.ready.then(() => {
    /* 
根の新たな~viewを~animateする：
◎
Animate the root's new view
 */
    document.documentElement.animate(
      {
        clipPath: [
          ``^`circle^(0 at ${%x}px ${%y}px)``^,
          ``^`circle^(${%endRadius}px at ${%x}px ${%y}px)``^,
        ],
      },
      {
        duration: 500,
        easing: 'ease-in',
        /* 
どの疑似要素を~animateするか指定する：
◎
Specify which pseudo-element to animate
 */
        pseudoElement: '::view-transition-new(root)',
      }
    );
  });
}

2.1. 個別に遷移している下位treeの~tag付け： `view-transition-name^p ~prop

注記： `view-transition-name$p は`離散的$に~animate可能であるが、 ~animateしても，稼働中な~view遷移には影響しない。 そうではなく、［ 時間~越しに／`時列線$に基づいて ］変化し得る仕方で，その値を設定する仕方を与える。 例えば、 `~scroll駆動な~animation$に基づいて `view-transition-name$p を変更することに利用できよう。 ◎ Note: though view-transition-name is discretely animatable, animating it doesn’t affect the running view transition. Rather, it’s a way to set its value in a way that can change over time or based on a timeline. An example for using this would be to change the view-transition-name based on scroll-driven animations.

`view-transition-name$p ~propは、 `~view遷移~内に捕捉され＠#captured-in-a-view-transition$た要素に対し， 指定された `~view遷移~名@ の下で［ `~view遷移~tree$内で独立に追跡する ］ために， “~tag” を付与する。 捕捉された要素は、 当の~pageを成す残りとは独立に~animateされる。 ◎ The view-transition-name property “tags” an element for capture in a view transition, tracking it independently in the view transition tree under the specified view transition name. An element so captured is animated independently of the rest of the page.

`none@v

`要素$は、 ~view遷移において独立に関与することはない。 ◎ The element will not participate independently in a view transition.

`custom-ident$t

`要素$は、 ~view遷移において， 指定された`~view遷移~名$を伴う［ 旧-／新- ］`要素$として独立に関与する。 ◎ The element participates independently in a view transition—as either an old or new element—with the specified view transition name.

この `custom-ident$t においては、 値［ `none^v, `auto^v ］は除外される。 ◎ The values none and auto are excluded from <custom-ident> here.

注記： この名前が一意でない場合 （すなわち、 同じ `~view遷移~名$が複数の要素に同時に指定された場合）、 `~view遷移$は中止されることになる。 ◎ Note: If this name is not unique (i.e. if two elements simultaneously specify the same view transition name) then the view transition will abort.

注記： この~APIの目的においては、［ 旧-状態~内にある要素, 新-状態~内にある別の要素 ］に同じ`~view遷移~名$ `foo^v が付与された場合、 それらは［ 同じ要素の異なる視覚-状態を表現している ］ものとして扱われ，`~view遷移~tree$内で~pairにされることになる。 それらの要素が同じ~objを指すことは必要yでないので，これは紛らわしくもなり得るが、 それらを［ 同じ概念的な~page実体を成す，視覚的な状態 ］であると見なすことは、 ~modelとして有用になる。 ◎ Note: For the purposes of this API, if one element has view transition name foo in the old state, and another element has view transition name foo in the new state, they are treated as representing different visual state of the same element, and will be paired in the view transition tree. This may be confusing, since the elements themselves are not necessarily referring to the same object, but it is a useful model to consider them to be visual states of the same conceptual page entity.

要素の`首要~box$が［ `断片化され$る／ `飛ばさ＠:~CSSCONTAIN#skips-its-contents$れる／ `描画されない$ ］場合、 この~propによる効果は無い。 正確な詳細は `§ ~algo＠#algorithms$ を見よ。 ◎ If the element’s principal box is fragmented, skipped, or not rendered, this property has no effect. See § 7 Algorithms for exact details.

3.1. 疑似要素~tree

注記： これは、 疑似要素たちが成す~tree用の一般な定義である。 他の特能にもこの挙動が必要になった場合、 これらの定義は `css-pseudo-4$r へ移動されることになる。 ◎ Note: This is a general definition for trees of pseudo-elements. If other features need this behavior, these definitions will be moved to [css-pseudo-4].

`疑似要素~根@ とは、 `疑似要素~tree$における`根$を指す，`~treeに留まる疑似要素$である。 ◎ A pseudo-element root is a type of tree-abiding pseudo-element that is the root in＼

`疑似要素~tree@ とは、 `~treeに留まる疑似要素$たちが成す`~tree$である。 ◎ a tree of tree-abiding pseudo-elements, known as the pseudo-element tree.

`疑似要素~tree$は、 その`子孫$たちの文書~順序を定義する。 ◎ The pseudo-element tree defines the document order of its descendant tree-abiding pseudo-elements.

`疑似要素$ %要素 が ある`疑似要素~tree$に`関与-$しているときは、 %要素 の`親$が %要素 の`出自の疑似要素$になる。 ◎ When a pseudo-element participates in a pseudo-element tree, its originating pseudo-element is its parent.

`疑似要素~根$のある`子孫$ %疑似要素 に自身以外に`同胞$は無い場合、 `only-child$ps は， %疑似要素 に合致する。 ◎ If a descendant pseudo of a pseudo-element root has no other siblings, then :only-child matches that pseudo.

注記： このことは、 `::view-transition-new(ident):only-child^css が `view-transition-new(ident)^pe を選択するのは、 親である `view-transition-image-pair(ident)^pe の`子$は 1 つしかない — すなわち，`同胞$である `view-transition-old(ident)^pe は無い — 場合に限られることを意味する。 ◎ Note: This means that ::view-transition-new(ident):only-child will only select ::view-transition-new(ident) if the parent ::view-transition-image-pair(ident) contains a single child. As in, there is no sibling ::view-transition-old(ident).

3.2. ~view遷移~用の疑似要素

`~view遷移$の視覚-化は、 `疑似要素~tree$として表現される — それは、 `~view遷移~tree@ と呼ばれ，以下に定義される `~view遷移~疑似要素@ たちから構成される。 この~treeは，`遷移~疑似要素たちを設定しておく$間に築かれ、［ `根~要素$を`出自の要素$とする `view-transition$pe 疑似要素 ］が，その根になる。 `~view遷移~疑似要素$を成すすべては、［ それらの`最終的な出自の要素$である，`文書~要素$【すなわち根~要素】 ］から【相対的に】選択される。 ◎ The visualization of a view transition is represented as a pseudo-element tree called the view transition tree composed of the view transition pseudo-elements defined below. This tree is built during the setup transition pseudo-elements step, and is rooted under a ::view-transition pseudo-element originating from the root element. All of the view transition pseudo-elements are selected from their ultimate originating element, the document element.

`~view遷移~tree$は、 ~accessibility~treeには公開されない。 ◎ The view transition tree is not exposed to the accessibility tree.

::view-transition
├─ ::view-transition-group(%name)
│  └─ ::view-transition-image-pair(%name)
│     ├─ ::view-transition-old(%name)
│     └─ ::view-transition-new(%name)
└─ …他の~groupたち…

::view-transition-%pseudo(`pt-name-selector$t)

`pt-name-selector@t
	= '*'
	| `custom-ident$t

4.1. ~snapshot包含塊

`~snapshot包含塊@ は、［ ~UIwindowを成す~page内容を表示するようになり得るもの ］が成す すべての区画を覆う矩形であり， （したがって［ 根~scrollbarや `対話的~widget＠https://drafts.csswg.org/css-viewport/#interactive-widget$ ］に関わらず一貫する）。 これにより、 `文書~要素$の［ `旧-画像$cE, `新-要素$cE ］が一貫する見込みが高くなる。 ◎ The snapshot containing block is a rectangle that covers all areas of the window that could potentially display page content (and is therefore consistent regardless of root scrollbars or interactive widgets). This makes it likely to be consistent for the document element's old image and new element.

`子~navigable$の中の`~snapshot包含塊$は、 当の~navigableの`表示域$に`~scrollbar側溝$（もしあれば）を併せた領域になる。 ◎ Within a child navigable, the snapshot containing block is the union of the navigable’s viewport with any scrollbar gutters.

`~snapshot包含塊の原点@ は、 `~snapshot包含塊$の左上~隅を指す。 ◎ The snapshot containing block origin refers to the top-left corner of the snapshot containing block.

`~snapshot包含塊の~size@ は、 `~snapshot包含塊$の［ 横幅, 縦幅 ］を順に与える， 2 個の実数が成す`~tuple$。 ◎ The snapshot containing block size refers to the width and height of the snapshot containing block as a tuple of two numbers.

`~snapshot包含塊$は、［ `view-transition$pe, その各~子孫 ］用の［ `絶対~位置決め包含塊$, `固定d位置決め包含塊$ ］を与えるものと見なされる。 ◎ The snapshot containing block is considered to be an absolute positioning containing block and a fixed positioning containing block for ::view-transition and its descendants.

4.2. ~view遷移における塗ng順序

この仕様は、 `CSS2$r `§ 積層~文脈の詳しい記述＠~CSS22/zindex.html#elaborate-stacking-contexts$ にて確立される塗ng順序の終端に， 新たな積層~層として`~view遷移~層$を導入する。 ◎ This specification introduces a new stacking layer, the view transition layer, to the end of the painting order established in CSS2§E Elaborate Description of Stacking Contexts. [CSS2]

`view-transition$pe 疑似要素は、 `~view遷移~層@ と呼ばれる新たな積層~文脈を生成する。 それは、 文書を成す他のすべての内容（`上端~層$内に描画される内容も含む）より後に塗られる — そのような内容に適用された~filterその他の効果があれば，それらより後に。 （それは、 そのような効果の~subjectにならない — 効果は、［［ `view-transition-old()$pe, `view-transition-new()$pe ］疑似要素を成す描画される内容 ］に影響する所までに限られる。） ◎ The ::view-transition pseudo-element generates a new stacking context, called the view transition layer, which paints after all other content of the document (including any content rendered in the top layer), after any filters and effects that are applied to such content. (It is not subject to such filters or effects, except insofar as they affect the rendered contents of the ::view-transition-old() and ::view-transition-new() pseudo-elements.)

注記： この特能の意図は、 ~pageを成す内容を，上端~層~内の要素を含めて捕捉-可能にすることにある。 それを成遂げるため、 `~view遷移~層$は，捕捉された積層~文脈の一部を成し得ない — そうすると循環依存になるので。 したがって、 `~view遷移~層$は，他のすべての内容の同胞になる。 ◎ Note: The intent of the feature is to be able to capture the contents of the page, which includes the top layer elements. In order to accomplish that, the view transition layer cannot be a part of the captured stacking contexts, since that results in a circular dependency. Therefore, the view transition layer is a sibling of all other content.

［ `文書$ %文書 にて`作動中な~view遷移$docの`相$vT ~EQ `~animate中$i ］の間は、［ %文書 内の要素のうち`~view遷移~内に捕捉され＠#captured-in-a-view-transition$たもの ］により生成される~box，および その`要素~内容$は、 `遷移~根~疑似要素$vTの`広義-子孫$を除いて ⇒＃ 塗られない（要素の `visibility$p は `hidden^v であったかのように）／ 接触判定に応答しない（要素の `pointer-events$p は `none^v であったかのように） ◎ When a Document's active view transition's phase is "animating", the boxes generated by any element in that Document with captured in a view transition and its element contents, except transition root pseudo-element's inclusive descendants, are not painted (as if they had visibility: hidden) and do not respond to hit-testing (as if they had pointer-events: none).

注記： 遷移に関与している要素は、 その~DOM内での所在における塗ngを飛ばす必要がある — それらの画像は、 代わりに，対応している `view-transition-new()$pe 疑似要素~内に塗られるので。 類似に，接触判定も飛ばされる — 要素の~DOM内での所在は、 その内容が描画される所には対応しないので。 しかしながら、 これらの要素が［ 支援技術／~accessibility~tree ］により どう~accessされるかは変化しない。 ◎ Note: Elements participating in a transition need to skip painting in their DOM location because their image is painted in the corresponding ::view-transition-new() pseudo-element instead. Similarly, hit-testing is skipped because the element’s DOM location does not correspond to where its contents are rendered. However, there is no change in how these elements are accessed by assistive technologies or the accessibility tree.

6.1. `Document^I に対する追加

partial interface `Document$I {
  `ViewTransition$I `startViewTransition$m(optional `UpdateCallback$I %updateCallback);
};

callback `UpdateCallback@I = `Promise$<`any$> ();

`viewTransition$V【！ViewTransition】 = document【！Document】.`startViewTransition$m(`updateCallback$V)

新たな`~view遷移$を開始する （`文書$に既存の`作動中な~view遷移$docがある場合、 それを取消した上で）。 ◎ Starts a new view transition (canceling the document’s existing active view transition, if any).

`updateCallback$V は、 供された場合は，非同期的に — 当の文書の現在の状態が捕捉されたなら — ~callされる。 その後， `updateCallback$V が返した~promiseが充足されるとき、 当の文書の新-状態が捕捉され，遷移が起動される。 ◎ updateCallback, if provided, is called asynchronously, once the current state of the document is captured. Then, when the promise returned by updateCallback fulfills, the new state of the document is captured and the transition is initiated.

`updateCallback$V は、 供された場合は，遷移が起こり得ない場合でも （例：重複な `view-transition-name^p 値に因り）， `常に^em ~callされることに注意。 遷移は，状態~変更~周りの増補なので、 遷移を作成することに失敗しても， 【 `updateCallback$V による】状態~変更は決して防止されない。 この原則についての詳細は、 `§ 増補としての遷移＠#transitions-as-enhancements$ を見よ。 ◎ Note that updateCallback, if provided, is always called, even if the transition cannot happen (e.g. due to duplicate view-transition-name values). The transition is an enhancement around the state change, so a failure to create a transition never prevents the state change. See § 1.4 Transitions as an enhancement for more details on this principle.

`updateCallback$V が返した~promiseが却下された場合、 遷移は飛ばされる。 ◎ If the promise returned by updateCallback rejects, the transition is skipped.

6.2. `ViewTransition^I ~interface

[`Exposed$=Window]
interface `ViewTransition@I {
  readonly attribute `Promise$<`undefined$> `updateCallbackDone$m;
  readonly attribute `Promise$<`undefined$> `ready$m;
  readonly attribute `Promise$<`undefined$> `finished$m;
  `undefined$ `skipTransition$m();
};

`ViewTransition$I ~interfaceは、 単独の同一-文書な`~view遷移$ — すなわち、［ 開始~時の文書, 終了~時の文書 ］が同じで，場合によっては文書の~DOM構造に対する変更を伴う遷移 — を表現し，それを制御する。 ◎ The ViewTransition interface represents and controls a single same-document view transition, i.e. a transition where the starting and ending document are the same, possibly with changes to the document’s DOM structure.

`viewTransition$V.`updateCallbackDone$m

この~promiseは、 `updateCallback$V が返した~promiseが充足されたとき充足され， 却下されたとき却下される。 ◎ A promise that fulfills when the promise returned by updateCallback fulfills, or rejects when it rejects.

注記： `~view遷移^cite ~APIは， ~DOM変更を包装して視覚的な遷移を作成するが、 遷移~animationの［ 成功／失敗 ］について~careすることなく，当の~DOM変更が［ 起きたか否か, いつ起きたか ］を知ることだけ求まれるときもある。 `updateCallbackDone$m は、 そのような利用事例~用にある。 ◎ Note: The View Transition API wraps a DOM change and creates a visual transition. However, sometimes you don’t care about the success/failure of the transition animation, you just want to know if and when the DOM change happens. updateCallbackDone is for that use-case.)

`viewTransition$V.`ready$m

この~promiseは： ◎ ↓

• 遷移~用の疑似要素たちが作成され，~animationが開始しつつあるとき充足する。 ◎ A promise that fulfills once the pseudo-elements for the transition are created, and the animation is about to start.
• 遷移が始まり得ない場合には却下される。 `view-transition-name$p が重複しているなど，誤った環境設定に因り／ `updateCallbackDone$m が却下される~promiseを返した場合など。 ◎ It rejects if the transition cannot begin. This can be due to misconfiguration, such as duplicate 'view-transition-name’s, or if updateCallbackDone returns a rejected promise.

`ready$m が充足される時点は、 `~view遷移~疑似要素$を `~Web~animation~API＠~WANIMapi#extensions-to-the-element-interface$cite で~animateする理想的な機会である。 ◎ The point that ready fulfills is the ideal opportunity to animate the view transition pseudo-elements with the Web Animation API.

`viewTransition$V.`finished$m

この~promiseは： ◎ ↓

• 終了~状態が全部的に可視になり，利用者からヤリトリ-可能になったなら充足される。 ◎ A promise that fulfills once the end state is fully visible and interactive to the user.

• 却下されるのは、 `updateCallback$V が却下される~promiseを返す場合に限られる — それは、 終了~状態が作成されなかったことを指示するので。 ◎ It only rejects if updateCallback returns a rejected promise, as this indicates the end state wasn’t created.

  他の場合、［ 遷移が始まるのに失敗したか （ `skipTransition()$m により）飛ばされた ］場合でも， 終了~状態には到達するので充足する。 ◎ Otherwise, if a transition fails to begin, or is skipped (by skipTransition()), the end state is still reached, so finished fulfills.

`viewTransition$V.`skipTransition$m()

遷移が開始されたなら即時に完遂させ，まだなら開始されないようにする。 ◎ Immediately finish the transition, or prevent it starting.

これにより `updateCallback$V が~callされなくなることは決してない — ~DOM変更は、 遷移とは独立なので。 この原則についての詳細は、 `§ 増補としての遷移＠#transitions-as-enhancements$ 見よ。 ◎ This never prevents updateCallback being called, as the DOM change is independent of the transition. See § 1.4 Transitions as an enhancement for more details on this principle.

`ready$m が解決される前に これが~callされた場合、 `ready$m は却下されることになる。 ◎ If this is called before ready resolves, ready will reject.

`finished$m が解決される前に これが~callされた場合、 `finished$m は `updateCallbackDone$m が決着するに伴い決着することになる。 ◎ If finished hasn’t resolved, it will fulfill or reject along with updateCallbackDone.

各 `ViewTransition$I %~view遷移 は、 次に挙げるものを有する： ◎ A ViewTransition has the following:

`有名~要素~群@vT ◎ named elements

`有順序~map$ — 各~entryの ⇒＃ ~keyは，`~view遷移~名$を与える。 値は，`捕捉された要素$を与える。 ◎ a map, whose keys are view transition names and whose values are captured elements.＼

初期~時は，新たな`有順序~map$とする。 ◎ Initially a new map.

注記： これは、 `ViewTransition$I に結付けられるので， `~view遷移を~clearする$が~callされたとき片付けられることになる。 ◎ Note: Since this is associated to the ViewTransition, it will be cleaned up when Clear view transition is called.

`相@vT ◎ phase

次に挙げるいずれかをとり， 挙げられた順に（場合によっては，一部を飛ばして）進捗する — 初期~時は `捕捉-待ち$i とする ⇒＃ `捕捉-待ち@i, `更新~callbackは~call済み@i, `~animate中@i, `済み@i ◎ One of the following ordered phases, initially "pending-capture": • "pending-capture". • "update-callback-called". • "animating". • "done".

注記： これらの相は，自動的に進捗するので、 この~APIを利用している開発者【作者】は， ほとんどにおいて どの相にあるか心配する必要はない。 しかしながら，どの手続きが どの相で起こるか — ~snapshotは いつ捕捉され, 疑似要素~DOMは いつ作成されるか, 等々 — を理解することは、 重要になる。 以下に与える各~相を成す記述は、［ 仕様に準拠する実装を生産するために従うべき一義的な手続きが成す集合 ］を実装者~向けに供する意図をもって，アリな限り精確であろうと試行する。 ◎ Note: For the most part, a developer using this API does not need to worry about the different phases, since they progress automatically. It is, however, important to understand what steps happen in each of the phases: when the snapshots are captured, when pseudo-element DOM is created, etc. The description of the phases below tries to be as precise as possible, with an intent to provide an unambiguous set of steps for implementors to follow in order to produce a spec-compliant implementation.

`更新~callback@vT ◎ update callback

~NULL ／ ある `UpdateCallback$I ◎ an UpdateCallback or null.＼

初期~時は ~NULL とする。 ◎ Initially null.

`準備済み時の~promise@vT ◎ ready promise

`~promise$ ◎ a Promise.＼

初期~時は，次を遂行した結果になるとする ⇒ `新たな~promise$( %~view遷移 に`関連な~realm$ ) ◎ Initially a new promise in this’s relevant Realm.

`更新~callback済み時の~promise@vT ◎ update callback done promise

`~promise$ ◎ a Promise.＼

初期~時は，次を遂行した結果になるとする ⇒ `新たな~promise$( %~view遷移 に`関連な~realm$ ) ◎ Initially a new promise in this’s relevant Realm.

注記： ［ `準備済み時の~promise$vT, `更新~callback済み時の~promise$vT ］は即時に作成されるので、 却下は — `取扱済みとして~markされ$ない限り， `updateCallbackDone$m などの取得子に~accessされなかった場合でも — `unhandledrejection$et を発火させることになる。 ◎ Note: The ready promise and update callback done promise are immediately created, so rejections will cause unhandledrejections unless they’re handled, even if the getters such as updateCallbackDone are not accessed.

`完遂-時の~promise@vT ◎ finished promise

`~promise$ ◎ a Promise.＼

初期~時は，次を遂行した結果になるとする：

1. %~promise ~LET `新たな~promise$( %~view遷移 に`関連な~realm$ )
2. `~promiseを取扱済みとして~markする$( %~promise )
3. ~RET %~promise

◎ Initially a new promise in this’s relevant Realm, marked as handled.

注記： `unhandledrejection$et が重複して発火されるのを防止するため、 これは，`取扱済みとして~markされ$る。 この~promiseが却下されるのは、 `更新~callback済み時の~promise$vTが却下されるときに限られるので。 ◎ Note: This is marked as handled to prevent duplicate unhandledrejections, as this promise only ever rejects along with the update callback done promise.

`遷移~根~疑似要素@vT ◎ transition root pseudo-element

ある `view-transition$pe ◎ a ::view-transition.＼

初期~時は新たな `view-transition^pe とする。 ◎ Initially a new ::view-transition.

`初期~snapshot包含塊~size@vT ◎ initial snapshot containing block size

~NULL ／ ［ 横幅, 縦幅 ］を順に与える 2 個の実数が成す`~tuple$ ◎ a tuple of two numbers (width and height), or null.＼

初期~時は ~NULL とする。 ◎ Initially null.

注記： これは、 `~snapshot包含塊の~size$における変化を検出するために利用される — そのような変化が生じた場合、 遷移は`飛ばされ$る。 この挙動の論点は、 `8045$issue にある。 ◎ Note: This is used to detect changes in the snapshot containing block size, which causes the transition to skip. Discussion of this behavior.

7.1. ~data構造

7.2. 処理待ち遷移~演算を遂行する

注記： この~algoは、 `描画を更新する段＠~WAPI#update-the-rendering$ `HTML$r の中から呼出される。 ◎ This algorithm is invoked as a part of update the rendering loop in the html spec.

7.3. ~view遷移を設定しておく

7.4. 更新~callbackを~callする

7.5. ~view遷移を飛ばす

7.6. ~view遷移の~page可視性~変化-時の手続き

7.7. 画像を捕捉する

7.8. 遷移~frameを取扱う

7.9. 疑似要素~styleを更新する

7.10. ~view遷移を~clearする