- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 10 Jul 2012 19:15:27 +0000 (UTC)
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Mon, 23 Apr 2012, Henri Sivonen wrote:
>
> 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.
Done.
> 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.
Done.
> 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.
Done.
> 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.
Done.
> 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".
Agreed.
> 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.
Disagreed. IMHO DOMContentLoaded is equivalent to 'load', just a bit
earlier (it's basically 'load' but before the scripts have run). In fact,
I'd specifically define DOMContentLoaded as meaning "the DOM content was
completely loaded", which clearly can't happen if the parser aborted.
> 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.
Agreed.
> 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.
Agreed.
> 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.
Agreed.
> 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.
I haven't defined this because to define this I'd have to define a ton of
infrastructure that explains how XSLT works in the first place, and I'm
still waiting for the XSLT community to write the tests that demonstrate
what the requirements should be:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689
> Aside: Might make sense to spec DOMFrameContentLoaded. Firefox and
> Opera support it.
I haven't specced this yet. Is there interest from other browsers to
support it? I hesitate to make this part of the spec any more complex...
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 July 2012 19:16:09 UTC