RE: Dropping angle-bracket syntax for animation

Well, here are a few more thoughts:

0.       I'll use the phrase SVG -SMIL to refer to <animate> and cousins
<animateTransform>, <animateMotion>, <set>  etc (including <animateModifier>
a proposed extension of the existing model (see [1]) to differentiate it
from all other modes of SVG animation (including script and CSS), and to
differentiate it from the larger SMIL spec that seems to have caused such
consternation in the HTML community.

 

1.       The parts of SVG-SMIL that would be easiest to separate from markup
and stick into CSS would be those cases where a small number of animate tags
are used to animate a small number of features. Of the 800 or so examples
I've written using SVG-SMIL, this would be the majority, but that is largely
because of intentionally writing simple examples for textbooks, workshops
and face-to-face instruction. I can't talk about live content on the web,
though I think most of it could be rewritten using CSS-like notation. Net
cost would probably be about 50-200 person years to rewrite all of it, and I
assume the W3C and its contributors would underwrite these costs. <humor />

2.       It is precisely these parts that would be easiest for implementers
to implement. Watching as Opera, WebKit, and Firefox have gradually
implemented more and more of the SVG 1.1 spec over the past several years,
it is the low-hanging fruit that usually gets implemented first, and this is
the stuff that is a) easiest to implement and b) largely already done by
most browsers and mobile user agents.

3.       It is the fancier stuff, involving dynamically created <animate>
tags, dynamically modified <animate> tags, and interaction between script
and the beginnings and ends of animations that seem to be trickiest to
implement. It is also this that would seemingly be hardest to conceptualize
in the framework of CSS. Passing events back and forth from JavaScript to
DOM has already been specced , implemented and adopted by authors.

4.       Usually, there are two reasons it seems that HTML authors use CSS:
one is that it makes life easier - one doesn't need to repeat attribute
value pairs throughout a complex document. The other is the philosophical
zeitgeist of the 20th century mandating separation of behavior, appearance,
and semantics. While, the separation of behavior, appearance and semantics,
is somewhat a flaky distinction when it comes to HTML, it is distinctly
unsound and unresolved in the context of SVG. What is the clear distinction
between appearance and semantics when it comes to rectangles? Is it
Geometry? Should we rename SVG as Scalable Vector Geometry and move color,
motion, pattern, gradient, APIs, interaction, and semantics to other
specialty realms? What a wonderful way to create decades of conflict and
strife! 

Let me catch a breath. the point here is that the reason one would generally
use CSS within SVG it seems is when lots of different objects share the same
attribute values - sort of like paragraphs and headings and titles and
footnotes and asides and all those DocBook things that HTML makes its
domain. How often do those things really happen in graphics? And when do
they happen?

Why, in other words, would we want CSS inside SVG? Well, the most obvious
answer is when it is easier to define classes of properties to be shared by
lots of objects. When does that happen, and specifically when would lots of
objects wish to share common animations? Usually when I build examples with
lots and lots of animations, the objects are moving and reshaping - it is
not just the "presentation" attributes like color that are being animated,
but their geometry. And it is this very geometry that needs to be
individualized. Creating hundreds of separate little CSS classes inside a
<style> tag to apply to hundreds of disjoint little objects located
elsewhere in the DOM just doesn't make much sense. The problem that CSS
would solve best for animation is the very problem it is most ill-suited to
solve!

5.       Any attempt to reconceptualize SVG animation in hopes of killing
SVG-SMIL should think about how to do certain things. From a collection of
recent examples that I discussed in a workshop at Devcon5:  [2], I looked
quickly at lots of the examples. Most could in fact be rewritten with their
animation located in a different part of the document, in a different
document or maintained by an offshore animation factory (since US animators
are an expensive lot). Here is a set of ones I consider problematic and the
reasons:

 

http://srufaculty.sru.edu/david.dailey/svg/ballclock.svg  (animations
created through script)

http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/Polygons/polygons10.s
vg  (from and to points of an animation are varied through script)

http://srufaculty.sru.edu/david.dailey/svg/swatch3.svg  (script used to
create random paths and associate those as mpaths for motion of objects)

http://srufaculty.sru.edu/david.dailey/svg/triangles6.svg  (animation
temporarily halted to run script that changes values)

http://srufaculty.sru.edu/david.dailey/svg/triangles7.svg  (similar to
above)

http://srufaculty.sru.edu/david.dailey/svg/triangles4l.svg  (similar to
above, but each animation is rebuilt interactively, with possibility of
synchronization)

http://srufaculty.sru.edu/david.dailey/svg/clips2.svg  (each object has a
different animation built for it by script)

http://srufaculty.sru.edu/david.dailey/svg/svgopen2008/makestars4.svg  (each
object is built at position of mouseclick with its mpath and animate being
randomly extended from there -- relies on walking the DOM -- animations are
then "recycled" using onend and beginElement())

http://srufaculty.sru.edu/david.dailey/svg/strands3.svg  (each object has a
different animation built for it by script)

http://srufaculty.sru.edu/david.dailey/svg/tribraids9.svg  (a collection of
paths is randomly constructed. A moving object has its mpath randomly and
repeatedly reassigned to one of those existing paths)

http://srufaculty.sru.edu/david.dailey/svg/svgopen2008/bouncing3.sv g
(imagine lots of these things bouncing around - they cannot exactly share
the same CSS class can they?)

http://srufaculty.sru.edu/david.dailey/svg/triangles4h.svg  (each triangle
has a customized gradient and a customized duration of the animation
thereof)

http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/modifierD.svg  (the
children of an animate are declaratively located and modified)

http://srufaculty.sru.edu/david.dailey/svg/texture/rects4a.svg  (playing
with 3D animation by randomly replicating animations)

http://srufaculty.sru.edu/david.dailey/svg/text/bubblesc.svg  (bubbles
inside a pattern are each given separate animations)

 

Implement all of these in CSS and if the resulting code is shorter, I'll
drop some of my skepticism. 

 

One more set of examples (out of a hundred or so that I have that deal with
filters and animation) can be found at

 

http://srufaculty.sru.edu/david.dailey/svg/text/texteffects2.htm    

 

They serve to remind us that among the things that are animateable are
attributes of all the SVG "modifiers" - gradients, filters, patterns, masks,
and clipPaths (except, of course, animate, which while a modifier does not
typically allow its children's attributes to be animated - sigh). As the
zeal to strip all of these modifiers from SVG DOM into CSS seems to have
some traction, let's not forget that if filters and gradients become
CSS-only in some dark possible future of the internet, then SVG will just
have to be reinvented by a new generation of frustrated authors.

 

Regards

David

 

[1]
http://svgopen.org/2010/papers/46-A_proposal_for_adding_declarative_drawing_
to_SVG/index.html

[2] http://srufaculty.sru.edu/david.dailey/svg/bucketful.htm 

 

From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of
Vincent Hardy
Sent: Wednesday, August 03, 2011 11:06 AM
To: Patrick Dengler; Brian Birtles; David Dailey
Cc: public-fx@w3.org; 'www-svg'
Subject: Re: Dropping angle-bracket syntax for animation

 

I also thought we had resolved, during the FX meeting last week, to work on
requirements first. However, looking at the minutes log, I cannot find any
RESOLUTION or ACTION recorded on that.

 

http://krijnhoetmer.nl/irc-logs/fx/20110726

 

It seems that the log is truncated at midnight, and I do not see the
following part at:

 

http://krijnhoetmer.nl/irc-logs/fx/20110727

 

Vincent

 

From: Patrick Dengler <patd@microsoft.com>
Date: Wed, 3 Aug 2011 07:50:28 -0700
To: Brian Birtles <birtles@gmail.com>, David Dailey
<ddailey@zoominternet.net>
Cc: "public-fx@w3.org" <public-fx@w3.org>, 'www-svg' <www-svg@w3.org>
Subject: RE: Dropping angle-bracket syntax for animation

 

This was indeed what we agreed upon last year in Lyon at TPAC.

 

-----Original Message-----

From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf
Of Brian Birtles

Sent: Tuesday, August 02, 2011 4:55 PM

To: David Dailey

Cc: public-fx@w3.org; 'www-svg'

Subject: Re: Dropping angle-bracket syntax for animation

 

Hi David,

 

Thanks very much for your feedback here.

 

I just want to clarify a couple of things in defense of those who suggested
dropping SMIL:

 

a) No one's proposing dropping declarative animation altogether. Rather, the
option that many seemed to prefer was replacing SMIL with CSS Animation.

 

b) Everyone recognises that the folks who developed SMIL know their domain
best. Everyone wants to build on that experience even if they don't use SMIL
syntax per se.

 

 

The real concern is that currently we have two competing models for
animation which is not a good state of affairs for the Web platform. 

Myself and others have been considering how to harmonise the two models but
some implementors expressed concern about investing time in implementing
SMIL when CSS Animations already appears to have wider adoption.

 

Regarding the last point about adoption however, we're mostly just guessing,
I don't think anyone really has hard data on this. Also, it was recognised
that there's a lot more HTML on the Web than SVG so it's not really a fair
comparison.

 

 

I believe Dean Jackson is going to look into what is required to bring CSS
Animations up to feature parity before any resolution is made about how we
go forward.

 

 

I think it would also be useful to draw up a concrete proposal about how to
merge the two models into one. It is something I would like to do but may
not have the opportunity (although I made a start [1]).

 

Thanks again,

 

Brian

 

 

[1]

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Animations/Ha
rmonisation