[css-view-transitions-1] Questions about capturing

[fantasai]

Some reactions to reading the last sections of the spec... (Happy to file follow-up issues as necessary for ones that seem to need discussion, but this seemed easier to handle than a slew of new issues, one for each question.)

1. Is the reason you're capturing the writing mode for the cascade, or some other reason?

2. I think what you want to capture is the “writing mode”, not just writing-mode and direction, right? So you need to also capture text-orientation.

3. You define “old image” as an ImageData, but actually I think we just want it to be a static 2D image. How it's stored or represented doesn't matter, what it is does.

4. I'm trying to understand the rendering model...
   4.1 What causes ::view-transition-new() to render the corresponding DOM element?
   4.2 What causes :root and its descendants to not render?

5. Wrt origins,

   The origin of element’s ink overflow rectangle is anchored to canvas origin.

   I think this sentence should be deleted?

6. Wrt filters etc.

   Effects on the element, such as opacity and filter are applied to the capture.

   By “on the element”, do you mean “applied to the element”, or possibly those applied by ancestors?

7. Wrt capturing the root,

   Render the region of the element and the document's top layer that intersects the snapshot containing block, on a transparent canvas the size of the snapshot containing block

   I think you want to render the entire document, right? Including the canvas background and the (non-excluded) descendants. This paragraph doesn't seem to be saying that...

8. Also wrt capturing the root, if an item in the top layer (or its ancestor) has view-transition-name then it probably shouldn't be captured by the root, right?

9. The last line of capturing seems to capture (:P) our earlier resolution that the pseudo-element's replaced content has a natural size and origin corresponding to the border box while capturing ink overflow. But where do we say that we paint the ink overflow for ::view-transition-old()?

[noamr]

Sorry, I missed this issue.
Answering some of the questions:

Some reactions to reading the last sections of the spec... (Happy to file follow-up issues as necessary for ones that seem to need discussion, but this seemed easier to handle than a slew of new issues, one for each question.)

1. Is the reason you're capturing the writing mode for the cascade, or some other reason?
2. I think what you want to capture is the “writing mode”, not just writing-mode and direction, right? So you need to also capture text-orientation

@khushalsagar I think the same, do you have context about (1) or (2)?
.

3. You define “old image” as an ImageData, but actually I think we just want it to be a static 2D image. How it's stored or represented doesn't matter, what it is does.

Yea I was wondering what type to use. I'll used a ref-less 2D image instead of an ImageData.

4. I'm trying to understand the rendering model...
   4.1 What causes ::view-transition-new() to render the corresponding DOM element?

It doesn't render the DOM element, it renders an image that was captured from the DOM element.

4.2 What causes :root and its descendants to not render?

They do render, but captured elements are handled as visibility: hidden. this line captures it but needs rewording, I see that it doesn't say exactly what it's supposed to.

9. The last line of capturing seems to capture (:P) our earlier resolution that the pseudo-element's replaced content has a natural size and origin corresponding to the border box while capturing ink overflow. But where do we say that we paint the ink overflow for ::view-transition-old()?

At the end of https://drafts.csswg.org/css-view-transitions-1/#capture-the-image. We capture the ink overflow rect, but the observed geometry and natural size are the border box.

[khushalsagar]

Sorry for the late reply. Adding stuff on top of @noamr's reply.

• For 1 and 2, let's discuss more on [css-view-transitions-1] How do the writing-mode and direction properties affect the view-transition pseudo-elements? #8230. There's a few other related issues about when to use properties that correspond to logical vs physical coordinates which could use feedback : [css-view-transitions-1] top/left vs block-start/inline-start #8886 and [css-view-transitions-1] Size animation should use logical properties. #9057.

• For 4, how exactly it works is an implementation detail. The spec details how the browser should generate an image representation of an element. And characteristics about that image which is required by layout of replaced elements (like what its natural size is). The details required for compatibility across browsers. But how the browser hooks up that image into the replaced element is an internal detail.

  @noamr has a PR to make the spec clearer in this area: [css-view-transitions-1] A few clarifications and nits #9028

• For 5, sure here's a PR for it: [css-view-transitions-1] Update capture rendering characteristics #9059

• For 6, effects on the element (which apply to its descendants) are included in the capture. But if the element has an effect applied to it from an ancestor, that will be ignored. For example, if the element has opacity from anything in its ancestor chain, it will disappear during the transition. We want nested transition groups and more granular style capture to support these use-cases going forward.

  [css-view-transitions-1] Handling mix-blend-mode on elements captured for a transition #8962 is related to this.

• For 7, yeah we want to render the entire Document, including canvas background and any effects (like filter) which are on the document element's computed style but are lifted onto the root stacking context. Happy for suggestions to improve the wording here.

• For 8, yeah. Capture ignores any descendants which are captured in a view transition. It's in the spec here.

  Intentionally not saying those with a view-transition-name since cases like fragmentation ignore the view-transition-name property. I just realized though that captured in a view transition is only being set for elements in the new DOM but skipping independently transitioning elements in the snapshot needs to be done for old images as well. So might need to refactor the spec a bit.

[fantasai]

1. OK
2. Looks good
3. Looks good
4. OK
5. Looks good, but filed a follow-up at [css-view-transitions-1] Clarify that ink overflow is outside the image content box #8819 #9137
6. Looks good, but follow up question: [css-view-transitions-1] Where is “effects” defined? #9139
7. Sounds like this needs follow up, filed [css-view-transitions-1] Clarify that the whole canvas is captured not just root box #9138
8. “So might need to refactor the spec a bit.” ... so does this need a follow-up issue?
9. OK

A few nits on the Clarifications and Nits at #9028 (review) :)

[khushalsagar]

6. Commented on [css-view-transitions-1] Where is “effects” defined? #9139.
7. Thanks for filing this, it will need a think for the precise wording.
8. This was fixed by [css-view-transitions-1] Refactor VT old capture algorithm #9135.

And the remaining stuff you mentioned on #9028 (review) landed in #9143.

Since we have follow up issues for each of the above, let's close this and take it further on the follow up issues.