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 01/10] 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 890030fb4ad1c2623453e5f587999c06ddab7a15 Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Thu, 2 Dec 2021 11:59:29 -0500 Subject: [PATCH 02/10] Update for app-history dependency question --- explainer.md | 1 - 1 file changed, 1 deletion(-) diff --git a/explainer.md b/explainer.md index d863d4f..c604dde 100644 --- a/explainer.md +++ b/explainer.md @@ -230,7 +230,6 @@ Expanding on the capabilities of the CSS properties, a JS API allows the develop Also, data can be provided via `setData`. This can be anything structured-clonable, and will be made available to Page-B. -- [Open question](https://github.com/WICG/shared-element-transitions/issues/77): Is this a tight-coupling with app-history, or could it be usable without it? - [Open question](https://github.com/WICG/shared-element-transitions/issues/78): Do we need `offerElement`? The same thing could be done by adding the CSS properties. ```js From 147debae8198d8bbc6f05e0db3125e8b4a9d385c Mon Sep 17 00:00:00 2001 From: Khushal Sagar <63884798+khushalsagar@users.noreply.github.com> Date: Thu, 2 Dec 2021 12:02:31 -0500 Subject: [PATCH 03/10] Add UA stylesheet update --- explainer.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/explainer.md b/explainer.md index d863d4f..3b42304 100644 --- a/explainer.md +++ b/explainer.md @@ -136,9 +136,7 @@ transition root - **image**: This contains the cached image, which may paint outside the parent elements. This would be a replaced element so CSS properties like `object-fit` will be supported. This element is absolutely positioned at 0, 0 and has a width and height of 100%, although the image may paint outside of its own bounds, similar to how a `box-shadow` is painted outside of an element's bounds. - **child transition elements**: If this transition element is a 'transition container', child transition elements will be nested here. -These elements will be accessible to the developer via pseudo-elements. - -- [Open question](https://github.com/WICG/shared-element-transitions/issues/75): How does the UA apply styles to these elements? Particularly styles which are specific to one transition element, such as its transform. Inline styles are simple, but tricky for a developer to override in a stylesheet. An alternative would be to generate a `