- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 15 Jun 2012 15:24:48 +0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>, Jonas Sicking <jonas@sicking.cc>
On Tue, Jun 12, 2012 at 1:46 AM, Ian Hickson <ian@hixie.ch> wrote: > When a document is aborted the state is more or less left exactly as it > was when it was aborted. This includes the readiness state. It also means > no events fire (e.g. no 'load', 'unload', or 'error' events), a number of > scripts just get abandoned without executing, appcache stuff gets > abandoned, queued calls to window.print() get forgotten, etc. > > Aborting a document is a very heavy-handed measure. Documents are not > expected to last long after they have been aborted, typically. Pages > aren't expected to remain functional beyond that point. That's not reality in all browsers right now, and I think it doesn't make sense to make that the reality. That is, there already browsers that transition readyState to "complete" upon aborting the parser and I think doing that makes sense (and I want to change Gecko to do that, too), because a non-"complete" readyState is a promise to fire an "load" event later. I think it's a bad idea to leave a document into the "loading" state when the browser engine knows that it won't fire and "load" event for the document. Basically, I think the platform should maximize the chances of the following code pattern causing doStuff to run once the document has completely loaded: if (document.readyState == "complete") { setTimeout(doStuff, 0); } else { document.addEventListener("load", doStuff); } -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 15 June 2012 12:25:30 UTC