Re: [whatwg] Readiness of script-created documents
Ian Hickson
>
> 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. `._.-(,_..'--(,_..'`-.;.'
Henri Sivonen
> 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
hsiv...@iki.fi
http://hsivonen.iki.fi/
Jonas Sicking
> 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
Henri Sivonen
> On Friday, March 30, 2012, Henri Sivonen 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.
Jonas Sicking
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
Jonas Sicking
> 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?
>
> on a crazy edge case behavior.
I think we should aim higher than that for the web platform.
/ Jonas