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

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.

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).

/ Jonas

Received on Monday, 13 June 2011 08:32:16 UTC