[whatwg] Readiness of script-created documents
jonas at sicking.cc
Mon Apr 2 01:29:59 PDT 2012
On Mon, Apr 2, 2012 at 12:12 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Fri, Mar 30, 2012 at 8:26 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Friday, March 30, 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.
>> That's not a particularly strong argument. The question is what's better for
> 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.
More information about the whatwg