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

On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth <w3c@adambarth.com> wrote:
> 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.

Just to update this thread, Mark Pilgrim has stepped forward to get
the ball rolling on this work, so WebKit is making progress on this
front.

Thanks,
Adam


>> 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 Sunday, 19 June 2011 06:36:46 UTC