SVG WG response to SMIL Animation last call

 

Forwarded message 1

  • From: Chris Lilley <chris@w3.org>
  • Date: Wed, 1 Mar 2000 14:42:14 -0500 (EST)
  • Subject: [Moderator Action] SVG WG response to SMIL Animation last call
  • To: www-smil@w3.org
  • CC: w3c-svg-wg@w3.org, symm@w3.org
  • Message-ID: <38BD728A.6AF8A7F1@w3.org>
The SMIL Animation last call WD was discussed at the Thursday 17 Feb
telcon, and the SVG WG came up with four items of feedback plus one item of
notification FYI. 

The first two are critical, long-standing requirements from the SVG working
group which are not yet addressed in the SMIL Animation specification. It
was already agreed that SVG WG would raise these issues during last call,
so here they are. The description of the requirements for the first two
items is extracted from email archives
(http://lists.w3.org/Archives/Member/w3c-svg-wg/1999OctDec/0193.html).

      (1) INADEQUATE ABILITY TO MIX DOM WITH DECLARATIVE ANIMATION 
The most significant problem is the following excerpt from SMIL Animation
section 6.2 Supported Methods
[http://www.w3.org/AudioVideo/Group/Animation/smil-animation-WD-991022.html#DOM-SupportedMethods]: 

'The beginElement() method must do nothing if the animation is not
explicitly set with the begin="indefinite" syntax above. The endElement()
method must do nothing if the animation is not explicitly set with the
endActive="indefinite" syntax above.' 

This was felt to introduce incredible hassle to end users and authoring
tools generators, but provide none of the targeted benefit of constraining
or simplifying implementations. SVG WG would very much like to see this
restriction lifted.

      2) NEED A LIST OF EVENT VALUES FOR BEGIN AND END [used to say
ENDACTIVE] ATTRIBUTES 

In the latest SMIL Animation draft, only one value (a time value, an event
specification, or a dependency) can be given for 'begin', 'end' or
'endActive'. However, in the latest SMIL Timing draft, the 'begin' and
'end' attributes can take a semicolon-separated list. 

It is clear that a semicolon-separated list is the obvious and best way to
extend the SMIL 1.0 and SMIL Animation specs in an upwardly compatible way.
It is also clear that it allowing multiple begin and end triggers versus
one is not a huge additional burden on implementors, especially since they
already have to deal with multiple potential triggers (e.g., the 'begin'
attribute and hyperlinks). 


The other two items were discussed in the 17 Feb teleconference:

      3) Add the ability to trigger animations based on a repeat event.
Thus, in addition to being able to say begin='foo.begin', you also should
be able to say begin='foo.repeat'. This is for the sake of consistency and
completeness, but it is also a useful feature. 

For example, the LiveMotion team at Adobe has requested this feature in SVG
as the product allows for this behavior to be defined. (LiveMotion is
Adobe's recently previewed dynamic SVG authoring product which also exports
SWF.) 

The consistency argument is that there are TimeEvents for begin, end and
repeat; thus, there should be syncbase values for begin, end and repeat.

      4) It is inconvenient and a source of needless duplication that the
'animateMotion' element
requires inline path data, as in <animateMotion path="M0 0 L20 20" ...>.
For SVG, it is common that you will have a single path which is both
rendered and used as the target of a motion path. With the current syntax
of SMIL Animation, you have to repeat the path data to achieve this effect.
Therefore, the SVG working group requests that the 'animateMotion' element
be modified (at least for SVG) to allow for either inline path data or
reference to a 'path' element.

Here is a proposal for syntax:

    <animateMotion ...>
        <motionPath xlink:href=  d= ... />
    </animateMotion>

The requirement for the child element is because of XLink's restriction
that there can only be one reference per element. (There is already an
xlink:href on 'animateMotion' to point to the object which is being moved.) 

One approach would be that SMIL Animation only support the 'd' attribute.
SVG would add the 'xlink:href' attribute as an SVG-specific extension.
Another approach which would require no changes to the SMIL Animation
specification would be:

    <animateMotion d=...>
        <motionPath xlink:href= />
    </animateMotion>


Finally, at the teleconference, we decided that the following fifth feature
was SVG-specific and has no impact on the SMIL Animation specification.
However, we wanted the SYMM team to be aware of this direction in case they
had feedback:

5)      SVG has event attributes for all event types supported by the SVG
DOM. For example, the SVG DOM recognizes a 'click' event. Associated with
the 'click' event, all graphics elements and container elements in SVG have
an 'onclick' attribute to provide a convenient way of associating scripts
to events. 

Right now, the correspondence between events in the DOM and event
attributes is one-for-one, with the exception that the TimeEvents from SMIL
Animation (i.e., begin, end and repeat) do not currently have corresponding
event attributes. For consistency with the rest of SVG, we are going to add
attributes onbegin, onend and onrepeat to SVG's animation elements so that
script can be associated to animation events with the same convenience as
the other events supported by SVG.

--
Chris Lilley
Chair, SVG WG

Received on Thursday, 2 March 2000 04:08:42 UTC