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

Philip Jägenstedt philipj at opera.com
Fri Oct 9 00:32:56 PDT 2009


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


More information about the whatwg mailing list