- From: Sylvain Galineau <galineau@adobe.com>
- Date: Tue, 23 Sep 2014 22:44:02 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: "<www-style@w3.org>" <www-style@w3.org>
On Sep 23, 2014, at 3:39 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Sep 23, 2014 at 3:33 PM, Sylvain Galineau <galineau@adobe.com> wrote: >> On Sep 9, 2014, at 9:04 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> Event-handling needs to be dealt with here; we propose that start and >>> end events are fired once, and are guaranteed to fire, even if an >>> adjustment caused the actual start/end time to never be instantiated. >> >> I do not understand what the 'even if' clause means. Specifically, how we guarantee events to be fired even of the actual property values prevent them from ever being fired. Examples of what you had in mind may help. > > Hmm, didn't realize that was unclear. > > We discussed during the f2f the difference between events happening > "when they're played through" vs just when the logical constraints of > the problem would dictate they'd occurred. The iteration events are > the former - we only fire them as we "play through" an iteration > boundary, so you don't have to fire infinite events for the > "duration:0; iterations:infinite;" case, and so if you skip forward a > ton in an animation you don't have to fire all the intervening events. > Start/end are the latter; if the animation is currently at a progress > point past the start, then the start event must fire if it hasn't > already, even if we never "played through" the actual start (because > it had a negative delay, for example); same for end, if you adjust the > time to suddenly be past the end. > Check, that makes sense. Let's just say you were terse enough I couldn't connect it with this thread of the conversation. Thanks.
Received on Tuesday, 23 September 2014 22:44:31 UTC