The DOM WG assigned a reviewer to review the SMIL animation spec from the DOM perspective and reports no problems.
Thanks,
Lauren Wood
Date: Wed, 1 Mar 2000 14:42:18 -0500 (EST)
Chris Lilley
Chair, SVG WG
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).
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
SYMM Response: This functionality has been completed in the WG while working on SMIL-Boston. At the March2000 face2face, the SYMM-WG approved incorporating this functionality into SMIL-Animation. Note that beginElement() is also subject to restart rules. Functionality is just as in SMIL-Boston. Immediate evaluation and scheduling of the restart in the context of the restart rules.
Resolved during April 12, 2000 SYMM/SVG telecon: SVG agrees to this proposed change. Also, beginElementAt() takes a signed time offset. endElementAt() takes a positive offset.
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 implementers, especially since they already have to deal with multiple potential triggers (e.g., the 'begin' attribute and hyperlinks).
Resolved during April 12, 2000 SYMM/SVG telecon: Use multiple begin and end conditions just as in SMIL Boston with the same syntax and semantics.
The other two items were discussed in the 17 Feb teleconference:
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.
SYMM Response: This functionality has been completed in the SYMM WG while working on SMIL-Boston. While the comment does not ask specifically for this, an additional issue is the numbering of the repeat index. Is repeat(1), the first repetition? By the semantics of the current spec, no repeat event is generated when the element first starts, just a begin event.
We have agreed that the iterations are counted from 0, so the first observed repeat has an iteration value of 1. For technical reasons, repeat is not a syncbase value, but instead an event. This should provide the requested functionality. We must be clear that this is an event, and not a syncbase. The distinction is important for us.
foo.repeat(integer) is the syntax for this, starting with 1 being the first repeat. Iterations are zero based, first iteration raises a begin event, and first repeat event has detail value 1 on the second iteration of the element. Also can use unqualified repeat syntax: foo.repeat gets all repeat events.
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>
Resolved during April 12, 2000 SYMM/SVG telecon: SVG will have a referencing mpath element as an optional child of animateMotion which will override any path attribute in the animateMotion attribute. SMIL-Animation path attribute will remain unchanged.
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:
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.
Date: Wed, 1 Mar 2000 14:48:25 -0500 (EST)
The last call specification was discussed at the 28 Feb telcon. There were a number of items which seemed to need clarification, but we resolved them ourselves, we believe.[1]
So having discussed the spec, we find we have no problems with it.
[1] http://lists.w3.org/Archives/Member/w3c-css-wg/2000JanMar/0184.html
Chris Lilley Chair, CSS WG
Date: Mon, 28 Feb 2000 03:08:56 -0500 (EST)
De:Daniel Dardailler
Most of these comments are to do with improving the accessibilty of the specification itself, or of the examples that it uses.Demonstrates an animation being raised 5 seconds after a click event. Since we hope not to have click events, we should ask that this be changed to an activate event. WCAG checkpoint 6.2 requires device-independence for input triggers. Same comment arises in relation to most of the examples in 3.3.2.
In 3.3.5 an example is given that is based on a mouseover. Although the example appears to be inherently spatial, removing the device-dependence (and replacing it with a focus event, or perhaps in this case a select or activate) would provide the input dependence required. Since the rest of the example is hypothetical it doesn't need to be taken further, although a model of how this might work would allow for either selection, or a means of navigating independently rather than purely serially.
3.3.6 again has a number of click examples - more cases for a simple activate.
Section 3.5 describes the sandwich model, noting that changes to CSS rules will still be subject to the CSS cascade, which is an accessibility requirement. It is probably worthwhile at that point making a brief statement that another effect of this is that animations may not in fact be rendered, so important changes to content must not be specified purely by animation of style (as per WCAG 6.3). This is implicit in the final paragraphs of the section, but making it more explicit would be helpful.
Figure 4 - the state diagram for start, stop, restart, freeze, would be a lot better with a short description in a longdesc, d-link, or immediately below the image. Alternatively, the alt should say that the diagram is explained in the following section.
3.7.3 again uses click as an example of a user input event. The example at the end of 3.7.4 is click-driven again, and uses the link content "Click Here!" (contrary to WCAG checkpoint 13.1)
3.7.5 starts with another click-based example
The final example of 4.2 uses mouseover / mouseout, and would be better off using focusin / focusout. Whether a corresponding adjustment in the link text is strictly necessary is a moot point - one could expect users of assistive technologies and mouseless systems to go the extra distance in learning to use their interfaces and not need the behaviour explicitly described, although it would be nice if the talk was device-independent as well as the walk.
The example of illegal SMIL in 5.4 should nonetheless provide alternative content for the image - an alt attribute at least.
Other than that we think the question of giving assistive technologies access to the animation effects is a (soon to be fairy important) matter for User Agent Guidelines.
Date: Mon, 28 Feb 2000 01:10:51 -0500 (EST
De: Martin J. Duerst
Dear SMIL WG, These are some last call comments on SMIL animation, both technical and presentational.
Major comments:
The interaction between to/from/by,... is much too complicated. The most successful specifications are simple and straightforward ones, because they lead to easy understanding, easy and consistent implementation, and so on. Please, please, pull yourself out of the swamp you got in here, and streamline and clean up the definition of these attributes. Maybe adding one or two more attributes will make everything much clearer. Maybe giving up one or two of the edge case functionalities would help. It would be very much worth doing!
Various attributes use a syntax of "ID.EVENT+TIME". This should be changed to align with the general policy of the W3C to use web addresses for all kinds of references. This can easily be done by defining an XPointer extension for begin, end, and other events. The syntax would then e.g. be "xpointer(id(ID))begin(TIME)" or "xpointer(id(ID))event(begin)timeoffset(TIME)" or so. This can later easily be extended to provide general xpointer expressions instead of just ids and can make it possible to be able to refer to animation elements in different documents. While this may not be desirable at the moment, choosing a syntax that makes extension difficult should be strongly avoided. Also, defining begin(), end(), events, and offsets in an XPointer-compatible way means that these can be used on other occasions. Also, the current event syntax does not allow for parameters to events, which can in many cases (e.g. mouse events, key events) be a very serious drawback. An XPointer-like syntax can easily take this into account.
While in the above case, at least the argument of simpler syntax may be brought forward for the current proposal, this becomes completely bogus for the 'targetElement' attribute. This attribute has no justification for existence at all. And claims of simpler syntax, as they are made in the spec, are just plain wrong. Using href and a '#' is much shorter, and everybody knows it already from HTML.
"1. Intro: This version of SMIL Animation may not be used with documents that otherwise contain timing". Why that? In many cases, it would lead to very nice results, e.g. one part of a seq or a par being animated.
General: There should be a glossary. Terms such as 'simple duration', 'document duration', 'animation function', and so on should go in there.
2.1: DOM: the dom values are not changed, and there is no way to access the actual values. This may simplify lots of things, but I'm very sure that very soon, we will see at least a read-only interface for the actual values. Instead of waiting for divergent implementations, it would be better to define how to access current values in this spec.
That said, we recognize that some implementations may not be able to strictly comply with this model. We are interested in working with the W3C to solve these issues in the larger context of DOM, views, script, CSS, a nd XSL all interacting to produce the document displayed to the user.
2.1: Animation functions could be defined that were purely algorithmic; Why not define a few of these straight away?
2.1: "position) .": spurious space.
2.1: "As a simple example, the following"...: A simple example of addition, or of what? If not of addition, the example should come much earlier.
This chapter is too long and too complicated. Also, some of the complications (in particular around from/to/by) don't really deserve the term 'model'. The whole thing, in particular sections 3.1/2/3, reads much more like a description of attribute values. Probably the whole thing is best split into two, one general part (containing the later subsections) first, and one part on specific attributes (containing the former subsections) later. Definitely section 3.9 should go into section 4.
3.1: Instead of 'The Target element', the subtitle should be either 'The target element' or 'The targetElement attribute'.
3.1: 'If however, both attributes must be included in the host language, and they both occur...': I don't understand the 'must' here.
3.1: 'locater' -> 'locator'.
3.2.1 (and other places): the method names 'beginElement()',... are far from informative. They are methods of elements anyway, so having 'Element' in the name is completely superfluous. Also, for somebody not familiar with Animation, reading 'beginElement()' in some source code will be difficult to understand. It would be much better to change the names to 'beginAnimation()' and 'endAnimation()',....
'Syncbase value': This title appears much too small. Please make sure the style sheet is updated for such titles.
'linear' vs. 'paced' animation: The difference is difficult to get. Please make sure this is clear from the start. The best thing would be to have an example with a graph for each of the four variants.
';' as a separator e.g. in keyTimes: Using only space as a separator will be more compatible with XML Schema.
3.3, first paragraph: 'However SMIL Animation allows the author to repeat this' this? what?
3.3.1 @@ picture would help here: Yes, please!
3.3.1 Example of repeated additive animation: Repeating animation here looks very bad. It's much easier to define this as by='100px' dur='100s' without repeatCount. Please choose a better example.
3.3.2 'indefinite' could be an id value, but an element with such an id cannot be addressed. One more reason to clean up the syntax here.
3.3.5, Figure 3: If this is not simplified (as I very much hope), the spec should very clearly say what happens in the general case, e.g. two 'by' animations, or two 'to' animations.
3.3.6: 'If the clicks again at 6 seconds': Who clicks?
3.3.6, last paragraph: The SMIL Boston timing model is mentioned, but a reference is missing.
3.5: Sandwich model: - A sandwich is something well known, around the world. 'submarine' is a brand and should not turn up in a spec. Let people who do not know what a sandwich is without getting the 'submarine' hint, which is extremely US-specific, look up this in a dictionary. - A sandwich has bread both at the bottom and at the top. However, this model never explains the top bread layer. Either the top bread layer should be explained, or a different metaphor should be chosen.
3.5: GetOverrideStyle(): Where is this defined? Please add a reference.
3.6: State transition model: This has to come much earlier.
3.6: Frozen state: Is that result reflected in the Dom? Even if intermediate states are not, I think it might make sense that a final, long-lastig value actually is.
3.7.2: 'when a runtime actually': Change 'runtime' to 'runtime library' or some such.
3.7.2: 'fill="freeze", this may in fact be the case.': 'this': what?
3.7.3: The word 'seek' is used in a very special sense that I haven't found in any dictionary. Seek is more or less a synonym for search, but here it is used instead of 'position', and should be replaced by 'position' or something similarly appropriate.
3.8: 'should handled' -> 'should be handled'
3.8: 'violates the principal' -> 'violates the principle'
4.1: 'it can also animate discrete sets of non-numeric attributes': I guess it can animate a discrete set of values on a single non- numeric attribute.
4.2: Cannot reasonably by interpolated: by -> be
4.3: It should be mentioned that a host language also has to specify directions, e.g. whether x grows upwards or downwards.
4.3: path: Please say which features of SVG paths are excluded.
4.3: path: 'the host language must specify the coordinate system of the path values': The coordinate system is also needed for relative values.
4.3: multiple x values for H/h: 'although this generally only makes sense for the relative form': Why?
4.3: origin="default": What are the other values? How are they defined?
4.4: Say something about the fact that this definition of color animation does not automatically lead to 'nice' color changes, because human color perception is not linear.
5.2: 'abstract values should handled': add 'be'
5.2: host languages should be encouraged to suppor the formats defined in XML Schema.
6.2: 'methods calls' -> 'method calls'.
6.2: 'boolean true': The 'true' appears much lower than the 'boolean' when I print it out. Please check markup/stylesheet.
Dear SMIL WG, This is an i18n-related comment regarding SMIL Animation, from the I18N WG and IG.
It does not seem to be possible to animate the contents of an element (e.g. XML element). Maybe this can indeed be done by just leaving out the 'attributeName' attribute. If not, this is a problem. For textual "attributes" that are more than just fixed values, the very clear recommendation from an i18n side is to make these elements, so that if necessary further markup can be used depending on the need of the language and/or script. If the fact that animation is only allowed on attributes leads to a tradeoff between animation and internationalization, that would be highly undesired. The SMIL WG should therefore make sure that element contents (including possibly markup) can be the target of an animation.
Regards, Martin.
For example:
Hello, World!
<set attributeName="content" to="Goodbye, World" dur="5s">
</ text>
Objet: minor typos in WD-smil-animation-20000128
Date: Sun, 6 Feb 2000 00:54:39 -0500 (EST)
De: Susan Lesch
Here is a short list of suggested minor typographical improvements for the last call SMIL Animation [1] "work in progress." These comments could be premature, but I hope they help as you move to Candidate Recommendation. I found the spec to be well-written, easy to follow, and in need of almost no corrections. Reference: [1] http://www.w3.org/TR/2000/WD-smil-animation-20000128
Best wishes and good luck with your project,
-- Susan Lesch susan@textet.com http://www.textet.com/
All e.g.'s and i.e.'s need a comma: e.g., and i.e.,
There are a few instances of "doesn't" and "can't" in section 6.2 which I would spell out "does not" and "cannot."
Also, parenthesized amplification that is itself a complete sentence needs a preceding semicolon. They appear throughout the spec and I won't enumerate them here. For example, in 3.1 final section for attributeType: The attribute value is one of the following (values are case-sensitive): ^ The attribute value is one of the following; (values are case-sensitive):
I would try to link to [XML] and [SMIL1.0] in the Introduction. (As it stands, those references first come up in sections 3 and 5.)
3.2.3 last par. semi-colon semicolon
3.3 last example However, animation function still uses the specified simple duration. ^ an or the?
3.5 par 5 it's -> its side-effects -> side effects
3.6 par 3 from the Frozen state to the Finished state from the frozen state to the finished state or from the frozen state to the finished state
3.7.4 par 2 #3
begin="indefinite" -> begin="indefinite"
3.7.4 par 5 seeked- to -> seeked-to
4.2. Example 2 sets class attribute sets the class attribute [not sure here]
4.3 Vertical Line To although generally although this generally
4.3 Cubic bezier Curve To commands -> Cubic Bezier Curve To commands [assuming that you want to capitalize Bezier elsewhere]
4.3 calcMode and origin.
I would make these P-delimited points or ULs (rather than
BR-delimited sentences). Also the final mention of calcMode could be
marked up calcMode.
4.4 par 2 sRGB could link to a reference: [SRGB] "A Standard Default Color Space for the Internet - sRGB", M. Anderson, R. Motta, S. Chandrasekar, M. Stokes. Available at: http://www.w3.org/Graphics/Color/sRGB.html.
5. intro par allowed/supported events. [To remove the slash construct, I'd propose the following minor rewrite:] This includes basic definitions, constraints upon animation, allowed events and supported events.
"...Host language designers are discouraged from allowing animation elements to target elements outside of the document in which the animation element is defined (the XLink syntax for the target element could allow this, but the SMIL timing and animation semantics of this are not defined in this version of SMIL Animation)." [I would break this into two sentences:] Host language designers are discouraged from allowing animation elements to target elements outside of the document in which the animation element is defined. (The XLink syntax for the target element could allow this, but the SMIL timing and animation semantics of this are not defined in this version of SMIL Animation.)
6.2 par 3 in the much same way in much the same way
6.2 par 7 DOMImplementation -> DOM Implementation
6.2 ElementTimeControl - Methods
Return Values for beginElement, beginElementAt, endElement, and endElementAt: The list items contain complete sentences without caps or periods. Example: (the begin attribute is not set to "indefinite") Could read: (The begin attribute is not set to "indefinite".)
6.5 Object TimeEvent
"TimeEvent has the all the properties TimeEvent has all the properties"
8. [HTML] HTML 4.0 Specification HTML 4.01 Specification
The SMIL Animation draft (Jan 28) in section 3.1 fifth paragraph says to include a namespace prefix if a given target attribute is not in the namespace of the target element. Actually, this is incorrect on two fronts, I believe:
a) According to my understanding of the XML Namespace spec, attributes without a namespace prefix are not in any namespace (they are in some sort of anonymous namespace). They are not in the namespace of the given element. Thus, the SMIL Animation spec needs to be changed to say that you must specify a namespace "if the target attribute is in an XML namespace".
b) The DOM2 spec is very clear that attributes are identified according to their _namespaceURI_ and their local name. The prefix is just something that is kept around and does not represent anything that can be counted on as being accurate or meaningful.
Thus, I believe that SMIL Animation needs a new attribute on the various animation elements to identify the namespace for the attribute that is being animated. A proposal is an attribute called 'attributeNS'. The value of the attribute is a namespace string, not a prefix, to match how DOM2 deals with namespace strings and not prefixes.
SVG needs this because we use the XLink namespace.
SVG would like 'systemRequired' to take a list of names, not just a single name. We want to allow an element within a 'switch' test for both DOM and animation support, for example.
Why is 'animateColor' needed instead of just using 'animate'?
Martin Duerst of the I18N IG thinks 'system-language' (nka systemLanguage) is a bad attribute name and thinks it should be changed to userLanguage. (The SVG group thinks the most important thing is that SMIL-Boston and SVG are consistent, so we are very likely to go along with whatever the SYMM group thinks about this issue.)
The SMIL Animation spec doesn't explicitly state what happens if no animation values are provided (e.g., no from/by/to or values). My assumption is that the underlying value is retained throughout the length of the animation. Is this correct? Should a sentence be added to make this clear?
Will the SMIL Animation draft be updated to include negative offsets from an event-value?
Relaxing the path data requirements for SMIL Animation to remove the requirement of an initial moveto. Is this necessary?
Do we want to talk about attributeType's rules (i.e., CSS takes priority over XML) against the Converged SVG proposal where CSS properties are also available as XML attributes?
Editorial nit: In section 3.1 of SMIL Animation (Jan 28 spec) fourth paragraph, the term "CSS namespace" is used. It would probably be better to talk about "the list of CSS properties which are recognized by the user agent." Same comment applies to the description of the 'auto' keyword which comes a few paragraphs later.
The Xlink href example needs to show proper use of the XLink namespace properly, as in:
<foo xmlns:xlink="http://www.w3.org/1999/xlink/namespace/">
<animate xlink:href="#foo" attribute="bar" .../>
</foo>
From: "Tim Berners-Lee" <timbl@w3.org>
To: <www-smil@w3.org>
Subject: [Moderator Action] SMIL muddled about Namespaces
This has just come to my attention. http://www.w3.org/TR/2000/WD-smil-animation-20000128/ says: "All constraints upon animation must be described in the host language specification, as the DTD cannot reasonably express this."
Please specify a way to do this using schemas.
There is an example in which there are no namespaces:
<rect ...>
<animate attributeName="width" from="10px" to="100px"
begin="0s" dur="10s" />
<animate attributeName="height" from="100px" to="10px"
begin="0s" dur="10s" />
</rect>
used to distinguish between the SVG and SMIL spaces. This is clearly an error.
Please ensure that future version of the spec use namespaces clearly.
Tim BL
As far as the second issue, there is no problem with namespaces here. The example is straight from SVG, and uses the elements and attributes defined in the SVG specification. While the timing and animation attributes and elements are present in the "SMIL-Animation namespace", SVG defines them as being part of the SVG language and does not qualify them as being part of a separate namespace. It certainly should be possible to create a namespace as a combination or superset of other namespaces, to support this, or to have elements/attributes be included in more than one namespace. In any case, this is a decision for SVG, and the example simply reflects the syntax in their language. Please see: http://www.w3.org/TR/SVG/animate.html#AnimateElement.
Last modified on: Tuesday, April 18, 2000 04:17:06 PM
By: Aaron Cohen (aaron.m.cohen@intel.com)