- From: Sylvain Galineau <galineau@adobe.com>
- Date: Thu, 17 Oct 2013 07:20:56 -0700
- To: Shane Stephens <shans@google.com>, www-style list <www-style@w3.org>
- CC: Steve Block <steveblock@google.com>
- Message-ID: <CE853E84.EBDB%galineau@adobe.com>
Indeed, I do not believe we ever clarified this; in particular, I think the current model assumes the animation hasn't started until the delay has elapsed (the delay is evaluated once while the animation may run for multiple iterations). So it's not clear whether animation-play-state: paused causes the delay to elapse and then freezes the animation; or if it also pauses the delay clock. The latter seems the better behavior for your specific scenario. I'd note that pause/resume events would also be useful; but if animation-play-state can pause delays they could fire before animationstart. From: Shane Stephens <shans@google.com<mailto:shans@google.com>> Date: Wednesday, October 16, 2013 8:44 PM To: www-style list <www-style@w3.org<mailto:www-style@w3.org>> Cc: Steve Block <steveblock@google.com<mailto:steveblock@google.com>> Subject: [css-animations] Starting animations with animation-play-state: paused Resent-From: <www-style@w3.org<mailto:www-style@w3.org>> Resent-Date: Wednesday, October 16, 2013 8:45 PM Hi list, The current ED defines the behavior of animations when setting animation-play-state: paused to be: "A paused animation will continue to display the current value of the animation in a static state, as if the time of the animation is constant." It seems likely that this is intended to be extended to animations that start paused - that is, animations that start paused should display the value at (- animation-delay). This isn't completely clear from the current wording, however, and neither Chrome nor Firefox currently exhibit this behavior. What is the intended behavior? Should we reword the specification to clarify this? Cheers, -Shane
Received on Thursday, 17 October 2013 14:21:29 UTC