W3C home > Mailing lists > Public > www-style@w3.org > November 2007

Re: Apple's Proposal for CSS Animation

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 07 Nov 2007 20:46:45 +0100
To: David Hyatt <hyatt@apple.com>
Cc: www-style@w3.org
Message-ID: <d214j3h4qt3oml78olv07ai0ve3bbrlqdf@hive.bjoern.hoehrmann.de>

* 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?

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 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.

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% { ... } }

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).

The autostart semantics of animations are rather worrying. It seems
quite likely that authors would want to trigger animations based on
things not readily available through CSS selectors like DOM events; to
accounts for those we'd have to constantly add new selectors, redesign
the feature (e.g. by having a animation-begin property and specify the
animation in some other way) or live with complaints that scripting is
required for very simple things, with code like

  onfoo="this.style.animationName = '\'...\''"
  onfooend="this.style.animationName = null"

to trigger and remove animations.

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 Media line for all the properties seems wrong, clearly you can also
have animations in audio and speech environments, not just visual ones.

I am all for making it easy to associate animations with markup, but it
does not seem like inventing a new system is warranted here, especially
if the new system is a lot less powerful than the existing one, and we
can do it lot better in terms of syntax. So I am unimpressed by this
proposal. Understanding what problems needs to be solved would help to
propose some alternative.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Wednesday, 7 November 2007 19:46:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:56 GMT