Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
Jonas Sicking [EMAIL PROTECTED] In IE you can at least test for .status == 200 to test if things worked out ok. Even though the statuscode for various errors seem to be weird to say the least, at least they are different from the success codes. I actually think this is how we should do errorhandling for now since that should work with most existing content. I would be content with this, but no-one else appeared to be in Oslo. If we do go to state 4 then things will look almost exactly like a successful response. The only difference is that .responseXML will be null, but that is already the case for a lot of consumers that send non-xml data. I'd sort of disagree, the problem will manifest itself by the result not being parseable as expected, as you say a null XML document is a perfectly fine indicator of failure for XML expecting people - those sending json will get a script error, those getting some other structured format won't be able to parse it etc. The only situation will be if the responseText is trivially directed to the output, but as I say that's the reality anyway, this sort of error handling simply isn't used. Cheers, Jim.
Re: Further update to Window Object 1.0, I think it's ready for first Working Draft
On Mon, 27 Mar 2006, Maciej Stachowiak wrote: That's the purpose of the global scope object, which is an ECMAScript concept. As specced, the Window interface (it's not an object) is just something that the global scope object implements. Agreed, it shouldn't say the main purpose. I'll reword this to say that is one feature of the Window object (the spec will actually require that it be implemented by the ECMAScript global scope for in-page script execution such as script elements or event listener markup) and put it last, since that aspect is not language-independent. I'd also suggest changing namespace to scope or context, since that's what it is normally called. You inconsistently refer to the window object, Window object, Window interface, etc, in a way that is a bit subtle for me. In particular, speaking of the Window object in the singular and with that capitalisation seems a bit odd to me. (later note: It seems this may be because you define Window object after you first use it.) Should I move the definition to before the first use? The first use is the first sentence of the introduction paragraph. IMHO yes, you should define the term clearly before using it, but this will probably require a lot of rejigging. Any use of window object is a mistake. Well then you have a mistake in the second paragraph. :-) Window Object 1.0 is the title of the specification, I try to use it only with the version number. Ok. Window object is an object that implements the Window interface, so I don't have to keep writing the 7-word phrase. Window interface is the interface as defined. Fair enough, but in that case the intro is wrong. It says The Window Object 1.0 specification defines a subset of the features of the Window object, but by definition that can't be true (the spec can't define a subset of something defined by the spec itself). By the way I just noticed you have This section is not normative normative. (note the two normatives) in non-normative sections. | Need to define the term document? If you do, I'd define it as A document is an object that implements the Document interface or some such. Works for me. (Leaving this in my mail since it's not yet done.) A browsing context is a place where a user agent presents a document I don't think this is true. A browsing context isn't a place, it's a set of views. I suppose that depends on how much you reify the abstraction. I'm not sure it is good to define it as just the set of views, but maybe that works. Well, it's certainly not a place, by any definition. Only one document of this sequence is presented at a time. This is a statement of fact, and as such is incorrect. There is no technical reason why a UA couldn't show multiple documents from a browsing context at once; the WHATWG spec goes to some lengths to not preclude crazy UI innovations and I think the Window spec should likewise avoid limiting allowed UI unnecessarily. I need to think about this. I think removing this requirement would make some of the conformance criteria either inconsistent with this possibility or untestable. For instance I intend to require that the default view for all documents in the sequence must be the same object, since this behavior is interoperably implemented and depended on by some content. This would not be consistent with the same browsing context presenting multiple documents given the requirement that the document property of the Window object must be the document being presented. Huh. Interesting. I hadn't realised that the window objects were indeed the same. That does change things. Overall, would you consider using the WHATWG text instead of the current Window text? What is it about the WHATWG text that would need to change in order to make that possible? I would have to compare the latest WHATWG text to evaluate this possibility. Any luck with the evaluation? Section 3.3. The Location Interface duplicates the definitions in the WHATWG spec. Is there any way we can just use the text from the WHATWG spec here? The WHATWG spec is equally incomplete, but I'd like to not have to fork here. I didn't actually look at the WHATWG spec for this interface yet, the bits of it that I wrote were based on reading docs and/or implementation code for Safari, Firefox and IE. I will make sure to look at the WHATWG spec when fleshing out this section. Let me know when you do this. We should make sure we coordinate everything. When a document has no embedding element that points to it the document is a root document. Any chance we could use the WHATWG terminology here? (top-level browsing context document) It avoids the word root which I think is overloaded enough already. (You actually use the term top-level browsing context in the spec already, though without defining it.)
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
If we do go to state 4 then things will look almost exactly like a successful response. The only difference is that .responseXML will be null, but that is already the case for a lot of consumers that send non-xml data. I'd sort of disagree, the problem will manifest itself by the result not being parseable as expected, as you say a null XML document is a perfectly fine indicator of failure for XML expecting people - those sending json will get a script error, those getting some other structured format won't be able to parse it etc. The problem is that many formats can't detect that they have been cut off. Even for something as strict as XML you could be loosing comments and PIs at the end of the document if the transation is terminated. The reason responseXML would be null in mozilla is that we'd get an internal error-notification from our network layer and would know not to even attempt parsing. However that would not be possible for anyone using XMLHttpRequest since those notifications are never exposed. So my point is that for many (most?) data formats it is not always possible to detect that the transaction failed. The only situation will be if the responseText is trivially directed to the output, but as I say that's the reality anyway, this sort of error handling simply isn't used. I'm not sure I'm following you here... / Jonas
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
Jonas Sicking [EMAIL PROTECTED] The problem is that many formats can't detect that they have been cut off. Even for something as strict as XML you could be loosing comments and PIs at the end of the document if the transation is terminated. The reason responseXML would be null in mozilla is that we'd get an internal error-notification from our network layer and would know not to even attempt parsing. Ah, I see what you mean, if the failure was after partial content had arrived! Yes I agree this would be generally undetectable for a lot of formats. I don't think it's crucial to address this though, recovery from network failure errors are pretty rare things to deal EEK! there's been an error! is just about all you can do - even referencing an image or providing a link is basically unsafe from a user perspective. Cheers, Jim.
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
Jim Ley wrote: Jonas Sicking [EMAIL PROTECTED] In IE you can at least test for .status == 200 to test if things worked out ok. Even though the statuscode for various errors seem to be weird to say the least, at least they are different from the success codes. I actually think this is how we should do errorhandling for now since that should work with most existing content. I would be content with this, but no-one else appeared to be in Oslo. If we do go to state 4 then things will look almost exactly like a successful response. The only difference is that .responseXML will be null, but that is already the case for a lot of consumers that send non-xml data. I'd sort of disagree, the problem will manifest itself by the result not being parseable as expected, as you say a null XML document is a perfectly fine indicator of failure for XML expecting people - those sending json will get a script error, those getting some other structured format won't be able to parse it etc. Even though you can always imagine to find solution to workaround it. I think it is a bad idea to go to 4 without having a clear knowledge of what the status really is (successful or erroneous). Indeed bad or null XML can be due to a bug on the server, not necessarily a network error! -- Christophe
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
Christophe Jolif [EMAIL PROTECTED] Even though you can always imagine to find solution to workaround it. I think it is a bad idea to go to 4 without having a clear knowledge of what the status really is (successful or erroneous). Indeed bad or null XML can be due to a bug on the server, not necessarily a network error! Currently I don't think we can avoid it, there's a lot of content that assumes there will always be a 4, and use it to enable/disable controls whilst the request is being made. If we make 4 optional then this content will break. Cheers, Jim.
Re: ISSUE-76: Shoud window participate in event propagation
On Apr 13, 2006, at 01:29, Web APIs Issue Tracker wrote: Should we define if or how the Window objects participates in the event propagation? At least Firefox makes the Window object implement EventTarget and puts it above the Document node in the propagation chain. Yes, it should be defined (either way, I don't have a strong preference). Also, which spec should address this? The Window spec or DOM L3 Events? I think it's definitely something that would go in the Window spec. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-76: Shoud window participate in event propagation
On Apr 12, 2006, at 4:29 PM, Web APIs Issue Tracker wrote: ISSUE-76: Shoud window participate in event propagation http://www.w3.org/2005/06/tracker/webapi/issues/76 Raised by: Jonas Sicking On product: Window Should we define if or how the Window objects participates in the event propagation? At least Firefox makes the Window object implement EventTarget and puts it above the Document node in the propagation chain. Also, which spec should address this? The Window spec or DOM L3 Events? I think this is a duplicate of ISSUE-64: http://www.w3.org/2005/06/tracker/webapi/issues/64 I closed 76, please redirect further comments to the ISSUE-64 thread. Regards, Maciej
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
Jim Ley wrote: Christophe Jolif [EMAIL PROTECTED] Even though you can always imagine to find solution to workaround it. I think it is a bad idea to go to 4 without having a clear knowledge of what the status really is (successful or erroneous). Indeed bad or null XML can be due to a bug on the server, not necessarily a network error! Currently I don't think we can avoid it, there's a lot of content that assumes there will always be a 4, and use it to enable/disable controls whilst the request is being made. If we make 4 optional then this content will break. Yes, I'm unfortunately aware of that ;) That's why the only solution is to have an additional error handling stuff to detect erroneous cases... (maybe only in next version). -- Christophe
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
The problem is that many formats can't detect that they have been cut off. Even for something as strict as XML you could be loosing comments and PIs at the end of the document if the transation is terminated. The reason responseXML would be null in mozilla is that we'd get an internal error-notification from our network layer and would know not to even attempt parsing. Ah, I see what you mean, if the failure was after partial content had arrived! Yes I agree this would be generally undetectable for a lot of formats. I don't think it's crucial to address this though, recovery from network failure errors are pretty rare things to deal EEK! there's been an error! is just about all you can do - even referencing an image or providing a link is basically unsafe from a user perspective. Doing EEK! is better than doing nothing though. One case where it could actually happen is if the user hits the stop-button during the transfer (IIRC in mozilla we start the throbber and enable the stop button during the XHR request). I'll raise an issue on this stuff. / Jonas
[comment] Window Object 1.0 - HTML User Agent
Hi, This is a QA Review comment for Window Object 1.0 http://www.w3.org/TR/2006/WD-Window-20060407/ Fri, 07 Apr 2006 17:19:28 GMT First WD [[[ The Window object is a long-standing de facto standard for HTML user agents. ]]] and [[[ The Window Object 1.0 specification defines a subset of the features of the Window object, a widely implemented part of HTML User Agents, with parts also found in non-HTML UAs that offer scripting and DOM access. ]]] -- Window Object 1.0 http://www.w3.org/TR/2006/WD-Window-20060407/ Fri, 07 Apr 2006 17:19:28 GMT * What is an HTML user agent? * What is a non-HTML UA? I can imagine a straight answer which would say desktop browsers. Then we start to think about search engine bots (with or without scripting engine), HTML Scrapers, XSLT, etc. And what about SVG, MathML or XHTML? What about a vocal browser? etc. etc. - See Define unfamiliar terms in-line and consolidate the definitions in a glossary section. http://www.w3.org/TR/qaframe-spec/#define-terms-inline-gp - See Use terms already defined without changing their definition. http://www.w3.org/TR/qaframe-spec/#reuse-terms-gp - See W3C Glossary for user agent http://www.w3.org/2003/glossary/keyword/All/?keywords=user+agent PS: ACTION-130: Need to add definition of document Maybe this will help http://www.w3.org/2003/glossary/keyword/All/?keywords=document -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
