W3C home > Mailing lists > Public > www-style@w3.org > December 2012

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

From: Brian Birtles <bbirtles@mozilla.com>
Date: Tue, 25 Dec 2012 08:52:31 +0900
Message-ID: <50D8EABF.7050105@mozilla.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>
Hi Sylvain,

Thank you very much again for your response. Sorry for my delay in 
getting back to you.

I think I had misunderstood about how you were suggesting animation 
delay could be used as a substitute for spacer animations but it is 
clear now.

If I could try to summarise what we have arrived at so far:

A) It seems that if CSS Animations are to be used in sequencing in the 
future, then having animations that refer keyframes with no supported 
properties fail to 'run' (in the sense of taking time) would be 
problematic from an interop/authoring point of view. If such animations 
'run', it is probably natural to expect that they would also fire 
animation events.

(Even without sequencing a similar situation already exists for the use 
case of shrinking a box to scale(0) using, e.g. '-moz-transform', and 
then removing the box on 'animationend'.)

B) From an architectural/abstract point of view it may be more 
consistent to treat start/end/iteration events as related to the 
animation's timing/duration and not its interpolation.

If that seems like a reasonable summary then I would suggest it would be 
more useful to make animations fire events regardless of the state of 
the @keyframes rule they refer to.

I would like to hear any objections to this. Are there important 
precedents this would break or implementation issues this would cause?

Best regards,

Brian

(2012/12/21 2:03), Sylvain Galineau wrote:
> [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 Monday, 24 December 2012 23:53:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT