Re: [css3-animations] Clarifying the handling of repeated animation names

On Fri, 11 Jan 2013 19:54:23 +0100, Sylvain Galineau  
<sylvaing@microsoft.com> wrote:

>    # If at one point in time there are multiple animations specifying
>    # behavior for the same property, the animation whose name occurs
>    # last in the value of 'animation-name' will override the other
>    # animations at that point. [3]
>
>    # If multiple animations are attempting to modify the same property,
>    # then the animation closest to the end of the list of names wins. [4]
>
> It seems there are at least two possible interpretations of these  
> statements:

(For some reason these talk about the shorthand. The issue is not specific  
to that, of course.)

> 1. If the animation shorthand runs multiple animations against the same
> property, use 'last one wins' to decide which @keyframes rule animates
> that property. Then only allow this one animation to update the property
> *regardless of the respective durations of the winning/losing  
> animations*.
>
> 2. If the animation shorthand runs multiple animations against the same
> property, use 'last one wins' to decide which @keyframes rule animates
> the property *first*. Once this animation has completed, use  
> last-one-wins to
> pick the next @keyframes rule to animate the property *among the losing
> animations that are still running*.

This representation of alternative 2 seems to make sense only for a subset  
of the possible cases. Note that the "winning" animation could have a  
delay. This wording doesn't explain what happens during that delay.

Another way of looking at option 2 is that for each frame of animation,  
each animation in the list is given the chance to specify a value, and  
they are checked from left to right so that the ones at the end are able  
to override the previous ones. As long as the conflicting animations have  
different names, WebKit and Gecko appear to be consistent with this.

(If you have "foo 10s, bar 4s 2s", 'foo' applies during the first two  
seconds, then 'bar' takes over during the next 4s, then it's back to 'foo'  
for the remaining 4s. But note that animation-fill would change this - if  
'bar' fills backwards, it overrides 'foo' also during the first two  
seconds.)

> <!doctype html>
> <style>
>  @keyframes rightward {
>   to { margin-left: 600px;}
>  }
>  #test {
>   animation: rightward 10s, rightward 4s;
>  }
> </style>
> <p id="test">Moving  
> right</p>https://www.w3.org/Bugs/Public/show_bug.cgi?id=14658
>
> Interpretation #1 would run rightward for 4s. IE and WebKit do this.
> Interpretation #2 would first run rightward for 4s, then run the last 6s  
> of the
> 10s rightward animation. Firefox does this.

OK, so here we get to the repeated animation names. (I raised this at  
<http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html>, by the  
way, but although <https://www.w3.org/Bugs/Public/show_bug.cgi?id=14658>  
is apparently marked as fixed I don't think it's addressed by the current  
wording.)

I think this is really a separate issue from the general conflict  
resolution. Then there are basically two alternatives:

A) For a given element, an animation-name ident uniquely identifies an  
animation. (Behavior would need to be specified; does the above example  
behave the same as with "animation: none 10s, rightward 4s", for instance)

B) An element can have multiple animations with the same name (pointing to  
the same @keyframes). The question of which animation takes precedence  
should be resolved in the same manner as if the names were different. I.e.  
the stylesheet in the example above would behave exactly the same as

 @keyframes rightward-1 {
    to { margin-left: 600px;}
   }
 @keyframes rightward-2 {
    to { margin-left: 600px;}
   }
   #test {
    animation: rightward-1 10s, rightward-2 4s;
   }

> While #1 is much simpler, I'm not sure this reflects author intent well.  
> It may
> not even reflect the spec's original intent either; the first prose  
> excerpt above
> specifically says the last animation wins *at that point in time*.

For what it's worth, that wording is not the *original* one (it was  
changed for <https://www.w3.org/Bugs/Public/show_bug.cgi?id=14778>).

> I strongly suspect #2 is what we want; from a syntactic standpoint I do  
> find it
> awkward that animations 'run' a property from last to first but this is  
> the
> compatible behavior today.

As mentioned above I don't think "'run' a property last to first" sounds  
like an accurate description. I think of it more like each entry in the  
'animation-name' list giving a special kind of declaration block whose  
existence and contents change with time. And in case of conflicts the one  
specified last takes precedence, just like with regular declaration blocks  
with equal specificity and origin.

Going with #2 / B) seems fine. Though B) might require clarifying what  
happens if 'animation-name' is changed. For instance, what happens if you  
go from 'foo 10s foo 20s' to 'foo 30s' and then to 'foo 10s foo 20s'  
again? Does the 20-second 'foo' get restarted? ("In order to restart an  
animation, it must be removed then reapplied.")

-- 
Øyvind Stenhaug
Opera Software ASA

Received on Monday, 14 January 2013 14:26:43 UTC