Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Sun, Jun 19, 2011 at 2:35 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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. I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. -Mark
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Cheers! On 6/23/11, Mark Pilgrim pilg...@google.com wrote: On Sun, Jun 19, 2011 at 2:35 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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. I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. -Mark -- Sent from my mobile device
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. Great work! I’m really happy to see some of the more complex requirements of Web IDL start to get implemented, so that we can find out sooner whether there are any problems that require spec changes. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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).
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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. We saw that happen with addEventListener. The reason we made the last argument optional for addEventListener wasn't that we had compatibility problems, but rather that it seemed like a good idea as the argument is almost always set to false, and being the last argument, making it optional works great. The fact that webkit already had this behavior was only discussed tangentially. Jonas Sicking: This is why it surprises me of WebIDL specifies WebKit behavior as the compliant behavior as Cameron seems to indicate. In the spec right now it’s listed as an open issue, and it was the WebKit behaviour that I was going to specify to resolve the issue this week. (So it’s not what the spec currently says.) This is what I mentioned in http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html although I didn’t get any pushback then. I am happy to keep discussing it but I would like to settle on a solution soon. So I guess you are arguing for “throw if too few arguments are passed, ignore any extra arguments”. Yes. In fact, unless someone can show that the web depends on the currently specced behavior, I don't see a reason to change Gecko. When we have overloads like void f(in long x); void f(in long x, in long y, in long z); we’d need to decide whether f(1, 2) throws or is considered a call to the first f with an extra, ignored argument. The former seems more consistent to me. I agree, throwing seem better as it's more likely a bug on the callers part. Or at the very least ambiguous which behavior they want which means it's better to throw. / Jonas
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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. Adam We saw that happen with addEventListener. The reason we made the last argument optional for addEventListener wasn't that we had compatibility problems, but rather that it seemed like a good idea as the argument is almost always set to false, and being the last argument, making it optional works great. The fact that webkit already had this behavior was only discussed tangentially. Jonas Sicking: This is why it surprises me of WebIDL specifies WebKit behavior as the compliant behavior as Cameron seems to indicate. In the spec right now it’s listed as an open issue, and it was the WebKit behaviour that I was going to specify to resolve the issue this week. (So it’s not what the spec currently says.) This is what I mentioned in http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html although I didn’t get any pushback then. I am happy to keep discussing it but I would like to settle on a solution soon. So I guess you are arguing for “throw if too few arguments are passed, ignore any extra arguments”. Yes. In fact, unless someone can show that the web depends on the currently specced behavior, I don't see a reason to change Gecko. When we have overloads like void f(in long x); void f(in long x, in long y, in long z); we’d need to decide whether f(1, 2) throws or is considered a call to the first f with an extra, ignored argument. The former seems more consistent to me. I agree, throwing seem better as it's more likely a bug on the callers part. Or at the very least ambiguous which behavior they want which means it's better to throw. / Jonas
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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. Here's the bug: https://bugs.webkit.org/show_bug.cgi?id=21257 Sample opinion from one of the project leaders: [[ Like other such sweeping changes, it’s highly likely there is some content unwittingly depends on our old behavior. All a programmer has to do is forget one argument to a function, and the program gets an exception whereas before it would keep running. If it’s code or a code path that was never tested with engines other than WebKit then this could easily be overlooked. Thus this change is almost certain to break Safari-only code paths or even WebKit-only ones on at least some websites, Dashboard widgets, Mac OS X applications, iPhone applications, and iTunes Store content. Other than that, I’m all for it! ]] Adam We saw that happen with addEventListener. The reason we made the last argument optional for addEventListener wasn't that we had compatibility problems, but rather that it seemed like a good idea as the argument is almost always set to false, and being the last argument, making it optional works great. The fact that webkit already had this behavior was only discussed tangentially. Jonas Sicking: This is why it surprises me of WebIDL specifies WebKit behavior as the compliant behavior as Cameron seems to indicate. In the spec right now it’s listed as an open issue, and it was the WebKit behaviour that I was going to specify to resolve the issue this week. (So it’s not what the spec currently says.) This is what I mentioned in http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html although I didn’t get any pushback then. I am happy to keep discussing it but I would like to settle on a solution soon. So I guess you are arguing for “throw if too few arguments are passed, ignore any extra arguments”. Yes. In fact, unless someone can show that the web depends on the currently specced behavior, I don't see a reason to change Gecko. When we have overloads like void f(in long x); void f(in long x, in long y, in long z); we’d need to decide whether f(1, 2) throws or is considered a call to the first f with an extra, ignored argument. The former seems more consistent to me. I agree, throwing seem better as it's more likely a bug on the callers part. Or at the very least ambiguous which behavior they want which means it's better to throw. / Jonas
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Mon, Jun 13, 2011 at 6:19 PM, Jonas Sicking jo...@sicking.cc wrote: 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. Actually there was a compatibility problem with one site, and that's what triggered us to make the third parameter of addEventListener optional: https://bugzilla.mozilla.org/show_bug.cgi?id=613634 Yes. In fact, unless someone can show that the web depends on the currently specced behavior, I don't see a reason to change Gecko. I don't know of any other examples other than that one site, so I wouldn't say we have evidence that the Web depends on the currently specced behavior. I think we can hold the line unless more compatibility issues appear. I think Ojan's request to make more parameters explicitly optional here: https://bugs.webkit.org/show_bug.cgi?id=21257#c16 is a great idea and we should do that no matter what. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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
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 jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@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
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Sun, Jun 12, 2011 at 1:05 AM, Adam Barth w...@adambarth.com wrote: On Sat, Jun 11, 2011 at 7:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 10, 2011 at 5:13 PM, Cameron McCormack c...@mcc.id.au wrote: Mark Pilgrim: What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places. That’s the right behaviour. Huh?? At least in the Gecko DOM implementation we always throw an exception if too few parameters are defined. Only if parameters are explicitly marked as [optional] are you allowed to not include them. I was under the impression that this was the case in most DOM implementations, with notable exception of webkit. 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. :( This is why it surprises me of WebIDL specifies WebKit behavior as the compliant behavior as Cameron seems to indicate. / Jonas
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: That is highly unintuitive. What's the point of listing the argument as not optional if it is, in fact, completely optional? It’s not optional in that if there were another method of the same name which doesn’t have that argument, you can distinguish between the two calls. For example if you had: void f(); void f(in DOMString s); then in JS if you called obj.f() it would behave as described for the first method, and if you called obj.f(undefined) or obj.f(whatever) it would behave as described for the second method. If you had void f(in optional DOMString); then prose describing the behaviour of f could distinguish between obj.f() and obj.f(undefined). And if you had void f(); void f(in optional DOMString); then it’d be ambiguous which one you’re calling with obj.f(). It’s also not optional in language bindings where function calls and declarations are stricter than in JS. But you are right that it’s confusing if you just have a single method void f(in DOMString s); since clearly you can call obj.f() in JS and it won’t throw a TypeError. (For that matter, why list it as non-nullable if null is treated like the empty string and the empty string is an acceptable value?) The “non-nullableness” is really a property of the type, not the argument, and it means whether null is one of the valid values of the type or not. So at the IDL level, the value can’t be null. If in JS you pass in null, the default coercion behaviour is to turn that into . For arguments of type DOMString, you can pass in pretty much any kind of value in JS and it’ll get stringified in some way. Jonas Sicking: Huh?? At least in the Gecko DOM implementation we always throw an exception if too few parameters are defined. Only if parameters are explicitly marked as [optional] are you allowed to not include them. I was under the impression that this was the case in most DOM implementations, with notable exception of webkit. WebKit and Chrome, I think, which have independent JS binding code. 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. We saw that happen with addEventListener. Jonas Sicking: This is why it surprises me of WebIDL specifies WebKit behavior as the compliant behavior as Cameron seems to indicate. In the spec right now it’s listed as an open issue, and it was the WebKit behaviour that I was going to specify to resolve the issue this week. (So it’s not what the spec currently says.) This is what I mentioned in http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html although I didn’t get any pushback then. I am happy to keep discussing it but I would like to settle on a solution soon. So I guess you are arguing for “throw if too few arguments are passed, ignore any extra arguments”. When we have overloads like void f(in long x); void f(in long x, in long y, in long z); we’d need to decide whether f(1, 2) throws or is considered a call to the first f with an extra, ignored argument. The former seems more consistent to me. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Fri, Jun 10, 2011 at 5:13 PM, Cameron McCormack c...@mcc.id.au wrote: Mark Pilgrim: What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places. That’s the right behaviour. Huh?? At least in the Gecko DOM implementation we always throw an exception if too few parameters are defined. Only if parameters are explicitly marked as [optional] are you allowed to not include them. I was under the impression that this was the case in most DOM implementations, with notable exception of webkit. / Jonas
RE: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Jun 10, 2011 6:56 PM, Eliot Graff eliot.gr...@microsoft.com wrote: ... 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 I removed [TreatNullAs=EmptyString] from IDBDatabase.setVersion() and IDBDatabaseSync.setVersion. Wait, does this mean that setVersion(null) is the same as setVersion(null)?
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: Wait, does this mean that setVersion(null) is the same as setVersion(null)? It means it’s the same as setVersion(), per the recent changes to Web IDL which make that the default stringification of null. (To get the opposite behaviour, you now need to specify [TreatNullAs=String].) -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Fri, Jun 10, 2011 at 7:43 PM, Cameron McCormack c...@mcc.id.au wrote: Mark Pilgrim: Wait, does this mean that setVersion(null) is the same as setVersion(null)? It means it’s the same as setVersion(), per the recent changes to Web IDL which make that the default stringification of null. What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places.
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places. That’s the right behaviour. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Jun 10, 2011 8:13 PM, Cameron McCormack c...@mcc.id.au wrote: Mark Pilgrim: What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places. That’s the right behaviour. That is highly unintuitive. What's the point of listing the argument as not optional if it is, in fact, completely optional? (For that matter, why list it as non-nullable if null is treated like the empty string and the empty string is an acceptable value?)
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
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 isra...@microsoft.comwrote: 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
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
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 jor...@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 isra...@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
RE: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
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 jor...@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 isra...@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? Israel
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Israel Hilerio: Are we saying that we should remove the TreatNullAs=EmptyString and keep the parameter restriction that version cannot be nullable? The [TreatNullAs=EmptyString] behaviour is now the default, so you definitely want to remove it. When you say “keep the parameter restriction that version cannot be nullable” do you mean keep the type as “DOMString”? If so, then that seems like the right thing to do. Only make it “DOMString?” if you want to distinguish between null being passed and being passed. -- Cameron McCormack ≝ http://mcc.id.au/
RE: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Tuesday, June 07, 2011 2:44 PM, Cameron McCormack wrote: Israel Hilerio: Are we saying that we should remove the TreatNullAs=EmptyString and keep the parameter restriction that version cannot be nullable? The [TreatNullAs=EmptyString] behaviour is now the default, so you definitely want to remove it. When you say “keep the parameter restriction that version cannot be nullable” do you mean keep the type as “DOMString”? If so, then that seems like the right thing to do. Only make it “DOMString?” if you want to distinguish between null being passed and being passed. -- Cameron McCormack ≝ http://mcc.id.au/ What I meant was that on the method description of IDBDatabase.setVersion, there is a table that has a nullable column. In it the version parameter there is an x in the Nullable column, which implies that the version parameter cannot be nullable. I'm guessing we want to keep this setting and that the only thing we want to remove is the [TreatNullAs=EmptyString] from the WebIDL definition (as you described above) of the setVersion. I don't see any reason for changing the type of the parameter from DOMString. Israel
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Israel Hilerio: What I meant was that on the method description of IDBDatabase.setVersion, there is a table that has a nullable column. In it the version parameter there is an x in the Nullable column, which implies that the version parameter cannot be nullable. I'm guessing we want to keep this setting and that the only thing we want to remove is the [TreatNullAs=EmptyString] from the WebIDL definition (as you described above) of the setVersion. I think the Nullable column is really just a reflection of whether the type is nullable, i.e. if the type has a “?” at the end of it. Having the type be “DOMString” yet having a tick in the Nullable column doesn’t make sense. I don't see any reason for changing the type of the parameter from DOMString. Right, unless you wanted to allow null to be passed as the argument and you wanted to distinguish that from . In that case, you would change the type to “DOMString?”, which would mean there’d be a tick in the Nullable column. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Tue, Jun 7, 2011 at 11:30 AM, Israel Hilerio isra...@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 jor...@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 isra...@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
