- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Oct 2022 23:46:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shared-element-transitions-1] Define "active animation" used to signal end of transition`, and agreed to the following: * `RESOLVED: only consider animations using document timeline for determining when the end of a view transition has come` * `RESOLVED: View animations are still active if there are running or paused view transition animations or any events in the pending event queue associated with animations on these pseudos` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-shared-element-transitions-1] Define "active animation" used to signal end of transition<br> <fantasai> khush, I think wrt group, since in e.g. SVG and vector editing, groups are a hierarchical concept<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/7785<br> <fantasai> khush, I think it's better not to use it for the image-pair-wrapper<br> <dael> khush: The bg for this issue is that the pseudo elements we just discussed generated for a transition are meant to be temporary. need to decide when it's torn down<br> <fantasai> khush, seems more appropriate for the higher-level construct that you can nest other things inside<br> <TabAtkins> q+<br> <dael> khush: We use declarative elments to decide. web animations, animations, transitions. raff -based are excluded b/c browser doesn't know when we're done. For these want to auto-detect done<br> <dael> khush: Wanted precise def for what state animations are in for active<br> <TabAtkins> Actually kind of a point of order for this<br> <dael> khush: Issue leaned to rely on animation state. Go through all pseudo elements and check for idle, running, paused<br> <dael> TabAtkins: The entire point of the issue I wrote is it's supposed to abort if any other shared element transition are running, not any other animation. I never intended for web or css animations to be part of it. When I wrote spec I presumed only 1 running shared element transition at a time and need to check.<br> <dael> khush: I think might be confusing different part of feature. This is have a single transistion going and need to know when it ends. That relies on the pseudo elements generated for the transition<br> <dael> TabAtkins: Possibly. I don't recall writing that but okay<br> <TabAtkins> Okay yes, I was misreading<br> <TabAtkins> Ignore me. 😅<br> <astearns> ack TabAtkins<br> <dael> khush: Clarify exact point. Started a transtion and have detected shared elements. Constructed full pseudo element tree. UA animations applied. Nw want to detect when tree can be torn down. We keep checking animastions on all pseudo elements. Need to define when animation is active for this transition<br> <dael> khush: I see IRC. Glad on same page<br> <dael> khush: On issue, concultion is check for any aniamation in running or paused. If yes, it's still acitve. Then check pending animation event queue. If there's something in there the's a pending event. Use case for that is chaining and we want to make sure all events chained<br> <dael> khush: Hoping to resolve on that<br> <dael> khush: Second is animation timeline. Animation uses doc timeline and we know timeline will progress. If you aheva scroll timeline the timeline progress dpends on if there's a scroll gesture.<br> <vmpstr> q+<br> <astearns> ack vmpstr<br> <dael> khush: Prop is ignore those for now b/c couldn't narrow down. When we decide a solution for raff we can handle similar or decide when have more idea of use<br> <dael> vmpstr: Even with doc timeline you can set up animation that loops so can get same situation<br> <dael> khush: True, but in that case it is easier to tell. With scroll timeline it's ambig since user gesture might never happen<br> <dael> astearns: Sounded like 2 things to resolve. Timeline first?<br> <dael> khush: Sure. Prop: Only consider animations using the document timeline in the active animation set<br> <dael> astearns: Opinions? Questions?<br> <dael> astearns: as I understand, only consider animations using doc timeline for determining when the end of a view transition has come<br> <dael> astearns: Concerns?<br> <dael> astearns: Obj?<br> <dael> RESOLVED: only consider animations using document timeline for determining when the end of a view transition has come<br> <ydaniv> only paused and running too, right?<br> <dael> astearns: Second<br> <dael> khush: Second For the animations we consider we consider them active if there's in running or paused and when there are not animations in the pending event queue<br> <dael> astearns: Can be animations on things other than view transform pseudos<br> <dael> khush: right.<br> <dael> khush: No animations on the pending event queue that correspond to these pseudos<br> <ydaniv> that's cool<br> <dael> astearns: Prop: View animations are still active if there are running or paused animations in the pending event queue associated with these pseudos<br> <dael> astearns: I imagine I may have something wrong<br> <dael> khush: View animations are still acitve if they are in runing or paused state and if there are any events in the pending event queue associated with them<br> <ydaniv> * View transition animations<br> <khush> View animations are still active if there are running or paused animations or any events in the pending event queue associated with animations on these pseudos<br> <dael> astearns: More discussion on this?<br> <dael> astearns: Objections?<br> <dael> astearns: One ammendment. View animations are still acitve if there are running or paused animations<br> <dael> astearns: One ammendment. View animations are still acitve if there are running or paused view transistion animations<br> <dael> khush: View animations means animations on any of thses pseudo elements<br> <dael> astearns: Obj?<br> <dael> RESOLVED: View animations are still active if there are running or paused view transition animations or any events in the pending event queue associated with animations on these pseudos<br> <dael> astearns: I see a comment in github while we discussed. He's asking about timelines to current document.<br> <dael> astearns: Is the comment something we can decide on or should we go back to the issue?<br> <astearns> https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1269109950<br> <dael> astearns: Comment ^<br> <dael> khush: I need to read on this more. Okay coming back for this<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1269115123 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 October 2022 23:46:38 UTC