Re: Apple's Proposal for CSS Animation

On Nov 7, 2007, at 1:46 PM, Bjoern Hoehrmann wrote:

> * David Hyatt wrote:
>> Animation is currently possible in languages like SVG, but no system
>> exists for the native animation of CSS styles. This proposal defines
>> two types of animation. The first is implicit transitions, which
>> describe how CSS properties can be made to change smoothly from one
>> value to another. The second is defined animations, which specify the
>> values that CSS properties will take over a given time interval.
>
> I do not really understand what problem this is trying to address.  
> It is
> quite clear to me that we do have a system to animate styles, while  
> SMIL
> does not currently have a CSS syntax or CSS features that make it easy
> to use SMIL animation in style sheets, it can certainly do what the  
> pro-
> posal seems to offer. Could you say what problem you seek to solve,  
> why
> it needs a solution, and how your proposal is superior to other  
> possible
> solutions?
>

We are concerned with animations that are presentational effects.   
Describing presentational animations using declarative markup like  
SMIL is inappropriate when the animations themselves are  
presentational.  Examples of such animations can be found in the GUIs  
of both Vista and OS X.  For example the pulsing dialog buttons in OS  
X or the fade animation when hovering over buttons on Vista are both  
animations that are part of the current theme (the Vista theme API  
even includes animation support).

If a page has multiple visual looks defined (using alternate  
stylesheets), it should clearly be possible to have different  
animation effects as part of each theme's presentation.  Markup or  
script in the HTML file would make this difficult.

> I note that your proposal will necessarily have to co-exist with SMIL,
> yet the proposal includes not a single word how conflicts between the
> two are resolved (say, you specify conflicting animations using both).
> How do you intend to update the proposal to remove this  
> incompatibility?
>

I agree that we need to reconcile the two and add some language to  
talk about this.

> I could not quite figure out why you have transitions in the proposal.
> It seems they are equivalent to animations with slight notational
> differences. If they are there because specifying animations takes a
> lot of effort, maybe the animation part needs to be improved. The name
> is somewhat unfortunate, I would expect transitions to offer  
> transition
> effects as they are specified in SMIL.
>

Yes, this is a concern of mine as well.  It would be nice if we could  
find a way to reconcile the two systems as they are very close.   
However there were enough differences that we ended up breaking them  
out into two separate sets of properties.

Transitions are implicit and have the following characteristics:
(1) They degrade gracefully in browsers that don't support transitions
(2) The end result is always that the object ends up at the  
destination value (i.e., the same end result as in browsers that  
don't support transitions).

Animations are explicit and in old browsers the entire animation  
simply won't run.  Animations are about running multiple iterations  
(possibly with keyframes) between from/to values, possibly ending  
where you began, etc.

> I could not quite figure out keyframes as used with transitions. In  
> par-
> ticular, behavior for these examples seems underdefined:
>
>   @keyframes 'wobble' {                         }
>   @keyframes 'wobble' { 0% { ... }              }
>   @keyframes 'wobble' { 100% { ... }            }
>   @keyframes 'wobble' { 0% { ... } 100% { ... } }
>

If 0 or 100% specify explicit values there would be a snap at the  
beginning and end (as you snapped into the initial keyframe position  
and snapped out of the final keyframe position).  Transition  
keyframes should also support interpolated values (I think that got  
left out of the proposal, I'll get a revised one out in a bit).

> The triggering condition for transitions is also underdefined, it just
> says "transitions trigger implicitly when property values change"  
> which
> can mean many things (specified value, computed value, are 0 and 0.0
> the same value, what about special values like inherit, currentColor).
>

Yes, this is an open issue.  Right now when styles re-resolve is  
underspecified in general, and since transitions/animations hook into  
this idea, when they start is under-specified.

> I find the syntax in general quite terrible; clearly SMIL's XML syntax
> is very verbose and annoying to write manually, but you've hardly im-
> proved upon that. These matrix style properties are in fact a major
> annoyance,
>
>   a: 1,2,3,4;
>   b: 1,2,3,4;
>   c: 1,2,3,4;
>   d: 1,2,3,4;
>
> becomes very unreadable and error-prone the moment the items are not
> all the same length, or do not fit on a single line. Your choice to  
> use
> strings rather than identifiers to identify keyframe at-rules is not a
> good one either.
>

The syntax is identical to CSS3 multiple backgrounds (with all the  
same rules for repeating patterns etc.).  You don't have to have  
properties that are all the same length as the patterns intuitively  
repeat into subsequent layers.  We've authored quite a few examples  
and this has not been a point of confusion at all.  Besides, how else  
would you list multiple animations on the same element if not in ...  
well... a list? :)

> The Media line for all the properties seems wrong, clearly you can  
> also
> have animations in audio and speech environments, not just visual  
> ones.
>

Yes, good point.

dave
(hyatt@apple.com)

Received on Wednesday, 7 November 2007 20:06:08 UTC