Re: [css-animations] Animations that start and end in the past

On Jun 3, 2014, at 9:55 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Jun 3, 2014 at 9:24 AM, Sylvain Galineau <galineau@adobe.com> wrote:
>> On Jun 2, 2014, at 7:54 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
>>> Again, I'm ok with (a) but is it odd that:
>>> 
>>> animation: anim 3s -3s forwards;
>>> 
>>> Dispatches start and end and fills but:
>>> 
>>> animation: anim 3s -3.0001s forwards;
>>> 
>>> Dispatches nothing and fills?
>> 
>> I don't really see a way around this.
> 
> Well, the way around it is to define the behavior to not have
> discontinuities, and just always fire events.  ^_^
> 
> While it isn't an absolute argument, this kind of API design question
> has already been answered and documented in our wiki.  Unless there's
> a good reason *not* to do so, we should avoid discontinuities.
> 
Discontinuities does not worry me anywhere near as much as the usability of the API. And I do not believe this discontinuity to be any different from the ones we already have with css-animations events e.g. if you animation iterates, you may receive one more/one less iteration event by moving your negative delay .0001s forward/backward. This is no different.

I'd rather make the API simple, predictable and usable for the use-cases authors care about first, and then, if possible, predictable for edge cases. Firing start/end events after the animation's duration is inconsistent with not firing them during the initial delay; yet the latter is both what the spec and implementation require. It's really not clear to me why authors would expect start/end to fire beyond the animation's duration.

Beyond consistency and symmetry, this effectively overloads animationstart to reflect more than one thing: either a) the animation enters its execution phase and will go through some/all of its keyframe rules or b) it has been applied at a point on the time line that will not execute any keyframe rules. These are practically opposite outcomes. 

The better fix here imo would be to have a separate pair of events indicating the application of an animation and its overall completion, instead of overloading the existing start/end events with a contradictory meaning for some edge cases. In Brian's case, these events would both fire with the same elapsedTime. The animationapplied event might even, for instance, report the animation is applied but in the paused state etc.

I'm in favor of adding such events if people think they're useful, though I am not sure this is needed in L1.

We should try to get a WG resolution. Not yet sure if I can make tomorrow's call. Next week's at the latest.

Received on Tuesday, 3 June 2014 20:05:42 UTC