Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define how the transition DOM is painted. #92

Closed
vmpstr opened this issue Nov 17, 2021 · 3 comments
Closed

Define how the transition DOM is painted. #92

vmpstr opened this issue Nov 17, 2021 · 3 comments

Comments

@vmpstr
Copy link
Collaborator

vmpstr commented Nov 17, 2021

For the live element snapshot, we need to capture the root element and then put it inside a pseudo element in the top layer. But the root element snapshot includes the top layer as well. That introduces a circularity into the captured content.

Do we need to introduce special casing for capturing the root but excluding the top layer transition elements?

Possibly related: #76

@vmpstr vmpstr added this to untriaged in open question triage Nov 17, 2021
@vmpstr vmpstr moved this from untriaged to agenda in open question triage Nov 17, 2021
@khushalsagar
Copy link
Collaborator

Capturing a discussion with @vmpstr and @chrishtr today on this issue. This is related to the questions in #76 and #68.

TLDR: The DOM structure we're generating to render the shared element snapshots needs to paint in a new stacking context that's above the top layer. This is necessary to capture the entire page content (including other elements in the top layer).

Currently the root stacking context has the following hierarchy :

root stacking context
|_ root element (html) stacking context
|_ top-layer-element#1 stacking context
|_ top-layer-element#2 stacking context

During a transition, we generate the following DOM hierarchy where one element is displaying the "root image". Something like :

transition stacking context
|_ live root image (for the new page)
|_ cached root image (for the old page)

The current proposal suggests painting the transition stacking context into the root stacking context like other top layer elements. But this makes it difficult to explain how the root image is generated. We considered an option where the root image is the output of the root element's stacking context. But this implies that the top layer elements are excluded from this image. A compromise could be to not support transitions when there is other content in the top layer but that would exclude multiple common cases (like dialog or same-document fullscreen transitions).

Ideally, the live root image should be the output of the root stacking context (clipped to viewport bounds). But this requires the transition stacking context to paint above the root stacking context so it can use its output. The new proposal is to create the following stacking context hierarchy during a transition :

uber-root stacking context
|_ root stacking context
|_ transition stacking context

This introduces a new stacking context (called uber-root) which is created during a transition. The root stacking context and the transition stacking context are siblings underneath this uber-root stacking context (similar to the relationship between root element and top layer elements within the root stacking context).

The live root image in the transition stacking context will use the output of the root stacking context (this defines how the output of element(html) is being generated). Just like shared elements are not displayed in the actual DOM, the root stacking context is also not painted while it is being displayed as a live root image.

@khushalsagar
Copy link
Collaborator

The different stacking context also helps ensure that effects which are on the root element and lifted to the root stacking context (therefor apply to top layer elements also) won't affect the context in the transition stacking context.

These effects are mentioned in w3c/fxtf-drafts#282 (comment)

@vmpstr vmpstr moved this from agenda to resolved in open question triage Nov 23, 2021
@khushalsagar khushalsagar changed the title When capturing the root snapshot, how to deal with capturing top layer Define how the transition DOM is painted. Nov 23, 2021
@khushalsagar
Copy link
Collaborator

khushalsagar commented Nov 23, 2021

The first option we considered for painting the transition DOM was in the top layer. This makes the transition DOM a sibling of the root element and every other element which is the top layer in the stacking context hierarchy.

This caused the following issues :

  • It's unclear how to generate the root image in a way that includes top layer content. We had considered defining it as an image of the root element but this would exclude top layer content by design.
  • The effects on the root element which are lifted to the root stacking context (background-color, filter) are also difficult to capture.

The second option is to introduce a new stacking context above the root stacking context during a transition. The root stacking context and transition DOM are siblings under this stacking context (similar to the root element and top layer elements being siblings within the root stacking context). The root image is then defined as the output of the root stacking context.

The second option is what we're going with. One detail worth highlighting is that similar to how shared elements are not painted within their original stacking context (as if they have opacity:0) while they are being displayed in the transition DOM, the root stacking context behaves similarly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
open question triage
closed (explainer updated)
Development

No branches or pull requests

2 participants