- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 09 Oct 2009 09:32:56 +0200
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