Dear SYMM WG-
This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to email@example.com.
"The begin attribute supports offset and event values, "indefinite", or
a semi-colon separated list of values. All other values are not
supported. The allowed values and semantics of the begin attribute are
defined in the SMIL 3.0 Timing and Synchronization module."
Please add links to the definition of "offset" and "event" values.
Please consider allowing the full range of begin values, or provide
reasons why SMIL Timesheets needs to be different from the rest of SMIL
Please clarify what happens if an unsupported value is encountered. Or
if is it intended that the host language defines it, please state that.
"The dur attribute supports the clock values, "media", and "indefinite".
The allowed values and semantics of the dur attribute are defined in the
SMIL 3.0 Timing and Synchronization module."
The listed values are exactly the same as in SMIL 3.0 Timing and
Synchronization specifies for dur. Repeated it here increases the risk
of errors and outdated definitions. We recommend pointing to the dur
definition and saying it MUST be exactly as defined there.
"The end attribute supports offset and event values, "indefinite", or a
semi-colon separated list of values. All other values are not
supported.The allowed values and semantics of the end attribute are
defined in theSMIL 3.0 Timing and Synchronization module."
Same comments apply here as for the 'begin' attribute.
"Since SMIL Timesheets does not include transitions, the
fill="transition"value of fill attribute is not supported. Also, since
the fillDefault attribute is not included in the SMIL Timesheets, the
fill="default" is interpreted the same as fill="auto"."
Note that the SMIL defaults are different from the SVG 'fill' attribute
defaults. See http://www.w3.org/TR/SVG11/animate.html#TimingAttributes.
That can be confusing, so please provide an example and some informative
text to explain this.
Why are there no transitions? This is something that authors will want,
and which is common in many script libraries (such as when a button
glows then fades when activated, or photo galleries blend between
images). Perhaps describing transitions in the form of opacity
animations and the like would be useful. If this functionality that is
intended for a later specification?
"The first attribute sets the current active child of a time
container"inactive". Then, it selects the first child element and sets
it "active". The first attribute can only be used for the excl time
container. The allowed value of the first attribute is a DOM event
Please clarify what it mean to set a time container to "inactive"/"active".
Please allow host languages to extend the set of allowed values to
include events that are not defined in DOM2Events.
"The prev attribute first checks, whether the current active child is
the first child. If not, it sets the current active child of a time
container "inactive". Then, it selects the previous child of the time
container and sets it "active". The prev attribute can only be used for
the excl timecontainer. The allowed value of the prev attribute is a DOM
Please clarify that these attributes (first,next,prev,last) only operate
on elements, not on textnodes. As it is now it might mean for example a
previous child textnode.
Also it's not clear why the attribute has to be restricted to <excl>
only, we think just specifying that it only applies to <excl> might be
better. Host languages might want to reuse these attributes, so perhaps
leave that open too.
These comments apply to all of the first, prev, next, last attributes.
While the next, prev etc might be useful for creating a slideshow, it
seems to be lacking something like a "skip multiple", say next+10 or
prev-5 elements. Although this might be difficult to add as an
attribute, it shows that the current set of prev, next, first, last may
not cover all common use-cases, and that they should be thought over
once more to see if there's a better solution.
-Doug Schepers, on behalf of the SVG WG