- From: Sylvain Galineau <galineau@adobe.com>
- Date: Wed, 20 Aug 2014 20:13:21 +0000
- To: Brian Birtles <bbirtles@mozilla.com>
- CC: Tab Atkins Jr. <jackalmage@gmail.com>, "<www-style@w3.org>" <www-style@w3.org>
On Aug 18, 2014, at 9:30 PM, Brian Birtles <bbirtles@mozilla.com> wrote: > On 2014/08/19 9:26, Tab Atkins Jr. wrote: >> On Mon, Aug 18, 2014 at 5:05 PM, Sylvain Galineau <galineau@adobe.com> wrote: >>> Resurrecting an old open issue [1]. >>> >>> I'm specifically proposing to resolve that it does apply per Øyvind's response [2]. >> >> Yes, it definitely should. If you don't want an animation, don't set one. > > Agreed. > >>> Note that whether start/end events fire in this case is indeed related though covered by separate issues though opinions on that bit are welcome. For now my higher-order bit is to resolve on whether animation-fill-mode is respected in this case. >> >> Ignoring any legacy constraints, I think they should fire. > > Agreed. > > We should avoid discontinuities where possible, particularly since animation-iteration-count is not necessarily an integer. > > The same is true of zero-duration animations. Right. In fact, we have prose that says animation-iteration-count:0 behaves like a 0s duration. And animation-duration says: # If the <time> is 0s, like the initial value, the keyframes of # the animation have no effect, but the animation itself still # occurs instantaneously. That is, animation-fill-mode applies # as normal, filling backwards or forwards as appropriate, and # animation events still fire. In other words, animation-iteration-count:0 will show the 0% keyframe when there is an animation-delay and animation-fill-mode is either 'backwards' or 'both. After the delay expires, the animation runs instantaneously and then uses the values defined by the 100%/to keyframe if animation-fill-mode is set to 'forwards' or 'both'. I think this is all implied but it might not hurt clarifying this interaction.
Received on Wednesday, 20 August 2014 20:13:55 UTC