From f736d8e7e7ac98c6e325d603cd3c2f191e26bf02 Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Thu, 2 Dec 2021 11:49:38 -0500 Subject: [PATCH 1/5] Update explainer.md --- explainer.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/explainer.md b/explainer.md index d863d4f..bd9cf3d 100644 --- a/explainer.md +++ b/explainer.md @@ -60,18 +60,20 @@ The entire painting of the element is captured, including things which appear ou https://user-images.githubusercontent.com/93594/141118353-d62d19a1-0964-4fa0-880f-bdde656ce899.mp4 -The element is captured without the effects (such as opacity and filters) from parent elements. Effects on the element itself are baked into the image. However, the element is captured without transforms, as those transforms are reapplied later. +The element is captured without the effects (such as opacity and filters) from parent elements. Effects on the element itself are baked into the image. However, the element is captured without transforms, as those transforms are reapplied later. The root is always captured as a single image, with the other transition elements removed (similar to how compositing works today). Capturing an element in this way isn't a new concept to the platform, as [`element()`]() in CSS performs a similar action. The differences are documented later. -The root is always captured as a single image, with the other transition elements removed (similar to how compositing works today), and is also clipped to the viewport, as capturing the entire page would take an enormous amount of memory in many cases. - Capturing as a CSS image avoids the interactivity risks, complexities, and memory impact of fully preserving these parts of Page-A as live DOM. On the other hand, it means that the capture will be 'static'. If it includes things like gifs, video, or other animating content, they'll be frozen on the frame they were displaying when captured. -- [Open question](https://github.com/WICG/shared-element-transitions/issues/72): Should we have a way to expand the root capture area for particular transitions? For example, transitions that involve vertical movement? -- [Open question](https://github.com/WICG/shared-element-transitions/issues/73): Other elements can also be massive. Do we need a way to limit and control the captured size of those? +#### Image Size +The size of the image cached for an element is equal to its border box size + the ink overflow from visual effects like shadows and blurs applied to the element. This allows exposing parts of an element during the transition which may have been hidden earlier. If an element is massive a UA may need to clip the image to a capped size (a common case would be the max texture size supported by the device). When caching a subset of the element due to this constraint, the rect within the element cached by the UA is the area closest to the viewport (computed using a heuristic). + +The size of the root image and the area captured follows a pattern similar to shared elements. However, since the root image is generated using the root stacking context it is likely to exceed and be clipped to capped size in most cases. + +An alternate choice was to clip the element to viewport bounds to limit memory use, particularly for the root element. This can be added as a perfomance hint from the developer in future iterations. See issues [72](https://github.com/WICG/shared-element-transitions/issues/72) and [73](https://github.com/WICG/shared-element-transitions/issues/73) for detailed discussion on this topic. -This mode works great for the share button and the root, as their transitions can be represented by simple transforms. However, the header changes size without stretching its shadow, and the content of the header moves independently and doesn't stretch. There's another mode for that: +The single image mode works great for the share button and the root, as their transitions can be represented by simple transforms. However, the header changes size without stretching its shadow, and the content of the header moves independently and doesn't stretch. There's another mode for that: ### As the element's computed style + content image From 4cfb6dad3ec27a8d7464fd3fae8d796f813a2a37 Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Mon, 6 Dec 2021 16:03:44 -0500 Subject: [PATCH 2/5] Update explainer.md Co-authored-by: vmpstr --- explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explainer.md b/explainer.md index bd9cf3d..c0f7aec 100644 --- a/explainer.md +++ b/explainer.md @@ -67,7 +67,7 @@ Capturing an element in this way isn't a new concept to the platform, as [`eleme Capturing as a CSS image avoids the interactivity risks, complexities, and memory impact of fully preserving these parts of Page-A as live DOM. On the other hand, it means that the capture will be 'static'. If it includes things like gifs, video, or other animating content, they'll be frozen on the frame they were displaying when captured. #### Image Size -The size of the image cached for an element is equal to its border box size + the ink overflow from visual effects like shadows and blurs applied to the element. This allows exposing parts of an element during the transition which may have been hidden earlier. If an element is massive a UA may need to clip the image to a capped size (a common case would be the max texture size supported by the device). When caching a subset of the element due to this constraint, the rect within the element cached by the UA is the area closest to the viewport (computed using a heuristic). +The size of the image cached for an element is equal to the element's [ink overflow rectangle](https://drafts.csswg.org/css-overflow-3/#ink-overflow-rectangle). This allows exposing parts of an element during the transition which may have been hidden earlier. The user-agent is allowed to clip the image to an implementation defined size (a common case would be the max texture size supported by the device). When caching a subset of the element due to this constraint, the area within the element cached by the user-agent is the area closest to the viewport. The size of the root image and the area captured follows a pattern similar to shared elements. However, since the root image is generated using the root stacking context it is likely to exceed and be clipped to capped size in most cases. From 8380fbd10324ccb08091454f8ba61995ba9d9cc8 Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Mon, 6 Dec 2021 16:03:53 -0500 Subject: [PATCH 3/5] Update explainer.md Co-authored-by: vmpstr --- explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explainer.md b/explainer.md index c0f7aec..014d32e 100644 --- a/explainer.md +++ b/explainer.md @@ -69,7 +69,7 @@ Capturing as a CSS image avoids the interactivity risks, complexities, and memor #### Image Size The size of the image cached for an element is equal to the element's [ink overflow rectangle](https://drafts.csswg.org/css-overflow-3/#ink-overflow-rectangle). This allows exposing parts of an element during the transition which may have been hidden earlier. The user-agent is allowed to clip the image to an implementation defined size (a common case would be the max texture size supported by the device). When caching a subset of the element due to this constraint, the area within the element cached by the user-agent is the area closest to the viewport. -The size of the root image and the area captured follows a pattern similar to shared elements. However, since the root image is generated using the root stacking context it is likely to exceed and be clipped to capped size in most cases. +The size of the root image and the area captured follows a pattern similar to shared elements. However, since the root image is generated using the root stacking context it is likely to be clipped to an implementation defined size in most cases. An alternate choice was to clip the element to viewport bounds to limit memory use, particularly for the root element. This can be added as a perfomance hint from the developer in future iterations. See issues [72](https://github.com/WICG/shared-element-transitions/issues/72) and [73](https://github.com/WICG/shared-element-transitions/issues/73) for detailed discussion on this topic. From 5d2f5f40551b52723e849a7746d4d6308a1ca962 Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Tue, 4 Jan 2022 06:09:50 -0500 Subject: [PATCH 4/5] Update explainer.md --- explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explainer.md b/explainer.md index 71a41d6..cca8122 100644 --- a/explainer.md +++ b/explainer.md @@ -186,7 +186,7 @@ https://user-images.githubusercontent.com/93594/141100217-ba1fa157-cd79-4a9d-b3b ## Part 4: The end -When the transition is complete, the transition elements created by the UA are removed, revealing the real Page-B. +When the transition is complete, the transition elements created by the UA are removed, revealing the real Page-B. The transition completes once no pseudo element has an active animation. # The MPA API From 886abdd8365a6f334b8ffe97b569d6d6d90c6f25 Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Tue, 4 Jan 2022 06:21:16 -0500 Subject: [PATCH 5/5] Clarify start of animations. --- explainer.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/explainer.md b/explainer.md index 71a41d6..cc57af9 100644 --- a/explainer.md +++ b/explainer.md @@ -184,6 +184,8 @@ Everything is now in place to perform the transition. The developer can animate https://user-images.githubusercontent.com/93594/141100217-ba1fa157-cd79-4a9d-b3b4-67484d3c7dbf.mp4 +Note that the browser defers displaying elements from Page-B and starting the animation until Page-B is ready for first render. This is currently driven by internal browser heuristics and is being standardized in the proposal [here](https://github.com/whatwg/html/issues/7131). + ## Part 4: The end When the transition is complete, the transition elements created by the UA are removed, revealing the real Page-B. @@ -270,7 +272,6 @@ Because the images are sized to 100% of the container, the images will also chan In all cases, the duration and easing is some undecided default, that could even be platform independent. -- [Open question](https://github.com/WICG/shared-element-transitions/issues/83): When will the default animation start? When the browser would usually first render Page-B? - [Open question](https://github.com/WICG/shared-element-transitions/issues/84): Default animations work well for things which are at least partially in-viewport in both Page-A and Page-B, but it gets tricky if you consider a non-sticky header that scrolled out of view by 1000s of pixels. - [Open question](https://github.com/WICG/shared-element-transitions/issues/85): If the developer wants a default animation of the root only, how do they define that?