Re: [whatwg] Readiness of script-created documents
On Thu, 30 Aug 2012 00:16:56 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 8/29/12 6:11 PM, Ian Hickson wrote: Documents that are aborted do not need to work, they were aborted precisely because they don't need to work and are no longer needed. Or because once again some ad was taking forever to load and the web page developer is doing all their stuff from onload, so the user just hit stop to finally get the damn ui to show up. Happens all the time for me... Indeed. It would be pretty bad user experience if we didn't fire load when the user clicks stop. -- Simon Pieters Opera Software
Re: [whatwg] Readiness of script-created documents
On Tue, Jun 12, 2012 at 1:46 AM, Ian Hickson i...@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
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Fri, 30 Mar 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. On Fri, 30 Mar 2012, Jonas Sicking wrote: That's not a particularly strong argument. The question is what's better for authors. On Mon, 2 Apr 2012, Henri Sivonen wrote: Gratuitously changing features introduced by IE does not help authors when they have to support the old IE behavior for years. Either authors don't use the API in the uninteroperable situation or they will have to deal with different browsers returning different things. The easiest path to get to the point where all browsers in use return the same thing would have been for others to do what IE did. On Mon, 2 Apr 2012, Jonas Sicking wrote: Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? Second, you are assuming that people are actually aware of this edge case and account for it. Here it seems just as likely to me that generic code paths would result in buggy pages given IEs behavior, and correct behavior given the specs behavior. Third, if no-one is hitting this edge case, which also seems quite plausible here, then it having a while longer without interoperability won't really matter what we do and doing the most useful thing seems like the best long-term goal. On Tue, 3 Apr 2012, Henri Sivonen wrote: No one is worse off and stuff works even if an author somewhere relies on a crazy edge case behavior. On the other hand, for cases no one is hitting, it's probably not worthwhile to spend time trying to get the behavior to change from what was initially introduced. On Tue, 3 Apr 2012, Jonas Sicking wrote: I think we should aim higher than that for the web platform. I agree with Jonas here. If browsers are going to have to change anyway, why not change to the better solution, even if that isn't the solution that is most trivial to implement or the solution that the first implementation happened to have? The platform has enough crazy without us adding more to it when we don't have to. On Mon, 23 Apr 2012, Henri Sivonen wrote: On Mon, Jun 20, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. Why don't aborted documents reach complete in Gecko? It seems weird to have aborted documents stay in the loading state when they are not, in fact, loading. On Wed, 25 Apr 2012, Jonas Sicking wrote: Sounds like a bug, I don't think this was done on purpose. I agree that we should ideally only be in loading when we're actually loading. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 23, 2012 at 4:55 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Jun 20, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. Why don't aborted documents reach complete in Gecko? It seems weird to have aborted documents stay in the loading state when they are not, in fact, loading. Sounds like a bug, I don't think this was done on purpose. I agree that we should ideally only be in loading when we're actually loading. / Jonas
Re: [whatwg] Readiness of script-created documents
On Mon, Jun 20, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. Why don't aborted documents reach complete in Gecko? It seems weird to have aborted documents stay in the loading state when they are not, in fact, loading. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 2, 2012 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? No one is worse off and stuff works even if an author somewhere relies on a crazy edge case behavior. Second, you are assuming that people are actually aware of this edge case and account for it. Here it seems just as likely to me that generic code paths would result in buggy pages given IEs behavior, and correct behavior given the specs behavior. Third, if no-one is hitting this edge case, which also seems quite plausible here, then it having a while longer without interoperability won't really matter what we do and doing the most useful thing seems like the best long-term goal. On the other hand, for cases no one is hitting, it's probably not worthwhile to spend time trying to get the behavior to change from what was initially introduced. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Tue, Apr 3, 2012 at 4:39 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Apr 2, 2012 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? No one is worse off and stuff works even if an author somewhere relies on a crazy edge case behavior. I think we should aim higher than that for the web platform. / Jonas
Re: [whatwg] Readiness of script-created documents
On Fri, Mar 30, 2012 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Friday, March 30, 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. That's not a particularly strong argument. The question is what's better for authors. Gratuitously changing features introduced by IE does not help authors one day have to support the old IE behavior for years. Either authors don't use the API in the uninteroperable situation or they will have to deal with different browsers returning different things. The easiest path to get to the point where all browsers in use return the same thing would have been for others to do what IE did. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 2, 2012 at 10:12 AM, Henri Sivonen hsivo...@iki.fi wrote: Gratuitously changing features introduced by IE does not help authors one day have to ...when they have to... -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 2, 2012 at 12:12 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, Mar 30, 2012 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Friday, March 30, 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. That's not a particularly strong argument. The question is what's better for authors. Gratuitously changing features introduced by IE does not help authors one day have to support the old IE behavior for years. Either authors don't use the API in the uninteroperable situation or they will have to deal with different browsers returning different things. The easiest path to get to the point where all browsers in use return the same thing would have been for others to do what IE did. Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? Second, you are assuming that people are actually aware of this edge case and account for it. Here it seems just as likely to me that generic code paths would result in buggy pages given IEs behavior, and correct behavior given the specs behavior. Third, if no-one is hitting this edge case, which also seems quite plausible here, then it having a while longer without interoperability won't really matter what we do and doing the most useful thing seems like the best long-term goal. / Jonas
Re: [whatwg] Readiness of script-created documents
On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Friday, March 30, 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch javascript:; wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. That's not a particularly strong argument. The question is what's better for authors. / Jonas
Re: [whatwg] Readiness of script-created documents
On Mon, 20 Jun 2011, Henri Sivonen wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) On Mon, 20 Jun 2011, Jonas Sicking wrote: complete seems like the most useful and consistent value which would seem like a good reason to require that. Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Readiness of script-created documents
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. / Jonas
