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

In IE9 we throw an  "Argument not optional" TypeError when calling document.getElementById() without parameters.
We're planning to follow this model for IndexedDB and continue to throw a TypeError [1].  This seems in line with the results of this
thread.

Israel
[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0917.html

 
> On Monday, June 13, 2011 9:41 AM, Adam Barth 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.
> >
> > > 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).
> >
> > Thanks,
> > Adam

Received on Monday, 13 June 2011 19:12:26 UTC