- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Mar 2019 05:03:21 +0000
- To: public-css-archive@w3.org
> The missing piece (I think) would be how to compute the result of adding the final keyframes' styles, which may not be trivial. Right, especially if the animation is filling in between two keyframes. We may want to add an API for querying intermediate animation values in future anyway, but I think in this context the advantage of putting it on the events is that we snapshot the values. That's particularly important because the `Animation` should already be `replaced` by the time the `replace` event is processed (so it would be too late to query animation values without un-replacing the animation first). Snapshotting also makes this work correctly when we have multiple `replace` events (since clobbering specified style in one event callback won't affect the snapshotted value passed to the next event callback). > It would be nice to have more predictable behavior that "just works", whether that's replacing completed `fill: forwards` additive animation with a single generated fill: forwards animation I think that's essentially the `FillAnimation` proposal (but with coalescing of these generated animations, since otherwise we'd continue to leak). > something more noticeable like modifying the topmost animation or automatically applying the final value to the inline style. I'm a little averse to this because I'm afraid it will be surprising to the author if we silently update specified style or their `Animation` objects. I'm also afraid it will lead to awkward race conditions--more so than if we require authors to actually make the change themselves. (I believe we actually tried to implement updating specified style in a previous iteration of this discussion and it didn't work but I don't recall what the specific issue was.) -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3689#issuecomment-469538865 using your GitHub account
Received on Tuesday, 5 March 2019 05:03:38 UTC