- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 May 2024 16:42:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Handle startVT for offscreen iframes`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Khush, ping me with any difficulties or for review<br> <fantasai> khush: optimization that if an iframe is off-screen, we don't run lifecycle updates or slow them down<br> <fantasai> khush: So as an optimization, offscreen doesn't get animated<br> <fantasai> khush: During view transitions, looking for that refresh<br> <fantasai> khush: but for iframe won't refresh until iframe comes on screen<br> <fantasai> khush: given it's already off-screen, user isn't going to see any animation<br> <fantasai> khush: so suggestion that if it's offscreen, treat it as invisible<br> <fantasai> khush: or if iframe is detached from tree<br> <fantasai> khush: current spec is to skip the transition<br> <fantasai> khush: just update the DOM directly, since user won't see the animation anyway<br> <fantasai> khush: Question here is, what if iframe is not detached, but is far enough off-screen that it's not being animated by the browser<br> <emilio> q+<br> <fantasai> khush: currently what happens is transition once you bring it on screen<br> <fantasai> khush: other option is to skip the transition<br> <fantasai> khush: third option is to force the update and do the transition<br> <astearns> ack emilio<br> <fantasai> khush: once the browser has set up the animation, just like other animations the UA won't need ot run the animation, just update the timeline, as long as it's offscreen<br> <fantasai> emilio: I'm not a fan of forced-rendering, because it allows [missed]<br> <fantasai> emilio: you can call requestAnimationFrame and then startViewTransition<br> <fantasai> emilio: I tend to think current behavior is more consistent with regular animation frame would work<br> <vmpstr> q+<br> <fantasai> emilio: so I think current behavior is fine<br> <fantasai> emilio: skipping transition allows you to detect this more directly, I don't think it's great<br> <fantasai> emilio: we rely on the page not knowing whether it's throttled<br> <fantasai> khush: because iframe is not ??, can't they already detect offscreen?<br> <fantasai> emilio: well yeah, but you don't know if it's because of slow machine or because offscreen<br> <vmpstr> s/??/getting rAF callbacks/<br> <fantasai> emilio: can act somewhat differently, but iframe isn't allowed to unthrottle itself, which is what forced rendering would do<br> <astearns> ack vmpstr<br> <fantasai> ??: We'll timeout by the time the animation is on screen, so if call startViewTransition callback won't run until at least one rAF callback, and by that time we are likely to skip the transition<br> <astearns> s/??/vmpstr/<br> <fantasai> khush: timeout starts after we cache the old state. Just happens to ???<br> <fantasai> vmpstr: doesn't seem great<br> <fantasai> emilio: Should we change that so that the timeout starts when you actually call the API?<br> <fantasai> khush: don't see any reason not to<br> <khush> q+<br> <fantasai> astearns: other questions/comments?<br> <fantasai> emilio: Given we unthrottle not exactly when you're in the viewport bounds, but in some range, likely that by the time you scroll to the iframe transition has finished anyway<br> <fantasai> stephenfromgoogle: Is throttling behavior thought to be interoperable at this time? Vague in the spec.<br> <fantasai> stephenfromgoogle: would we introduce an interop issue if we don't force rendering?<br> <vmpstr> +1<br> <fantasai> flackr: that was one of my concerns about not forcing rendering. it would expose more of those differences in behavior<br> <fantasai> emilio: that difference is already exposed by rAF tagging<br> <astearns> s/tagging/timing/<br> <fantasai> emilio: I think it's somewhat reasonably interoperable, at least I assume all browsers to be throttling visibility:hidden and very far off screen<br> <fantasai> emilio: this is an area that could get improvement, especially now that lazyloading thresholds are a thing<br> <flackr> q+<br> <fantasai> stephenfromgoogle: I can tell you, our throttling code in Chromium has no margin. If an iframe is even 1px outside viewport, it will be throttled. That's different form lazyloading, which does have a margin.<br> <fantasai> emilio: worth discussing in an HTML spec issue<br> <fantasai> emilio: in any case, I still think forced rendering is not a great option<br> <fantasai> emilio: if you call startVT, then you can force engine to unthrottle you all the time, which is not great<br> <astearns> ack khush<br> <fantasai> khush: +1 everything Emilio said<br> <fantasai> khush: especially for one frame<br> <vmpstr> q+<br> <fantasai> khush: with other CSS animations, unless animating we don't need to spend resources on it, but here do<br> <fantasai> khush: so would prefer current behavior<br> <fantasai> khush: Yes, different browsers use different margins, and different features have different margins, being exposed doesn't seem like a big constraint<br> <astearns> ack flackr<br> <fantasai> flackr: difference with animations is that you can always produce the thing that would have been drawn<br> <fantasai> flackr: whereas with VT, once you draw the updated, you have destroyed the old state<br> <fantasai> flackr: can't recover if it suddently becomes visible<br> <fantasai> flackr: One use case was starting a view transition on a frame, and then bring it into view<br> <fantasai> flackr: maybe there's an alternative to consider who's starting the transition<br> <fantasai> flackr: if starting within hidden frame, ... but if starting from root frame, could unskip frame by moving it into view?<br> <astearns> ack vmpstr<br> <fantasai> vmpstr: whether we keep these frames alive or not is also a function of whether started when iframe on screen and then moved offscreen or started offscreen<br> <fantasai> vmpstr: Also don't understand concern wrt frame throttling. You could set timeouts and force rendering in a script<br> <fantasai> vmpstr: why would they use VT to unthrottle?<br> <fantasai> flackr: Browsers can force minimum timeouts on setTimeout<br> <fantasai> vmpstr: it would force it to run rAF?<br> <fantasai> vmpstr: iframe would do more work?<br> <fantasai> flackr: yes, it would force it right away, but setTimeout would wait a second<br> <fantasai> vmpstr: what's the attack vector here?<br> <fantasai> emilio: I'm not sure whether there's a good way... I've seen frames consuming too much CPU unintentionally<br> <fantasai> emilio: I can't think of a recent case where they do it intentionally<br> <fantasai> dholbert: maybe an ad wants to start playing immediately rather than skipping a few frames, so continuously burns CPU in the background so it's ready<br> <fantasai> khush: use case I'm concerned is, it's hard for an iframe to do the right thing without a lot of code<br> <fantasai> khush: whereas with other animations, just browser doesn't spend resources. This is the first case where we would force rendering<br> <fantasai> vmpstr: more wondering about second case<br> <fantasai> vmpstr: we could enforce setTimeout limits<br> <fantasai> vmpstr: concerned that you call your startViewTransition for some effect, and that will only start running when you're on screen<br> <emilio> q+<br> <fantasai> vmpstr: so I would force rendering or skip trnasition, but not doing thing until on screen<br> <astearns> ack emilio<br> <fantasai> emilio: alternatively set timeout mechanism to start when you call API?<br> <fantasai> vmpstr: [missed]<br> <flackr> q+<br> <fantasai> vmpstr: much better than current behavior<br> <astearns> ack flackr<br> <fantasai> flackr: one possibility, when we start the animation we could start it with a negative start delay, so that it would be timed as if it had started on time<br> <vmpstr> s/[missed]/it's timing dependent -- whether you've scrolled the frame into view within the timeout or not/<br> <fantasai> flackr: this would basically defer the work until the animation became visible<br> <fantasai> khush: you'd have to render to cache?<br> <fantasai> flackr: when it becomes visible. If it doesn't become visible until end of duration, then you can skip it<br> <fantasai> khush: complexity of all the animation after caching old DOM, you still have to do at least one render to cache it<br> <fantasai> flackr: or you defer the dom change<br> <fantasai> khush: which pseudo-elements get rendered depends on the new DOM<br> <fantasai> khush: we don't know until we run the callback<br> <fantasai> flackr: you defer until it becomes visible<br> <fantasai> flackr: when it becomes visible, you do pre-snapshot, you do the update, you determine animations, and you determine that the animations are finished, so immediately jump to end state<br> <fantasai> khush: sounds like skip<br> <fantasai> flackr: except it fires all the events<br> <fantasai> flackr: and [missed]<br> <fantasai> flackr: it's only "skipped" ...<br> <fantasai> khush: what's the goal? we don't want the author to know we skipped it?<br> <fantasai> flackr: there's no difference between whether your frame was on screen or offscreen<br> <fantasai> flackr: if it comes on-screen during animation, you'll see the animation<br> <fantasai> flackr: I haven't fully thought this out, but thinking that if you know when the request to start the animation occurred, that's the start of your timeline<br> <fantasai> khush: like current behavior, except animations will finish faster<br> <fantasai> emilio: might also be consistent with how time-based CSS animations work<br> <fantasai> emilio: if you have an iframe, and then scroll down, by the time you scroll up again the browser has done no rendering updates, but animation jumps to the correct point<br> <fantasai> emilio: that's worth consideration<br> <fantasai> vmpstr: capture right now can take some amount of time, and so that time would then be immediatley skipped into the animation, which won't be a smooth experience<br> <fantasai> vmpstr: essentially the animation start waits until the capture is available; with this change it would be a frame or two of delay<br> <khush> q+<br> <fantasai> vmpstr: so those first 2 frames would be immediately skipped into the third frame of the animation, which is not ideal<br> <fantasai> flackr: that's a fair concern, possible ways to mitigate that<br> <fantasai> flackr: you take the time until the frame started as your negative start delay<br> <fantasai> vmpstr: worth considering this model, but need to be careful about the math<br> <astearns> ack khush<br> <fantasai> khush: my issue is this approach is complicated. What benefit do we derive from it?<br> <fantasai> khush: ...<br> <fantasai> khush: what's the benefit of bringing iframe on screen with the old DOM?<br> <emilio> q+<br> <fantasai> vmpstr: it supports cases of, suppose your animation is 30s and starts offscreen, and then you scroll it into view partway through<br> <fantasai> vmpstr: it looks like everything was working all along<br> <fantasai> khush: you eventually want user to see the new state<br> <fantasai> khush: point of doing animation is to go from old state to new state nicely<br> <fantasai> astearns: maybe we should look at the new option and bring it back<br> <astearns> ack emilio<br> <fantasai> emilio: perhaps more realistic use case for this model is, consider a lazyloaded iframe<br> <fantasai> emilio: page being loaded has a view transition while loading<br> <fantasai> emilio: right now, given stephen's comment about no margin<br> <fantasai> emilio: lazyloading kicks in first, page is invisible, then you call startViewTransition. If you skip it, then you discard everything the author wanted even though user is about to scroll the iframe<br> <flackr> +1<br> <fantasai> emilio: That model doesn't seme too complicated, just need to handle the first two frame jump<br> <fantasai> emilio: It behaves more consistently with our APIs also<br> <fantasai> emilio: rAF we just delay your callback, this seems similar<br> <fantasai> emilio: I think there are more use cases that justify this kind of model<br> <astearns> ack fantasai<br> <fantasai> fantasai: basically agree with astearns and emilio<br> <fantasai> fantasai: let's explore flackr's model, and come back<br> <fantasai> vmpstr: ok, let's look into the issue and comment with our findings<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9839#issuecomment-2100983884 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 May 2024 16:42:09 UTC