W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: waiting and seeking events in media element seek algorithm

From: Simon Pieters <simonp@opera.com>
Date: Thu, 08 Apr 2010 08:25:47 +0200
To: Philip J├Ągenstedt <philipj@opera.com>, "Ian Hickson" <ian@hixie.ch>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.vatys9igidj3kv@simon-pieterss-macbook.local>
On Thu, 08 Apr 2010 01:10:45 +0200, Ian Hickson <ian@hixie.ch> wrote:

>> "skip"? Do you mean if there is a detectable delay before the new frame
>> shows up? What's the use case for this? The waiting event for the
>> network serves this purpose if the delay is because of the network. For
>> decoding, however, it's quite difficult to know how long it's going to
>> take before it's done, so we will simply always fire it. Is there any
>> browser that does things differently or plans to? The spec could
>> certainly be clearer on what a UA behavior is allowed here.
>
> The use case is not having flickering UI (blinking the word "seeking...")
> if it's not necessary. If it would be helpful, I can make the spec more
> explicitly queue the task to fire "seeking" and then abort the send if by
> the time the task is ready, the seek is complete, or some such.

You get unwanted flickering UI anyway if the seek takes 1ms instead of  
0ms. I think it's better if sites implement the logic for flickering  
avoidance (e.g. with a timeout and transisions) than the UA sometimes not  
firing an event. Having the event sometimes not fire seems like a  
surprising and hard to debug behavior for authors.

-- 
Simon Pieters
Opera Software
Received on Thursday, 8 April 2010 06:26:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:07 GMT