[whatwg] Readiness of script-created documents

[Ian Hickson]

On Fri, 30 Mar 2012, Henri Sivonen wrote:
> On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson <ian at 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 <jonas at sicking.cc> wrote:
> > On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen <hsivonen at 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.   `._.-(,_..'--(,_..'`-.;.'