Re: [XHR] Error flag
On Thu, 11 Dec 2008 04:05:36 +0100, Kartikaya Gupta [EMAIL PROTECTED] wrote: I see the change in the XHR2 draft, but not the XHR draft. Forgot to commit, should be fixed now. I was not planning on doing this. It makes the IDL unreadable in my opinion and I believe it is not required in Web IDL (and if it is we should change that :-)). It does hamper readability somewhat, but it also increases usefulness. I guess the question is whether the IDL is informative or normative. If it's normative, then I think the exceptions should be added for correctness. It is normative, as in combination with Web IDL it defines how languages bindings are supposed to work. The [Null] and [Undefined] extended attributes are much worse for readability, IMO. True, but they have a nice property (less prose needs to be written in the specification). And on the topic of IDL, I assume you're sticking with your plan of not specifying a module/namespace? It seems like clutter to me. Can't we have a default module all W3C specifications use unless otherwise specified? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR] Error flag
On Sun, 07 Dec 2008 23:14:34 +0100, Kartikaya Gupta [EMAIL PROTECTED] wrote: The editor's draft of the XHR spec doesn't say when to clear the error flag. Based on experimentation I'm guessing it's supposed to be cleared in step 21 of the open() algorithm. Is this correct? Yeah. Though it should probably also be cleared the moment you invoke send(). Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. I was not planning on doing this. It makes the IDL unreadable in my opinion and I believe it is not required in Web IDL (and if it is we should change that :-)). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR] Error flag
On Wed, 10 Dec 2008 16:04:08 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: On Sun, 07 Dec 2008 23:14:34 +0100, Kartikaya Gupta [EMAIL PROTECTED] wrote: The editor's draft of the XHR spec doesn't say when to clear the error flag. Based on experimentation I'm guessing it's supposed to be cleared in step 21 of the open() algorithm. Is this correct? Yeah. Though it should probably also be cleared the moment you invoke send(). Actually, clearing it when you invoke send() should be enough. Made that change to the editor drafts. (I saw you made this comment way earlier in May as well as a private comment, sorry for taking so long to get to it.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR] Error flag
On Wed, 10 Dec 2008 16:28:25 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Actually, clearing it when you invoke send() should be enough. Made that change to the editor drafts. I see the change in the XHR2 draft, but not the XHR draft. Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. I was not planning on doing this. It makes the IDL unreadable in my opinion and I believe it is not required in Web IDL (and if it is we should change that :-)). It does hamper readability somewhat, but it also increases usefulness. I guess the question is whether the IDL is informative or normative. If it's normative, then I think the exceptions should be added for correctness. The [Null] and [Undefined] extended attributes are much worse for readability, IMO. And on the topic of IDL, I assume you're sticking with your plan of not specifying a module/namespace? Cheers, kats
[XHR] Error flag
The editor's draft of the XHR spec doesn't say when to clear the error flag. Based on experimentation I'm guessing it's supposed to be cleared in step 21 of the open() algorithm. Is this correct? Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. Cheers, kats
