- From: kevers-google via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Jul 2022 14:12:02 +0000
- To: public-css-archive@w3.org
With Timeline before/after phase being removed from web-animations-1, the hold phase is irrelevant. Rather than making animation.currentTime unresolved when in the timeline before/after phase, we now allow timeline.currentTime to extend beyond the range of 0 to 100%, and let the animation effect phase take care of the rest. This plays nicely with animation delays and is a simpler solution. Issue tracked here: https://github.com/w3c/csswg-drafts/issues/7240 The "unlimited current time" for the "at progress timeline boundary" calculation is new and intentional. the problem is that a finished animation has a start time and a hold time so the current time is clamped at end time and it appears that the timeline is at the boundary when it fact the in the after phase. This problem was previously mitigated by considering the timeline phase, but once the timeline phase is removed this safeguard becomes necessary. I'm still not overly keen on the method for detecting if at a boundary. The current method is trying to be overly clever and accommodate the playback rate. It might simply be better to detect if the timeline is at 0 or 100% and leave it at that. If the playback rate is not 1, then these boundaries simply won't align with the animation effect boundary, which seems fine. Having said that, I'd like to leave the choice of algorithm for a later discussion. The fix here was aimed at making the current algorithm work with the removal of timeline phase. -- GitHub Notification of comment by kevers-google Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/7487#issuecomment-1181811352 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 July 2022 14:12:04 UTC