W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2011

Dropping angle-bracket syntax for animation

From: Brian Birtles <birtles@gmail.com>
Date: Wed, 27 Jul 2011 22:39:49 -0700
Message-ID: <CAA3_ugSDmgRmk=4quW24phfghP5UOdRQD9L8DjCEfprq+6opSA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 July 2011 05:40:17 GMT