- From: Øyvind Stenhaug <oyvinds@opera.com>
- Date: Thu, 01 Dec 2011 14:04:58 +0100
- To: www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
On Sun, 06 Nov 2011 20:48:53 +0100, L. David Baron <dbaron@dbaron.org> 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
Received on Thursday, 1 December 2011 13:05:36 UTC