- 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