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

Last call comments on SMIL animation]

From: Thierry MICHEL <tmichel@w3.org>
Date: Tue, 29 Feb 2000 17:23:02 +0100
Message-ID: <38BBF266.9042D3E@w3.org>
To: www-smil@w3.org


Thierry MICHEL                        	tmichel@w3.org
W3C / INRIA 				+33 (0) 4 92 38 79 87
2004, Route des Lucioles                       	
BP 93                                   
06902 Sophia Antipolis Cedex,           

attached mail follows:


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

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

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.

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 'endAnimation()',....

'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 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: 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 sense
   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 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.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org
Received on Tuesday, 29 February 2000 11:23:17 UTC

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