W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2011

Re: Dropping angle-bracket syntax for animation

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 03 Aug 2011 11:40:22 +1200
Message-ID: <4E388AE6.70002@mcc.id.au>
To: David Dailey <ddailey@zoominternet.net>
CC: 'Brian Birtles' <birtles@gmail.com>, public-fx@w3.org, 'www-svg' <www-svg@w3.org>
On 3/08/11 8:20 AM, David Dailey wrote:
> Are the folks who proposed such a thing in fact aware of a) how much content
> they would break b) how much future functionality they would break c) why
> declarative approaches to computing (like HTML, SVG and SMIL) are easier for
> the human mind to comprehend d) why the SVG animation model is so compelling
> that others are basing new forms of declarative syntax upon it e) how they
> are likely to provoke ire, cynicism and disrespect?

I don't think anyone is arguing for having no declarative solution to 

That there is some existing content that does use SVG/SMIL animation 
means that it's certainly not likely that this functionality will be 
dropped from existing implementations.  At least not immediately.

Regardless of what we decide for ourselves in SVG, CSS Animation is 
going to increase in functionality.  Vendors who do not wish to 
implement SVG/SMIL animation as it stands, due to its complexity, will 
then have a solution (the evolved CSS Animation) that may solve the use 
cases that SVG animation aims to solve.  I think they will then have an 
even harder time justifying to themselves to put in the work to 
implement a second animation language.

Does it make sense to have an angle-bracket syntax to handle more 
complex animations than can reasonably be written with CSS Animations, 
just like we are doing for Filters?  I think that is the fundamental 
question that Brian is getting at.

Having two animation features that can do the same thing, but with 
different syntax, doesn't seem like a particularly good state to be in.
Received on Tuesday, 2 August 2011 23:41:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC