[whatwg] Proposal for readyState behavior

[Henri Sivonen]

I propose we adopt the following rules:
 1) Every document that's being built by a parser or being built by an
XSLT engine has "loading" as its readyState.
     Rationale:
       * This is intuitive.
       * It makes sense to make the XSLT experience as similar as
possible to the parser experience to avoid weirdness and also because
in most browser the XSLT result going through the HTML parser.
       * This is already true in Chrome, Opera and Firefox 14. (It's
not always true in older Firefox: document.open() forgets to change
readyState to "loading" in Firefox < 14.)
     Note: This is not true for trivial non-script-created documents
in IE 6 through 10 inclusive, but since all other engines get away
with not cloning IE's weirdness, it seems we don't need to clone it.
In all versions of IE 6 through 10 inclusive, it's possible for a
document to be in mid-parse but have "interactive" as its readyState.
It seems to me that complex cases (enough external resources not
already in cache) may change the behavior to a direction more similar
with other browsers, but now I fail to reproduce this.
     Delta from the spec: Make this explicit for XSLT.
 2) Every document that's no longer being parsed reaches readyState
"complete" as the event loop gets to spin.
     Rationale:
       * It's counter-intuitive for aborted documents to stay in the
"loading" state forever.
       * This seems to be already true in Chrome, Opera and IE for
documents that have been being parsed at some point. (Curiously,
Firefox makes an effort to keep this false for Firefox!)
     Delta from the spec: Aborted documents reach "complete". Making
this explicit for XSLT.
 3) No document transitions from "loading" to "complete" without an
intermediate "interactive" state.
     Rationale:
       * It's counter-intuitive and potentially bug-inducing for
special cases to skip the "interactive" state when the "interactive"
state occurs on the common path in Chrome, Opera and Firefox.
       * Cases where this currently isn't true are so inconsistent
between browsers that I'm assuming they are bugs or intentional ad hoc
hacks that haven't been informed by broader research.
    Delta from the spec: To the extent there's the above delta that
aborted documents reach "complete", this is new. Making this explicit
for XSLT.
 4) Whenever a transition to "interactive" is made, "DOMContentLoaded"
must eventually get fired later if the document stays in a state where
events can fire on it.
     Rationale:
       * This seems sensible for consistency with the common case.
Currently, there are cases where Firefox fires DOMContentLoaded
without a transition to "interactive" or transitions to "interactive"
without ever firing DOMContentLoaded, but these cases are inconsistent
with other browsers, so it's hard to believe they are well-considered
compatibility features.
    Delta from the spec: Same as for point 3.
 5) window.stop() aborts the parser.
     Rationale:
       * Already true in Firefox and Chrome.
       * document.execCommand('Stop') is the closest equivalent in IE
and it aborts the parser when loading from network (not in the
document.open() case, though!)
    Delta from the spec: Currently, the spec cancels navigation
instead of aborting the parser.
 6) The "load" event doesn't fire for documents whose parser has been aborted.
     Rationale:
       * Already true in Firefox, Chrome and IE. (I don't know of a
way to abort the parser in Opera from JS without side effects that'd
interfere with testing.)
    Delta from the spec: If "the end" part of the parse starts running
on abort, "load" can't fire as an unconditional part of "the end".
 7) The "load" event shouldn't fire synchronously.
     Rationale:
       * Events that sometimes fire synchronously and sometimes
asynchronously are trouble.
       * Already true in Opera and Firefox. (But not in Chrome and IE9!)
    Delta from the spec: No delta.
 8) When readyState changes, a "readystatechange" should be fired
(synchronously immediately after readyState changed)
     Rationale:
       * Seems illogical not to.
       * Already true in Chrome and Firefox, so it seems browsers can
get away with doing the logical thing.
    Delta from the spec: No delta.
 9) Never fire "readystatechange" so that the old and new readyState
are the same.
     Rationale:
       * Logic.
       * All deviations from this rule look like browser-specific bugs.
    Delta from the spec: No delta.
10) XSLT error pages don't count as aborts but instead as non-aborted
loads of the error page.
     Rationale:
       * Makes parent pages less confused about events they are waiting.
       * Already true except for bugs in Firefox which is the only
browser with XSLT error pages.
    Delta from the spec: Make explicit in spec.

Aside: Might make sense to spec DOMFrameContentLoaded. Firefox and
Opera support it.

Demos of interest:
http://hsivonen.iki.fi/test/moz/readystate/

IE can go to "interactive" prematurely:
http://hsivonen.iki.fi/test/moz/readystate/baseline.html
IE can omit "interactive":
http://hsivonen.iki.fi/test/moz/readystate/document-open.html
"load" can be synchronous in Chrome and IE:
http://hsivonen.iki.fi/test/moz/readystate/document-open.html
Firefox forgets DOMContentLoaded for XSLT:
http://hsivonen.iki.fi/test/moz/readystate/xslt.html
Firefox skips "interactive" but not DOMContentLoaded when aborting:
http://hsivonen.iki.fi/test/moz/readystate/window-stop.html
Documents aborted by window.location reach "complete" in Opera:
http://hsivonen.iki.fi/test/moz/readystate/window-location.html
Defer scripts are executed at the wrong time in Firefox:
http://hsivonen.iki.fi/test/moz/readystate/defer-script.html

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/