RE: Dropping angle-bracket syntax for animation

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:34 UTC