Re: [whatwg] Proposal for readyState behavior
On Mon, 16 Jul 2012, Henri Sivonen wrote: 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. Could you please leave your sense of logic at the door instead of rocking the interop boat like this? We're talking about when a document gets aborted here. Interop really isn't particularly critical. I think this is an area where it makes a lot more sense to keep things simple. The platform is confusing enough as it is without us having confusing behaviour where it's not strictly necessary. I think that in a situation like this change is more harmful and likely to break something than the sort of logic you offered is useful. Can you elaborate on how any changes here are really likely to break anything? I'm finding it hard to see why this area is interop-sensitive. 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 I don't think you need to spec infrastructure to define a high-level expectation that loads with XSLT errors are supposed to finish as if they were successful loads rather than aborted loads. IMHO there's no value in making vague meaningless statements (which the statement loads with XSLT errors are supposed to finish as if they were successful loads would be without defining loads for XSLT, finish for such loads, and as if). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for readyState behavior
On 8/29/12 6:18 PM, Ian Hickson wrote: We're talking about when a document gets aborted here. Interop really isn't particularly critical. It depends on _why_ it was aborted. From a user point of view, having aborted documents work correctly (including firing onload) is really nice in many cases. It sounds to me like we're putting implementors and spec authors ahead of users here -Boris
Re: [whatwg] Proposal for readyState behavior
On Tue, Jul 10, 2012 at 10:15 PM, Ian Hickson i...@hixie.ch wrote: Done. Thanks. 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. Could you please leave your sense of logic at the door instead of rocking the interop boat like this? Personally, I'm already spending way more than enough time in this quagmire of trying to sort out events and readyStates with abnormal document loads that I have about zero interest in making Gecko not fire an event in a situation where Firefox, IE10 and Opera currently fire it. Furthermore, I think that in a situation like this change is more harmful and likely to break something than the sort of logic you offered is useful. 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 I don't think you need to spec infrastructure to define a high-level expectation that loads with XSLT errors are supposed to finish as if they were successful loads rather than aborted loads. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Proposal for readyState behavior
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
[whatwg] Proposal for readyState behavior
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
