Re: [css3-animations] multiple 'animation-name' and cascading

On Tuesday 2011-04-12 15:16 -0700, Simon Fraser wrote:
> On Apr 12, 2011, at 12:53 PM, Tab Atkins Jr. wrote:
> 
> > On Tue, Apr 12, 2011 at 12:32 PM, L. David Baron <dbaron@dbaron.org> wrote:
> >> On Tuesday 2011-04-12 11:33 -0700, Simon Fraser wrote:
> >>> On Apr 12, 2011, at 10:29 AM, L. David Baron wrote:
> >>>> On Tuesday 2011-04-12 08:56 -0700, Tab Atkins Jr. wrote:
> >>>>> On Mon, Apr 11, 2011 at 9:09 PM, L. David Baron <dbaron@dbaron.org> wrote:
> >>>>>> (Alternatively, I suppose one could check for whether the property
> >>>>>> is specified in any keyframe -- though that's a bit more work.)
> >>>>> 
> >>>>> You need to check all the keyframes.  Given a keyframe like this:
> >>>>> 
> >>>>> @keyframes wobble {
> >>>>>   0% { left: 0; top: 0; }
> >>>>>  33% { top: 100px; }
> >>>>>  67% { top: -100px; }
> >>>>> 100% { left: 100px; top: 0; }
> >>>>> }
> >>>>> 
> >>>>> In the middle third of the animation, the nearest keyframe blocks
> >>>>> don't have any mention of 'left', but 'left' is still being animated.
> >>>> 
> >>>> The spec should perhaps mention that somewhere.
> >>> 
> >>> Agreed :)
> >>> 
> >>>> Additionally, it should say how that behavior interacts with timing
> >>>> functions specified in keyframes.
> >>> 
> >>> In this case left animates exactly as if the middle two keyframes were missing:
> >>> 
> >>> @keyframes wobble {
> >>>   0% { left: 0; top: 0; }
> >>> 100% { left: 100px; top: 0; }
> >>> }
> >>> 
> >>> If the first keyframe had a timing-function, then that's the one that would apply.
> >>> 
> >>> In other words, properties are interpolated between the keyframes
> >>> that specify them.
> >> 
> >> This makes sense -- and seems better for authors -- but it surprises
> >> me given that (a) the spec doesn't say this and (b) the spec says
> >> that duplicate keyframes get dropped, which is part of what led me
> >> to the model that I interpreted (and implemented) from what the spec
> >> does say.
> >> 
> >> So given this model, it seems like it would make much more sense if
> >> the spec also said that duplicate keyframes weren't dropped, but
> >> were instead cascaded, so that, with:
> >> 
> >>  0% { left: 0; top: 0 }
> >>  50% { top: 40px; left: 40px }
> >>  50% { top: 25px; }
> >>  100% { top: 100px; left: 100px }
> >> 
> >> you'd end up with top animating according to:
> >>  0% { top: 0 }
> >>  50% { top: 25px }
> >>  100% { top: 100px }
> >> and left animating according to:
> >>  0% { left: 0 }
> >>  50% { left: 40px }
> >>  100% { left: 100px }
> >> instead of having, as the spec currently says, left animating
> >> according to:
> >>  0% { left: 0 }
> >>  100% { left: 100px }
> >> because the second 50% keyframe overrides the first.
> 
> What's the use case for cascading keyframes?

One is when you want some properties to be repeated at multiple key
selectors.  For example, you could traverse the edges of a square,
clockwise from top left, with:

  0%, 25%, 100% { top: 0 }
  50%, 75% { top: 100px }
  0%, 75%, 100% { left: 0 }
  25%, 50% { left: 100px }

rather than having to write:
  0%, 100% { top: 0; left: 0 }
  25% { top: 0; left: 100px }
  50% { top: 100px; left: 100px }
  75% { top: 100px; left: 0 }

> If we allow cascading keyframes, it's not obvious that you could use separate
> timing functions for different properties, since the timing-function property itself
> would be affected by the cascade.

That depends on how you define the cascading:  if you defined it to
use the last keyframe for any keyframe selector that has the
property (rather than actually merging the keyframes together) you
wouldn't have that problem.

-David

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

Received on Wednesday, 13 April 2011 00:26:03 UTC