Re: transitions vs. animations

On Thu, Apr 8, 2010 at 12:24 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> This also
> allows the use of individual transition-animation-* properties after the
> slash, instead of always using the shorthand. I think that's a pretty big
> deal, and a motivation for doing it this way.

I don't understand what you mean by this.  Could you expand on this?


>> You haven't specified how this is supposed to work.  Does this mean
>> that if I am transitioning 'left' and the animation has a 'left:20px;'
>> rule in one of the keyframe-declarations, that point in time will have
>> left equal to (whatever the transition would set it to) + (20px)?
>
> Yes, exactly. Or if the keyframe was a negative number, it would subtract
> (naturally).
>
>> If so, how does a % work?
>
> TBD. I haven't pondered it much. I was thinking multiply instead of add, but
> I need to consider that more.
>
>> How do colors work?  How do keyword
>> properties work?
>
> I'm not sure. Maybe only lengths and numbers make sense. I'll give it some
> thought.

I don't like that this uses normal CSS syntax but actually expresses
something completely different and new.  Further, it means that the
same keyframe used in a transition and an animation could mean
*entirely* different things.

I agree that this use-case is valuable, but I think we should solve it
some other way.  Let's leave existing CSS syntax alone.

As an example of "some other way", perhaps we could use calc()?  That
would potentially allow us to refer to various values (starting,
ending, current) and be explicit about how we're manipulating it, such
as by adding or multiplying it by an amount.

The point is that we *can* solve this use-case without trying to
invent some new way to interpret existing CSS values into meaning
something else.


>> How do I say "ignore the transition, instead use
>> this cool animation function I've defined here" (the "fling and
>> bounce" transition I mentioned earlier).
>
> Sorry, I'm not familiar with that use case. I'll look it up when I get home
> tonight (or you could forward me the quoted part of what you're talking
> about there).

No problem, I'll explain with an example.

I've seen a few sites (can't find a URL right now, sorry) that have a
very cool animation on their main navigation using javascript.  The
text of the nav link is naturally at the top of the block, but when
you hover over it it drops the bottom quickly, bounces, and settles
down.  When you unhover, it flies up and bounces the same way.

Without any fanciness, this is just a change in positioning.  With
transitions, we can trivially make this a smooth slide from being
positioned at the top to being at the bottom.  But to do the "fly and
bounce" thing, you need an animation.  I want to use this idea of
attaching an animation to a transition, as it generally *works* the
way I want, but I want to override the default transition slide with
my own keyframe path.

I think this sort of thing will be reasonably common, and so I believe
that transition-animations should override the transition they're
attached to, if they manipulate the same property.  I think we have
reasonable freedom to later add an ability for the
transition-animation to combine with the transition, rather than
straight overriding it, but I don't think that's necessary *right now*
to get it working.

~TJ

Received on Thursday, 8 April 2010 19:38:48 UTC