[css-view-transitions-1] Add snapshot viewport concept #8037

jakearchibald · 2022-11-07T15:46:34Z

I also tried to tighten up the language around the document element capture.

jakearchibald · 2022-11-07T15:54:33Z

css-view-transitions-1/Overview.bs

+			1. Render the region of the [=document element=] that intersects the [=snapshot viewport=],
+				on a transparent canvas the size of the [=snapshot viewport=],
+				following the [=capture rendering characteristics=], and these additional characteristics:
+
+				- Areas outside the [=scrolling box=] should be rendered as if they were scrolled to, without moving the [=layout viewport=].
+					This must not trigger events related to scrolling or resizing, such as {{IntersectionObserver}}s.
+
+					Issue: "scrolling box" and "layout viewport" are not exported. They either need exporting, or replaced with better references.

-			* The origin of |element|'s [=ink overflow rectangle=] is anchored to canvas origin.
+				- Areas that cannot be scrolled to (i.e. they are out of scrolling bounds),
+					should render transparent.


@bramus what's your take on this? I'm not sure if I'm using the right language.

I'm trying to say that, if the keyboard is open, and it's changed the size of the viewport, we should capture the area under the keyboard as if it were removed, but the layout viewport stayed the same size.

The css-viewport spec speaks of “interactive widgets”. I guess you could simply say “areas obscured by interactive widgets should render transparent”, and leave the definition up to the css-viewport spec.

I'm not sure we want them to render transparent though. I was trying to clarify that with the "Areas outside the [=scrolling box=] should be rendered as if they were scrolled to" language.

Ah I see. Was (incorrectly) focussing on the last line there. The way you worded things in your comment is much clearer than the text currently in the spec.

My hunch would be to try to include a reference to the interactive widgets. Does “the presence of interactive widgets and their effects on layout are taken into account when rendering“ capture it? Possibly, explicitly also mention that this implies that areas obscured by the interactive widgets do get rendered if they are in the snapshot viewport, and that no scroll/resize events get triggered.

khushalsagar · 2022-11-07T16:19:12Z

css-view-transitions-1/Overview.bs

@@ -393,6 +393,30 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 		:: a boolean. Initially false.
 	</dl>

+## The snapshot viewport ## {#snapshot-viewport-concept}
+
+	The <dfn>snapshot viewport</dfn> covers all areas of the window that could potentially display web content. This area is consistent regardless of transitionary UI that overlays content, or reduces the size of other viewports, such as scrollbars, virtual keyboards, or URL bars that can be scrolled away.


nit: Break at "This area is..." for semantic line-feed. Probably the same at, ", or reduces the..."

Oh, good catch. I think there are a few other places I didn't correctly apply the formatting too,

css-view-transitions-1/Overview.bs

khushalsagar · 2022-11-07T17:57:11Z

css-view-transitions-1/Overview.bs


-			* The origin of |element|'s [=ink overflow rectangle=] is anchored to canvas origin.
+				- Areas that cannot be scrolled to (i.e. they are out of scrolling bounds),


Can you share an example for this case.

On mobile, when the document is scrolled to the very top, the URL bar is not overlaying content. I assume the same can happen with the bottom of the page when the keyboard is open.

Got it.

The resolution was that we won't paint occluded elements which can't be scrolled to but the root element background will be painted there. For example if an element has the following CSS:

position: fixed; top: -10px; left: -10px;

It could be occluded by the URL bar and the user can't scroll to it. So we should skip painting this element, but the area should have the root element background. That could be a color or a repeated image.

The current spec text indicates that this area should be transparent.

LG other than updating for this. phone-browser-scrolled-to-top-with-url.svg also shows that the area under the URL bar in the snapshot is transparent but we should paint the root background there (it should have the blue color).

Hah, I'd forgotten to push. Done!

jakearchibald · 2022-11-08T10:43:34Z

@bramus @khushalsagar I've added some diagrams to explain the captured area. Does it make more sense now?

bramus · 2022-11-08T11:34:38Z

The diagrams make it much clearer; nice!

khushalsagar

Looking great. The diagrams are awesome!

khushalsagar · 2022-11-08T15:15:59Z

css-view-transitions-1/Overview.bs


-			* The origin of |element|'s [=ink overflow rectangle=] is anchored to canvas origin.
+				- Areas that cannot be scrolled to (i.e. they are out of scrolling bounds),


Got it.

The resolution was that we won't paint occluded elements which can't be scrolled to but the root element background will be painted there. For example if an element has the following CSS:

position: fixed; top: -10px; left: -10px;

It could be occluded by the URL bar and the user can't scroll to it. So we should skip painting this element, but the area should have the root element background. That could be a color or a repeated image.

The current spec text indicates that this area should be transparent.

css-view-transitions-1/Overview.bs

jakearchibald · 2022-11-09T11:43:15Z

@khushalsagar

Mind including the note about the filter/opacity effects too. It's very subtle that these effects are in the snapshot as opposed to on the pseudo tree generated by the transition.

It feels like the wrong place to talk about the rendering of the view transition layer.

There's already an issue in the section that documents the view transition layer:

Issue: Do we need to clarify that the stacking context for the root and top layer elements has filters and effects coming from the document element's style?

khushalsagar · 2022-11-10T13:18:47Z

css-view-transitions-1/Overview.bs

 		* [=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'',
 			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'.


It's ignored. This property is only relevant when blending an element into its target and doesn't need to impact the snapshot. How this snapshot is blended into its target is determined by the pseudo-element hosting it.

You can leave a non-normative note to clarify.

Why non-normative rather than normative?

I figured it's implicit because mix-blend-mode is only relevant when an element is drawn into its target. The UA styles we add on the pseudo-element is because the corresponding DOM element's mix-blend-mode might not be accurate for what's needed during the transition. So what else could we do with the DOM element's mix-blend-mode.

I'm fine with normative text for this too.

Would it be more correct to say the element is rendered within a new stacking context? That effectively ignores mix-blend-mode on the root, but explains what happens for mix-blend-mode on inner elements.

Because we require layout containment, each snapshotted element already has its own stacking context. The mix-blend-mode applies when this stacking context is drawn into its target stacking context. For View Transitions we take that stacking context's output as the snapshot and host it on the pseudo-element. Since we never draw the element's stacking context into its target, this property is effectively ignored.

The text about skipping painting of the DOM element's stacking context into its actual target is here btw: https://drafts.csswg.org/css-view-transitions-1/#create-transition-pseudo-elements:~:text=The%20new%20element%20and,none)%20until%20new%20exists. Feel free to send a PR to make this explicit.

bramus · 2022-11-10T13:23:27Z

Before this get merged, I want to point attention to the suggestion in #8037 (comment)

khushalsagar · 2022-11-10T19:34:58Z

css-view-transitions-1/Overview.bs

@@ -225,8 +225,8 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 		```

 		Note: This pseudo-element provides a containing block for all ''::view-transition-group()'' pseudo-elements.
-		The aim of the style is to size the pseudo-element to cover the [=large viewport size=]
-		and position all ''::view-transition-group()'' pseudo-elements relative to the origin of the large viewport.
+		The aim of the style is to size the pseudo-element to cover the [=snapshot viewport=]


I just realized this PR missed the part about UA styles on this pseudo-element. inset: 0 is no longer correct.

The first part is updating the style block for html::view-transition to:

position: fixed; top: 0; left: 0;

The second part is to add a point in Style transition pseudo-elements algorithm. Something like:

Let |root| be the ''::view-transition'' pseudo-element.

Set "width" and "height" to snapshot viewport bounds.

Set "transform" to a CSS transform that would place element at snapshot viewport origin.

jakearchibald · 2022-11-16T14:04:19Z

I've specified that the view-transition stacking layer covers the snapshot viewport, assuming we'll resolve on option 2 in #8070. I'll change the spec if things resolve differently.

khushalsagar · 2022-11-16T16:14:42Z

css-view-transitions-1/Overview.bs

@@ -336,6 +339,38 @@ urlPrefix: https://wicg.github.io/navigation-api/; type: interface;
 	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.

+	## The snapshot viewport ## {#snapshot-viewport-concept}


Indentation looks off.

khushalsagar

LGTM.

css-view-transitions-1/Overview.bs

Fixes w3c#7859

jakearchibald added 3 commits November 7, 2022 15:17

Add snapshot viewport concept

9806781

Try to be more specific about the document element capture

933ac6f

More tweaks

7ed8b30

jakearchibald added the css-view-transitions-1 View Transitions; Bugs only label Nov 7, 2022

jakearchibald requested review from bokand and khushalsagar November 7, 2022 15:46

jakearchibald added 3 commits November 7, 2022 15:49

Fix bikeshed indenting

0144582

Add issue

bb1f606

Use variable

b801ba5

jakearchibald commented Nov 7, 2022

View reviewed changes

jakearchibald added 3 commits November 7, 2022 15:57

Better language

c2365c9

Tweak

36cfe7a

Tweak

de904cb

khushalsagar reviewed Nov 7, 2022

View reviewed changes

jakearchibald added 3 commits November 8, 2022 09:54

Include top-layer in root capture

3a53097

Update formatting

5fcd47b

Add diagrams to explain capture area

c276051

khushalsagar reviewed Nov 8, 2022

View reviewed changes

jakearchibald mentioned this pull request Nov 8, 2022

[css-view-transitions-1] Handling snapshot viewport sizes changes during transitions #8045

Closed

Use the canvas background

7a31615

Tweaks

2f8e60e

khushalsagar reviewed Nov 10, 2022

View reviewed changes

khushalsagar approved these changes Nov 10, 2022

View reviewed changes

khushalsagar reviewed Nov 10, 2022

View reviewed changes

Make the snapshot stacking layer cover the snapshot viewport

84767b5

khushalsagar reviewed Nov 16, 2022

View reviewed changes

jakearchibald commented Nov 16, 2022

View reviewed changes

css-view-transitions-1/Overview.bs Outdated Show resolved Hide resolved

Update css-view-transitions-1/Overview.bs

22a329c

jakearchibald merged commit be01ea4 into w3c:main Nov 16, 2022

jakearchibald deleted the viewport branch November 16, 2022 16:23

jakearchibald added a commit to jakearchibald/csswg-drafts that referenced this pull request Jan 16, 2023

[css-view-transitions-1] Add snapshot viewport concept (w3c#8037)

901b63f

Fixes w3c#7859

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-view-transitions-1] Add snapshot viewport concept #8037

[css-view-transitions-1] Add snapshot viewport concept #8037

jakearchibald commented Nov 7, 2022

jakearchibald Nov 7, 2022

bramus Nov 7, 2022

jakearchibald Nov 7, 2022

bramus Nov 7, 2022

khushalsagar Nov 7, 2022

jakearchibald Nov 8, 2022

khushalsagar Nov 7, 2022

jakearchibald Nov 8, 2022

khushalsagar Nov 8, 2022

khushalsagar Nov 9, 2022

jakearchibald Nov 10, 2022

jakearchibald commented Nov 8, 2022

bramus commented Nov 8, 2022

khushalsagar left a comment

khushalsagar Nov 8, 2022

jakearchibald commented Nov 9, 2022

khushalsagar Nov 10, 2022 •

edited

Loading

jakearchibald Nov 11, 2022

khushalsagar Nov 11, 2022

jakearchibald Nov 14, 2022

khushalsagar Nov 14, 2022

bramus commented Nov 10, 2022

khushalsagar Nov 10, 2022

jakearchibald commented Nov 16, 2022

khushalsagar Nov 16, 2022

khushalsagar left a comment


		* The origin of \|element\|'s [=ink overflow rectangle=] is anchored to canvas origin.
		- Areas that cannot be scrolled to (i.e. they are out of scrolling bounds),

[css-view-transitions-1] Add snapshot viewport concept #8037

[css-view-transitions-1] Add snapshot viewport concept #8037

Conversation

jakearchibald commented Nov 7, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakearchibald commented Nov 8, 2022

bramus commented Nov 8, 2022

khushalsagar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakearchibald commented Nov 9, 2022

khushalsagar Nov 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bramus commented Nov 10, 2022

Choose a reason for hiding this comment

jakearchibald commented Nov 16, 2022

Choose a reason for hiding this comment

khushalsagar left a comment

Choose a reason for hiding this comment

khushalsagar Nov 10, 2022 •

edited

Loading