On Wed, 11 Apr 2012 12:57:23 +0200, Jonas Sicking jo...@sicking.cc wrote:
Apologies if this has been discussed before and I missed it, or have
forgotten about it.
It has been discussed before. I think last time this came up I was
wondering why we needed these various options for what to do
On Wed, 11 Apr 2012 18:43:20 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/11/12 12:26 PM, Boris Zbarsky wrote:
That's not correct. For nullable types, ES undefined is converted to IDL
null per step 3 of
http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type. There's some
extra complexity
On Thu, Apr 12, 2012 at 12:08 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 11 Apr 2012 12:57:23 +0200, Jonas Sicking jo...@sicking.cc wrote:
Apologies if this has been discussed before and I missed it, or have
forgotten about it.
It has been discussed before. I think last time this
Hi All,
Apologies if this has been discussed before and I missed it, or have
forgotten about it.
Currently the IDL for the .open function looks as follows:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if
On 4/11/12 6:57 AM, Jonas Sicking wrote:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if anything other than null is passed as value for the
user/password arguments, then the value should be stringified
On 4/11/12 12:26 PM, Boris Zbarsky wrote:
On 4/11/12 6:57 AM, Jonas Sicking wrote:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if anything other than null is passed as value for the
user/password
