W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 09 Oct 2009 09:32:56 +0200
Message-ID: <op.u1iu86lysr6mfa@sisko>
On Thu, 08 Oct 2009 23:08:32 +0200, Robert O'Callahan  
<robert at ocallahan.org> wrote:

> On Fri, Oct 9, 2009 at 1:32 AM, Philip J?genstedt <philipj at opera.com>  
> wrote:
>
>> The spec notes that "Some resources, e.g. streaming Web radio, can never
>> reach the NETWORK_LOADED state." In my understanding, you mustn't go to
>> NETWORK_LOADED if you can't guarantee that the resource will remain in
>> cache. Browsers with clever caching or small caches simply won't send a  
>> load
>> event most of the time.
>>
>
> Right, HTML5 allows Gecko to simply never enter the NETWORK_LOADED state  
> and
> send a "load" event. That would be the simplest thing for us to do, and I
> think the best in terms of letting us do intelligent caching. But I'd  
> prefer
> not to do it alone.

No objection to dropping the event and implementing as such here.

> Aesthetically, however, I think it would be strange to not have the load
>> event.
>>
>
> If you mean because of the analogy with the "load" events of other  
> elements,

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/

-- 
Philip J?genstedt
Opera Software
Received on Friday, 9 October 2009 00:32:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:17 UTC