Re: [csswg-drafts] [css-view-transitions-1] Handle startVT for offscreen iframes (#9839)

Summary for another conversation on this, it's between the follow options. "Current Behaviour" is least preferred but mentioning for completeness.

### Force Rendering
If an offscreen iframe starts a ViewTransition force it to render, i.e., the UA is not allowed to throttle an iframe with a ViewTransition. We can relax it to say that this force mode is applicable until the pseudo-DOM is set up and animations (UA or author provided) have started.

Because once the animations have been setup, it's no different from a regular CSS or web animation on the page. The animation progresses based on its timeline an the UA can optimize rendering similar to other offscreen animations. When the animations finish, all the setup will be torn down.
   
The pro for this is it better aligns with how CSS and web animations work on the platform today, its not web observable whether the content is offscreen. And avoids edge cases where the iframe comes onscreen while the `updateCallback` is running, resulting in a flash of intermediate DOM state.

The con is its suboptimal. Regular CSS or web animations don't force the browser to render offscreen content, while this will because the old DOM state will be torn down. So it consumes compute and memory for content never shown to the user. It's also a footgun, both the main and iframe might not realize that transitions in offscreen iframes are costly.

### Skip transition
If the iframe is offscreen (based on a UA defined margin), transitions in it are skipped. The behaviour is the same as the Document being hidden, spec'd [here](https://drafts.csswg.org/css-view-transitions-1/#page-visibility-change-steps) and [here](https://drafts.csswg.org/css-view-transitions-1/#page-visibility-change-steps:~:text=If%20document%E2%80%99s%20visibility%20state%20is%20%22hidden%22%2C%20then%20skip%20transition%20with%20an%20%22InvalidStateError%22%20DOMException%2C%20and%20return%20transition.).

The pro/cons for this is inverse of "Force Rendering". Its more optimal but can result in flashing of intermediate DOM states if the iframe is scrolled offscreen. For example, an abrupt change in scroll position using scrollbars.

### Current Behaviour
The behaviour in the spec today is that after script calls startVT, the VT object is created and it waits for a rendering lifecycle update to cache the next frame. If the iframe is throttled, that rendering update won't happen until its un-throttled. So the iframe's VT would be blocked from starting until then.

The pro for this is that it takes care of both: don't use resources for offscreen content *and* don't flash intermediate DOM states. But it defers updating the DOM so the user unnecessarily sees stale content when the iframe comes onscreen. It's also possible the author is deferring some work until the transition's finished promise resolves, which is also delayed.

@nt1m @emilio fyi.

-- 
GitHub Notification of comment by khushalsagar
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9839#issuecomment-2045566336 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 9 April 2024 16:06:15 UTC