I understand that some here have reasons not to be happy with SMIL, but its
implementation within SVG really is quite nice and understandable. So far as
I can see, the discontent with it stems primarily from the fact SMIL seems
to have alternative specifications. Since the SVG implementation is the one
which seems to have met with fairly wide adoption, why not just converge
with the attribute set used there to control an animation?
Instead of media-loop-count it uses repeatCount. "dur" controls the
duration, "begin" controls when it starts, "end" controls when it stops.
Just for fun, one can add things like "begin=object.click" or
"begin=M.begin+1" to allow control to be passed declaratively, and to
synchronize multiple events, hence avoiding the need for copious script. If
one had multiple media elements on a page, controlling the synchronization
of those elements is quite within the province of SMIL(SVG).
All the timing mechanisms that are discussed here, are I believe, covered in
SMIL, each with a different set of attribute names.
It even has spline interpolations on the timing elements. In Opera or IE
with the Adobe plugin http://srufaculty.sru.edu/david.dailey/svg/smil.htm
shows some of the range of extant behavior.
Sorry if this horse is already dead, and copious apologies about my
cluelessness when it comes to how to read and write specifications, but
there are already authors and developers who are fluent in SVG/SMIL, so why
reinvent wheels?
respecfully,
David
----- Original Message -----
From: "Maciej Stachowiak" <[EMAIL PROTECTED]>
To: "Vladimir Vukicevic" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2007 10:58 PM
Subject: Re: [whatwg] Apple Proposal for Timed Media Elements
On Apr 4, 2007, at 7:31 PM, Vladimir Vukicevic wrote:
Maciej Stachowiak wrote:
CSS Timed Media Module proposal - http://webkit.org/specs/
Timed_Media_CSS.html
Some feedback on my initial reading.. the CSS properties specified seem
like a good set that will cover most common functionality. Some
comments about the spec, though:
Thanks for reading over this part.
1. 'media-loop-count' is an awkward name, especially with "The default
value of 1 means the item will play through once but will not loop." We
went through this with APNG, and ended up renaming that member. I would
suggest 'media-play-count' instead -- that way there is no ambiguity
with what the number means.
We considered 'media-repeat-count' instead of 'media-loop-count', but
that turned out to be more confusing. We really wanted all the
looping-related properties to have consistent naming, and I don't think
'play' would work in the other places mentioned.
2. The descriptions for 'media-loop-start-time' and 'media-loop-end-
time' don't match; start-time says "sets the time at which the media
item begins playing after looping", and end-time says "sets the time at
which the media item loops for the second and subsequent repetitions".
I would suggest that start-time says "sets the time index at which the
media item starts playing for the second and subsequent repetitions",
and that end-time says "sets the time index at which the media item ends
playing for the second and subsequent repetitions." The language for
end-time is still a little awkward, since "ends playing" could imply
that it simply stops playing (and does not loop), but it's clearer than
before.
I think the language might have ended up actually defining it wrong. The
intent of 'media-loop-end-time' is that this is the point where you end
where repeating, but on the last iteration you go all the way to
'media-end-time'. So if 'media-loop-count' has a value of 3, the three
repetitions would go as follows:
media-start-time ===> media-
loop-end-time
media-loop-start-time ===> media-
loop-end-time
media-loop-start- time
===> media-end-time
I'll update the spec.
3. 'media-timing' I would get rid of completely; while a shorthand would
be useful, I don't think that media-timing as specified really works.
Shorthands for properties such as 'background' are understandable on
their own; 'media-timing: playing 0s -0.5s 2 2s -4s 1' is very opaque.
If it's still desirable, I would remove the setting of start/end times
and change the volume shorthand to only accept the symbolic names; e.g.
'media-timing: playing high 4;'... but I think that removing the
shorthand entirely would be preferable.
I'll reply in more detail about media-timing in a later message.
Regards,
Maciej
