W3C home > Mailing lists > Public > www-smil@w3.org > January to March 2000

ALL Last call comments on SMIL animation

From: Thierry MICHEL <tmichel@w3.org>
Date: Tue, 29 Feb 2000 17:25:02 +0100
Message-ID: <38BBF2DE.F11D1993@w3.org>
To: Aaron Cohen <aaron.m.cohen@intel.com>, Chris Lilley <chris@w3.org>, Patrick Schmitz <pschmitz@microsoft.com>
CC: www-smil@w3.org

I have collected in this mail ALL the Last call comments on SMIL
animation sent to the Smil mailing list (www-smil@w3.org). 

The Last Call review period is now over, it ended at 2359Z on 27
February 2000. 



Objet: SMIL animation WAI review
Date: Mon, 28 Feb 2000 03:08:56 -0500 (EST)
De:Daniel Dardailler <danield@w3.org>

Most of these comments are to do with improving the accessibilty of the
specification itself, or of the examples that it uses:

The last example in section 3.2.1 demonstrates an animation being raised
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
requires device-independence for input triggers.

Same comment arises in relation to most of the examples in 3.3.2

It is noted that some more pictures would help - indeed they would.

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
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
example is hypothetical it doesn't need to be taken further, although a
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

Section 3.5 describes the sandwich model, noting that changes to CSS
will still be subject to the CSS cascade, which is an accessibility
requirement. It is probably worthwhile at that point making a brief
that another effect of this is that animations may not in fact be
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 pragraphs 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
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
using focusin / focusout. Whether a corresponding adjustment in the link
is strictly necessary is a moot point - one could expect users of
technologies and mouseless systems to go the extra distance in learning
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 example of illegal SMIL in 5.4 should nonetheless provide
content for the image - an alt attribute at least.

Other than that we think the question of giving assistive technologies
to the animation effects is a (soon to be fairy important) matter for
Agent Guidelines.


Objet: Last call comments on SMIL animation
Date:Mon, 28 Feb 2000 01:10:51 -0500 (EST)
De:"Martin J. Duerst" <duerst@w3.org>


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

- 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 boguous for the 'targetElement' attribute. This attribute
  has no justification for existence at all. And claims of simpler
  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.

Other comments:

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

General: There should be a glossary. Terms such as 'simple duration',
   'document duration', 'animation function', and so on should go in

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
   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.

2.1: Animation functions could be defined that were purely ...
   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.

3. 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 familliar 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

'Synchbase value': This title appears much too small. Please make sure
   the stylesheet 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 examlpe 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

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: Sandwitch 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 choosen.

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
   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: Cannont reasonably by interpolated: by -> be

4.3: It should be mentionned 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
   for the relative form': Why?

4.3: origin="default": What are the other values? How are they

4.4: Say something about the fact that this definition of color
   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.

Regards,   Martin.

Objet: I18N last call comments on SMIL Animation
Date:Sun, 27 Feb 2000 21:33:54 -0500 (EST)
De: "Martin J. Duerst" <duerst@w3.org>


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.

Objet: minor typos in WD-smil-animation-20000128
Date:  Sun, 6 Feb 2000 00:54:39 -0500 (EST)
De: Susan Lesch <susan@textet.com>

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.

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 

The attribute value is one of the following (values are case-sensitive):
The attribute value is one of the following; (values are

 From this point on, a section and paragraph number is followed by a 
quote, followed by a suggested correction.

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.

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 <em>frozen</em> state to the <em>finished</em> state
from the frozen state to the finished state

3.7.4 par 2 #3

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

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 <code>calcMode</code>.

4.4 par 2
sRGB could link to a reference:
"A Standard Default Color Space for the Internet - sRGB", M. 
Anderson, R. Motta, S. Chandrasekar, M. Stokes. Available at 

5. intro par
allowed/supported events.
[To remove the slash construct, I'd propose the following minor
This includes basic definitions, constraints upon animation, allowed 
events and supported events.

5.2 par 2
"...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
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

[1] http://www.w3.org/TR/2000/WD-smil-animation-20000128

Best wishes and good luck with your project,
Susan Lesch


Thierry MICHEL                        	tmichel@w3.org
W3C / INRIA 				+33 (0) 4 92 38 79 87
2004, Route des Lucioles                       	
BP 93                                   
06902 Sophia Antipolis Cedex,           
Received on Tuesday, 29 February 2000 11:28:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:22 UTC