- From: Brian Birtles <birtles@gmail.com>
- Date: Wed, 27 Jul 2011 22:39:49 -0700
- To: public-fx@w3.org
- Cc: www-svg <www-svg@w3.org>
(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/Harmonisation Minutes: http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0024/26-fx-minutes.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#ConformingSVGViewers [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_improvements#Wanted_feature:_re-use_animations
Received on Thursday, 28 July 2011 05:40:16 UTC