- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 7 Jun 2011 18:40:08 -0700
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: Jeremy Orlow <jorlow@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jun 7, 2011 at 11:30 AM, Israel Hilerio <israelh@microsoft.com> wrote: > On Tuesday, June 07, 2011 1:13 AM, Jonas Sicking wrote: >> Actually, WebIDL just changed from turning null into "null" to turning null >> into "". Turns out that a bunch of functions depended on that behavior and >> so it seems like that's what we'll be stuck with. >> >> In any case, I think IndexedDB should be silent on the issue and simply rely >> on WebIDL defaults. That should give the most consistent behavior to most >> other DOM functions. >> >> / Jonas >> >> On Mon, Jun 6, 2011 at 11:54 PM, Jeremy Orlow <jorlow@chromium.org> >> wrote: >> > We should probably just remove the special case. I believe WebIDL >> > specifies that a null would then turn into the string "null". This is >> > what we've done pretty much everywhere else I believe. >> > J >> > >> > On Mon, Jun 6, 2011 at 7:23 PM, Israel Hilerio <israelh@microsoft.com> >> > wrote: >> >> >> >> The parameter of IDBDatabase.setVersion is defined in the WebIDL as >> >> [TreatNullAs=EmptyString] but in the method definition it says that >> >> the parameter cannot be nullable. Do we want to enable null values? >> >> >> >> Israel >> >> >> > >> > > > Are we saying that we should remove the "TreatNullAs=EmptyString" and keep the parameter restriction that "version" cannot be nullable? I think we should remove any extended attributes from the IDL and just use the default behavior. It is much less important to me what the actual default behavior is, than that we use the default behavior which presumably is the most common behavior. So, "yes" :) / Jonas
Received on Wednesday, 8 June 2011 01:41:05 UTC