- From: Thierry MICHEL <tmichel@w3.org>
- Date: Tue, 29 Feb 2000 17:25:02 +0100
- 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.
Thierry.
-------------------------------------------------------------
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
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
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
(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 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
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.
----------------------------------
Objet: Last call comments on SMIL animation
Date:Mon, 28 Feb 2000 01:10:51 -0500 (EST)
De:"Martin J. Duerst" <duerst@w3.org>
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.
---------------------------------------------------------------
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>
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.
---------------------------------------------------------------
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
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):
From this point on, a section and paragraph number is followed by a
quote, followed by a suggested correction.
1.
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 <em>frozen</em> state to the <em>finished</em> state
or
from the frozen state to the finished state
3.7.4 par 2 #3
begin="indefinite"
<code>begin="indefinite"</code>
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 <code>calcMode</code>.
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.
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
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
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/
_______________________________________________________________
Thierry MICHEL tmichel@w3.org
W3C / INRIA +33 (0) 4 92 38 79 87
2004, Route des Lucioles
BP 93
06902 Sophia Antipolis Cedex,
France
_______________________________________________________________
Received on Tuesday, 29 February 2000 11:28:57 UTC