Re: ACTION-126: What is DOM3EV about...
On Tue, 04 Apr 2006 15:39:56 +0200, Jim Ley [EMAIL PROTECTED] wrote: Anne van Kesteren [EMAIL PROTECTED] What we should make sure of is that the conformance on specifications section clearly states what is allowed and what is not so that we don't end up with 'mousemove' being incompatible in two different languages. At the same time, we should ensure that specifications are not going for a slightly different name just because they don't like that the event doesn't bubble or whatever. So what do you propose specifications do if the DOM3 event event doesn't meet their needs? I think that's a separate issue. We need some guidelines for specifications on that. Personally I think everyone should be free to make up new events as long as they put them in a namespace, though they are encouraged to ask the Web APIs WG for review, and everyone who wants a new event to be in the null namespace must ask for permission. We just need some formal language to handle that. That language should deal with existing not in a namespace events as well probably. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: First Public WD of XMLHttpRequest released
On Wed, 05 Apr 2006 23:35:10 +0200, Robin Berjon [EMAIL PROTECTED] wrote: The responseXML MUST be null if the document is not WF cannot currently be relied on in implementations, do you want to highlight that fact? I think that we agreed that that behaviour was a bug and that we really should be encouraging null. I guess that flagging what implementations do might depend on how soon the bug is fixed. Authoring guidelines, I say. MUST for xmlEncoding seems unreasonably tight restriction, what's the motivation? Agreed. You want to allow implementations to do some random serialization? Immediately before processing the message body (if any), the readyState attribute MUST be set to to 3 (Receiving). Processing the message body is unclear - does that mean XML parsing it, or does that mean loading it or what? Actually, what we said at the f2f was immediately after having read the headers (i.e. hit the \n\n) which is simpler and also means that we have defined behaviour for HEAD and other disembodied, err, bodiless responses. How is that different from what the text currently says? Perhaps processing should be replaced with retrieving? HEAD requests seem to be covered by (if any) although HEAD requests need some explicit language somewhere. Mostly for saying readyState goes to 3 first and after that directly to 4. (Which should be clear more or less, but still.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object
On Wed, 05 Apr 2006 22:56:28 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: If that is indeed true we need to fix it I agree. Is there a sensible value we could set .status to for example? Lets keep .status an HTTP status code. What about dispatching an abort event on the object as I suggested? Not sure if that's appropriate for this version though... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest object suggestion
On Mon, 17 Apr 2006 19:48:08 +0200, Mark Kawakami [EMAIL PROTECTED] wrote: As I'm sure you're well aware, one of the challenges facing developers of websites that utilize the XMLHttpRequest object (or the current IE equivalent) is the bookmark/back button issue. In short, because the state of the page changes independent of the URI, bookmarking and using the back button can potentially have unexpected or undesirable results. There was a long thread on this back in November (2005): http://lists.w3.org/Archives/Public/public-webapi/2005Nov/thread.html#3 I think that if something could be done through scripting it would be solved using an extension on the History object, not the XMLHttpRequest object as the problem is more general than that. However, there are all kinds of security implications which make it a bit of a rat hole... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: References in XHR spec
On Wed, 12 Apr 2006 15:16:49 +0200, Marc Hadley [EMAIL PROTECTED] wrote: Dare Obasanjo wonders why there's no reference to the XHR spec from MS. http://www.25hoursaday.com/weblog/PermaLink.aspx? guid=b6a6febf-51ba-4263-84a0-360e67d98391 That was a mistake on my part. The plan was to add it before publishing, but I never actually made the change... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Small typo
On Tue, 11 Apr 2006 20:08:22 +0200, Douglas Livingstone [EMAIL PROTECTED] wrote: With reference to: http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ Section 3, Methods, abort, the following: this method MUST cancels any network activity should be: this method MUST cancel any network activity Thanks, this has been fixed on the dev.w3.org version... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-75: Is method case-sensitive?
On Thu, 20 Apr 2006 22:09:32 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: One argument is that it's simply impossible to work around an XHR implementation that changes the casing in a way that the server doesn't expect. For example if the server wants a 'doit' method and the XHR implementation case folds to uppercase, the script author will simply not be able to use that method. So in this case I think both mozilla and opera does the wrong thing. And IE7 does the wrong thing too in having 'head' mean 'head', 'HEAD' '', 'get' - 'GET', 'post' 'POST', 'put' error, 'foo' error... As in, it doesn't support arbitrary method names anymore and does do some uppercasing for the methods everyone is using, mostly. (And not for 'put' apparently.) See http://svg.jibbering.com/webapi/2006-04-20.html#T13-55-43 for all the funny conversations surrounding the above. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-75: Is method case-sensitive?
On Thu, 20 Apr 2006 23:38:56 +0200, Julian Reschke [EMAIL PROTECTED] wrote: In the end, we want to have these clients/libraries fixed, right? I guess that's the question. Is it sensible to implement it as case-sensitive knowing that you probably break content? (Such as the examples in the specification...) Should we specify that methods MUST be treated as case-sensitive knowing that we will than never exit CR state given the way it has been implemented and will stay implemented because of the content that's out there? Those type of questions... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-75: Is method case-sensitive?
On Thu, 20 Apr 2006 23:42:39 +0200, Mark Baker [EMAIL PROTECTED] wrote: I'm not aware of any HTTP extension methods which use a lower case character, so why not make method case-insensitive, but prescribe that it be converted to upper case in the HTTP message? I guess that might actually work, although we'd effectively rewrite HTTP for a bit. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-75: Is method case-sensitive?
On Fri, 21 Apr 2006 06:46:51 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Apr 21, 2006, at 00:18, Mark Nottingham wrote: Make it a SHOULD and twiddle your CR exit criteria to take it into account; in the long term, implementations will sort themselves out. My thoughts exactly. A specification that doesn't accurately represent what implementations do is useless. Make it implementable, take into account feedback from implementers who are telling you the constraints, and don't write a spec that you know will not represent reality. My thoughts exactly... Twiddling with the exit criteria doesn't solve any of the problems. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest Object feedback
leads developers to believe that they always have to set these headers; that's not the case. Why? It specifically mentions UAs... set should probably be use, and Content-Length should be in there too. In fact, I'd require UAs to set Content-Length; while theoretically you can chunk a request body, there are some practical interop problems with doing so. Could you elaborate on that? The Referer header MUST be set, and MUST NOT be overridable; once cross-site XHR is available, sites will want to use it for security, logging, etc. Lets defer this to the separate thread on that, ok? What about automatically setting headers to do with delta encoding (RFC3229)? TE (for transfer encoding negotiation)? Content-MD5 (for request body integrity)? Meter (HTTP hit metering from caches)? The UA-* request headers? MUST NOT is too strong a prohibition for automatically-set headers; I'd suggest SHOULD NOT. (The response shown in the Manipulating response headers example is actually impossible for conforming implementations to see; you need to send TE to get a Transfer-Encoding back). Would it work if I removed Transfer-Encoding: chunked from the example? And what are your suggestions for those other headers? * In open(), send() and setRequestHeader(), it says that the userinfo MUST be used. This is too simplistic; a naive implementation will send them optimistically as HTTP Basic authentication, which is the wrong thing to do from a security perspective. If they're supplied, the UA needs to wait for a 401 Unauthenticated response, so it can learn that a) credentials are required and b) what scheme (and details thereof) to use. So request to uri using method method, authenticating using user and password as appropriate is sent should have some addition? Otherwise, the readyState attribute MUST be set to 2 (Sent) and a request to uri using method method, authenticating using user and password as appropriate is sent. UAs MUST NOT use HTTP Basic authentication when doing so, instead they MUST wait for a 401 Unauthenticated response and use its details to perform the request. Something like the above? Also, if the browser is already sending credentials for a particular protection space (to use RFC2617 terminology), XHR SHOULD send them when accessing resources in the same space. It'll need to define precedence between these and those explicitly used in a call (which would override, I presume). Please raise a separate issue on this. Your comments are much appreciated. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-75: Is method case-sensitive?
On Fri, 21 Apr 2006 18:33:57 +0200, Mark Nottingham [EMAIL PROTECTED] wrote: The specs last a *lot* longer than the current versions of Mozilla, Safari and IE. Sure, so does content. There's a place for making sure you have a path from the current implementations to the new standard, but this isn't it. Specifying this behaviour well isn't going to cost anything; some implementations won't be conformant for a little while, but fixing them won't break any existing applications. Actually, that's not true. prototype.js for example does it wrong and so do several other libraries http://annevankesteren.nl/2006/04/http-method#comment-5263 apparently. Besides which, each of those implementations does a different thing; how do you accurately represent that? All implementations do it for GET and POST consistent at least (and probably all other implemented methods). And that's what most content is using... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - Abstract section
On Wed, 12 Apr 2006 08:45:46 +0200, Karl Dubost [EMAIL PROTECTED] wrote: The abstract section is a bit vague, out of the document context. Maybe because of the some. Yeah, I agree. What about? This specification defines the XMLHttpRequest object, an API that provides additional HTTP client functionality for transferring data between a client and a server. Used that text. Added some abbr too... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - history in Introduction section
On Wed, 12 Apr 2006 08:45:54 +0200, Karl Dubost [EMAIL PROTECTED] wrote: This information is very contextual to the history of XMLHttpRequest Object *now*. Would it make sense in a few years from now on. I would suggest - to remove it - and/or to create an Appendix about the history, - or move it to the status section So you're suggesting to have the make the Introduction section an actual introduction? Might make sense... A subsection on history might be an idea, if people are interested in it. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - Address Extensibility
On Wed, 12 Apr 2006 08:44:48 +0200, Karl Dubost [EMAIL PROTECTED] wrote: Please, Address extensibility. The new extensibility section currently contains the following text: pExtensions to the codeXMLHttpRequest/code interface are reserved for future work by the Web APIs WG. WGs besides the Web APIs WG may extend the interface, but MUST coordinate that with the Web APIs WG. UAs MAY extend the interface, but MUST prefix the new members using a string specific to the vendor following the varVendor/varvarMember/var scheme. (Normally members follow the varmember/var scheme.) Company Foo could introduce a codeFooFollowRedirect(varboolean/var)/code method for example./p pAuthors MAY use extension mechanisms specific to the host language, like code.prototype/code in ECMAScript./p -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: No arguments to XMLHttpRequest.send (ACTION-58)
On Fri, 03 Mar 2006 20:41:38 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: I think there is need for some perspective here. Mozilla isn't broken in that .send doesn't work at all or that we in some cases have very broken behaviour. We simply follow DOM convention and have all the parameters to the function required even if they in some cases are not needed. I agree with Karl, Mark, others and myself that the specification should be relevant in the future as well. It's now stated that implementations MUST support send() to be invoked without arguments. Specifically, the new text is: pInvoking codesend()/code without the vardata/var argument MUST give the same result as if it was invoked with codenull/code as argument./p Even if I fix this today, there will be around 6 months before a release with the fix is out, and another 6 months to a year before everyone has upgraded. So authors will have to provide an argument for a significant time if they want to work in the major browsers. I don't think the specification will have reached Recommendation status by that time though, given the many differences between implementations that have to be fixed first during the CR phase... So I don't see that as a show-stopper. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - Address Extensibility
On Fri, 21 Apr 2006 22:38:05 +0200, Jim Ley [EMAIL PROTECTED] wrote: This is very silly, the VendorMember scheme is entirely stupid, it's completely useless for authors, we can't do anything with it, and is much worse than simple invented terms that eventually get standardised. I didn't really like it either, I was hoping for comments :-) It seems extensibility in the DOM in general is a bit unaddressed. [...] Extension requirements similar to ECMAScript would be a much more logical approach. Pointer? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - clarity of language
On Wed, 12 Apr 2006 08:44:53 +0200, Karl Dubost [EMAIL PROTECTED] wrote: [...] What is IDL? say it. Interface Definition Language I replaced `IDL` with `abbr title=Interface Definition LanguageIDL/abbr` in the source code. DOM 3 Core, that you reference, is using OMG IDL. Maybe that would be a good choice considering you are referring to Dom Core as well. Please see http://www.w3.org/2006/webapi/track/issues/44 for a discussion on that. You're welcome to contribute. I think we currently thought of the following solutions: (1) Use OMG IDL and modify the draft for a bit. (This might be not possible, forgot the details.) (2) Write up our own ODL specification and publish it as a note. (3) Assume people will understand it and put all the useful stuff in the language bindings. [...] There are also a few typos in the document. I'd love to fix them, pointers? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - DOM 3 Load and Save
On Wed, 12 Apr 2006 08:45:36 +0200, Karl Dubost [EMAIL PROTECTED] wrote: One of the common mistake, we can read online about XMLHttpRequest is that Dom 3 Load And Save is the *same* thing but was not implemented. Opera implemented it, sort of... [...] I'm not asking the WebAPI WG to chase all these mistakes available everywhere, but the specification (Appendix) or a primer could be a good opportunity to fix that. The working group decided not to mention DOM Level 3 Load and Save and all during our first F2F. Do you want us to revisit that? On a related note, did you coordinate with the DOM WG where a project to add a method to DOM 3 for XMLHttpRequest functionnality has been proposed in the past by Philippe Le Hégaret? I was not aware (and have heard nothing about it in the Web APIs WG meetings) of such functionality. Do you perhaps have a pointer? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - no interoperable implementations
On Wed, 12 Apr 2006 08:45:39 +0200, Karl Dubost [EMAIL PROTECTED] wrote: [...] The specification is here to set what is the correct behavior for the technology. Certainly there will be problems of interoperability, because of the history of the development. But I believe that a complete Test Suite should help to solve these issues by showing, don't tell what is the correct behavior. I would suggest to suppress most in the sentence and believe. The sentence contains also a prose which might be obsolete after a few years as it is only valid now. Perhaps we should move this to the history section, if we really need one (see other reply)? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR] What mime types should trigger XML parsing?
On Sun, 23 Apr 2006 02:34:08 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: Otherwise, if the Content-Type header contains a media type (ignoring any parameters) that is either text/xml, application/xml, or ends in +xml, it must be an object that implements the Document interface representing the parsed document. If the document was not an XML document, or if the document could not be parsed (due to an XML well-formedness error or unsupported character encoding, for instance), it must be null. Should this be taken to mean that for any other Content-Type, implementations MUST NOT attempt to parse as XML? If so, please say that. Optionally allowing XML parsing for types not specifically mentioned would be bad for interoperability. So instead of If the document was not an XML document having If Content-Type did not contain such a media type? Also, consider the following media types that represent XML data of some form, but are not text/xml, application/xml, or a type that ends in +xml. Some of these are unofficial or obsolete: text/xsl 364,000: http://www.google.com/search?q=text%2Fxsl application/xslt+xml 9,270: http://www.google.com/search?q=application%2Fxslt%2Bxml application/xsl-xml (note the dash...) 137: http://www.google.com/search?q=application%2Fxsl-xml text/mathml 569: http://www.google.com/search?q=text%2Fmathml application/mathml+xml 815: http://www.google.com/search?q=application%2Fmathml%2Bxml text/xml-external-parsed-entity application/xml-external-parsed-entity Are these supported? application/smil That one is obsoleted by application/smil+xml... But yeah... Of these, I only know for sure that text/xsl is in common use for sending XML content, even though it is unofficial and technically illegal. Any proposals? Personally I don't really care about any of them... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-75: Is method case-sensitive?
On Sun, 23 Apr 2006 05:18:24 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: That being said, whether all methods are uppercased or only the methods that get significant use, is not really a major issue. But let's not just casually increase spec complexity without doing our due diligence. We also haven't decided yet, ISSUE-74, whether or not to allow arbitrary method names. Internet Explorer 7, for one, doesn't support it as has been pointed out earlier. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - Address Extensibility
On Mon, 24 Apr 2006 07:58:34 +0200, Brad Fults [EMAIL PROTECTED] wrote: That's an unfortunate ripple in that case. Most of what I said assumed that one vendor implemented a feature in a certain way and the rest implemented it in the same way (save for IE). That almost never happens, if ever. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest readystatechange events
On Sun, 23 Apr 2006 23:08:53 +0200, Robin Berjon [EMAIL PROTECTED] wrote: At the moment, Gecko allows adding a single onreadystatechange listener that's notified of changes in readyState. We would like to add the ability to add such listeners via addEventListener; the event name would be readystatechange. So basically this would amount to supporting EventTarget on XHR, right? This has been discussed several times by the WG, and while we like the idea it's pretty much a v2 thing. So why is that? It's not like we can move the current specification that fast to W3C Recommendation. It's also that if we don't do it now v2 isn't so much about cleaning up anymore... rather more reverse engineering. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest progress events
On Mon, 24 Apr 2006 18:35:01 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: I would wait until all vendors get a chance to review a proposal in public. The people that need this behaviour are capable of implementing it today using server side scripting. Actually, we have consumers that need this behavior that cannot implement it via server-side scripting (e.g. the browser UI and various extensions). I've put this on hold for now while we're discussing it, but we do need to do something along these lines in the next few months at most. Given that, unlike load, error etc., these are new events it would be useful if you stated what type of interface they would implement, what .bubbles and .cancelable are for the event. So far the only things that are clear from your proposal are .type and .namespaceURI... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: handling of POST in XMLHTTPRequest.
On Wed, 03 May 2006 14:46:19 -0700, [EMAIL PROTECTED] wrote: The MIME type of the stream should be specified by setting the Content- Type header via the setRequestHeader method before calling send. [...] That sounds like good advice to me. Any objections? Used: Authors SHOULD specify the codeContent-Type/code header via codesetRequestHeader/code before invoking codesend/code with an argument. (Reference to setRequestHeader is included as well.) It seems implementations should not set a Content-Type header if the author didn't specify one for non-Documents, and for Documents it should be the type of the Document, and if that type is not known, and the Document supports the XML feature, an XML media type. Does that make sense to you? How do you determine the type of the Document? You mean HTMLDocument results in application/xhtml+xml or text/html? It makes sense for at least XML documents given your test results. Can you still overwrite it though? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest Object feedback
On Mon, 01 May 2006 19:17:27 +0200, Mark Nottingham [EMAIL PROTECTED] wrote: [...] Well, another way to set these headers is letting the author do it. So I can see why there's a requirement on UAs here from that perspective... I was thinking of something like UAs must not allow the Content-Length, Connection or Keep-Alive headers to be overridden. instead of UAs must set the Connection and Keep-Alive headers as described by the HTTP specification, and must not allow those headers to be overridden. because HTTP already tells UAs how to deal with these headers, and they don't always have to set them. Same sort of text for the Host header. Given that we now have a separate thread on headers and everything else in this list of comments has been addressed I consider this thread as closed. Thanks for your comments! Also, add TE to the list of headers that UAs MAY add. It MUST NOT be overriden? Yes. That's been done. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-87: Selectors API
On Sat, 13 May 2006 05:49:45 +0200, liorean [EMAIL PROTECTED] wrote: I've written some commentary on the Selectors API draft on WebGraphics. uri:http://web-graphics.com/2006/05/12/javascript-and-selectors/ 1. I'm aware how selectors work in browsers and that that's different from how they'd work here, but there was no pushback from implementors given that this is something authors want to use. Note also that you don't get live collections. 2. I'm not convinced it should be a native data type in ECMAScript. It operates on the DOM which is not native to ECMAScript either. Having an object which implements some selector interface on which you can perform node tests seems like an interesting idea, but is currently outside the scope of this specification. If there is enough interest though it seems certainly we should look into. 3. Letting StaticNodeList inherit from Array and NodeList not is not an option. They have to be identical. Hopefully DOM Level 3 Core gets errata to say that only some object implementing the NodeList interface is live and not all objects implementing NodeList (well, it currently says something even vaguer if I remember correctly) so we can drop StaticNodeList and just define that the object is static. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-87: Selectors API
On Sat, 13 May 2006 21:08:26 +0200, liorean [EMAIL PROTECTED] wrote: I do think you're unnecessarily limiting the use of the Selectors API in the current draft by only allowing selector matching on the subtree of the document node though. The same way you might want to use getElementsByTagName not on the document node but on some deeper element node, you might want to do selectors matching on the subtree of a deeper element node instead of on the entire tree. The Selectors specification doesn't define scoped selectors as noted in Outstanding Issues. Not sure if this specification should define that for them. This has been noted though. I'm not really decided about the more general issue: A group of selectors becoming some kind of object instead of a string. I can see it would have some advantages for the simple use cases this draft was written for it's not really needed. 3. Letting StaticNodeList inherit from Array and NodeList not is not an option. They have to be identical. Hopefully DOM Level 3 Core gets errata to say that only some object implementing the NodeList interface is live and not all objects implementing NodeList (well, it currently says something even vaguer if I remember correctly) so we can drop StaticNodeList and just define that the object is static. Well, does it matter if StaticNodeList in the ECMAScript bindings is defined to have the Array.prototype as it's prototype object instead of the Object.prototype? That doesn't change the interface itself, it's just a question of ECMAScript bindings. The reason one would want this is of course that one might want to use array methods such as Array.prototype.sort, Array.prototype.map or Array.prototype.filter on the returns from the selector match without having to jump through hoops to do so. At least the ECMAScript defined Array.prototype methods are written to be generic and work on any array-like object, I hope the Mozilla JavaScript 1.6 Array extras are written that way too. And StaticNodeList looks to me to be pretty array-like. Well, if StaticNodeList looks that way NodeList would look that way too and I'd therefore suggest raising that on [EMAIL PROTECTED] instead. Note that I don't really want to be defining StaticNodeList in the first place. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest security section draft
On Mon, 20 Mar 2006 20:00:19 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: Here's a draft for a security section of the XHR spec. It's probably in desperate need of editing from someone with more spec writing experience then me, but it's a start. That start has now been integrated http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html?content-type=text/html;%20charset=utf-8#security into the editor's version. It probably needs a lot of work... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: First Public WD of XMLHttpRequest released
On Thu, 06 Apr 2006 11:51:17 +0200, Jim Ley [EMAIL PROTECTED] wrote: I don't see why responseText MUST be null other than in readyState 3 or 4, why not undefined (e.g. if the firing of the 2 is delayed for some reason then data could be available) Equally MUST on 3 is incompatible with existing implementations. It's never null. If the firing of the 2 is delayed, isn't that just a bug? No, we're not mandating that events fire in realtime - we can't as ES is single threaded etc. Another way of saying is that until you fire the event the attribute MUST be the empty string... The MUST on 3 is incompatible with existing implementations in what way? MS's XHR implementation throws an error on 3. I'm in favor of leaving the specification as is and considering what IE does at the moment as a bug. alert( ) isn't defined anywhere, traditionally print has been used as a dummy function in ES code. Any pointers of its use? The ES spec, just changing alert to print... Used a print() function instead. by data.xmlEncoding, if specified and supported, or UTF-8 otherwise Makes some sense to me... I still don't see the point of the restriction at all, and inputEncoding would be a better option than xmlEncoding - if we're assuming the server knows the best format for a document serialisation, but I don't see the point of requiring such behaviour. See ISSUE-83. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-29: how is uri parameter of the open() method resolved
On Tue, 28 Feb 2006 02:38:50 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: What we do is that we use window.document.baseURI, most likely for IE compat wrt interaction with base. It is worse if multiple documents are calling each other and there are XMLHttpRequest objects involved. Then it is more or less unpredictable in mozilla. During the F2F we resolved to go with what IE does now which is more predictable. I drafted something http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html?content-type=text/html;%20charset=utf-8#definitions but it should probably get some additional references and a bit more clarification. Suggestions are welcome. What we resolved for ISSUE-29 is that the XHR object has an intrinsic property holding Window.document.baseURI from the Window it was created in. That intrinsic property never changes, etc. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest Object feedback
On Fri, 21 Apr 2006 15:58:27 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: example) would contain a user name and password. I *assume* you're referring to the userinfo production in RFC3986; e.g., http://user:[EMAIL PROTECTED]/path/?query It may be better to use this terminology (userinfo) explicitly, along with an appropriate reference. Also, AIUI, the security gods have determined that userinfo is a no- no in URLs, and IE (for example) doesn't support it (at least in the browser, ... Internet Explorer removed support for illegal HTTP URLs such as the one you've provided above because it has been abused too much in phishing mails. For other schemes where this is perfectly valid, like ftp, it works just fine in Internet Explorer. What does IE does in such cases and do we want the draft to reflect that? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - no interoperable implementations
On Wed, 26 Apr 2006 07:10:51 +0200, Karl Dubost [EMAIL PROTECTED] wrote: The specification is here to set what is the correct behavior for the technology. Certainly there will be problems of interoperability, because of the history of the development. But I believe that a complete Test Suite should help to solve these issues by showing, don't tell what is the correct behavior. I would suggest to suppress most in the sentence and believe. The sentence contains also a prose which might be obsolete after a few years as it is only valid now. Perhaps we should move this to the history section, if we really need one (see other reply)? Yes it could be a solution And would satisfy your comment? We're planning on doing this for the next draft. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest.abort()
On Wed, 26 Apr 2006 16:22:49 +0200, Ian Hickson [EMAIL PROTECTED] wrote: This has been asked a couple of times before. At some point reset will be defined and it will say that all members of the object are set to their initial value (as if you create a new instance of the object yes, I suppose)... Hopefully it will also include a requirement that any active connections are dropped, and so forth? Do we really want to define in that level of detail? Currently it says: When invoked, this method MUST cancel any network activity for which the object is responsible and reset the object. ... but perhaps it should only say the object is resetted and no new data should be made available to the object or something along those lines. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
ACTION-148: responseText and encoding
reponseText now reads: If the codetermreadyState/term/code attribute has a value other than 3 (Receiving) or 4 (Loaded), it MUST be the empty string. Otherwise, it MUST be the fragment of the entity body received so far (when codereadyState/code is 3 (Receiving)) or the entity body when codereadyState/code is 4 (Loaded)), interpreted as a stream of characters. If the response includes a codeContent-Type/code understood by the UA, with the exception that the rule in the final paragraph of section 3.7.1 of [RFC2616], and the rules in section 4.1.2 of [RFC2046] MUST be treated as if they specified the default character encoding as being UTF-8. Invalid bytes MUST be converted to U+FFFD REPLACEMENT CHARACTER. If the UA can't derive a character stream in accord with the media type specification, codereponseText/code MUST be codenull/code. This seems a lot better than how http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#dfn-responsetext reads at the moment, but I've the feeling I should add some more references. Perhaps [RFC2616] after the first paragraph for entity body etc.? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Extension HTTP methods
On Sun, 14 May 2006 13:59:34 +0200, Jim Ley [EMAIL PROTECTED] wrote: There are currently some methods that can't be allowed for security reasons and because such method smay be introduced in the future as well allowing arbitrary method names does not seem like a good idea. I think you need to list these methods that cannot be used for security reasons, to explain more of the motivations for this decision. It also appears to be a direct reversal of the decision at the previous f2f (issue 74) It would be good to see what had changed in between to motivate the change, as there was no public discussion, other than more support for having any verb. I'm just stating the resolutions as they have been made here. Feedback from implementors suggested that TRACE and CONNECT have issues and that future HTTP methods might become problematic (new specification released, servers updated, UAs are not, hole). What was raised against that is that it hurts adoption of new HTTP methods. That's true for all other types of APIs as well though. Internet Explorer 7 as opposed to Internet Explorer 6 uses a whitelist and other browsers vendors are planning to do the same thing. The whitelist would contain all safe methods currently spreaded over various RFCs. Mark Nottingham would report back if the IETF was ok with this approach or not. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest.abort()
On Sun, 14 May 2006 14:00:08 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Currently it says: When invoked, this method MUST cancel any network activity for which the object is responsible and reset the object. That's fine. Ok! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-51: XMLHttpRequest and 403
On Mon, 20 Mar 2006 08:33:35 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: I tested what mozilla does when receiving a statuscode of 403. We basically do the same as for a 200, except that xhr.status returns 403. The onreadystatechange handler fires as normal and both xhr.responseXML and xhr.responseText is set as normal. A testcase can be found at http://people.mozilla.com/~sicking/testcases/xhr-header.html For XHR2 it would be interesting to know if you invoke .onload or .onerror and if you think that can be changed. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-148: responseText and encoding
On Sun, 14 May 2006 14:35:16 +0200, Jim Ley [EMAIL PROTECTED] wrote: That was your personal opinion, and not a decision by the group... currently I do not believe any of todays user agents could pass a test suite of the XHR object, if that's the case then I think it's difficult to claim that we're defining a common subset that authors can rely on. That may of course be fine, but if it is then we should stop pretending we're trying to define what people can rely on. My view is that like Moz's (null) bug, we should make it a SHOULD so authors know they cannot rely on the behaviour currently. During the F2F (again, minutes are not yet released) the group agreed upon not having this reliable baseline approach as it didn't work out. Therefore Moz's (null) bug is now a MUST and this is too. That's also the reason we made XMLHttpRequest an EventTarget and introduced the readystatechange event. There was an additional resolution on a feature freeze so no more features will be added, but all features that are added will be sufficiently defined to be interoperable implementable in browsers. I hope that clarifies things and I also hope you can attend next meeting :-) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR constructor example
On Sun, 14 May 2006 14:05:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: var request = new XMLHttpRequest(); Given that it doesn't have to be a request I think 'r' is saver or perhaps just 'x'... Please don't use single letter variable names for anything but loop index variables (in languages that require those), it's generally considerd quite bad practice. Sure, give a me a sensible suggestion and I'll take it. Given recent discussions (you can post as well as retrieve) I'm not sure the original suggestion `var request` makes sense. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
ACTION-139: the IDL is non-normative
Used text: A more complete description of what can be done with codeXMLHttpRequest/code can be found in the abbr title=Interface Definition LanguageIDL/abbr below and its associated details. The IDL is non-normative and does not intend to conform to [OMGIDL]. Only the language bindings are normative. Also removed http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#xmlhttprequest the second editorial note regarding drafting up a note and all that. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-87: Selectors API
On Wed, 22 Mar 2006 15:45:21 +0100, Jim Ley [EMAIL PROTECTED] wrote: Fair enough, here are the requirements for the name: * short * simple Why are these requirements for the name, no other DOM names are short and simple, they're clear and unambiguous, I'd say they were the requirements. If people want to use shorter names they understand in their closed world the $x() approach is perfectly simple for them (although discouraged by ECMA of course). This has been noted as an open issue. The reason is performance. Then one 1 method with an optional limit is ,uch better, it optimises for all situations when the author knows how many they're interested in, rather than 1 special case. I don't see why the 1 case is that much more special than the N case - as I say gEBI meets most of the 1 cases. The 1 case returns a Node as opposed to a StaticNodeList. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
XMLHttpRequest request bodies (was: Re: Issue: request bodies)
On Mon, 24 Apr 2006 21:15:36 +0200, Mark Baker [EMAIL PROTECTED] wrote: On 4/22/06, Maciej Stachowiak [EMAIL PROTECTED] wrote: Current implementations silently ignore the body in this case. FWIW, I decided to test this. As it turns out, IE and Firefox on WinXP pass bodies on all methods except GET (actually, I couldn't test GET on IE - it would only send POST!), and Opera passes them only with POST (and doesn't support PUT?!). That's all the browsers I have access to right now. http://www.markbaker.ca/2006/XHRTests/ So I have no strong opinions about this, but my suggestion would be to say that the data passed to send() is always used as the entity body, if present, unless the method argument is GET in which case it's dropped. Any objections? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-148: responseText and encoding
On Mon, 15 May 2006 01:54:02 +0200, Ian Hickson [EMAIL PROTECTED] wrote: If the codetermreadyState/term/code attribute has a value other than 3 (Receiving) or 4 (Loaded), it MUST be the empty string. it here refers to readyState, which is wrong. Fixed. Otherwise, it MUST be the fragment of the entity body received so far (when codereadyState/code is 3 (Receiving)) or the entity body when codereadyState/code is 4 (Loaded)), interpreted as a stream of characters. or the complete entity body, or or the entire body returned or some such would make more sense. Used complete. If the response includes a codeContent-Type/code understood by the UA, with the exception that the rule in the final paragraph of section 3.7.1 of [RFC2616], and the rules in section 4.1.2 of [RFC2046] MUST be treated as if they specified the default character encoding as being UTF-8. That makes no sense at all. There's a missing verb as far as I can tell. That part now reads: If the response includes a codeContent-Type/code understood by the UA the characters are encoded following the relevant media type specification, with the exception that the ... [...] Doesn't really matter, IMHO. References are important when the reader might not know what was being referenced, but for this kind of thing... Fine by me. Thanks for your comments. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-87: Selectors API
On Mon, 15 May 2006 01:22:21 +0200, liorean [EMAIL PROTECTED] wrote: I just have a look at the XPathNSResolver interface. In the Selectors spec, the selector elm is equivalent to *|elm in the case of a missing default namespace, but ns|elm where ns is the default namespace if a default namespace is declared. The XPathNSResolver interface specifically states that it must never be called with a null or empty argument. I imagine the Selectors API would want to be able to send a null argument as a way to ask for the default namespace, or be given some equivalent functionality. During our F2F I discussed this Jonas (he's the editor of DOM Level 3 XPath) and we're considering something like that, yes. Not sure yet if DOM Level 3 XPath will allow it and say that for XPath related methods UAs MUST do nothing or that Selectors API widens the scope of it. I hope the former, but we'll see that when we get there. Thanks for raising it on the list. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Issue: Authentication Credentials
On Fri, 21 Apr 2006 18:33:28 +0200, Mark Nottingham [EMAIL PROTECTED] wrote: If the browser is already sending credentials for a particular protection space (to use RFC2617 terminology), XHR SHOULD send them when accessing resources in the same space. It'll need to define precedence between these and those explicitly used in a call (which would override, I presume). In other words, if I'm already logged into a site, XHR should reuse my credentials, rather than ask me for them again. I assume this has been solved by your integrated rewrite of send()? It seems to mention this although a bit more abstract in the part about authentication. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-87: Selectors API
On Wed, 17 May 2006 06:29:54 +0200, liorean [EMAIL PROTECTED] wrote:
* Several people have raised issues with naming the methods match and
matchAll as those might suggest a boolean return value. Alternate
suggestions
have been select and selectAll.
For ECMAScript, I think match is a fine choice of verb and is
consistent. For the closest comparison, regex 'match' isn't boolean.
Sure, I like match() as well. Mostly because it's short and simple, but
there were some concerns raised.
I think there's some confusion here about what is requested and what
you think is requested. What I personally mean when I want to have a
way to ask for all nodes in a NodeList that matches a selector or all
nodes in an element's subtree that matches a selector doesn't effect
the scope of the selectors. For example:
doc
/.../
elm1
elm2 xml:id=bleh
elm3/
elm3/
elm2
/elm1
/.../
/doc
var
selectorMatches=document.getElementById('bleh').matchAll(':root
elm3',resolver);
This selectorMatches variable would be StaticNodeList of both nodes in
the subtree below #bleh that match the selector. It would not at all
affect the scoping of the selector (':root' still matches the 'doc'
element, for example). It would only affect a single thing: it would
ask for matches in a subtree of the document instead of all matches in
the entire document tree.
That would be a different request yes. This issue was not really coming
from you though... I guess I could add it, but it probably won't make the
first public Working Draft.
At least one issue more that I think should be added:
Currently you can ask gimme all matches in the document against this
selector but you can't ask I've got this element handle (from
event.target or whereever). Does this very element match this
selector?. Even if you did add 'match' and 'matchAll' on the Element
interface, those don't make it any easier to get an answer to that
question. So, some type of equivalent to regex.test(string) would be
immensely useful.
We already discussed that and imho it's out of scope for this version.
(It can also be noted that this is the only functionality really
needed. Traversal is already in the DOM1, so that is not the problem.
What is missing is the functionality of asking for if an element
matches a selector.)
Well yeah, and XPath is in DOM Level 3... This is more about providing a
simple way of selecting a bunch of modes based on a group of selectors.
This functionality is already provided in libraries and people would find
this really useful. (As would I!)
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: ACTION-87: Selectors API
On Wed, 17 May 2006 15:19:46 +0200, Lachlan Hunt
[EMAIL PROTECTED] wrote:
I like match() too because it's much shorter than
getElementsBySelector(),
Right... :-)
but I think the fact that it only returns a single node is confusing and
that, in most cases, authors would want the whole collection, not just
the first match. I think it would be better if the methods were:
[...]
In that case you have this issue:
* match(foo)[0] (when match() would return a list)
* matchOne(foo)
* matchFirst(foo)
The shortest name should represent the most efficient method imho.
What's wrong with using:
var selectorMatches = document.matchAll('#bleh elm3', resolver);
There may still be use cases for matching a sub tree, so it may be worth
extending the Element interface too, but all the ones I can think of can
be handled by simply writing a more specific selector.
Yeah, except when you get a random element back like event.target. And
even in that case you can probably give the event some random ID in most
cases but it's not really flexible.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: ACTION-87: Selectors API
On Wed, 17 May 2006 15:35:24 +0200, Jim Ley [EMAIL PROTECTED] wrote: The shortest name should represent the most efficient method imho. Crazy notion, names should be clear, not short for efficiency. The point was that if the more efficient one of the two actually had a longer name, people would probably use the shorter name and just take the first node using [0] or whatever can be used for that in their language binding. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHTTPRequest Issue on behaviour when method not supported
On Wed, 24 May 2006 16:41:53 +0200, Jim Ley [EMAIL PROTECTED] wrote: A valid HTTP method name. The GET, POST, PUT, DELETE and HEAD values MUST be supported Nowhere is the behaviour defined for what happens if the methods are not supported, the current behaviour in those user agents who only support a couple of methods - that of silently transformed into GET, is not much use, and I would say very wrong. Please change it to throw an exception on open if you use a method which is not defined, or alternatively provide a property which is the actual method going to be used, preferably the exception. I'd like to defer this until the whole method discussion has been sorted out. Consider it noted though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-87: Selectors API
On Wed, 31 May 2006 02:56:46 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: What we could maybe do though is to return a real ECMAScript array. I actually like this idea a lot since that'll integrate much better with scripts than a StaticNodeList would. That makes a lot of sense. I support this. Heck yeah. Jonas: I think that would constitute a very good thing to put in the Bindings 4 DOM document. Of course, it's mean of me to suggest this means you have a new action item, but you can only blame yourself for having good ideas. Yeah, that makes sense. I raised an action on me. I'm fine with DOMArray. Let me know when there's something in TR/ I can point to. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
regrets 20060607
Don't have a phone here that actually works. :-( -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [ANN] Selectors API
On Thu, 08 Jun 2006 01:12:40 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: ▪ (1) “This specification introduces two methods which take a selector (technically a group of selectors) as argument and return the matched elements as result.” Why not just call them a group of selectors from the get go, since that’s the correct term? Since it's the introduction. ▪ (1.1) The example ‘test’ function uses matchAll to select “:root”. This returns a StaticNodeList, but you compare it for strict equality with the document element. This is always going to be false. The node is not a copy, why would it be false? ▪ (1.2) Maybe a sentence just before the list of conformance classes such as “The following conformance classes are defined by this document:” should be present. Thanks, added. ▪ (1.3) Although it’s obviously a reasonably subjective issue, FWIW I say to use select and selectAll. I registered more votes for this and I personally would like to use them as well, but the main concern is that authors would confuse them with selectNode and selectSingleNode (used for XPath). What's your take on that? ▪ (1.3) Regarding extensibility being addressed by DOM 3 Core, what extensibility is being envisaged exactly? The extensibility section in 2.1.1 doesn’t give much. How vendor extensions to the interface are done when they are not part of a standard. If the semantics of the members of interface can change overtime (I guess) and all kind of related questions. 2.1.1 was just some tryout. ▪ (1.3) I was going to mention the default namespace. DOM 3 XPath says of the XPathNSResolver: “The XPath evaluator must never call this with a null or empty argument, because the result of doing this is undefined.” I don’t think this would be incompatible with Selectors API defining what happens with null is passed as the argument (i.e., to return the default namespace’s URI if one is desired) in the context of the DocumentSelect methods. Yeah, I'm coordinating this with Jonas when he edits the XPath document. ▪ (2.1) I think the term “document order” is sufficiently known that it’s unnecessary to say that it uses a “depth-first pre-order traversal”. I think being clear doesn't hurt here. ▪ (2.1) Having matchAll return null if no nodes matched, instead of an empty NodeList, is somewhat inconsistent with other DOM methods that return NodeLists, such as Document.getElementsByTagName. Let's resolve this once it's decided if we go with an Array or not (and we probably go with an Array; DOMArray). ▪ (2.1) Should mentioning that an ECMAScript Function can be passed as the namespace resolver be in a separate bindings section? Perhaps this can defer to Bindings For DOM if that is completed in time. Either way, the “MUST do this thing (or MAY do this other thing)” feels strange. Maybe omitting the MAY would help. Good call, dropped MAY there. ▪ (2.1.1) “Authors may use extension mechanisms specific to the host language, like .prototype in ECMAScript.” I don’t know what kind of extensibility this is meant to be referring to. Assigning to myNSResolver.prototype.lookupNamespaceURI for some reason? This is just some text to make people complain. I hope to be able to remove the section... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [ANN] Selectors API
Hi Cameron, your feedback is much appreciated! On Thu, 15 Jun 2006 13:59:21 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: Since it's the introduction. Ok, but with the current wording it sounds like you are contradicting yourself, equivalent to something like “the methods take a selector—no that’s not right, they really take a group of selectors”. Perhaps: This specification introduces two methods which take a group of selectors (often mistakenly just called “selectors”) as argument and return the matched elements as result. where “group of selectors” is a link to the definition in CSS 2.1 or CSS 3 Selectors. Or something. (Actually, checking CSS 3 Selectors, there isn’t a nice definition for a group of selectors in section 5 like there is for selector in section 4.) I didn't make it a link, but I did change the wording http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8 to something along the lines of what you suggested. ▪ (1.3) Although it’s obviously a reasonably subjective issue, FWIW I say to use select and selectAll. I registered more votes for this and I personally would like to use them as well, but the main concern is that authors would confuse them with selectNode and selectSingleNode (used for XPath). What's your take on that? For those authors not just copying and pasting code, I don’t think it will be much of a problem. If they do confuse them initially, it won’t take them long to work out they have typed the wrong one. If you find that it is important to take into account these IE XPath function names, perhaps you can align them more closely by using matchNodes and matchSingleNode. Yeah, I'll think about it. ▪ (2.1) I think the term “document order” is sufficiently known that it’s unnecessary to say that it uses a “depth-first pre-order traversal”. I think being clear doesn't hurt here. Ok. Maybe move the “document order” to the previous paragraph, since that’s where the “depth-first pre-order traversal” is first mentioned. Fair enough, done that. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR constructor example
On Mon, 22 May 2006 12:32:32 +0200, Mark Nottingham [EMAIL PROTECTED] wrote: client. (XHR is a HTTP client API specification). Taken. Thanks. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[DOM3EV] introduce Event.trusted? (ISSUE-10)
http://www.w3.org/TR/2006/WD-xbl-20060619/#eventxbl introduces EventXBL.trusted which basically has to be implemented by all objects implementing the Event object. Given that this information might also make sense outside of XBL perhaps we should lift the text and put it on Event directly? In http://lists.w3.org/Archives/Public/public-webapi/2006Mar/att-0092/23-webapi-minutes.html#item11 there was some WG discussion indicating that this wouldn't address all possible use cases though that isn't entirely clear to me anymore. In an action taken upon that discussion it was suggested to http://www.w3.org/mid/[EMAIL PROTECTED] defer this feature indefinitely. The WG hasn't discussed the outcome of this action. First raised on http://www.w3.org/mid/[EMAIL PROTECTED] public-appformats. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-195: mousewheel proposal
On Sat, 24 Jun 2006 11:17:08 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: Based on discussion by Maciej, Ian and Björn I propose the following for the two mousewheel events we want to introduce based on the discussion during the SF F2F. It probably needs some editorial work, but it should be mostly complete. Cool. Presumably the default action of the mousewheel event is to do the scrolling or whatever would normally happen. If the mousemultiwheel event is cancelled, does this stop the other axis scrolling that would occur? Perhaps this should have been more clear in the draft. The default action of the mousemultiwheel when wheelDeltaY is non-zero is to dispatch a mousewheel event. Besides it's normal default action to scroll, zoom, whatever you have configured it too. If mousemultiwheel is cancelled all default actions won't happen. The default action of the mousewheel event is to scroll, zoom, whatever in vertical direction. If mousewheel is cancelled it's default action won't happen. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Optional method arguments in the DOM
On Fri, 23 Jun 2006 16:50:52 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Now there are several obvious modifications to this system that could be made: [...] How about having specified in the IDL which parameters default to certain value when omitted? So both the parameter being omitted is specified and it's value to be assumed by the UA is. void() test(foo, [bar] null) Would be a way to do it I guess. (I don't really like the syntax though...) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Editorial
On Wed, 26 Jul 2006 03:30:04 -0400, [EMAIL PROTECTED] wrote: We encourage you to not use this specification to start sentences. Fixed, as suggested. * Introduction typo? It was actually intended because the reference name was the same as the name of the specification, but it might seem a bit weird so it's now Selectors [Selectors] as suggested. * Typo [[[ Using psuedo-elements … ]]] Could you please tell me what you mean here? (I haven't checked any of the fixes into CVS yet, will do that shortly.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] DOM Level 3 XPath
On Wed, 26 Jul 2006 03:30:12 -0400, [EMAIL PROTECTED] wrote: [[[ Make sure [DOM3XPath] actually defines this. Otherwise this draft will have to. (Which is needed anyway when this goes beyond Last Call and DOM Level 3 XPath does not.) ]]] Be sure to coordinate with the appropriate DOM IG. Did you send an email to [EMAIL PROTECTED] The plan is to push DOM Level 3 XPath to W3C Recommendation from within the Web APIs WG. I assume that satisfies your concern? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Future work on Extensibility
On Wed, 26 Jul 2006 03:30:13 -0400, [EMAIL PROTECTED] wrote: About http://www.w3.org/TR/2006/WD-selectors-api-20060525/#extensibility [[[ Extensions to the DocumentSelector interface are reserved for future work by the Web APIs WG. WGs besides the Web APIs WG may extend the interface, but must coordinate that with the Web APIs WG. ]]] How is it possible to achieve this once the WebAPI group is closed? This prose is in a normative part of the document. Yeah, the extensibility story needs work. I basically hope to be able to defer all that to DOM Level 3 Core at some point. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Security Considerations and stability
On Wed, 26 Jul 2006 03:30:15 -0400, [EMAIL PROTECTED] wrote: [[[ Another problem is hostile content. UAs should ensure they remain stable when facing a hostile XPathNSResolver object. Potential hostile things such an object could do include: ]]] What is hostile content? I agree with Ian that this term is sufficiently clear. How do you test the remain stable assertion? Ian has explained this to your satisfaction, right? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Editorial
On Fri, 04 Aug 2006 18:12:28 -0400, Sander [EMAIL PROTECTED] wrote: Could you please tell me what you mean here? Psuedo should be pseudo. ^^ ^^ Oops, fixed. Thanks! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Typo in XHR spec
On Mon, 19 Jun 2006 20:49:03 +0200, Alex Vincent [EMAIL PROTECTED] wrote: Under setRequestHeader(), there's a word spelled Destinaion. I believe you want Destination. Thanks, fixed (local copy). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest conformance comments
On Wed, 02 Aug 2006 19:18:16 +0200, Subbu Allamaraju [EMAIL PROTECTED] wrote: True. Since the XHR spec is not really concerned about if and how applications write/code to empty headers, it does not make sense to require that this method return empty string. I think the semantics of a single getResponseHeader() could include the cases of both non-existent headers as well as header with an empty value. But the current definition prevents this, prompting for methods isResponseHeaderPresent(), which IMO, would not be required if the semantics are changed to return null. They are changed. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XmlHttpRequest IDL non normative
On Wed, 26 Jul 2006 08:52:46 +0200, José Manuel Cantera Fonseca [EMAIL PROTECTED] wrote: It really sounds strange to me. To specify something in IDL that is not OMG-IDL-conformant but you are going to use the bindings of OMG-IDL. I'm not sure what you mean by us[ing] the bindings of OMG-IDL, but I don't think we are. The IDL in the draft is there because it's intuitive to people who are used to the DOM specifications and the such. We're not trying to conform to OMG IDL simply because it's not powerful enough to capture what we need to express. Bindings is the word that is used in the document :-) Actually. Language bindings is what's used in the document. I think that a document that tries to standardize something and itself doesn't conform or adhere other standards is simply nonsense. The IDL is simply non normative and illustrates the API. The actual language bindings (not yet included in the document) will define the exact mapping to ECMAScript and perhaps other languages. I don't see the problem. If you are not going to use the sintax and semantics of OMG-IDL it could be better not specifying the object in IDL. You could do it directly in EcmaScript. I'm not sure Ecmascript would be a good option here, but I don't have a strong opinion. The best option would be to document a Web API IDL but that's quite a lot of work. Why ECMAScript is not a good option? All the DOM developers and Web Developers know the language and in fact the APIs you are trying to standardize are yet defined in browsers and developers are used to use them from EcmaScript. As far as I know ECMAScript has no notion of IDLs... Anyway, I agree with Robin, we need a Web API IDL document. Unfortunately, I have no clue as how to write such a thing. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR editorial - UA
On Mon, 03 Jul 2006 21:17:39 +0200, Charles McCathieNevile [EMAIL PROTECTED] wrote: A comment that Denis raised after translating the XMLHttpRequest spec was that using UA rather than User Agent is not very clear. I agree (since to me it is so strongly the code for an airline that I find it jarring). Shouldn't it be user agent(s) or User agent(s) (at the start of sentence) in that case? Addressed in the local copy. The next public WD (and next revision of the Editor's copy) will have this fixed. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
XMLHttpRequest HTTP methods
I propose that for the open() method we throw a SYNTAX_ERR when the first argument does not match the token production of RFC 2616 and a (not yet defined) SECURITY_ERR when the method is not allowed for security reasons. Depending on whether we go for a blacklist or whitelist we can also have a NOT_SUPPORTED_ERR I suppose. For the user and password and perhaps the uri argument something similar has to be done I guess. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest HTTP methods
On Fri, 11 Aug 2006 14:15:23 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: I propose that for the open() method we throw a SYNTAX_ERR when the first argument does not match the token production of RFC 2616 and a (not yet defined) SECURITY_ERR when the method is not allowed for security reasons. Depending on whether we go for a blacklist or whitelist we can also have a NOT_SUPPORTED_ERR I suppose. For the user and password and perhaps the uri argument something similar has to be done I guess. This is related to ISSUE-74 fwiw. If you want your thoughts to be recorded please mention the literal string 'ISSUE-74' in any follow-up e-mails. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
ISSUE-39: XMLHttpRequest errors
Internet Explorer returns codes from http://support.microsoft.com/default.aspx?scid=193625 as status code when something goes wrong while still letting readyState go to 4. Other browsers let readyState go to four as well, but nothing really indicates the type of error. I'm open to suggestions as to how to resolve this issue. (Jim Ley basically brought this up during the first F2F meeting, but I haven't really gotten around to it so far. Sorry about that.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
ACTION-195: updated mousewheel/mousemultiwheel proposal
I basically reworded some things to make it more vague and leave it more
up to implementors. Hopefully at some point we can pinpoint more what it
should be.
This e-mail doesn't really help with the important use case from Ian,
but there is ISSUE-84 tracking that.
===
When mouse wheeling occurs, the implementation must dispatch a
codemousemultiwheel/code event implementing the following interface:
interface MouseMultiWheelEvent : MouseEvent {
readonly attribute longwheelDeltaX;
readonly attribute longwheelDeltaY;
readonly attribute longwheelDeltaZ;
void initMouseMultiWheelEventNS(in DOMString namespaceURI,
in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView
viewArg,
in long detailArg,
in long screenXArg,
in long screenYArg,
in long clientXArg,
in long clientYArg,
in unsigned short
buttonArg,
in EventTarget
relatedTargetArg,
in DOMString
modifiersList,
in long wheelDeltaX,
in long wheelDeltaY,
in long wheelDeltaZ);
};
wheelDeltaX is a number indicating the distance (positive means rotated to
the right, negative means rotated to the left).
wheelDeltaY is a number indicating the distance (positive means rotated
away from user or to the right, negative means rotated towards user or to
the left).
wheelDeltaZ is a number indicating the distance (...).
The default value of wheelDeltaX, wheelDeltaY and wheelDeltaZ is 0.
UIEvent.detail must always be 0.
XXX: wheelDeltaY - wheelDelta?
This event includes both scroll deltas. The default action of this event
is to dispatch a codemousewheel/code event if the y delta is non-zero.
Besides that, its default action is to do whatever platform conventions
suggest for the wheeling behavior.
The codemousewheel/code event implements the following interface:
interface MouseWheelEvent : MouseEvent {
readonly attribute longwheelDelta;
void initMouseWheelEventNS(in DOMString namespaceURI,
in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView viewArg,
in long detailArg,
in long screenXArg,
in long screenYArg,
in long clientXArg,
in long clientYArg,
in unsigned short buttonArg,
in EventTarget
relatedTargetArg,
in DOMString modifiersList,
in long wheelDelta);
};
If the codemousewheel/code event is cancelled, only the default action
for vertical wheeling is cancelled. The wheelDelta attribute is a number
indicating the distance (positive means rotated away from the user,
negative means rotated towards the user). The default value of the
wheelDelta attribute is 0.
XXX: What about UIEvent.detail?
For both codemousemultiwheel/code and codemousewheel/code
codeMouseEvent.relatedNode/code must point to the element being
wheel'd over or codenull/code if there is no such element. (For
example, when using some device without a pointer but with some way to
wheel you'd get that.)
===
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: XBL2 review
On Mon, 21 Aug 2006 23:06:10 +0200, Doug Schepers [EMAIL PROTECTED] wrote: Comments about XBL2 should be directed to public-appformats@w3.org, not [EMAIL PROTECTED] My mistake... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-195: updated mousewheel/mousemultiwheel proposal
On Mon, 21 Aug 2006 22:58:26 +0200, Doug Schepers [EMAIL PROTECTED] wrote: | When mouse wheeling occurs, the implementation must dispatch a | codemousemultiwheel/code event implementing the following | interface: I still prefer Bjoern's suggestion of mouseomniwheel since it indicates multiple directions, rather than multiple mice. I'm fine either way. | wheelDeltaX is a number indicating the distance (positive | means rotated to | the right, negative means rotated to the left). I would say indicating the horizontal distance. Sure, changed. | wheelDeltaY is a number indicating the distance (positive | means rotated | away from user or to the right, negative means rotated | towards user or to | the left). I would say indicating the vertical distance. Sure, changed. Should we consider yoking wheelDeltaZ to zooming? Perhaps, what do other people think? | The default value of wheelDeltaX, wheelDeltaY and wheelDeltaZ is 0. | UIEvent.detail must always be 0. | | XXX: wheelDeltaY - wheelDelta? I thought we agreed that this model is not backwards-compatible, and that we would provide a pass-through for mousewheel that would use wheelDelta. Backwards compatible or not, it might make sense for authors that the field has the same name. Granted, it makes a lot of sense to name it wheelDeltaY too... Removed the note. | For both codemousemultiwheel/code and codemousewheel/code | codeMouseEvent.relatedNode/code must point to the element being | wheel'd over or codenull/code if there is no such element. (For | example, when using some device without a pointer but with | some way to | wheel you'd get that.) | === I like this part. It will allow for context-specific wheel controls, like dials and custom scrolling list, or zooming in on a particular element. The wording could use some refining, but the intent suits me. What about something like, For both codemousemultiwheel/code and codemousewheel/code, codeMouseEvent.relatedNode/code must indicate the element over which the pointer is located, or if there is no such element (in the case where the device does not have a pointer, but does have a wheel) the current focused element, or codenull/code in the absence of an element. The currently focused element is always available through document.activeElement. I'm not sure it should be integrated here as well. What's the use case? The rest of the wording seems fine though. The proposal is now in CVS... http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/proposals/mousewheel.txt I should probably do something about the line wrapping but I don't really care at the moment. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Security Considerations and stability
On Sat, 05 Aug 2006 05:55:11 -, Ian Hickson [EMAIL PROTECTED] wrote: Given the sheer cost of getting security wrong, I'd rather that the security be right up there, and that the security-free implementations be non-conformant, than have the implementors not read the security section and therefore get it wrong. (Implementors read as little of the spec as they can get away with. In many cases, they read none of it and rely purely on the testcases. It sucks, but it's the way it is.) I tend to agree, but I don't think this is very relevant for the specification at hand. Selectors API is a very simple and small specification and the security issues being pointed out in the separate section are hopefully widely known already. And if they're not it's not just Selectors API that's affected. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest (re)synchronization
On Sat, 01 Jul 2006 22:32:54 -, Robin Pelgrim [EMAIL PROTECTED] wrote: Please watch closer to the functionality of XMLHttpRequest. Since it used mostly in a Javascript environment, where no threading functions are supported (at the moment) , ways for (re)synchronize asynchronous requests are insufficiant. Since there is no Thread.sleep functionality in Javascript there is no way wait for the request to be finished without leaving a function (without using setTimeout). This is unacceptable for application building. It's al so clumsy, primitive. I expect more from W3C and introduce good standards. Till there is no Threading functionality in JavaScript, the XMLHttpRequest object should be extended with a 'resync' function. With this function you (simply) can wait for a async request to finish. (Of coarse it would be better to impement Threading functionality in JS, but for the moment it just isn't there). it's far from complete by now, please try to improve the standards. I don't really get this comment. Why is it clumsy, insufficient and primitive? It's also unclear why you can't use a synchronize request which is functionality the API provides. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: cookies and XMLHttpRequest
On Mon, 15 May 2006 23:54:07 -, David Flanagan [EMAIL PROTECTED] wrote: Perhaps you did not see my response to Jonas' message: Yeah, sorry about that. [...] My original point was simply that there is a non-parallelism in the spec as it stands now. Outgoing cookies are explicitly addressed, but incoming cookies are not. If you make it clear that XMLHttpRequest uses the HTTP facilities of the UA, then that would satisfy me. The specification has the following regarding this: If the user agent supports HTTP State Mangement [RFC2109][RFC2965] it should persist, discard and send cookies (as received in the Set-Cookie and Set-Cookie2 response headers, and sent in the Cookie header) as applicable. ... and the specification has HTTP in its name. I think it's clear enough and the WG agrees, fwiw. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Introduction with more background
On Wed, 26 Jul 2006 07:30:05 -, [EMAIL PROTECTED] wrote: About http://www.w3.org/TR/2006/WD-selectors-api-20060525/#introduction [[[ It is often desirable to perform script and or DOM operations on a specific set of elements in a document. ]]] What are the benefits? Why is it important? How it makes the life of developers easier? It makes it easier to select a set of elements based on certain criteria (for example all div elements with a class of example) in a way that's consistent with how people are matching elements in CSS for instance. So instead of having to filter what getElementsByTagName returns you can directly filter it in the query. And given that implementations of Selectors are claimed to be pretty efficient it's expected this will be pretty efficient as well and most likely faster than a custom implementation of it. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: About XMLHttpRequest Draft
On Mon, 17 Jul 2006 17:14:40 -, Óscar Toledo G. [EMAIL PROTECTED] wrote: Also generating exceptions on reading status and statusText, is a little awkward, I think that zero and empty string are more sensible selections. There's some amount of legacy content and implementations we have to deal with... Other suggestions, the send method can include a second argument to indicate the desired timeout in milliseconds, to generate an event, would be better than setTimeout, as the event would not be generated if the answer comes first or the onerror handler exists and it is invoked first. Not for this version. We are considering something like that for XMLHttpRequest 2. The onerror event is necessary to detect a failed request (by example: server not responding HTTP connection), so is worth to have it into the draft, along with onload. Other alternative would be a special status 5 (Request error) for readyState. Error handling for XMLHttpRequest 1 comes down to going to readyState 4 and having fields set to their initial values which is what most UAs do today. XMLHttpRequest 2 will deal with this. In the responseXML description, the draft could say something like: An UA with a HTML implementation, may support additionally text/html, the Document node may have properties related to DOM HTML.. XMLHttpRequest 2. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
ACTION-209: dblclick
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/proposals/dblclick.txt has a new proposal for dblclick and as with the revised mousehweel proposal it's more vague and lets more up to platforms and such. The text is a mess though. It should really be revised, but at least it says not more than it should say. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest state after a send()
On Tue, 19 Sep 2006 14:01:41 -, Alexey Proskuryakov [EMAIL PROTECTED] wrote: I have tried searching the archives, but couldn't find this already discussed. The specification defines states 1 and 2 as: 1 Open. The open() method has been successfully called. 2 Sent. The UA successfully completed the request, but no data has yet been received. For async requests, send() MUST return immediately, i.e. even before resolving the hostname. However, it is also specified that the state MUST be set to Sent, which apparently violates its definition. In my tests, WinIE 6, Firefox 1.5 and Safari 2 all do not change readyState in an async send(). This effectively means that state Open is followed by an additional pseudo-state with the same numerical value (e.g., Safari currently ignores subsequent send() requests). So one way of doing it would be that after the request is completed you go to 2, then quickly to 3 and even quicker to 4 dispatching readystatechange in the process. Another way of doing it would be to go directly to 4 for async requests and dispatch readystatechange when going from 1 to 4. The people I talked to about this feel that doing the latter makes more sense and I tend to agree. It also means you can easily switch between async and sync requests. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-85: Where to define XPathNSResolver?
On Tue, 19 Sep 2006 12:59:30 -, Web APIs Issue Tracker [EMAIL PROTECTED] wrote: To make XPathNSResolver reusable in Selectors API it has to support a notion of a default namespace. Since DOM Level 3 XPath isn't really moving yet one idea would be to define it in Selectors API and have DOM Level 3 XPath refer to it or later copy it back. The idea (and a CVS copy of Selectors API is working towards that) is to specify NSResolver (not XPathNSResolver) in Selectors API and have XPath resolve that. If we really need the XPath prefix for XPath we'll do something like a typedef or an empty interface... Anyone with strong opinions on this? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest.setRequestHeader with non-ASCII strings
On Fri, 31 Mar 2006 08:57:48 -, Cameron McCormack [EMAIL PROTECTED] wrote: I asked on #webapi the other day what XHR should do if setRequestHeader is called with strings that contain non-ASCII characters, since that's not allowed by HTTP. Anne suggested I make a test, so here is one (temporarily, at least): Thanks for this. We decided that it would make the most sense to throw an exception (SYNTAX_ERR) if the header or value doesn't match the production given in HTTP. This is the same for getResponserHeader, obviously... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest test suite suggestion
On Fri, 21 Apr 2006 22:35:02 -, Boris Zbarsky [EMAIL PROTECTED] wrote: If I follow correctly, relative URIs passed to open() should be resolved relative to caller (whatever that means; more on that in a separate mail). That's not actually precisely what Gecko does right now; probably a bug in Gecko. I think you saw that we changed this to be more compatible with Internet Explorer. Basically, from the window you contruct the object in you take the window.document.baseURI property and somehow store that on the object to resolve URIs against. In particular, if you have documents A and B at two different URIs that can talk to each other: 1) Document A creates an XMLHttpRequest object 2) Document A sets an onreadystatechange listener on it. 3) Document B calls open() the base URI will be document A as far as I can tell from the code. Worth adding a test to the test suite for this and similar things where two different windows both work with the same XMLHttpRequest object. http://tc.labs.opera.com/apis/XMLHttpRequest/open/001.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/002.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/003.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/004.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/005.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/006.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/008.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/009.htm http://tc.labs.opera.com/apis/XMLHttpRequest/open/010.htm I welcome other variants to this story. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-86: Throw INVALID_STATE_ERR everywhere, don\'t or some mix?
On Wed, 20 Sep 2006 13:43:34 -, Web APIs Issue Tracker [EMAIL PROTECTED] wrote: My proposal is to throw an exception (INVALID_STATE_ERR) for every member where this is relevant (as has been suggested before on this list). I have implemented this proposal in the editor's draft based on group discussion. Pending feedback it will probably be in the next WD. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest test suite suggestion
On Fri, 22 Sep 2006 16:41:12 -, Boris Zbarsky [EMAIL PROTECTED] wrote: That doesn't answer my question above. It just shifts the burden onto defining what the window from which you use the constructor means. Can you point out the problem in that definition? Could we have a definition in terms of things defined in the ECMA specification or something? One that would be completely unambiguous? I'm getting pretty tired of definition-by-example, especially without an exhaustive example set. Well, I don't like definition-by-example at all and was trying to define something that wasn't. It's not really clear to me what the problem with the definition is. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Cross-site extensions for XMLHttpRequest (XXX...)
On Mon, 25 Sep 2006 03:56:28 +0200, Ian Hickson [EMAIL PROTECTED] wrote: I don't really have the bandwidth to do that in the coming weeks. If you want I can put it on my list of things to do and if I find the time I can do it. But no guarentees on timescale. That seems fine with me. If it some point people feel it takes too long I can try to find a gap. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest test suite suggestion
On Tue, 26 Sep 2006 16:37:12 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Again, my real issue is that the attempt at definition that currently exists in the XMLHttpRequest spec doesn't make it clear what the terms it's using mean. Do you have any suggestions to improve it? I don't really look forward to having to study ECMAScript. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Overriding userinfo in XHR.open()
On Tue, 26 Sep 2006 20:43:11 +0200, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
Is this a new feature that's not present in browsers yet? From my tests,
it looks like WinIE doesn't support userinfo at all, while Firefox takes
string values of whatever objects are passed as user/password, e.g.
req.open('GET', url, true, null, null) sets the credentials to
null/null, so the null clause doesn't apply.
Interesting. I suppose that could be a bug... Anyway, I suggest you use
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8
for reading as that's a more current version.
Second, should the password from userinfo be used if only the user
parameter is provided: req.open('GET', url, true, 'user')? Firefox
resets the password to an empty string in this situation.
I would say it shouldn't be provided in this case (same as null), but I
guess that needs more clarification.
Finally, I'm not sure whether userinfo support is required for
conformance. As quoted above, it's a MUST, but then, it is added that
browsers MAY not support it: The usage of userinfo is discouraged MAY
not work in implementations.
This should be more clear in the latest revision. For HTTP you probably
shouldn't support it (and throw a SYNTAX_ERR) but for some protocols it
makes some sense. For FTP you often have the username:[EMAIL PROTECTED]
logins... However, the current draft only covers HTTP.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [selectors-api] DOM Level 3 Core + Selectors API
On Wed, 27 Sep 2006 08:57:33 +0200, Karl Dubost [EMAIL PROTECTED] wrote: I agree with your sentence, but please be sure to have the same prose in both sections or to refer to extensibility section. Could you be more specific? I'm not sure what you're hinting at. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: HTTP Method list in new XMLHttpRequest draft
On Wed, 27 Sep 2006 18:09:22 +0200, Julian Reschke [EMAIL PROTECTED] wrote: thanks for adding the methods from RFC2518/RFC3253/RFC3648/RFC3744. However, I'm missing MKREDIRECTREF and UPDATEREDIRECTREF as defined in RFC4437. Could these be added as well? Perhaps. There was some discussion on the member list (should've been here) about removing them again as it already states that they SHOULD be supported and they have not much to do with XMLHttpRequest at all. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest test suite suggestion
On Wed, 27 Sep 2006 22:12:18 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Bjoern Hoehrmann wrote: * the internal [[Construct]] method must determine and memorize the /XHR base resource identifier reference/, the value of the baseURI property of the document property of the global object associated with the caller of the method Er... the caller? What's the caller in this case? Maciej has suggested the following text: Every XMLHttpRequest constructor is associated with the window object which initially had it as a property. When url is relative, the constructor must resolve it using window.document.baseURI of its associated window object as a base. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest test suite suggestion
On Wed, 27 Sep 2006 23:01:42 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: I don't see what's unclear here. When [[Construct]] is called, that is the result of evaluating a new expression. The expression is part of one ECMAScript program. Each ECMAScript program has one global object associated to it. What could you call the caller of a [[Construct]] method where it would be unclear what the caller's global object is? In that case this proposal doesn't actually match what's being done by IE. Internet Explorer does what's noted in my other e-mail. It resolves it relative to the window where the constructor is defined upon (that you call). (I hope I phrased that more or less correct. If not, see the other e-mail.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: comments on Selectors API WD
On Fri, 29 Sep 2006 09:50:45 +0200, Daniel Glazman [EMAIL PROTECTED] wrote: 1. I think the title of the document is badly chosen. The spec* does not offer any API on selectors themselves but, in substance, offers an implementation for document.getElementsBySelector(). Since we may have in the future a real API for accessing selectors themselves into the CSS OM, I strongly recommend a name more related to the contents than it is today. We've been through this several times. Some people think the name is ok, others don't and I don't really care anymore. Regarding the CSSOM, that will just let you access a selector as a DOMString and if it would provide an API that would be CSSSelector or something... 2. I think it's an error to restrict this new API to the document level, in particular if we have scoped stylesheets in the near future. I recommend extending the API to all nodes. Well, the option is kept for extending it to other nodes. I'd like scoped selectors to be defined first. 3. for scoped stylesheets, and if item 2 above is accepted, I recommend adding a boolean parameter to both matchSingl() and matchAll() methods saying if it's a scoped request or not. In the case of a scoped request, the :root pseudo-class then represents the current node on which the method is invoked. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. The result should always be a StaticNodeList. If the boolean is true, then the length of the result is = 1, and it's unconstrained otherwise. I don't think adding more arguments is acceptable. 5. Disruptive Innovations SARL becoming a W3C member on the 1st of October, we are ready to help on this specification. If you could provide a testsuite, that'd be cool! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: comments on Selectors API WD
On Fri, 29 Sep 2006 10:54:36 +0200, Daniel Glazman [EMAIL PROTECTED] wrote: Well having matchSingle and matchAll reply two different things is from here hardly acceptable too... That means that a given code will have to implement two different handlers depending on the queried set, first one or all. I don't really understand this argument. You need a separate codepath anyway because you only want to return the first and you might want to use some different (faster) code for that than when you're returning all nodes matching a given group of selectors. At least, make both methods reply a StaticNodeList please ! On scoped stylesheets : getElementsByTagName() is available on all Elements and matchAll() won't be allowed on Elements ??? While the former is a subcase of the latter ? Wow... Sorry, this is, from a DOM user point of view, VERY suboptimal So have the CSS WG define scoped selectors. I don't think the Web APIs WG should define that. This API isn't set in stone, there will be a version 2 if there's sufficient demand and need. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: comments on Selectors API WD
On Sat, 30 Sep 2006 04:21:39 +0200, Daniel Glazman [EMAIL PROTECTED] wrote: The one and only issue is the :root matching, and it makes perfect sense here to say it matches the root of the subtree because there is no other root element in this context ! The other option, ie match the root of the document, is pure non-sense... In the scope, that element is just not visible. Well, there have been several suggestions as to how it could work (this being a new one): * An implied descendant combinator at the start; * An implied child combinator at the start; * You select nodes from the whole Document, but only those part of the relevant subtree are returned (here :root matching the root of the Document does make sense); * You require :root at the start? Or something similar to that? that it's simpler and safer to restrict ourselves to Document at first, and extend to Element (or Node) later, rather than do the latter now and find out later that it introduces issues with what the CSS WG intends to do in the area. I thought your WG was more disruptive than that :-) More seriously, I really think this WD does not push far enough. The cost is little. Your WG and the CSS WG could probably solve this quickly. I'm happy for the CSS WG to suggest something sensible. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: HTTP Method list in new XMLHttpRequest draft
On Wed, 27 Sep 2006 20:14:53 +0200, Mark Baker [EMAIL PROTECTED] wrote: Yah - I recommended having the whitelist consist of just GET and POST. I'm wary of much longer lists because it might suggest that we've somehow vetted the operations, when that's not the case. I included PUT, DELETE and HEAD as well. HEAD is mentioned on multiple other locations and the other two are relevant for the case-insensitive matching. I'm about to check this in into the editor's draft. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] Introduction with more background
On Wed, 27 Sep 2006 09:00:14 +0200, Karl Dubost [EMAIL PROTECTED] wrote: The comment was not correctly framed, explained. Thanks for the explanation, but put it in the prose of the specification. Questions were here to foster a more detailed introduction giving context and inviting developers to understand the benefits of the technology. Please update the introduction. Fair enough, done. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest: Why list HTTP method names
On Tue, 10 Oct 2006 00:52:50 +0200, Subbu Allamaraju [EMAIL PROTECTED] wrote: I find a bit odd for the XMLHttpRequest draft to require all implementations to support the listed method names. In particular, what the motivation for the conformance statement - [...] In recent editor drafts this has been changed to GET, POST, PUT, DELETE and HEAD. All others should be supported, but are not explicitly listed. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Fwd: Liaison from JSR-287/280
On Tue, 10 Oct 2006 09:49:01 +0200, Robin Berjon [EMAIL PROTECTED] wrote: 1. WheelEvent We already decided on mousewheel here. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/proposals/mousewheel.txt I guess we still have to decide whether or not having mousewheelx as well makes sense. 2. ProgressEvent This would be part of a separate specification having both progress and uploadProgress (or similar names). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
