- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 13:26:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] How should scroll timeline animations be treated?`, and agreed to the following: * `RESOLVED: Add .waitUntil() promise to the VT object, prevents VT from finishing until the promises settle` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> bramus: When the animations contained in a VT all reach the finished state, the VT itself also reaches finished, and goes away<br> <TabAtkins> bramus: When implementing draggable VTs, or scroll-driven, there's a need to prevent that from happening.<br> <TabAtkins> bramus: If you touch the screen and drag the animation, you hit the bottom it reaches 100%, but if you drag back up you still want it to reverse.<br> <TabAtkins> bramus: So request is to prevent it from reaching that finished state<br> <khush> q+<br> <TabAtkins> bramus: Proposal is to add a method on the VT object that prevents it from finishing. Propose .preventAutoFinish()<br> <ydaniv> q+<br> <TabAtkins> bramus: But also a counterpart for allowAutoFinish(); if you lift your finger and it's finished you want to really finish it<br> <astearns> ack khush<br> <flackr> q+<br> <TabAtkins> khush: Two things to add. Similar cam efor scroll-driven, if you're doing something in a rAF loop the brwoser can't tell when you're done<br> <TabAtkins> khush: the other is the API option I added on the issue is a new api called waitUntil() which takes a promise<br> <TabAtkins> khush: lets you combine the browser figuring out when the animation is done and other things<br> <ydaniv> q-<br> <TabAtkins> khush: Also good because multiple parts can each call .waitUntil() and give their own promise, and it won't be done until they all settle<br> <astearns> ack flackr<br> <TabAtkins> flackr: for the animations case, WA has an .isCurrent concept for if the animation can continue to produce updates. we use that for .getAnimations() too, ,to return animations that are finished but can become active again<br> <TabAtkins> flackr: so VT might want to use this instead of the strict "finished" concept<br> <TabAtkins> flackr: but khushal pointed out ones driven entirey by the user. maybe do that with CustomEffect, called out in WA spec. A JS animation that's driven by a declarative aniamtion of some duration.<br> <bramus> On the side: demo of a (hacked together) Scroll-Driven View Transition: https://codepen.io/bramus/pen/BabRVLg<br> <TabAtkins> khush: I'm not sure about asking devs to use CustomEffect for something like this<br> <TabAtkins> khush: right now they work around it by setting up an infinite declarative animation, and just call abort when they're done<br> <TabAtkins> khush: there's a need for a pattern when they don't want or need anything declarative, doing it all in script, and just want an easy way to teell the browser when they're done<br> <TabAtkins> flackr: I think you could do the similar thing with an infinite duration customeffect, and you just cancel that when you're done animating<br> <bramus> q+<br> <TabAtkins> flackr: whether it's better is an open question, it just avoids the need for an additional api, which might be nice<br> <TabAtkins> khush: right now in the spec we ignore animations unless they use tehe doucment timeline. this was because it was hard to reason about the scroll timeline not finishing, etc<br> <TabAtkins> khush: now if the author overrides all animations with scroll timeline, is it possible for the browser to automatically identify when the animation is done?<br> <TabAtkins> flackr: no, they'd be considered to be permanently active<br> <astearns> ack bramus<br> <TabAtkins> khush: the new api was meant to address that too<br> <TabAtkins> bramus: wanted to mention animations using a non-document timeline<br> <emilio> q+<br> <TabAtkins> bramus: right now the behavior is if you drag outside the specified range, the VT gets zapped, i want to prevent that<br> <TabAtkins> flackr: .isCurrent "fixes" that, but it means we'd never be done with the VT<br> <TabAtkins> bramus: which isn't something you want since while tehe VT is running the snapshots are inert<br> <TabAtkins> khush: reading bramus's proposal, i don't mind the explicit finish call, but then you have to have in userland when all the animations are done<br> <TabAtkins> khush: the waitUntil() proposal lets each point hook in their own promises so userland doesn't have to manage things<br> <TabAtkins> bramus: so for a demo - i'd start on pointerdown, prevent it from autofinishing, then on pointerfinish unlock it again<br> <ydaniv> q+<br> <astearns> ack emilio<br> <TabAtkins> TabAtkins: You can just start a promise on pointerdown, resolve it on pointerup. then it's back under browse control<br> <TabAtkins> emilio: I think I'd prefer a prevent - the non-promise version, because building the promise on top seems more trivial. easy to leak with promises.<br> <TabAtkins> emilio: seems simpler that a bug is becuase someone didn't call .finish() versus tracking a never-resolved promise<br> <TabAtkins> emilio: but no strong objection either way. just feels like providing the lower-level api is a little nicer, a little less footgunny<br> <TabAtkins> flackr: devil's advocate, the one thing harder with the direct api is coordinating between libraries<br> <TabAtkins> flackr: one library might say it's done and end it<br> <TabAtkins> flackr: maybe not a strong reason, just pointing it out<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: i'm concerned it might be risky to give any api and then everything can get stalled<br> <TabAtkins> ydaniv: what if we default to if you reach 100% plus a scrollend was fired. would that be a reasonable default?<br> <TabAtkins> bramus: I think that's specifically targeted to this one use-case for scrolling, there might be more.<br> <TabAtkins> bramus: I'm also coming around more to the promises, there's a lot of promises on the web.<br> <TabAtkins> khush: the demos we've seen involve taking raw touch events and mapping them to gestures without having a scroll container<br> <TabAtkins> astearns: for my clarity, the promise-based is an alternative to the bare prevent/allowFinnish() calls<br> <TabAtkins> astearns: is there a summary of the promise-based that could be added?<br> <bramus> s/allowFinnish/allowFinish<br> <khush> transition.waitUntil(promise) keeps transition from finishing until all promises passed to waitUntil settle<br> <TabAtkins> (can be called multiple times to add promises to the list)<br> <TabAtkins> astearns: do we want to resolve, or take it back to the issue?<br> <flackr> q+<br> <TabAtkins> bramus: can we bikeshed the name? waitUntil() can be a little confusing...<br> <TabAtkins> TabAtkins: waitUntil() is already used in Service Worker for exactly this purpose<br> <astearns> ack flackr<br> <TabAtkins> flackr: I was gonna have a minor complaint about adding complexity, but if there's precedent...<br> <TabAtkins> emilio: I'm okay resolving on it. I think I'd rather build the simpler thing first, but not a super stron gopinion either way.<br> <TabAtkins> astearns: If we do this, is there a possibility we'll add the lower-level one anyway<br> <TabAtkins> TabAtkins: They can be layered either way - both can be built on top of the other<br> <TabAtkins> astearns: so proposal is to add a .waitUntil(promise) that keeps the transition from settling until all of the promises settle.<br> <TabAtkins> RESOLVED: Add .waitUntil() promise to the VT object, prevents VT from finishing until the promises settle<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9901#issuecomment-2165674531 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 13:26:57 UTC