Forwarded message 1
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 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
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.
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
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: 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
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.
Regards, Martin.
#-#-# Martin J. Du"rst, World Wide Web Consortium
#-#-# mailto:duerst@w3.org http://www.w3.org