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


[Øyvind Stenhaug:]
> 
> 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.)

Yes, that makes sense.

> 
> > <!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;
>    }
> 

You're right. This is a much better framing of the issue. 

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

Yes; I really meant 'the original intent of the current prose'; but since
you wrote it I'm comfortable taking your word as to what it meant :)

> 
> > 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.

Yes, that is what happens. I think it looks weird because this particular
last-one-wins behavior has a temporal dimension whereby the last things on
the list appears to run first, then the next to last etc. I don't think it's
a big issue though.

> 
> Going with #2 / B) seems fine. 

I do prefer being consistent whether the same name repeats or not.

> 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.")

I'm not sure I follow this point?

> 
> --
> Øyvind Stenhaug
> Opera Software ASA

Received on Monday, 14 January 2013 21:57:57 UTC