[Timesheets LC comment] 5.1 Attributes

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 www-svg@w3.org.


"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 
(and SVG).

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 
[DOM2Events]."

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 
event [DOM2Events]."

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.



Regards-
-Doug Schepers, on behalf of the SVG WG

Received on Saturday, 1 March 2008 22:53:09 UTC