Re: transitions vs. animations

On Apr 4, 2010, at 4:37 PM, Perry Smith wrote:

> 
> On Apr 4, 2010, at 3:12 PM, Tab Atkins Jr. wrote:
> 
>> On Sun, Apr 4, 2010 at 11:23 AM, Perry Smith <pedzsan@gmail.com> wrote:
>>> Perhaps instead of calling them 'states' or 'state changes', call them
>>> 'events'.  I'm new to this list so I don't understand Håkon's statement,
>>> "We'd like to do this without adding an event model to CSS."  It may be that
>>> my way of thinking opens a can of worms that has already been discussed.
>>> 
>>> First, it solves Simon's concerns because the event would not happen when a
>>> class is added or removed.
>> 
>> It doesn't solve the concerns so much as eliminate them, because it
>> makes transitions much weaker.  A lot of transition usage will be
>> based on :hover, :focus, etc., but a lot of it *won't* be.  There are
>> tons of places in code that I've written where I'd like to animate
>> some property change triggered by me swapping classes.
>> 
>> Simon points out, correctly, that trying to hack an event model that
>> responds to arbitrary selector matching changes would turn super-crazy
>> very quickly.  Both in terms of simple mechanics, and in terms of what
>> authors have to keep track of (the 'combinatorial explosion' he
>> mentions).
> 
> I clearly don't understand the objective.
> 
> If the user already is using javascript to change classes, then he can define the animations like script.aculo.us and others do.
> 
> I thought the desire was to have something so, lets call them "graphic artists", can use without knowing or mucking with JS.  Someone used the term "declarative".  I took that to mean something I can declare in CSS alone.

There is much more than just the convenience of a declarative form here. One of the biggest motivators for Transitions and Animations was to create a system that could perform animations in hardware. On embedded platforms, running Javascript timers and rerendering the entire page for each step quickly becomes expensive enough that framerates become unacceptably slow. 

-----
~Chris
cmarrin@apple.com

Received on Monday, 5 April 2010 17:07:48 UTC