- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 17:52:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Handle startVT/cross-doc transitions when Document is hidden`, and agreed to the following: * `RESOLVED: Skip transitions if the document state is hidden (or changes to hidden)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> khush: this is about what to do if, in any phase of he transition, the doc is hidden (you switch tabs)<br> <TabAtkins> khush: two quirky cases<br> <TabAtkins> khush: one, tab is hidden before you even cache the old dom's appearance<br> <TabAtkins> khush: In the spec we wait for a frame to happen so we can cache, and eventually time out<br> <TabAtkins> khush: confusing to authors<br> <TabAtkins> khush: second is we cache the screenshot, create the pseudo, but animations don't tick<br> <TabAtkins> khush: in principle they tick, like a web animation, but unless we queue a task for when the transition *should* finish we just hang onto the memory for the snapshot indefinitely<br> <TabAtkins> khush: both are bad. there's no reason to keep the machinery alive when the doc isn't visible. user should just see the new state when they arrive<br> <TabAtkins> khush: so proposal is, if the doc ever changes to hidden, just flip to the end state<br> <TabAtkins> khush: quiriker case is iframes. if you scroll it off-screen enough, browsers will throttle rendering<br> <emilio> q+<br> <TabAtkins> khush: so maybe another resolution - if an iframe isn't going to get rendering opportunities, just skip the transition. if needed i can go into detail about where that change will happen in html<br> <bramus> q+<br> <TabAtkins> khush: So first proposed resolution: if page is hidden, skip transitions.<br> <miriam> ack emilio<br> <TabAtkins> emilio: seems reasonable. what's the author-visible behavior? does promise reject or something else?<br> <noamr> q+<br> <flackr> q+<br> <TabAtkins> khush: there's already a bit in the API where a transition can skip to the end at any point.<br> <TabAtkins> khush: So all the promises define how they act in this case already<br> <TabAtkins> khush: [describes the promises behavior]<br> <TabAtkins> emilio: so that won't cause spurious exceptions... unless you await the ready promise?<br> <TabAtkins> emilio: Might be bad to test<br> <TabAtkins> TabAtkins: we dont' *reject* the promises, do we?<br> <TabAtkins> khush: we do reject the XXX promise because it indicates there is no pseudo-elements generated<br> <noamr> We reject the ready promise<br> <TabAtkins> khush: I'd expect most authors to have written error-handling code<br> <TabAtkins> emilio: ehhhhhhh<br> <TabAtkins> khush: if you do try to do something to the pseudo-element, your code will be wrong anyway and throw other errors<br> <TabAtkins> emilio: yeah my concern is just that it's really easy to write code that doesn't test for this<br> <TabAtkins> vmpstr: ready promise already rejects on timeout<br> <TabAtkins> emilio: ready promise is okay, i just don't want the other promises to reject<br> <miriam> ack bramus<br> <TabAtkins> bramus: Maybe we should only do that if animations are linked to document timeline?<br> <TabAtkins> khush: spec already says the only transition that holds the pseudo dom are those attached to document timeline<br> <TabAtkins> khush: So if the browser is slow internally or your callback is slow, that can already cause a timeout and reject the ready promise<br> <TabAtkins> khush: This also applies to cross-document transitions<br> <miriam> ack noamr<br> <TabAtkins> noamr: I think we already have spec language that says we can skip transitions for UA-defined reasons, that might be a good place to put the "if iframe is hidden" part since that's also UA-defined<br> <TabAtkins> noamr: And I suggest that if whole document is hidden (document.hidden) we should never expect a VT to work<br> <khush> q?<br> <TabAtkins> flackr: I didn't fully catch the reponse to Bramus' question, i think i have same concern<br> <noamr> q+<br> <TabAtkins> flackr: could create unpredictable behavior for transitions that last a long time or have a non-monotonic timeline<br> <miriam> ack flackr<br> <TabAtkins> bramus: it was covered<br> <TabAtkins> khush: If the only animations you ahve are non-document timeline'd, we already don't let you hold a transition forever<br> <noamr> q-<br> <TabAtkins> khush: when we walk thru the transitions and ask if there's anything that should keep the pseudo-dom alive, we ignore any that aren't attached to the document timeline<br> <TabAtkins> flackr: So you're not allowed to do this today<br> <TabAtkins> khush: Yeah, you'd have to manually hack it up<br> <TabAtkins> khush: There's an issue about us allowing raf/script-driven animations, and have an option to let people say "please dont' auto-shut-off my animation, I know what i'm doing"<br> <miriam> ack fantasai<br> <TabAtkins> fantasai: I hear emilio's concern about testing pathways<br> <TabAtkins> fantasai: but if we already have that problem, making it happen more often is helpful because it's more likely to occur in front of the dev<br> <TabAtkins> fantasai: re: what the user expects, since transitions should be temporary, it seems okay to just skip<br> <khush> q?<br> <vmpstr> q+<br> <TabAtkins> fantasai: so it seems that making them skip on hidden seems reasonable, and hopefully helps devs hit the error case more often if their code is broken<br> <miriam> ack vmpstr<br> <TabAtkins> vmpstr: the only thing from Bramus' point, there *are* cases where you want to control the animation with WebAnimations, so you can animation-play-state:paused and then respond to user input<br> <TabAtkins> vmpstr: Skipping on *those* cases if you swtich the tab seems unfortunate<br> <noamr> q+<br> <TabAtkins> khush: It's a behavior change you'd have to explicitly code for now<br> <TabAtkins> bramus: Isn't that already covered by the conditions?<br> <TabAtkins> khush: spec says keep the structure alive if the animation is running or paused<br> <TabAtkins> bramus: So should we remove the paused condition?<br> <TabAtkins> khush: I think I'm concurring with elika, since there are situations where this can occur already (gpu busy, your callback is longer than expected), in some cases the promise will reject already<br> <TabAtkins> khush: And in these scenarios the most logical thing to do is skip the transition<br> <miriam> ack noamr<br> <TabAtkins> noamr: The whole thing about paused transitions - at this time the document isn't interactive<br> <TabAtkins> noamr: It's a strange state, needs to be dealt with holistically<br> <TabAtkins> khush: proposed resolution: Skip transitions if the document state is hidden (or changes to hidden)<br> <TabAtkins> miriam: objections?<br> <TabAtkins> bramus: And this is with the current conditions in the spec right now?<br> <TabAtkins> khush: yes<br> <TabAtkins> RESOLVED: Skip transitions if the document state is hidden (or changes to hidden)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9543#issuecomment-1939242246 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 17:52:46 UTC