Re: CSS SVG Discussion on Thursday

Hi, Folks-

I just want to echo Dean's opinions here, and to add my own wish.  I 
strongly support the idea of both extending CSS and simplifying SVGA, 
using a common underlying model (and different syntaxes, which is less 
important).

The thing I'd like to add is some sort of simple state machine so we can 
have multi-state animations, like conditional on-off or mid-point state 
animation interrupts.  Maybe this would be SMIL State, SCXML, or maybe 
something else.  This is missing from SVGA and CSS 
Transitions/Animations, and I've needed it again and again.  Maybe an 
adequate script API and animation OM would solve this, but I'd like to 
at least take a stab at a a declarative solution.

I'd also like for SVGA to perhaps be able to modify the DOM.  I know 
this is controversial.  I'm not asking for Turing-completeness, but 
changing some attributes would be handy at times, especially with ARIA.

I've invited Jack Jansen to the FXTF, who worked on the SMIL specs and 
knows both SMIL and Core Graphics well, and is eager to help simplify 
the model without sacrificing important functionality like synchronization.

I am also sensitive to Dean's point about this being time-sensitive.  We 
should try to make progress on this soon... let me know what I can do to 
help.

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs


Dean Jackson wrote (on 11/2/10 7:54 PM):
>
> 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
>> <mailto: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
>

Received on Wednesday, 3 November 2010 10:45:20 UTC