[css-view-transitions-1] Resolve open issues. (#8948)

* [css-view-transitions-1] Resolve open issues

This change fixes the following issues inlined into the spec:

* The link for "paint order" doesn’t seem right. Is there a more canonical definition?

The DOM order of `::view-transition-group` pseudo-elements needs to match the paint order of the corresponding DOM elements. This is why elements are traversed in paint order when adding them to named elements. The definition of paint order used here is correct.

* Isolation and the dynamic setting of blending is only necessary...

This was resolved in #7814.

* Refactor this so the algorithm takes a set of elements that will be captured...

This was a problem because there was no way to refer to an element participating in a transition. Presence of view-transition-name was not enough. Now there's a bool on element to refer to this state.

* Specify what happens with mix-blend-mode.

Adds spec text to clarify this.

The issues remaining are related to web animations, will take those up in a follow up PR.

* Remove mix-blend-mode changes

Author: khushalsagar

css-view-transitions-1/Overview.bs

@@ -1284,9 +1284,6 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 			and has a [=node document=] equal to to |document|,
 			in [paint order](https://drafts.csswg.org/css2/#painting-order):
 
-			Issue: The link for "paint order" doesn't seem right.
-				Is there a more canonical definition?
-
 			1. If any [=flat tree=] ancestor of this |element| [=skips its contents=], then [=continue=].
 
 			1. If |element| has more than one [=box fragment=], then [=continue=].
@@ -1342,9 +1339,6 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 			and has a [=node document=] equal to to |document|,
 			in [paint order](https://drafts.csswg.org/css2/#painting-order):
 
-			Issue: The link for "paint order" doesn't seem right.
-				Is there a more canonical definition?
-
 			1. If any [=flat tree=] ancestor of this |element| [=skips its contents=], then [=continue=].
 
 			1. Let |transitionName| be the [=computed value=] of 'view-transition-name' for |element|.
@@ -1475,9 +1469,6 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 					Note: The above code example contains variables to be replaced.
 
 					Note: ''mix-blend-mode: plus-lighter'' ensures that the blending of identical pixels from the old and new images results in the same color value as those pixels, and achieves a "correct" cross-fade.
-
-					Issue: Isolation and the dynamic setting of blending is only necessary to get the right cross-fade between new and old image pixels.
-					Would it be simpler to always add it and try to optimize in the implementation?
 	</div>
 
 ## [=Call the update callback=] ## {#call-dom-update-callback-algorithm}
@@ -1616,14 +1607,12 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 			Implementations may adjust the rasterization quality to account for elements with a large [=ink overflow area=] that are transformed into view.
 
 		* [=list/For each=] |descendant| of [=shadow-including descendant=] {{Element}} and [=pseudo-element=] of |element|,
-			if |descendant| has a [=computed value=] of 'view-transition-name' that is not ''view-transition-name/none'',
+			if |descendant| is [=captured in a view transition=],
 			then skip painting |descendant|.
 
 			Note: This is necessary since the descendant will generate its own snapshot which will be displayed and animated independently.
 
-			Issue: Refactor this so the algorithm takes a set of elements that will be captured. This centralizes the logic for deciding if an element should be included or not.
-
-			Issue: Specify what happens with 'mix-blend-mode'.
+		Issue: Specify what happens with 'mix-blend-mode'.
 	</div>
 
 ## [=Handle transition frame=] ## {#handle-transition-frame-algorithm}