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

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.

(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.)

>> 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'?

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.

>> 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.

Best regards,

Brian.

Received on Thursday, 20 December 2012 06:09:09 UTC