W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 13 Jun 2011 09:40:47 -0700
Message-ID: <BANLkTikxR+UYOVcgSLJSkhHe=vpjtQTpfg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Mark Pilgrim <pilgrim@google.com>, Eliot Graff <Eliot.Graff@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Israel Hilerio <israelh@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>
On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth <w3c@adambarth.com> wrote:
>> On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>>>> Adam Barth:
>>>>> > WebKit is looser in this regard.  We probably should change the
>>>>> > default for new IDL, but it's a delicate task and I've been busy.  :(
>>>> What about for old IDL?  Do you feel that you can make this change
>>>> without breaking sites?  One of the “advantages” of specifying the
>>>> looser approach is that it’s further down the “race to the bottom” hill,
>>>> so if we are going to tend towards it eventually we may as well jump
>>>> there now.
>>> I can't remember getting a single bug filed on Geckos current
>>> behavior. There probably have been some which I've missed, but it's
>>> not a big enough problem that it's ever been discussed at mozilla as
>>> far as I can remember.
>> Unfortunately, there's a bunch of WebKit-dominate content out there
>> that folks are afraid to break.  We discussed this topic on some bug
>> (which I might be able to dig up).  The consensus was that the value
>> in tightening this for old APIs wasn't worth the compat risk (e.g., in
>> mobile and in Mac applications such as Dashboard and Mail.app).
>> For new APIs, of course, we can do the tighter things (which I agree
>> is more aesthetic).  It mostly requires someone to go into the code
>> generator and make it the default (and then to special-case all the
>> existing APIs).  I'd like to do that, but it's a big job that needs to
>> be done carefully and I've got other higher priority things to do, so
>> it hasn't happened yet.
> If there is agreement that new APIs should throw for omitted
> non-optional parameters, then it seems clear that WebIDL should use
> that behavior.
> That leaves the work for safari (and possibly other webkit devs) to go
> through and mark parameters as [optional] in their IDL. Possibly also
> filing bugs for cases where you want the relevant spec to actually
> make the argument optional. I realize that this is a large amount of
> work, but this is exactly what we have asked in particular of
> microsoft in the past which has been in a similar situation of large
> divergence from the DOM specs, and large bodies of existing content
> which potentially can depend on IE specific behavior.

Think folks are agreed that's the path we should follow.  My only
concern is that we don't have anyone signed up to do the work on the
WebKit side.

> FWIW, I'd be happy to do the same to align Gecko behavior with specs
> when needed. For example I thought we were going to end up having to
> do that to make <null> coerce to "null" by default for DOMString
> arguments. It appears that in that case the WebIDL behavior changed to
> align with Gecko, which I think is unfortunate, and so it doesn't look
> like this change will have to happen (I used to argue otherwise in the
> past, but I've come around to the idea that aligning with JS behavior
> is more important, even when I'm not a fan of JS behavior).

Received on Monday, 13 June 2011 16:41:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC