- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Mon, 24 May 2010 17:23:05 +1200
On Mon, May 24, 2010 at 3:52 PM, Philip J?genstedt <philipj at opera.com>wrote: > On Mon, 24 May 2010 03:03:15 +0200, Robert O'Callahan < > robert at ocallahan.org> wrote: > > Here's how I think it should work: >> -- currentTime (and related times, such as times in TimeRanges) range from >> 0 >> to 'duration' >> -- media resources are allowed to have a non-zero "initial playback time". >> This is what currentTime should be set to on media load. We could create a >> new DOM attribute to expose this. >> > > Is this a typo? If currentTime runes of 0 to duration, how can it begin at > something non-zero? Let me rephrase (English is such a bad language!): -- The valid values for currentTime (and related times) range from 0 to 'duration', inclusive. -- A media resource can specify an initial value for currentTime. What concretely should we change? Should we drop startTime, or redefine it? We could redefine it but it might be less confusing to drop it and use another name for the initial value of currentTime. Currently startTime means something quite different to that (as others have noted, it means basically the first time in the 'seekable' TimeRanges, or currentTime if those ranges are empty). So I would change: -- get rid of startTime and the concept of "earliest possible position", plus the related dispatching of timeupdate events -- create a new readonly DOM attribute, say call it "initialTime" that returns the default initial playback position for the media resource -- during media resource loading, when metadata loads set the current playback position to initialTime -- note that currentTime is always between 0 and 'duration' (if duration is known) Is it necessary to have the offset as an absolute date, or could that > probably odd case be handled in other ways? I can't really see a browser UI > making use of it, so I'd be happy to put it in a data-* attribute or using > microdata. > The "real time offset" is a property of the media resource (although I suppose we could have it settable via a content attribute as well) so it would need to be supported by the browser as an API on media elements. The question is whether there's enough demand to justify it. I don't know how widely supported this data is in media resource formats; Ogg Skeleton supports it, but I don't know about others. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100524/51449e23/attachment-0001.htm>
Received on Sunday, 23 May 2010 22:23:05 UTC