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

(2014/05/29 0:55), Sylvain Galineau wrote:
> Right, but the model has to make sense for use-cases first. Then you throw edge-cases at it to make sure it has answers for those. If I just look at this particular case I think we can argue pretty convincingly for or against firing events. (And, as we know from the interop situation you documented, the current spec pretty much allows implementors to go either way as well....)

Right. The model actually doesn't define these events (we tried but it 
was too hard to get events right when you have groups). So they are a 
CSS-specific feature. I probably misunderstood the discussion between 
you and Tab about the role of Web Animations here.

I think if we have animationstart events at all, they should be 
symmetrical with animationend events. I can imagine an app maintaining a 
tally of active animations by counting such events. (This could be used 
to tell when all animations have finished for taking a snapshot, or to 
gauge the load on the system.) Dispatching only an animationend event 
would confuse the tally.

I think if we say an animation that starts and ends in the past still 
applies a forwards fill, then it should dispatch an animationend event. 
An app that fades an element to opacity:0 might use the animationend 
event to remove the element from the DOM. Suppose this animation ends up 
running in the past (either due to author error, user styles, or because 
setting a negative delay was somehow easier than overwriting 
animation-duration to 0s to create an 'immediate' animation). So long as 
the element ends up with opacity:0, the animationend event should still 
fire so it can be removed from the DOM.

On the other hand, if we want to define animations in the past as not 
running and not applying a forwards fill, then I think they should not 
fire events.

What do you think?

Brian

Received on Thursday, 29 May 2014 01:16:56 UTC