[whatwg] Restarting the media element resource fetch algorithm after "load" event

[Andrew Scherkus]

Chiming in here from Chrome's perspective...

We use a combination of in-memory and block-based caching for media
resources.  There is no guarantee whatsoever on what is loaded.  There's a
nice side benefit of allowing complete random access to the file if the
server supports range request (in my opinion a must if you're working on an
audio/video site, but that's a side issue).

For http:// we don't support load at all and never reach NETWORK_LOADED.
 We're also baffled at what to report in our progress events because the
numbers are seemingly useless in our context.  Sometimes we'll cache the end
of the file to grab some useful metadata, but we don't want to fire a
progress event saying we've loaded the last bit of the file...

For file:// we immediately transition to NETWORK_LOADED.  This is how we
pass the WebKit layout tests :)

Being the only browser (I think?) that doesn't fire the load event we've ran
into site compatibility issues.  I believe a lot of web authors are used to
tacking onload= into a tag and expecting it to work.  I've reached out to
web authors to educate them about using canplaytype() +
oncanplay/oncanplaythrough as alternatives to user agent checking and
onload.

I'm in favour of getting rid of both load and progress events.

Andrew

On Fri, Oct 9, 2009 at 2:27 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Oct 9, 2009 at 8:32 PM, Philip Jägenstedt <philipj at opera.com>wrote:
>
>> Aesthetics is not a serious argument. More importantly, the progress
>> events spec [1] requires that exactly one of error/abort/load be fired
>> followed by loadend. Dropping load and loadend would be a willful violations
>> of that spec. In my opinion, the progress events spec should be the one to
>> change.
>>
>> [1] http://www.w3.org/TR/progress-events/
>>
>
> I agree.
>
> That spec says
>
>> If the Operation successfully completes, the user agent *must* dispatch a
>> load event.
>>
> Here we're just dealing with an operation that never completes. The only
> real problem in the spec is that it says "Exactly one of these *must* be
> dispatched", which seems to just not have considered the possibility of
> operations that run indefinitely.
>
> Some other Mozilla developers have actually argued that progress events in
> general don't make sense for media elements. The 'buffered' TimeRanges
> attribute gives you much more accurate and useful information than progress
> events. The progress event 'loaded' and 'total' attributes don't make a lot
> of sense in implementations where data may be discarded and redownloaded
> during the load. (If you discard some data, does the next progress event
> have a smaller 'loaded' value than the last one? Or does 'total' increase by
> the size of the discarded data?) But I don't want to open that can of worms
> just yet :-).
>
>
> 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/20091013/a52af18e/attachment-0002.htm>