- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 29 May 2014 10:16:24 +0900
- To: www-style@w3.org
(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