Re: transitions vs. animations

On Wed, Apr 7, 2010 at 6:37 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> So:
> **transitions: attached a value change
> **animations: attached to a state (including unadorned selectors and, perhaps, the state of a transition taking place)
> **third thing (if I understand correctly): attached to an event (mousedown, mouseup, submit, etc.)
>
> I am not at all enthusiastic about that third thing. It seems like we are trying to recreate DOM events (onclick, onsubmit, etc.).

I have no idea how we want to end up servicing that third use-case,
but it may be best to do through a purely javascript interface.  I was
simply pointing out a need, not necessarily suggesting it needed to be
solved in the same idea framework that we're using here.

> The 'play-out' (and brothers) as part of transitions feels messy and unclear to me. I'd be OK with leaving specific event handling to JavaScript, and only use CSS to animate value changes (transitions) and steady states (@keyframes animations).

The "play-in" and "play-during" I suggested are exactly the same as
the current Animations draft - play-in animations are just finite
iterations, while play-during are infinite.  There is no concept of
"events" or "states" invented to handle them; they trigger purely
through CSS values changing, exactly like the current Animations
draft.  "play-out" is nothing more than the inverse of the "play-in"
conditions.

I, too, would rather leave any concept of "events" out of CSS, and use
javascript to do that instead.

~TJ

Received on Wednesday, 7 April 2010 14:53:07 UTC