Re: [XHR] referencing HTML5
Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 16 May 2008, Julian Reschke wrote: If yes, then XHR can't be published earlier. If no, let's rephrase stuff so that HTML5 isn't required. No, this isn't accurate. We can publish XHR whenever we like. The only thing that would stop us is blind obediance to process. Conversely, completely ignoring the process is not an option either. I don't think that's what you're suggesting, though. In practice [having XHR depend on HTML5] is unlikely to be an issue since the goal is to get interoperable implementations, not a slavish drive to REC, and thus waiting for years at CR stage is not a problem. I agree with that. CSS2.1 has been at CR stage, gone back to WD for a few years, and back to CR again. I suspect that it will be a very long time before HTML5 is complete. -- Stewart Brodie Software Engineer ANT Software Limited
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Julian Reschke [EMAIL PROTECTED] wrote: Jonas Sicking wrote: ... If */* is semantically the same as not sending the header at all, and the former works with more servers, I would prefer that we use the former. ... I would prefer not to silently change what the client requested. It's semantically equivalent - it does not change the request, in the same way that adding the Connection header does not change the request. It's not like we're requiring that the UA add something that changes the meaning (even though that's what some of the desktop browser vendors seem to be doing anyway!) If a server can't cope with it (evidence, please!), fix it. Some older versions of Microsoft IIS are the servers that I've come across that fail to cope with it. It is unrealistic to expect these to be undeployed any time soon. The comment in my code does not specify version numbers - it simply indicates that a lack of an Accept header causes some versions of IIS to return a None Match error. On that basis, and because sending Accept: */* fixes the problem, I am assuming that the fault lies in the content negotation code. -- Stewart Brodie Software Engineer ANT Software Limited
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Julian Reschke [EMAIL PROTECTED] wrote: Stewart Brodie wrote: If a server can't cope with it (evidence, please!), fix it. Some older versions of Microsoft IIS are the servers that I've come across that fail to cope with it. It is unrealistic to expect these to be undeployed any time soon. The comment in my code does not specify version numbers - it simply indicates that a lack of an Accept header causes some versions of IIS to return a None Match error. On that basis, and because sending Accept: */* fixes the problem, I am assuming that the fault lies in the content negotation code. Well, the client alway can set Accept to */* if it needs to communicate with that server. That was my original point: the XHR LC explicitly prohibited the UA from adding an Accept header. That's why I requested that it be changed from a MUST NOT requirement. As far as I'm concerned, the UA has to be free to implement such workarounds, especially any that are semantically transparent. Please do not burden the spec with workarounds when it is clearly *not* required. I don't think it is being specified. My original suggestion was to add something saying that if the client chose to add the header then it SHOULD use */* as the value. Anne already rejected this on the grounds that existing desktop browsers send arbitrary values for the header. I don't like that situation (I think those browsers are simply broken), but given that the desktop browsers aren't going to change to comply, accepted that it could be left unspecified. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] LC-20080415 comment
Anne van Kesteren [EMAIL PROTECTED] wrote: On Wed, 16 Apr 2008 13:08:37 +0200, Stewart Brodie [EMAIL PROTECTED] wrote: In the last paragraph on send(data) (i.e. just above the start of the bit about the abort() method), there is a statement (which is missing the word header at the end, but that's not the point I wish to raise) : it MUST NOT automatically set the Accept. I think that this is a bad idea, because some servers fail to deliver resources in the absence of the Accept header where the resource has multiple variants available. Some older versions of IIS are known to fail in this manner. There may be others that I'm not aware of too, obviously. I see. What you're stating seems also in line with browser behavior so I have changed this to make Accept handling identical to that of Accept-Language. Unless it is specified through setRequestHeader() the user agent should provide it. http://dev.w3.org/2006/webapi/XMLHttpRequest/ Thanks. I have not followed your request of requiring a particular value as that does not seem in line with implementations and seems needlessly restrictive. I hope that's ok. I'm guessing that you mean that they add their own default Accept header? If so, then I think those implementations are buggy. However, given that implementations vary in this respect already, then it'll have to be OK. The only reason I suggested forcing implementations to use */* as the value for an automatically added header is that it preserves the semantics of the request, since this is the default to be assumed by HTTP servers in the absence of the header (RFC2396, section 14.1). Should clients be warned that failing to set an Accept header explicitly will lead to inconsistent behaviour between different UAs? By using values other than */*, the UA is overriding the script's type preference, as it restricts the types that the server may return - behaviour which I would class as a bug. The UA isn't going to be processing the returned entity body - the script is. I realise that the whole problem is caused by the new SHOULD requirement in the first place, but, unfortunately, it is needed for web compatibility. -- Stewart Brodie Software Engineer ANT Software Limited
Re: ISSUE-123: Should DOM Level 3 Events support namespaced events?
Web APIs Issue Tracker [EMAIL PROTECTED] wrote: ISSUE-123: Should DOM Level 3 Events support namespaced events? http://www.w3.org/2005/06/tracker/webapi/issues/123 Raised by: Anne van Kesteren On product: DOM 3 Events There are several reasons for dropping namespaced events as we discussed during today's telcon: * Browser vendors have not implemented them Large desktop browser vendors have not implemented them. I implemented them in our browser - it was a trivial job. * There has been very little to no demand from Web developers for these features. Out of interest, how has demand, or lack of it, been established? Is it from postings to this mailing list or via some other mechanism? * Implementing this feature increases QA cost That is true for any change, whether it be a feature or bug fix, though. * Implementing this feature increases the complexity of the Web platform In other standards, the need to namespace has been ignored initially and had to be hacked on later. XML has done it like this, CSS has done it like this (well, it is trying to, but it is struggling to maintain backward-compatible semantics). I do not believe that namespaced events introduce much complexity to the web platform at all, provided that they are added now. It is vital that if the APIs under consideration for enumerating event listeners ever come to pass (and I think that's a bad idea for several reasons), that namespaces are put in Events first, because trying to retrofit namespaces after that will definitely add a great deal of complexity and QA cost. Introducing vast amounts of complexity has not stopped the development of other features (HTML5, for example), so given the minimal impact that this feature has, I don't see adding to the complexity of the web platform as an issue here. The main argument in favor seems to be libraries being able to distinguish event types from each other. Given that they currently use a simple string for this purpose (dojo.xxx, etc.) and that seems to work fine having namespaces does not seem necessary here. You probably ought to insist on a full domain name - in which case, you might as well use namespaces anyway, as that's what they're for. If you choose to drop this feature, then you must also add a statement to the effect that any new events that appear in W3C standards will have org.w3c. on the front of the name to avoid collisions with other content. There's also not infinite libraries and you won't use infinite libraries on a Web page so the advantage seems really slim. Infinite libraries is not the real issue. It's two libraries trying to use events with the same name collision that's the problem, especially when unknown third party content is injected into other content (e.g. advertising content is often under the control of a third party). It is not acceptable to then demand that one (or both) of the parties alter their content - they will say that it works for them and they don't want to incur a huge QA cost either. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] LC-20080415 comment
Subbu Allamaraju [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 4:08 AM, Stewart Brodie wrote: I think that this is a bad idea, because some servers fail to deliver resources in the absence of the Accept header where the resource has multiple variants available. Some older versions of IIS are known to fail in this manner. There may be others that I'm not aware of too, obviously. Since sending Accept is not a MUST in 2616, isn't this kind of software already broken? Absolutely. However, the reality of the situation is that browsers have to be able to access resources stored on these somewhat widely-deployed servers. I cannot ship a browser that cannot talk to IIS. The XHR spec prohibits me from adjusting the request such that it can. My suggested change is semantically transparent, as the server is supposed to assume Accept: */* in the absence of the header anyway. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [selectors-api] Handling :link and :visited Pseudo Classes
Lachlan Hunt [EMAIL PROTECTED] wrote: Hi, The current Selectors API draft states: ... user agents may treat all links as unvisited links, or implement other measures to preserve the user’s privacy. [snipped] I'm considering adjusting the spec to allow just two options, and making IE8's behaviour non-conforming. Either: 1. Match unvisited and visted links normally with :link and :visited, respecitively. 2. Match all links with :link, and no links with :visted (i.e. treat all links as unvisited) Feedback from implementers on this issue, particularly from Microsoft, would be appreciated. Option 2 is what I do - primarily because there is usually no global history available with which to evaluate the visitedness of links anyway (the history is a configurable option that I don't believe any of our users ever enable). Another option would be to effectively treat :link and :visited as synonymous and match all links with both, but I'm not so comfortable with that. I don't think that you can do that safely, as it changes the specification - specifically, it removes the guarantee that something can never match both the :visited and :link psuedos at the same, which could break existing content in subtle ways. -- Stewart Brodie Software Engineer ANT Software Limited
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
Sunava Dutta [EMAIL PROTECTED] wrote: IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. Whatever you decide to do, please could you choose a different acronym, as XDR is already used for encoding in RPC. -- Stewart Brodie Software Engineer ANT Software Limited
Re: Extra Connection Support Proposal
Kris Zyp [EMAIL PROTECTED] wrote: As with pipelining, I think this would be better handled at the HTTP level than the XHR API level. We could define response headers for a server to indicate that it allows more than two connections per client, or alternately that a specific connection should not count towards the limit. I don't have a big problem with this being defined by headers, that seems reasonable. It is worth noting that doesn't achieve quite the same effect as doing it in XHR since there is time elapsed between the time the request is made and the response headers are received. If two connections are currently servicing responses, and third connection wishes to declare itself as an extra connection, from the client side this could be delivered immediately, but with header based permission, it would have to wait it's turn. That being said, I don't think these are terrible issues, and a fixing it at the HTTP level is fine with me. Kris XHR is an application-level protocol. I am not in favour of permitting XHR clients control over connection-level properties. The HTTP code should be responsible for pipelining and connection management - it is absolutely no concern of the application layer how it achieves its objective, which is simply the transmission of an HTTP request message and reception of an HTTP response message. If the application layer wishes to provide hints that particular features should be avoided, then that would be fine - provided that the HTTP implementation is permitted to ignore the hint. The same goes for cacheing - it needs to be hints from the application, not control. My HTTP code contains adaptive behaviour to deliver the optimum results based on prior history with the servers and proxies with which it is communicating. I'm sure other HTTP clients do similar things. A major part of this is working around known bugs in servers (like the aforementioned failures to support pipelining correctly) and a much lesser part (because the capabilities of conditionally using features are built into HTTP already) taking advantage of features, where possible. My code will tend to assume the worst, until it gets evidence that a given feature works. I do not want to permit the application layer to override my decision not to use pipelining, persistent connections, HTTP/1.1 etc. and cause a breakage by doing so. IMHO, allowing application layers control over low-level communications leads to inoperability, surprising behavioural differences in different environments, and makes proper testing of the application as a whole pretty difficult. -- Stewart Brodie
Re: Minutes, DOM3 Events telcon for 6 Feb 2008
Doug Schepers [EMAIL PROTECTED] wrote: Hi, WebAPI fans- Here are the minutes for the DOM3 Events telcon for 6 Feb 2008. Sorry for the funky formatting. http://www.w3.org/2008/02/06-webapi-minutes.html [2:47pm] aemmons: CM: I could not find a DOM Level 2 events test suite [2:47pm] aemmons: DS: I do not think one exists [2:47pm] aemmons: CM: How wass this tested in the past? [2:47pm] aemmons: DS: Not sure [2:47pm] aemmons: CM: How did it become a Recommendation [2:48pm] aemmons: Av: The requirements were more loose at that time [2:48pm] aemmons: CM: Should we have tests for DOM Level 2 Events? [2:48pm] aemmons: DS: May be useful, where there is overlap There is an existing test suite for DOM Level 2 events and DOM Level 3 events. It's in the CVS server on dev.w3.org in the 2001/DOM-Test-Suite component. That's what I use to test our implementation. It doesn't test some of what I would consider the more obscure aspects of DOM Level 3 events - no doubt because none of the large desktop vendors support it yet. [2:53pm] aemmons: Av: The biggest problem is that it requires namespaces on events [2:53pm] aemmons: Av: I do not think people are implementing the namespacing [2:54pm] aemmons: DS: I understand that there are people who dislike namespaces, [2:55pm] aemmons: DS: I am not sure it is a blocker for the spec [2:55pm] aemmons: Av: It is the think we do not see people implementing [2:55pm] aemmons: Av: It does not make sense for us to ship it if others do not as well I have implemented everything in DOM Level 3 events except for event groups. Namespaces are incredibly simple to support. ** NOTE: I've taken this next quote out of context from the transcript: ** [2:54pm] aemmons: DS: I am sure Microsoft will be involved in this process I'd really like it if IE implemented DOM events (level 2, let alone level 3) None of the tests I've ever tried on it have done anything, leading me to believe it doesn't support DOM events at all. Does it? [2:56pm] aemmons: DS: Another thing is - do authors want this? [2:56pm] aemmons: Av: Poeple hardly use namespaced elements, which have been around a long time [2:57pm] aemmons: AE: We've found them useful for content that uses CustomEvent It is very useful when you are building content that is going to be a component of a larger framework and may need to interwork with other third party content. Our TV UI content can happily use whatever event names it likes, because it will have used a separate namespace to avoid any potential clashes with other systems. [2:58pm] aemmons: DS: We need to make sure the spec is consistent and in publishable form [2:58pm] aemmons: DS: Good test suite [2:58pm] aemmons: DS: And that Key Events are acceptable for all the vendors TBH, I think that the whole area of Key events is a total mess. I don't understand the reluctance to at least document the keypress event, which is what the vast majority of content on the web seems to rely on, rather than just keyup and keydown. None of the HTML authors I've spoken to have ever heard of textInput. [3:05pm] aemmons: DS: Because most people doing web content, our focus should be ECAMScript for testing The aforementioned test suites already run within the JSUnit framework, just like the Core and HTML tests. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XHR] send doesn’t explain what to do w hen method is GET
Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: 3) The spec as written doesn't state nothing, it appears to clearly require sending an entity body and does not allow ignoring the body or throwing an exception regardless of what is allowed per RFC. So some change is needed, one way or another. Ok. How about we add a step 5 of the send() algorithm that states that additional requirements in RFC 2616 are also to be taken into account. That should effectively defer the issue to RFC 2616. Does any currently released browse include the body when doing an XHR GET request? If a big majority of them currently drop the body, then it seems like it would help interoperability if the spec explicitly stated that the body should be dropped. IMHO this wouldn't be going against RFC 2616 as it's the application, not the network layer, that drops the body. Under no circumstances will my code permit an entity body to be sent as part of a request for an object that is going to be requested via GET or HEAD. It's just asking for trouble. It also will not permit related headers to be set (Content-Length, Transfer-Encoding et al will be dropped) I never understood what I should do when an XMLHttpRequest object is presented with data to send and the method was GET or HEAD. Currently, I convert the data to a UTF-8 string and store it as the query field of the URI, as that seemed the most useful thing to do (particularly the the data attribute was a string or something that was easily stringified). I did briefly also consider automatically converting the method to POST, but decided that that was simply dangerous. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XHR] i18n comment 8: content negotiation handling
Alexey Proskuryakov [EMAIL PROTECTED] wrote: on 29.11.2007 20:16, Anne van Kesteren at [EMAIL PROTECTED] wrote: I think it actually makes sense to require user agents to not set the Accept-Language as appropriate so that content authors can do that. The author does not have access to browser or OS defaults, so I think that the UA should set Accept-Language, but not override one specified by the author. I concur - it's not at all like Accept in this regard. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XHR] i18n comment 8: content negotiation handling
Anne van Kesteren [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007 18:47:02 +0100, Alexey Proskuryakov [EMAIL PROTECTED] wrote: on 29.11.2007 20:16, Anne van Kesteren at [EMAIL PROTECTED] wrote: I think it actually makes sense to require user agents to not set the Accept-Language as appropriate so that content authors can do that. The author does not have access to browser or OS defaults, so I think that the UA should set Accept-Language, but not override one specified by the author. Isn't that what navigator.language is for? Do you think that content authors are going to bother setting the Accept-Language request header on every XHR request that they make? No, they are going to assume that the browser sets it automatically I think it is a decent compromise to permit authors to set the header and have that suppress the user agent's own header. -- Stewart Brodie Software Engineer ANT Software Limited
Re: Window pointer
Anne van Kesteren [EMAIL PROTECTED] wrote: On Sat, 17 Nov 2007 00:31:24 +0100, Subbu Allamaraju [EMAIL PROTECTED] wrote: But this can be done without requiring that a persistent pointer to the associated Window object must be stored on the newly created object. An implementation can store whatever it needs to resolve the URI argument. Isn't the requirement on the resolution and not on storing the pointer? I'm not sure what you mean. The URI is resolved the moment open() is invoked. If between creating the XMLHttpRequest and invoking the open() object the base URI of the document of the Window you have a pointer towards changes that has to be taken into account. If that Window is removed from the document (by removing the iframe that contains it) you still need to have a pointer towards it to ensure that the URI is properly resolved. This is how Internet Explorer handles these cases based on these testcases: http://tc.labs.opera.com/apis/XMLHttpRequest/open/ In such a case of a window having been deleted, and consequently the document within that window, what is the base URI? Is it the base URI of the last document that inhabited the window? -- Stewart Brodie Software Engineer ANT Software Limited
Re: Window pointer
Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 19 Nov 2007 12:00:35 +0100, Stewart Brodie [EMAIL PROTECTED] wrote: http://tc.labs.opera.com/apis/XMLHttpRequest/open/ In such a case of a window having been deleted, and consequently the document within that window, what is the base URI? Is it the base URI of the last document that inhabited the window? The Window is not deleted. Does that go for the document too? Does this mean that any Window whose document uses XMLHttpRequest will continue to exist and consume resources until the entire browser process terminates? -- Stewart Brodie Software Engineer ANT Software Limited
Re: Implementing HTMLDocument on all Documents (detailed review of the DOM)
Simon Pieters [EMAIL PROTECTED] wrote: On Tue, 21 Aug 2007 17:23:47 +0200, João Eiras [EMAIL PROTECTED] wrote: Does this make sense on Element? I mean, the class attribute and it's semantics are HTML/XHTML specific. The same goes for innerHTML. I agree there could be a generic property to access the markup directly, but innerHTML's name is out of context. innerHTML is actually not specific to HTML, despite its unfortunate name. In an XML context, innerHTML, on getting, returns a serialized string of the node's children, in XML syntax. On setting it parses the assigned string as XML and replaces the node's children with the parsed XML. http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dynamic.html#innerhtml1 I assumed that what the document means is that if you have an XML document and you have elements that are in the HTML namespace in that document, then they should implement the HTMLElement interface, and thus have an innerHTML property? And nodes that are not in the HTML namespace do not have such a property? If the suggestion is really that XML documents with XML elements in them have an innerHTML properties on all the elements, then that's just awful abuse of the name. It'd be better to add an innerContent property to Element that does the right thing, before people start using it. I'd be in favour of moving most of those other properties from HTMLDocument to Document that were listed earlier in the thread, though - at least it would fix the rather anomalous 'domain' property (which ends up being read-only on HTMLDocument and write-only on Document - or was it vice versa? It's certainly confusing) -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XHR] can't get this.readyState to work
Boris Zbarsky [EMAIL PROTECTED] wrote: In Gecko 1.9 ['this'] will be bound to the XMLHttpRequest object. Similarly, event.target will be the XMLHttpRequest object in 1.9. Out of curiousity, why has event.target not always been the XMLHttpRequest object (in Gecko)? Was it simply an oversight? -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XHR2] letting authors handle more response codes
Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 06 Aug 2007 16:07:16 +0200, Stewart Brodie [EMAIL PROTECTED] wrote: I don't think that introducing a new event for each (currently known!) response code is a good idea. Use the readystatechange event instead. It's not about currently known. It's about response codes for which the XMLHttpRequest object has special behavior. That's a limited range of response codes (listed in my opening post). Are you seriously considering special casing each individual response code as and when a case is made for it being useful for the client? I think that to do that is just asking for ongoing trouble. Just make it generic: create a new event if you don't want to re-use the already overburdened, overloaded and Byzantine readystatechange event. It'll be easier to implement and forward compatible, so the problem'll be solved for all time. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] Change to SENT state
Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 25 Jun 2007 14:25:36 +0200, Stewart Brodie [EMAIL PROTECTED] wrote: So now you get *three* events dispatched immediately one after the other when doing a HEAD request. Still, since the spec is just documenting IE's behaviour, you don't have a choice, I suppose. With XMLHttpRequest 2 you can just listen to the load event. I agree that the situation with readystatechange is far from optimal. Are you going to change all the methods like getRequestHeader so that they are now valid in state HEADERS_RECEIVED - it would be just bizarre to issue an event saying that we've got the complete HTTP header and then prohibit the reading of the HTTP status and headers until the entity body has started arriving. All methods? I changed getResponseHeader and getAllResponseHeaders. The specification does not define getRequestHeader. I'm sorry - my brain wasn't in gear properly yesterday. I didn't mean getRequestHeader. I meant getResponseHeader(), getAllResponseHeaders(), status and statusText. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] Change to SENT state
Anne van Kesteren [EMAIL PROTECTED] wrote: Feedback from Microsoft pointed out that the SENT state is in fact the state that indicates that all HTTP headers have been received and that LOADING indicates that the first few bytes of the response entity body are in. As a result, I renamed SENT to HEADERS_RECEIVED in the editor's draft and slightly changed the send() algorithm: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8 http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest/Overview.html.diff?r1=1.123r2=1.124f=h Kind regards, So now you get *three* events dispatched immediately one after the other when doing a HEAD request. Still, since the spec is just documenting IE's behaviour, you don't have a choice, I suppose. Are you going to change all the methods like getRequestHeader so that they are now valid in state HEADERS_RECEIVED - it would be just bizarre to issue an event saying that we've got the complete HTTP header and then prohibit the reading of the HTTP status and headers until the entity body has started arriving. -- Stewart Brodie Software Engineer ANT Software Limited
Re: Recent spec change to XMLHttpRequest default Content-Type
Carsten Orthbandt [EMAIL PROTECTED] wrote: It's obviously no big deal to re-add [Content-Type headers]. The point is that all available material said that stripping Content-Type would be fine and in fact it was. Now it's not and I suspect that we are not the only ones to get bitten by it. A webapp that spews hundreds of red errors in Firefox is simply not an option. My company's firewall blocks all incoming HTTP responses that do not contain a valid Content-Type. I suspect that we are not alone in doing this. If you are selling such an application, would your customers find it acceptable that people couldn't access it? -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] SENT state (readState = 2)
Anne van Kesteren [EMAIL PROTECTED] wrote: Hi, I made http://tc.labs.opera.com/apis/XMLHttpRequest/send/010.htm which shows that Opera switches to readyState = 2 when transmitting something large over the wire where Internet Explorer and Firefox (haven't tested Safari) stay in readyState = 1 until the whole transaction is over. This seems to indicate that readyState = 2 is pretty much useless and just becomes a required state to visit before going to state 3. I will update the specification soonish to reflect this unless implementors (or someone who can convince implementors) want to do it differently. What happens if you write a CGI script at the server that deliberately waits a bit between receiving the request and sending the response? Do IE FF switch to state 2 at *that* point? (i.e. indicating that it's finished sending the request but it hasn't received the response headers back yet) I prefer Opera's behaviour, FWIW. I don't like the idea that if you have scripting that is checking up on the state of the XHR object, then it will find that the readyState is still OPEN when actually you've already invoked the send() method. The problem is that an additional state is probably needed (SENDING) that covers the period of time during which the client is transmitting the request between OPEN and SENT. You already know that I strongly disagree with the spurious readystatechange events when the ready state hasn't changed. I wonder if this is what those spurious events are actually for - to cover up the lack of a separate state between OPEN and SENT? -- Stewart Brodie Software Engineer ANT Software Limited
Re: Method overloading in IDL
Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 21 May 2007 03:33:39 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: Implementors that use the IDL to generate code for the implementations: which would you prefer? Do implementors use the IDL directly or do they modify it before using it? In the latter case making the specification easier to write and read makes sense to me... Implementors that have ECMAScript support can also benefit as they can probably auto-generate more code if ECMAScript properties becomes part of the new IDL syntax. We don't auto-generate anything directly from the IDL, not least because of the sort of problems outlined earlier in this thread. Instead, we have our own internal XML format that serves the same purpose that we use to generate our DOM bindings headers, to drive automatic type coercions, and to build documentation of exactly which methods, constants, interfaces and properties are implemented. There is just too much DOM0 stuff that we need to support that isn't in the IDL in the later DOM specifications anyway. Trying to reverse engineer that into IDL format doesn't sound like a lot of fun. -- Stewart Brodie Software Engineer ANT Software Limited
Re: The XMLHttpRequest Object comments
Chris Lilley [EMAIL PROTECTED] wrote: On Tuesday, May 8, 2007, 12:11:38 AM, Innovimax wrote: IS I agree that it seems strange to have an XMLHttpRequest that IS does not support XML at all !! I agree that an XHR with no XML support does not make sense. Which means XML must be supported. On the other hand, that does not mean that XML is the only content that can be transported with it. I do not agree that it does not make sense - this is a generic mechanism for accessing URIs. Requiring simple textual data to be transmitted and received as XML would be a huge burden on embedded clients, for example. I don't see why HTTP is mandatory either, to be honest, although I accept that that's what most scripts will use it for. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] Request for Last Call 2
Re: the 8th May draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8 I like the reworking of the method descriptions to specify things algorithmically. However, I do not understand what is going on in the send() method. The send() event seems to have changed considerably since the previous drafts that I saw. I think that you need more explanation for the bizarre readystatechange event during step 5 of the send() algorithm since, as the note points out, the state hasn't changed. I do not understand why the transition to state SENT is so complex. In my current implementation, calling send() (in such a way that no errors occur) results in the state being set to SENT immediately and a single readystatechange event being raised. I think the above point may be answerable by providing a definition for has been successfully acknowledged in step 7. Is the purpose of the send() flag simply to cover the period of time between the invocation of the send() method and the transition to state SENT? Why is there a period of time during which this can occur? My implementation cannot work synchronously - and such operation is highly undesirable in embedded devices anyway. Currently, this is dealt with by raising NOT_SUPPORTED_ERR in the open() call when the async parameter is passed as false. I can see that the converse may be true for other agents. I think that implementations should be given this option. I don't think you can leave open()'s step 10 dangling without a definition of what the same-origin policy is, particularly since the document does now link with the Window object document via which the base URI will be obtained for the purposes of comparing the two URIs. This is likely to cause compatibility isues if different implementations use different rules. However, I'd also like a get-out that permits user agents to suspend the application of same-origin policy rules - or override the policy decision - in circumstances that the UA defines. I want the trusted content in my (closed) system to be able to access anything it likes. In the events section, what would it mean for an event on an XHR object to bubble anyway? Bubble to where? What about the Capture phase - what other objects will see the event? I suppose this is more of an issue for the DOM Events specification that here, though. Finally, there's a typo in step 8 (receieved) -- Stewart Brodie Software Engineer ANT Software Limited
Re: [XMLHttpRequest] Request for Last Call 2
Anne van Kesteren [EMAIL PROTECTED] wrote: On Tue, 08 May 2007 13:20:21 +0200, Stewart Brodie [EMAIL PROTECTED] wrote: The send() event seems to have changed considerably since the previous drafts that I saw. I think that you need more explanation for the bizarre readystatechange event during step 5 of the send() algorithm since, as the note points out, the state hasn't changed. This is matches what implementations do. Which implementations? It doesn't match what my implementation does. I do not understand why the transition to state SENT is so complex. In my current implementation, calling send() (in such a way that no errors occur) results in the state being set to SENT immediately and a single readystatechange event being raised. That would be in error. This is major change from the draft of February 27th which clearly stated that readystatechange events are ONLY raised when the readyState changes value. The new specification now prohibits the obvious behaviour. Plus, it is extremely inconvenient to have to issue multiple events in succession, as it introduces a whole raft of re-entrancy issues which weren't present before, since assuming I send this new extra readystatechange event in state OPEN, the event handler may well call abort(). Furthermore, the steps for send() permit that event handler to call send() again! This must be a bug in the algorithm, surely? I think you have to move the setting of the If async is true, the user agent MUST set the send() flag into a new step between steps 4 and 5, and update step 6 to If the send() flag is true or the state is not OPEN, return from the send() method call. Even that is probably insufficient, come to think of it. The event handler may do abort(), and then open() before returning, which would leave it in a valid state, but a completely different request. All these problems go away if you remove the spurious event (in the async case, at least) Alternatively, you could introduce a new flag that is set whilst that event is being dispatched, and then check that flag all over the place, and introduce another flag that is set to indicate that the send method should just silently stop executing when the event dispatch is completed. I think the above point may be answerable by providing a definition for has been successfully acknowledged in step 7. Is the purpose of the send() flag simply to cover the period of time between the invocation of the send() method and the transition to state SENT? Why is there a period of time during which this can occur? Because of current implementations, basically. (This hasn't changed much from last Last Call, fwiw.) I was referring to my printout of the draft of 27th February, which is marked as the latest revision of the document (on www.w3.org) However, it's not really clear what SENT exactly represents. It is not clear what has been successfully acknowledged means either. Does it mean that the URI accessing mechanism of the user agent has accepted the request for processing? Looking at it from a slightly different angle, what triggers the send() algorithm to continue executing after step 6 in the async==true case? Someone suggested renaming it to REQUESTING or something, but it seems some (maybe more than some?) implementations just make sure they don't skip the state and basically go straight from OPEN to LOADING making sure they do SENT just before LOADING... Yes, that's fine - I'm pleased that that is spelt out. The Microsoft documentation on MSDN seems to suggest that invoking send() does indeed set the state of the object to SENT (2), but I've pointed out to them that this is not what actually happens. They haven't informed me what does, though. Sounds to me like the person writing the documentation assumed the obvious behaviour, but the implementation team broke it, then? My implementation cannot work synchronously - and such operation is highly undesirable in embedded devices anyway. Currently, this is dealt with by raising NOT_SUPPORTED_ERR in the open() call when the async parameter is passed as false. I can see that the converse may be true for other agents. I think that implementations should be given this option. So you're proposing a Conforming non-synchronous user agent class or something that throws an exception on .open() when async is false? I rather not add such a thing. I don't see why you have to go that far. You already have several checks in the open() algorithm for badly-formed methods and URIs, methods the UA doesn't want to support etc. Having just checked, the default value for async has been flipped in this version of the specification too - it used to default to true, but this one now says false (step 11 of the open() algorithm). I don't think you can leave open()'s step 10 dangling without a definition of what the same-origin policy is, particularly since
Re: [XHR] send() stringification mechanisms of the host language
Maciej Stachowiak [EMAIL PROTECTED] wrote: On Mar 30, 2007, at 2:31 PM, Simon Pieters wrote: In the send(data) algorithm, step 3, says: data is not a DOMString or Document The stringification mechanisms of the host language must be used on data and the result must be treated as if data is a DOMString. I'm not sure what that means. For instance, if data is an Element, would it be serialized with .outerHTML or similar? Could it be clarified, or could an example be added, or, if the spec is fine and it's just me being slow, be explained to me? :-) JavaScript has a toString conversion operation defined on all types. For an HTML div element it would say [object HTMLDivElement] or something similar. OT: When it comes to Node and its subclasses, the resulting string depends on the browser/JS engine - you cannot rely on it taking any specific form. -- Stewart Brodie Software Engineer ANT Software Limited
[XHR] Typos and comments
These comments refer to the Feburary 27th Last Call version of the document. Section 1.2: typo: conforming script: A script MUST satisfy the **constrains** ... Section 2.1: typo: In addition, when the state is not uninitialized, all members of the object with the exception of **onreadystate** MUST be set to ... This should be onreadystatechange, presumably. Section 2.1 send(): typo: Note: This means that in case of a HEAD request the state is set to loaded immediately after having **being** set to receiving. Should be 'been', presumably missed after 'having' was added. Section 2.1 send(): same note on HEAD: clarification: I would like to see an additional sentence prepending that one in the note that rams home the point that you cannot skip states just because progress has been made quicker than expected. Something like: The object MUST pass through each of those states and not omit any states due to reaching the next state quickly. Then the sentence about HEAD that follows is an example. This clarification would be useful for non-HTTP transports where results are available instantly, for instance when file URIs are accessed. Section 2.1 right at the end: HTTP requests from multiple different XMLHttpRequest objects in succession SHOULD use a shared HTTP connection. I think this statement fits better in the description of send() - it seems rather lost in its current position, particularly since the main method that it affects is send(). I also think that it should be a non-normative note and SHOULD should be MAY, because this is a high-level specification that should not be interfering with the user agent's low-level transport. Section 2.1: the list of ignored headers: I really do not like the lack of Connection in this list at all. I don't see what value it affords the application that the user agent's HTTP engine cannot already derive. Section 2.1: the list of ignored headers: why is this not a MUST requirement? My HTTP implementation code will most certainly not permit some of those headers to be set, specifically Acknowledgements: typo: also to the WHATWG for **drafing** a first version An administrative section typo that I assume is irrelevant because those sections will change in the final document anyway: Status of this document: This is the 27 February 2007 Last Call Working Draft of The XMLHttpRequest Object **specifcation**. -- Stewart Brodie Software Engineer ANT Software Limited
