- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 13 Jan 2011 08:44:57 +0100
On Thu, 13 Jan 2011 01:23:57 +0100, Eric Carlson <eric.carlson at apple.com> wrote: > > On Jan 12, 2011, at 4:04 PM, Robert O'Callahan wrote: > >> On Wed, Jan 12, 2011 at 9:42 PM, Philip J?genstedt >> <philipj at opera.com>wrote: >> >>> For the record, this is the solution I've been imagining: >>> >>> * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false >>> if >>> missing >>> >>> * make setting HTMLMediaElement.currentTime be a non-exact seek, as >>> that >>> seems to be the most common case >> >> >> I think setting currentTime should be exact, since a) exact seeking is >> simpler from the author's point of view and b) it would be unfortunate >> to >> set currentTime to value T and then discover that getting currentTime >> gives >> you a value other than T (assuming you're paused). >> > I agree that precise seeking follows the principle of least surprise, > based partly on the bugs files against the <video> element on iOS where > this hasn't always been the behavior. Changing the default at this point wouldn't really hurt since not all browsers are doing exact seeking anyway, right? I think that keyframe seeking is more often what you want and it'd be better to let the few who want frame-exact seeking jump through hoops than having everyone who makes a simple seeking UI discover that seeking is a bit slow and 20% of them figuring out that it can be fixed by using seek(). -- Philip J?genstedt Core Developer Opera Software
Received on Wednesday, 12 January 2011 23:44:57 UTC