[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