- From: David Dailey <ddailey@zoominternet.net>
- Date: Wed, 3 Aug 2011 12:07:42 -0400
- To: "'Vincent Hardy'" <vhardy@adobe.com>, "'Patrick Dengler'" <patd@microsoft.com>, "'Brian Birtles'" <birtles@gmail.com>
- Cc: <public-fx@w3.org>, "'www-svg'" <www-svg@w3.org>
- Message-ID: <000901cc51f7$79d18d10$6d74a730$@net>
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
Received on Wednesday, 3 August 2011 16:08:24 UTC