Re: CSS SVG Discussion on Thursday

On 03/11/2010, at 5:21 AM, Robert O'Callahan wrote:

> On Tue, Nov 2, 2010 at 9:00 PM, Patrick Dengler <patd@microsoft.com> wrote:
> I posted the document that we could use as background or a launching point for our discussion on Thursday between the CSS and SVG working groups.   Perhaps it is useful.
> 
>  
> http://www.w3.org/Graphics/SVG/WG/wiki/images/6/64/SVGCSSTPAC.pdf
> 
> 
> 
> Three of the four major browsers have partial or complete implementations of SVG Animation 1.1 (SMIL). It's a solution that allows declarative animation of vector images today. In Opera and Firefox (not sure about Webkit), SMIL-animated SVG images are supported as <img> and CSS images. In the browsers that support HTML5 parsing, SVG Animation is supported in an HTML context. Quite a lof of demos and other content are using it on the Web.
> 
> You say that you don't think the Web should have two declarative animation frameworks. But for the animated image use-case (including the advertising niche currently served by Flash movies), I think CSS is inappropriate, since the animation there is content, not style.
> 
> Given all that, personally I think we should keep SVG Animation and build on it. We could diverge from the larger SMIL framework and simplify the model a bit if we identify specific opportunities to do that.

[this is not an official position from Apple]

I also think it is too early to declare end-of-life for SMIL/SVG animation. There are a number of very important things that SMIL/SVG has which are not available in CSS Animations, including:

- A Javascript API. It's pretty basic, but at least SMIL gives you the ability to easily start/stop/pause animations. The element-based approach also makes it very easy to create an animation and apply it to a single element. In CSS, this would require making a new style rule, making sure the element has an id or working out a selector to identify it, creating rules for all the keyframes, etc, all using the slow and cumbersome CSS OM.

- Triggering. CSS animations can only be triggered declaratively by changes in CSS state (typically this means :hover). Everything else requires a touch of Javascript to translate events into style updates. SMIL/SVG animations have the ability to begin and end animations based on events in a purely declarative form. eg begin="someelement.mousedown"

- Chained animations. Related to the previous point, animations in SMIL/SVG can be chained, in that the start of one animation is tied to the end of another. This is extremely convenient for authors, allowing them to make a change in one place rather than many.

- Additive animations. Sometimes you want two separate animations to apply to a single property on an element and have their effects combine (add). An example would be spinning an object constantly, but having it bounce once. CSS Animations only replace - the most specific one wins.

I believe that these features should be added to CSS Animations as well. I expect it will be difficult to come up with an API that everyone agrees on (the first step might be to decide whether or not every change needs to be reflected in CSS), while fairly easy to specify chaining/triggering/additive (although such as event-based model is new to CSS). The problem is that the CSS Working Group haven't yet agreed that the current state of CSS Animations is acceptable - any features we add now are just going to slow down the process [*].

As Rob mentioned, many animations are inherently part of the content, and should be kept as such.

Some of the complaints against SMIL/SVG animation is that it mixes the animation with the content, but that doesn't need to be so. It would be fairly simply to define behaviour of an "animation sheet", referenced by a <link> element, that is an external file containing the animations. I'd suggest adding a selector attribute to the animation elements to replace xlink:href.

My personal feeling is that we should do the following:

- try to unify the animation model of SMIL/SVG and CSS. The choice of which to use should be syntactic in most cases - pick whichever is most appropriate for the situation. But they should have a pretty similar feature set. Both SMIL and CSS are declarative APIs to this animation model.

- add a selector attribute to SMIL (possibly deprecating xlink:href) that would allow SMIL animations to apply to a collection of elements

- define a formal method for allowing external SMIL/SVG animation stylesheets

- define a JS API for animations that could apply to both technologies.

- add the missing features to CSS Animations

Dean

[*] I'll note there that with Adobe beginning to release tools that support the current syntax and feature set, as well as Apple shipping implementations and a lot of content for a number of years, that the current CSS Animation approach is rapidly getting to the point where it will be difficult to change.

Dean