- From: David Dailey <ddailey@zoominternet.net>
- Date: Tue, 2 Aug 2011 16:20:56 -0400
- To: "'Brian Birtles'" <birtles@gmail.com>, <public-fx@w3.org>
- Cc: "'www-svg'" <www-svg@w3.org>
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? Thanks, Brian, for bringing this to our attention, and for your good reasoning against it. Should the silliness progress further, please announce again and more broadly and I am sure tomes of other good reasons will be mustered from the broad corners of the earth. Moving backward in conceptualization to a rather worn set of principles derived from 20th thinking about separating behavior (script), appearance and geometry (CSS) and meaning (HTML) and then trying to apply this threadworn analogy to SVG is just wrong on so many levels. It is as though we have bought a horse and discover that the unfinished stable we have been putzing with doesn't fit the horse, so let us then kill the horse. Students love SMIL animation! Undergrads, postgrads, Europeans, Asians, American web professionals, aspiring web-professionals. Before breaking the web why not commission a human factors study to justify breaking it!? Prediction: any well-designed human factors study of the phenomenon will justify keeping the existing 10 year old specification by any manner of cost effectiveness specified, unless we limit those costs to implementers. David -----Original Message----- From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Brian Birtles Sent: Thursday, July 28, 2011 1:40 AM To: public-fx@w3.org Cc: www-svg Subject: Dropping angle-bracket syntax for animation (Cross-posting to www-svg since there may be concerned parties there who don't monitor public-fx. Please direct replies to public-fx) Dear all, Thank you to those who were able to provide input to our recent discussion on future developments for animation on the web platform. For those who were not able to be present, the notes are available: Notes: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Animations/Ha rmonisation Minutes: http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0024/26-fx-minut es.html#item05 At the meeting I expressed some concern about dropping the angle-bracket syntax and relying solely on CSS Animation. I'd like to follow that comment up with some specific concerns for your further input. 1) SVG viewers aren't currently required to support CSS.[1] It seems unreasonable to me to require CSS support in order to support animation. (There are SVG viewers in shipping products that don't support CSS so this is not a theoretical argument.) 2) Consistency. No other major feature in SVG is available only with CSS. It seems unusual to have to switch syntax for animation only. 3) Verbosity. I'm concerned that if the features currently available in SVG Animation (particularly syncbase timing) were added to CSS Animation the syntax would become cumbersome. Compare a very simple animation:[2] div { animation-name: 'diagonal-slide'; animation-duration: 5s; animation-iteration-count: 10; } @keyframes 'diagonal-slide' { from { left: 0; } to { left: 100px; } } In SVG this becomes: <animate attributeName="left" from="0" to="100px" dur="5s" repeatCount="10"/> Once syncbase timing is added, which relies on ID references, I expect this could become a bit unwieldy. Below is a greatly simplified fragment from a real-world SVG animation. I include it to illustrate syncbase dependencies since some may not be familiar with this feature. <text ... ><animate id="a" attributeName="y" begin="6s" dur="7s" to="-135,-120,-105,-90,-75,-60,-45,-30,-15,0,15" repeatCount="140" fill = "freeze"/>abcdefghijk</text> <text ... ><animateMotion id="b" begin="a.begin+6.3s;b.begin+70s" path="M 0 0 L 0 -150" ... calcMode="linear" dur="70s" fill="freeze" end="a.end"/> <set attributeName="y" begin="0s; b.begin+70s" end="a.end" to="15" fill="freeze" />...</text> I'm concerned that animations such as the above (particularly when in their non-simplified form) may become more lengthy to write. The additional <style> element required, and the need to bind the style to the target animation with ID/class references or something of that sort (SVG animation can avoid this by making the animation element a child of its target as shown above) may also make the CSS syntax a little more cumbersome. 4) Semantic grouping. One of the features that is sorely needed in SVG Animation is time containers and this has already been proposed.[3] These time containers can be nested arbitrarily to provide different semantics. XML-like notation seems a more natural fit for expressing this kind of hierarchy. 5) XML toolchain. By providing an angle-bracket syntax, content can be more easily manipulated and generated by existing XML tools. For example, in my experience it is simpler to produce XML elements than plain text with XSLT. 6) On a closely related note to (5), existing generic DOM APIs can be re-used. For simply manipulating the content (e.g. removing an animation) authors are not required to reference new APIs (e.g. CSSKeyframesRule) but can re-use existing knowledge and existing interfaces and frameworks (e.g. DOM Core/E4X/lightweight DOM wrappers etc.) I have heard other concerns but perhaps the above is enough for now. I'm not necessarily opposed to dropping SMIL if need be, but for the above reasons I'm not quite persuaded that dropping the angle-bracket syntax altogether is a good idea. I believe there are alternatives that allow us to keep an angle-bracket syntax whilst aligning with CSS Animations but for now I'm just interested to hear further thoughts about the above concerns. Looking forward to your feedback! Best regards, Brian Birtles [1] http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#ConformingSVGViewe rs [2] Based on the example here http://www.w3.org/TR/css3-animations/#animations- [3] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improveme nts#Wanted_feature:_re-use_animations
Received on Tuesday, 2 August 2011 20:21:33 UTC