W3C home > Mailing lists > Public > public-html@w3.org > August 2009

'progress' events for media elements

From: Simon Pieters <simonp@opera.com>
Date: Fri, 07 Aug 2009 16:22:29 +0200
To: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.uyap7rw5idj3kv@zcorpandell.linkoping.osa>
The spec says to fire 'progress' events every 350ms while downloading  
media data. If all media data is in cache, no 'progress' events will be  
fired. However, the 'load' event is not fired until the resource selection  
algorithm has finished, and the resource selection algorithm includes  
decoding data, so it is not predictable how long it will take until the  
'load' event is fired.

This makes it impossible to test that 'progress' events are fired at all,  
since a browser could just claim that they have all media data cached and  
are just spending time on decoding the video as part of the resource  
selection algorithm.

Arguably the 'load' event should not be coupled with media decoding, but  
OTOH it seems reasonable to assume that authors will expect duration and  
dimensions to be known in <video onload=...>.

I would suggest that the spec require that one 'progress' event is fired  
when all data is loaded, but not waiting for anything to be decoded. This  
will make 'progress' testable and also make progress bars more accurate.

Simon Pieters
Opera Software
Received on Friday, 7 August 2009 14:23:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC