W3C home > Mailing lists > Public > www-style@w3.org > October 2014

Re: [CSS-animations] animation-fill-mode on partial iteration

From: Sylvain Galineau <galineau@adobe.com>
Date: Mon, 6 Oct 2014 18:33:27 +0000
To: "L. David Baron" <dbaron@dbaron.org>
CC: Estelle Weyl <estelle@weyl.org>, "<www-style@w3.org>" <www-style@w3.org>
Message-ID: <E967BFE6-9738-4A3C-9332-9DBF24DD46EC@adobe.com>

On Oct 3, 2014, at 3:33 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Friday 2014-10-03 15:06 -0700, Estelle Weyl wrote:
>> The spec and implementation are different when it comes to handling animation-fill-mode on a partial animation cycle.
>> 
>> Safari follows the spec.
>> The implementation of FF and Blink do not follow the spec, but make more sense.
>> Haven't tried IE. 
>> 
>> Example is at http://estelle.github.io/animation/files/halfiterationforwards.html.

>> Spec is at: http://dev.w3.org/csswg/css-animations/#animation-timing-function where it reads:
>> 
>> Note: If animation-iteration-count is a non-integer value, the animation will stop executing partway through its animation cycle, but a forwards fill will still apply the values of the 100% keyframe, not whatever values were being applied at the time the animation stopped executing.
>> 
>> Basically the spec says now "no matter where you are in the animation, jump to the 100% keyframe" which is what safari does. FF and Blink stay on the keyfraome where the partial animation ended.
>> 
>> Safari goes to the 100% keyframe even if the last iteration is 'reverse', which seemingly conforms to the spec, but truly doesn't look right if you were on the 99% keyframe.
>> 
>> Is the spec going to change to reflect blink's and FF's behavior? Or should i file a bug with chrome and FF? I am hoping the spec changes.
> 
> I'm not sure why the spec says what it does; it was added as part of
> the conversion of the spec to bikeshed, in:
> https://dvcs.w3.org/hg/csswg/rev/cd69f7e8600c

> https://dvcs.w3.org/hg/csswg/rev/3e45563964a5

> 
> Note that the first of these revisions removed prose saying
> otherwise:
> 
>  # If the value for 'animation-fill-mode' is ''forwards'', then
>  # after the animation ends (as determined by its
>  # 'animation-iteration-count'), the animation will apply the
>  # property values for the time the animation ended. When
>  # 'animation-iteration-count' is an integer greater than zero, the
>  # values applied will be those for the end of the last completed
>  # iteration of the animation (rather than the values for the start
>  # of the iteration that would be next). When
>  # 'animation-iteration-count' is zero, the values applied will be
>  # those that would start the first iteration (just as when
>  # 'animation-fill-mode' is ''backwards'').
> 
> I'm in favor of reverting this change.

There is definitely a number of changes in here that need review and may need reversal. This is one of them. I'll revert.


> 
> -David
> 
> -- 
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>             Before I built a wall I'd ask to know
>             What I was walling in or walling out,
>             And to whom I was like to give offense.
>               - Robert Frost, Mending Wall (1914)

Received on Monday, 6 October 2014 18:33:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC