- From: Shane Stephens <shans@google.com>
- Date: Wed, 23 Oct 2013 09:53:45 +1100
- To: Sylvain Galineau <galineau@adobe.com>
- Cc: Steve Block <steveblock@google.com>, www-style list <www-style@w3.org>
- Message-ID: <CAGTfzwR4zJiDFEQb2sdc=N0Er11_Wguu5wg=Zu4un0tS8=gGEw@mail.gmail.com>
(I rearranged your questions to make them easier to reply to) > I think your interpretation of start is: "Some frame of the animation is > visible; whether the animation timer is also running is irrelevant". I do > not think the spec explicitly supports this interpretation. Though it does > not explicitly exclude it either I do not understand why this would the > more useful behavior for authors. If an animation is 'paused at birth' I > think authors expect the start event to not fire until it is first set to > running, regardless of the sign of animation-delay. In addition, I think > authors may want to listen for pauses and resumes. No, my interpretation of start is that it should fire when an animation stops being inactive or filling, and starts being active - i.e. the animation is interpolating. > Note that the first frame of the animation may also be visible during a > positive animation-delay i.e. using animation-fill-mode. Since the visual > state of the animation is in its 'active region', do you think we should > fire animationstart as soon as the animation is applied in this case? No. This is filling, not active. > It seems most consistent with what? The start event is generally used to > trigger some other effect or processing associated with the beginning of > the animation. In particular, I might want to create an animation in the > paused state and then, based on user interaction (which could be a :hover > or :active), set it to running. Only then do I want my start event > listener to initiate some other related change. But if the start event can > fire immediately and independently of the animation actually running then > my event listener better also check for animation-play-state. Except it > won't be called again when the animation is actually un-paused. This makes > the event less useful imo. > Given that this can only produce a difference when the user has specified a negative start delay and paused the animation, I don't find your use case particularly compelling. In almost all cases there won't be any delay (or, somewhat less commonly a positive delay), and in these cases the start event won't fire until the animation is un-paused and the interpolating (active) region of the animation starts. Cheers, -Shane
Received on Tuesday, 22 October 2013 22:54:13 UTC