[css3-animations] dynamic changes to animation properties or keyframes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[css3-animations] dynamic changes to animation properties or keyframes

L. David Baron
http://dev.w3.org/csswg/css3-animations/#animations says:
  # The values used for the keyframes and animation properties are
  # snapshotted at the time the animation starts. Changing them
  # during the execution of the animation has no effect. Note also,
  # that changing the value of ‘animation-name’ does not necessarily
  # restart an animation (e.g. if a list of animations are applied
  # and one is removed from the list, only that animation will stop;
  # The other animations will continue). In order to restart an
  # animation, it must be removed then reapplied.

This doesn't appear to match WebKit's behavior.  For example, in the
following testcase:

<!DOCTYPE HTML>
<title>animation test</title>
<style>
@-webkit-keyframes bounce {
  from, to { top: 100px }
  50% { top: 0px }
}
p {
  position: relative;
  -webkit-animation: bounce 4s linear infinite;
}
#hover { background: yellow }
#hover:hover p { -webkit-animation-duration: 1s }
</style>
<div style="height: 100px" id="hover">
<p>hello</p>
</div>

hovering over the yellow div makes the animation speed up, but
preserves its start time.

It seems relatively easy to handle dynamic changes here -- though
perhaps the main use case for doing so is to avoid having authors
get confused if they do things in the wrong order while setting up
an animation, or accidentally flush before it's all set up properly.

Should the spec say instead that dynamic changes are honored, but
the animation start time (as adjusted by pause duration) is
preserved for each animation name?

(Was there a reason WebKit's behavior differs from the spec here?)

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Reply | Threaded
Open this post in threaded view
|

Re: [css3-animations] dynamic changes to animation properties or keyframes

L. David Baron
On Saturday 2011-04-02 12:14 -0700, L. David Baron wrote:

> http://dev.w3.org/csswg/css3-animations/#animations says:
>   # The values used for the keyframes and animation properties are
>   # snapshotted at the time the animation starts. Changing them
>   # during the execution of the animation has no effect. Note also,
>   # that changing the value of ‘animation-name’ does not necessarily
>   # restart an animation (e.g. if a list of animations are applied
>   # and one is removed from the list, only that animation will stop;
>   # The other animations will continue). In order to restart an
>   # animation, it must be removed then reapplied.
>
> This doesn't appear to match WebKit's behavior.  For example, in the
[...]
> Should the spec say instead that dynamic changes are honored, but
> the animation start time (as adjusted by pause duration) is
> preserved for each animation name?

I'd note that if the spec does take this approach, it needs to
describe what happens when an animation-name occurs more than once
in the list of animations:  in that case, I believe the start time
for a given animation-name should always track the
animation-play-state value of the last occurrence of that
animation-name in the list of animations.

This is what I implemented in Gecko.

I think this behavior is preferable since in most cases the last
occurrence overrrides earlier ones, which means it's the most likely
of any simple rule to reflect the current state.  (This isn't true
for some values of animation-fill-mode if some of the animations
have completed (or not started yet) and some have not (e.g., because
they have different durations).  It also might not be true if we
allow a property to apply for only a part of animation (though Gecko
currently does not, as I described in [1]).

I'd note that this means that authors will get weird behavior if
they use multiple occurences of the same animation on the same
element *and* dynamically change the animations list on that
element.  But I think that's probably a cost worth paying to have
otherwise-sensible behavior when changing the animations list on an
element.

-David

[1] http://lists.w3.org/Archives/Public/www-style/2011Apr/0645.html

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Reply | Threaded
Open this post in threaded view
|

Re: [css3-animations] dynamic changes to animation properties or keyframes

Øyvind Stenhaug
On Sun, 06 Nov 2011 20:48:53 +0100, L. David Baron <[hidden email]>  
wrote:

> On Saturday 2011-04-02 12:14 -0700, L. David Baron wrote:
>> http://dev.w3.org/csswg/css3-animations/#animations says:
>>   # The values used for the keyframes and animation properties are
>>   # snapshotted at the time the animation starts. Changing them
>>   # during the execution of the animation has no effect. Note also,
>>   # that changing the value of ‘animation-name’ does not necessarily
>>   # restart an animation (e.g. if a list of animations are applied
>>   # and one is removed from the list, only that animation will stop;
>>   # The other animations will continue). In order to restart an
>>   # animation, it must be removed then reapplied.
>>
>> This doesn't appear to match WebKit's behavior.  For example, in the
> [...]
>> Should the spec say instead that dynamic changes are honored, but
>> the animation start time (as adjusted by pause duration) is
>> preserved for each animation name?
>
> I'd note that if the spec does take this approach, it needs to
> describe what happens when an animation-name occurs more than once
> in the list of animations:

I think the spec needs to describe that regardless.

I can think of two main approaches. Using

@keyframes name { foo }
#test { animation: name 1s, name 2s }

as an example:

a) Behave similarly to

@keyframes name1 { foo }
@keyframes name2 { foo }
#test { animation: name1 1s, name2 2s }

b) Behave similarly to

@keyframes name { foo }
#test { animation: name-that-matches-no-at-rule 1s, name 2s }

Where option a) seems kind of nice (can effectively have multiple  
animations re-using the same @keyframes rule).

> in that case, I believe the start time
> for a given animation-name should always track the
> animation-play-state value of the last occurrence of that
> animation-name in the list of animations.

I am unable to decode the meaning of that sentence. Can you give an  
example, perhaps?

> I'd note that this means that authors will get weird behavior if
> they use multiple occurences of the same animation on the same
> element *and* dynamically change the animations list on that
> element.  But I think that's probably a cost worth paying to have
> otherwise-sensible behavior when changing the animations list on an
> element.

I think I prefer what the spec currently says (snapshot the values). Even  
with different animation names, the behavior in both Gecko and Webkit  
still seems weird when I try to dynamically change things.

--
Øyvind Stenhaug
Core Norway, Opera Software ASA

Reply | Threaded
Open this post in threaded view
|

Re: [css3-animations] dynamic changes to animation properties or keyframes

Tab Atkins Jr.
On Thu, Dec 1, 2011 at 5:04 AM, Øyvind Stenhaug <[hidden email]> wrote:

> On Sun, 06 Nov 2011 20:48:53 +0100, L. David Baron <[hidden email]>
> wrote:
>
>> On Saturday 2011-04-02 12:14 -0700, L. David Baron wrote:
>>>
>>> http://dev.w3.org/csswg/css3-animations/#animations says:
>>>  # The values used for the keyframes and animation properties are
>>>  # snapshotted at the time the animation starts. Changing them
>>>  # during the execution of the animation has no effect. Note also,
>>>  # that changing the value of ‘animation-name’ does not necessarily
>>>  # restart an animation (e.g. if a list of animations are applied
>>>  # and one is removed from the list, only that animation will stop;
>>>  # The other animations will continue). In order to restart an
>>>  # animation, it must be removed then reapplied.
>>>
>>> This doesn't appear to match WebKit's behavior.  For example, in the
>>
>> [...]
>>>
>>> Should the spec say instead that dynamic changes are honored, but
>>> the animation start time (as adjusted by pause duration) is
>>> preserved for each animation name?
>>
>> I'd note that if the spec does take this approach, it needs to
>> describe what happens when an animation-name occurs more than once
>> in the list of animations:
>
> I think the spec needs to describe that regardless.
>
> I can think of two main approaches. Using
>
> @keyframes name { foo }
> #test { animation: name 1s, name 2s }
>
> as an example:
>
> a) Behave similarly to
>
> @keyframes name1 { foo }
> @keyframes name2 { foo }
> #test { animation: name1 1s, name2 2s }
>
> b) Behave similarly to
>
> @keyframes name { foo }
> #test { animation: name-that-matches-no-at-rule 1s, name 2s }
>
> Where option a) seems kind of nice (can effectively have multiple animations
> re-using the same @keyframes rule).

(a) is effectively equivalent to (b), since a later animation
manipulating the same property as an earlier animation wins.  The only
difference is when you're measuring the start or end of transitions
via the JS events.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css3-animations] dynamic changes to animation properties or keyframes

David Vest
On Thu, 1 Dec 2011 08:31:42 -0800, "Tab Atkins Jr." <[hidden email]> wrote:

> On Thu, Dec 1, 2011 at 5:04 AM, Øyvind Stenhaug <[hidden email]> wrote:
> > I can think of two main approaches. Using
> >
> > @keyframes name { foo }
> > #test { animation: name 1s, name 2s }
> >
> > as an example:
> >
> > a) Behave similarly to
> >
> > @keyframes name1 { foo }
> > @keyframes name2 { foo }
> > #test { animation: name1 1s, name2 2s }
> >
> > b) Behave similarly to
> >
> > @keyframes name { foo }
> > #test { animation: name-that-matches-no-at-rule 1s, name 2s }
> >
> > Where option a) seems kind of nice (can effectively have multiple animations
> > re-using the same @keyframes rule).
>
> (a) is effectively equivalent to (b), since a later animation
> manipulating the same property as an earlier animation wins.  The only
> difference is when you're measuring the start or end of transitions
> via the JS events.

No, a previous animation may be visible during the animation-delay
period:

  <style>
  @keyframes move {
    from { left:   0px; }
    to   { left: 100px; }
  }

  div {
    animation-name:          move,    move;
    animation-duration:        2s,      2s;
    animation-delay:           0s,      3s;
  }

  div {
    width: 100px;
    height: 100px;
    background-color: blue;
    position: relative;
  }
  </style>
  <div></div>

The example would give me two movements with model (a) and one movement
with model (b). I prefer the former.

David

Reply | Threaded
Open this post in threaded view
|

Re: [css3-animations] dynamic changes to animation properties or keyframes

Øyvind Stenhaug
On Fri, 02 Dec 2011 10:25:11 +0100, David Vest <[hidden email]> wrote:

> On Thu, 1 Dec 2011 08:31:42 -0800, "Tab Atkins Jr."  
> <[hidden email]> wrote:
>> On Thu, Dec 1, 2011 at 5:04 AM, Øyvind Stenhaug <[hidden email]>  
>> wrote:
>> > I can think of two main approaches. Using
>> >
>> > @keyframes name { foo }
>> > #test { animation: name 1s, name 2s }

animation: name 2s, name 1s;

>> > as an example:
>> >
>> > a) Behave similarly to
>> >
>> > @keyframes name1 { foo }
>> > @keyframes name2 { foo }
>> > #test { animation: name1 1s, name2 2s }

animation: name1 2s, name2 1s;

>> > b) Behave similarly to
>> >
>> > @keyframes name { foo }
>> > #test { animation: name-that-matches-no-at-rule 1s, name 2s }

animation: name-that-matches-no-at-rule 2s, name 1s;

>> > Where option a) seems kind of nice (can effectively have multiple  
>> animations
>> > re-using the same @keyframes rule).
>>
>> (a) is effectively equivalent to (b), since a later animation
>> manipulating the same property as an earlier animation wins.  The only
>> difference is when you're measuring the start or end of transitions
>> via the JS events.
>
> No, a previous animation may be visible during the animation-delay
> period:

Not just during the animation delay. I actually meant to specify the  
durations the other way around, as done above.

For the corrected alternative a), WebKit and Gecko are consistent: since  
there is no forward fill, name1 takes effect after name2 completes.

The spec is not actually very clear on this point, an issue which I raised  
at <http://lists.w3.org/Archives/Public/www-style/2011Sep/0388.html>.

--
Øyvind Stenhaug
Core Norway, Opera Software ASA

Reply | Threaded
Open this post in threaded view
|

Re: [css3-animations] dynamic changes to animation properties or keyframes

L. David Baron
In reply to this post by L. David Baron
On Sunday 2011-11-06 11:48 -0800, L. David Baron wrote:

> On Saturday 2011-04-02 12:14 -0700, L. David Baron wrote:
> > http://dev.w3.org/csswg/css3-animations/#animations says:
> >   # The values used for the keyframes and animation properties are
> >   # snapshotted at the time the animation starts. Changing them
> >   # during the execution of the animation has no effect. Note also,
> >   # that changing the value of ‘animation-name’ does not necessarily
> >   # restart an animation (e.g. if a list of animations are applied
> >   # and one is removed from the list, only that animation will stop;
> >   # The other animations will continue). In order to restart an
> >   # animation, it must be removed then reapplied.
> >
> > This doesn't appear to match WebKit's behavior.  For example, in the
> [...]
> > Should the spec say instead that dynamic changes are honored, but
> > the animation start time (as adjusted by pause duration) is
> > preserved for each animation name?
>
> I'd note that if the spec does take this approach, it needs to
> describe what happens when an animation-name occurs more than once
> in the list of animations:  in that case, I believe the start time
> for a given animation-name should always track the
> animation-play-state value of the last occurrence of that
> animation-name in the list of animations.
>
> This is what I implemented in Gecko.
>
> I think this behavior is preferable since in most cases the last
> occurrence overrrides earlier ones, which means it's the most likely
> of any simple rule to reflect the current state.  (This isn't true
> for some values of animation-fill-mode if some of the animations
> have completed (or not started yet) and some have not (e.g., because
> they have different durations).  It also might not be true if we
> allow a property to apply for only a part of animation (though Gecko
> currently does not, as I described in [1]).
>
> I'd note that this means that authors will get weird behavior if
> they use multiple occurences of the same animation on the same
> element *and* dynamically change the animations list on that
> element.  But I think that's probably a cost worth paying to have
> otherwise-sensible behavior when changing the animations list on an
> element.
Note that Gecko changed behavior slightly here in [2].  Instead of
always matching the last animation in the list, we now take the new
animations list, iterate it from last to first, and for each new
animation, find the *last* matching animation in the old animations
list, *remove* it from the old animations list, and transfer the
state of that animation.

This means that a given animation will never transfer its state to
more than one new animation across a change in animation name.


smfr pointed out to me that the spec still doesn't cover the
behavior here at all.

-David

> [1] http://lists.w3.org/Archives/Public/www-style/2011Apr/0645.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1037316

--
𝄞   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)

signature.asc (836 bytes) Download Attachment