RE: Animations issues (was Re: [CSSWG] Minutes Telecon 2012-12-12)

[Brian Birtles:]
> 
> Hi Sylvain,
> 
> Thanks very much for your response. I agree that point (iii), the question
> of whether start/end events reflect duration OR duration/interpolation, is
> the real question.
> 
> I've added a few more comments below.
> 
> (2012/12/20 13:49), Sylvain Galineau wrote:
> > [Brian Birtles:]
> > ...
> >> i) If in a future version, animations can be sequenced and an
> >> animation with a 3s duration but no keyframes is included in a
> >> sequence, we think one would still expect it to delay the next
> >> animation in the sequence by 3s. If it takes time, it seems reasonable
> to also fire events.
> >
> > So essentially using a @keyframes rule instead of animation-delay?
> > This suggests scenarios where the latter doesn't cut it. Any on your
> mind?
> 
> Yes, I agree that a delay is preferable. I *think* there may be some
> situations where you still end up with an animation with no keyframes but
> this is not a major issue.

Well, we do have an animation-delay property to introduce during which
your keyframe rules do not run. So my question here is: are there scenarios
where animation-delay does not fit and one would thus prefer an animation
with a duration but no keyframes rules?

> 
> (One example is that in Web Animations, for interoperability, if you
> create an animation but the target property is not supported in a given
> implementation (e.g. '-moz-transform') it still creates the animation but
> with a null animation effect. If that animation ends up in a sequence,
> then, from an interop point of view, I think it should still take up time
> as if it were doing something.)

Ah, that is a good point. If you sequence three animations A, B and C and you
want B to use its time regardless of the platform's ability to run its keyframe
rules then our preferred approach is a burden; the developer needs to figure
out whether to set a delay on C of the same length as B instead.

> 
> >> ii) In such a future scenario where sequencing and other
> >> synchronisation is possible, there are valid uses for empty
> >> animations--both to act as spacers in a sequence or simply to fire
> >> events at appropriate times for triggering other actions.
> >
> > We could make animation delays fire their own start/end events. That
> > leads us back to the previous comment.
> 
> So are you suggesting that if you have no keyframes you'd still fire
> 'animationdelaystart' and 'animationdelayend'?

You noted that a benefit of running empty animations was the ability to
use the start/end events to assign work to the 'spacers'. Given that we
already have animation delay this suggested to me that we may want those
intervals to have their own start/end events. Does that make sense?

> 
> I suppose that's reasonable. Is it odd that an animation with no keyframes
> produces 'animationdelaystart' and 'animationdelayend' but not
> 'animationstart' and 'animationend'? I guess this really relates to the
> next issue about the nature/meaning of these events.

Yeah, I agree it seems odd to say the animation can't start/end without keyframe
rules but its delay would run. If we don't animate then what are we delaying?

> 
> >> iii) We think it is useful to distinguish timing from the animation
> >> effect. If such a distinction is made then events are related to
> >> timing and should not depend on the animation effect.
> >
> > Indeed. That was my question during the call i.e. do start/end events
> > reflect only duration or both duration *and* interpolation? There is
> > support for the latter and at least two implementations support it.
> > (Though, interestingly, individuals' preferences do not always reflect
> > their browser's current behavior). In particular I do not think we
> > have really argued why this is the better behavior for authors.
> 
> Yes, I think (i) and (ii) are of lesser importance, and this is the main
> issue. I think start/end events should be considered timing events and
> reflect duration only. We could introduce animation-related events
> separately if needed (e.g. 'animationcomplete' meaning that the animated
> property has been set to its final value since this may happen prior to
> the end of the duration with some timing functions--this is not a serious
> proposal by the way since it has many problems, just an example).
> 
> Admittedly I'm largely approaching this from an architectural point of
> view since many animation technologies make this distinction between
> timing and animation. From an authoring point of view I'm less sure.
> 
> One use case that comes to mind is using an animation on '-moz-transform'
> to shrink a box down to nothing and then removing the element from the
> page in its 'animationend' event handler. If we deem that keyframes are
> invalid if the properties are not interpolable, and therefore animation
> events do not fire, such a function will break on all platforms that don't
> support '-moz-transform'. If events are still fired however even without
> valid keyframes, on UAs that don't support '-moz-transform' the box won't
> shrink, but it will still be removed at the end of the duration provided
> that the UA supports CSS Animations.
> That seems like a win for robustness.
> 
> >> In the Web Animations model, animations with no keyframes (and even
> >> those with no animation effect) still occupy time and fire events for
> >> the above reasons. If CSS decides otherwise that's not a major
> >> problem for us: the CSS bindings to Web Animations will simply
> >> require that no Animation object is created in that case. However,
> >> for the above 3 reasons, we wanted to quickly query the rationale
> behind this decision.
> >>
> > It's good to know it's not a major problem; it would at least seem
> > better for future authors if the models aligned, however.
> 
> Yes, agreed.
> 
> > The difference between IE/Firefox and Chrome suggests this has not
> > been an issue for content so far; we should be able to choose.
> 
> That's good to know.
> 
> Thanks again for your helpful response here.
> 
Not at all; this was great feedback.

Received on Thursday, 20 December 2012 17:05:14 UTC