- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Aug 2020 05:33:10 +0000
- To: public-css-archive@w3.org
The spec gives a bit of a summary of the motivation and alternatives here: https://drafts.csswg.org/web-animations-1/#fill-behavior The interesting part with regard to fill modes is that most animation APIs (going back to SMIL upon which CoreAnimation etc. were built) use endpoint exclusive timing so at the exact point when an animation finishes, it has no effect--unless there is an appropriate fill mode set. That's useful for sequencing and repeating animations since it ensures they don't overlap but it's been causing problems for scroll-driven animations recently. (There a [bit of explanation in the SMIL spec](https://www.w3.org/TR/SMIL3/smil-timing.html#q101).) Unfortunately, we very likely can't change this very fundamental part of the model (and other specs like SVG etc. depend on it if we ever want to rebase them on Web Animations). However `commitStyles()` already has the special behavior that it applies removed animations so I suppose we could make it also have the special behavior of altering the timing model to sample a finished animation as if its (root) target effect had `fill: both` set. That would solve half of this issue and, I believe, the troubles @jakearchibald encountered. It's also possible this API is new enough that such a change would be Web compatible. It wouldn't change the behavior for animations which are already filling which is likely to be the majority case anyway. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5394#issuecomment-681542821 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 August 2020 05:33:12 UTC