Web DOM Core Snapshot
I hope this will make it easier to review. This one includes a table of contents and all the hyperlinks you might want. I will try to sort out something better. http://lists.w3.org/Archives/Public/www-archive/2010Sep/att-0015/Overview.html The repository is still in the same place: http://bitbucket.org/ms2ger/web-dom-core -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Comments on the 7 September working draft
On Mon, 13 Sep 2010 20:10:23 +0200, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
The refactoring is not quite equivalent:
if(this.readyState == this.DONE this.status == 200) {
...
}
processData(null);
processData will be called even when this.readyState != DONE.
Oops. Fixed.
- The request URL, The URL used in the request - Could it be made
more obvious that this is the resolved, absolute URL, and not the
relative one passed as an argument?
Why does that matter here?
Less ambiguity?
I do not think there is any, but I changed it anyway.
- The upload events flag, Used to determine whether to send upload
progress events for cross-origin requests. The flag is either true or
false - Is it only for cross-origin requests? The send() algorithm
doesn't say so. Perhaps this is more correct:
The *upload complete* flag, Used to determine when to stop sending
upload progress events. The flag is either true or false.
The *upload events* flag, Used to determine whether to send upload
progress events. The flag is either true or false.
The send() algorithm does say so. It is only used for cross-origin
requests.
OK. Still, maybe the proposed text for the upload complete flag could be
used?
Done.
- The code sample at the end needs some kind of introduction.
Isn't it self-explanatory? I.e. with the comments?
Yes it is; I was talking about something like the text in the examples
from the first section:
Some simple code showcasing what happens when setting the same header
twice:
Fair enough, added.
See above, would differ for abort().
How exactly? abort() doesn't read the error flag.
Yeah, you are right.
There seems to be a problem with invoking abort() and then invoking open()
from an event handler. I wonder why I never caught that before. I guess
this needs another look. *sigh*
OK, I think I get it now. When registering listeners, even if the
request will fail since it's not allowed by the remote server, the
events fired might still give out some information about the server. Am
I right?
Yes, that it exists.
- If authentication fails, Authorization is not in the list of author
request headers, request username is null, and request password is
null, user agents should prompt the end user for their username and
password. + They are also not prompted for cross-origin requests.
= should a same-origin condition be included in the first text?
Fixed, simplified the text a lot too.
OK with the new text.
I just realized that AnonXHR is not mentioned here. I guess anonymous
requests should never prompt for username/password, right?
Anonymous requests are cross-origin by design.
- If the user agent supports HTTP State Management it should persist,
discard and send cookies (as received in the Set-Cookie response
header, and sent in the Cookie header) as applicable. - Shouldn't
the anonymous flag be mentioned here?
Maybe this paragraph should just be dropped? HTML5 does not have an
equivalent sentence. FWIW, CORS is very clear on the behavior here.
Personally, I'd keep it there. It was present in XHR1, and CORS deals
only with cross-origin requests.
I mean that no other specification dealing with requests specifically
calls out sending cookies in the request. That is already part of the
cookies specification. We should of course still call out when cookies are
not to be included or when they are not to be set, but just in general
repeating what the cookies specification says does not seem useful. (It
would also be removed from XMLHttpRequest Level 1.)
This applies also to the text on proxies.
Two spaces everywhere it is.
Almost, there's still the comment inside the processData function in
Section 1.
Heh, fixed.
Section 4, FormData:
- Shouldn't a read method be included?
Why?
In case different code components fill in parts of the request data and
they want to check that they're not overriding somebody else's data, in
case that some field names should have only one value, or in case one
component wants to change/remove the value placed by an earlier
component (which calls for a remove method as well, leading to a
full-fledged map interface :( ). Maybe it gets too complex, so it should
be left as it is now, complex scenarios should be handled with a custom
object which is then converted to a FormData
Yeah. We can always make it more complex later.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [DOMCore] Attr
On Fri, 10 Sep 2010 14:35:22 +0200, Anne van Kesteren ann...@opera.com wrote: Hi, I thought I'd email some people directly to figure out what we can do with Attr as it is one of the last bits not defined yet in Web DOM Core and I would sort of like to handle it so the specification is complete (at least beyond the initial 80%). Another thing I think we should consider is getting rid of the API differences in XML. The differences are annoying; consider trying to use XHTML with external script libraries that assume HTML is being used. * Let createElement have its argument converted to lowercase also in XML. * Let createProcessingInstruction create a PI also in HTML. * Let getElementsByTagName match the argument converted to lowercase for elements in the HTML namespace also in XML. * Let tagName be converted to uppercase for HTML elements also in XML. * Let getAttribute, setAttribute and hasAttribute have the first argument converted to lowercase for HTML elements also in XML. tagName is the only change that is likely to break in existing XHTML-only scripts, AFAICT. -- Simon Pieters Opera Software
Re: [XHR2] Comments on the 7 September working draft
On 09/14/2010 01:34 PM, Anne van Kesteren wrote:
On Mon, 13 Sep 2010 20:10:23 +0200, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
The refactoring is not quite equivalent:
if(this.readyState == this.DONE this.status == 200) {
...
}
processData(null);
processData will be called even when this.readyState != DONE.
Oops. Fixed.
OK.
- The request URL, The URL used in the request - Could it be made
more obvious that this is the resolved, absolute URL, and not the
relative one passed as an argument?
Why does that matter here?
Less ambiguity?
I do not think there is any, but I changed it anyway.
OK.
- The upload events flag, Used to determine whether to send upload
progress events for cross-origin requests. The flag is either true or
false - Is it only for cross-origin requests? The send() algorithm
doesn't say so. Perhaps this is more correct:
The *upload complete* flag, Used to determine when to stop sending
upload progress events. The flag is either true or false.
The *upload events* flag, Used to determine whether to send upload
progress events. The flag is either true or false.
The send() algorithm does say so. It is only used for cross-origin
requests.
OK. Still, maybe the proposed text for the upload complete flag could
be used?
Done.
OK.
- The code sample at the end needs some kind of introduction.
Isn't it self-explanatory? I.e. with the comments?
Yes it is; I was talking about something like the text in the examples
from the first section:
Some simple code showcasing what happens when setting the same header
twice:
Fair enough, added.
OK.
See above, would differ for abort().
How exactly? abort() doesn't read the error flag.
Yeah, you are right.
There seems to be a problem with invoking abort() and then invoking
open() from an event handler. I wonder why I never caught that before. I
guess this needs another look. *sigh*
Indeed, this will have weird results:
1. open()
2. Add listeners
3. send()
4. abort()
5. In the readystatechange listener, call open() and send()
6. abort continues, and sends the next events: abort, loadend, but now
the object's state is wrong: the state is not DONE, there might be
network activity, the error flag is not set.
7. The abort algorithm sets the state to UNSENT, although a request is
in progress.
One option would be to change the open() algorithm, so that step 15
aborts both the send() and abort() algorithms, and also the request
error algorithm. But this means that listeners won't get all the events
(this is also true if the open method is called when a request is
already in progress).
Allowing open() to be called at all times makes it almost impossible to
fix this error, so another option is to not allow open to be called when
some other algorithms are in progress.
- If authentication fails, Authorization is not in the list of author
request headers, request username is null, and request password is
null, user agents should prompt the end user for their username and
password. + They are also not prompted for cross-origin requests.
= should a same-origin condition be included in the first text?
Fixed, simplified the text a lot too.
OK with the new text.
I just realized that AnonXHR is not mentioned here. I guess anonymous
requests should never prompt for username/password, right?
Anonymous requests are cross-origin by design.
Indeed.
- If the user agent supports HTTP State Management it should persist,
discard and send cookies (as received in the Set-Cookie response
header, and sent in the Cookie header) as applicable. - Shouldn't
the anonymous flag be mentioned here?
Maybe this paragraph should just be dropped? HTML5 does not have an
equivalent sentence. FWIW, CORS is very clear on the behavior here.
Personally, I'd keep it there. It was present in XHR1, and CORS deals
only with cross-origin requests.
I mean that no other specification dealing with requests specifically
calls out sending cookies in the request. That is already part of the
cookies specification. We should of course still call out when cookies
are not to be included or when they are not to be set, but just in
general repeating what the cookies specification says does not seem
useful. (It would also be removed from XMLHttpRequest Level 1.)
This applies also to the text on proxies.
OK.
Two spaces everywhere it is.
Almost, there's still the comment inside the processData function in
Section 1.
Heh, fixed.
OK.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Re: [XHR] Redirects
On Mon, Sep 13, 2010 at 8:51 AM, James Leigh james-nos...@leighnet.cawrote: On Wed, 2010-09-01 at 01:03 -0700, Darin Fisher wrote: I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. -Darin I want to point out that resolving the Location header is not specific to 3XX responses. A 201 (Created) response also includes a Location header that may need to be resolved. If the problem of providing a way to resolve redirect is addressed it might be good to also address the problem of resolving 201 locations as well. One suggestion might be to provide a getResponseLocation() that returns the resolved Location header. James That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. -Darin
Re: [XHR] Redirects
On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher da...@chromium.org wrote: On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. I did not mean to downplay the problems you were raising. Do you think we should have a method like openPreserveState() that unlike open() does not reset a bunch of information? So to handle a redirect you would do openPreserveState(); send(); after the initial request if status is one of 301/302/303/307. (You might have to do some more.) That's a very interesting idea. Maybe it should be more specific, like openRedirectedLocation? That said, if one still has to call .send() afterwards, then we are still leaving it up to the caller to pass the right value to .send(). They have to know when the method is being changed from POST to GET and take appropriate action. That is a bit unfortunate. Maybe .send() and .openPreserveState() could just be combined into a single .followRedirect() method? Do you think I should comment out the followRedirects feature for now? At until we address the problem of how to follow it easily? I don't have strong opinions about that. It is up to you. I think it is OK to iterate :) -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, 2010-09-14 at 09:55 -0700, Darin Fisher wrote: On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher da...@chromium.org wrote: On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. I did not mean to downplay the problems you were raising. Do you think we should have a method like openPreserveState() that unlike open() does not reset a bunch of information? So to handle a redirect you would do openPreserveState(); send(); after the initial request if status is one of 301/302/303/307. (You might have to do some more.) That's a very interesting idea. Maybe it should be more specific, like openRedirectedLocation? That said, if one still has to call .send() afterwards, then we are still leaving it up to the caller to pass the right value to .send(). They have to know when the method is being changed from POST to GET and take appropriate action. That is a bit unfortunate. Maybe .send() and .openPreserveState() could just be combined into a single .followRedirect() method? A challenge with having these methods combined is that it prevents the caller from changing (or preserving) the request header between redirects (Mozilla, for example, resets all its headers following a redirect). By keeping them separate the caller can reinstate non-standard (or standard) headers between redirects as necessary. Thanks, James
Re: [XHR] Redirects
On Tue, 14 Sep 2010 19:22:30 +0200, James Leigh james-nos...@leighnet.ca wrote: A challenge with having these methods combined is that it prevents the caller from changing (or preserving) the request header between redirects (Mozilla, for example, resets all its headers following a redirect). By keeping them separate the caller can reinstate non-standard (or standard) headers between redirects as necessary. Well, that is a bug that needs to be fixed. We do not introduce new features to work around bugs. It is covered by the XMLHttpRequest test suite: http://tc.labs.opera.com/apis/XMLHttpRequest/send-redirect.htm -- Anne van Kesteren http://annevankesteren.nl/
[XHR2] FormData for form
Hi All, There was some discussions regarding the syntax for generating a FormData object based on the data in an existing form. I had proposed the following syntax myformelement.getFormData(); however it was pointed out that the downside with this API is that it's not clear that a new FormData object is created every time. Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? I'm fine with either syntax, but since we're getting close to shipping Firefox 4, and I'd like to include this functionality (in fact, it's been shipping for a long time in betas), I'd like to see if how much consensus the various proposals carried. / Jonas
Re: [XHR2] FormData for form
I have a preference for the second syntax. These sorts of classes should always be new-able. On Tue, Sep 14, 2010 at 10:46 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, There was some discussions regarding the syntax for generating a FormData object based on the data in an existing form. I had proposed the following syntax myformelement.getFormData(); however it was pointed out that the downside with this API is that it's not clear that a new FormData object is created every time. Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? I'm fine with either syntax, but since we're getting close to shipping Firefox 4, and I'd like to include this functionality (in fact, it's been shipping for a long time in betas), I'd like to see if how much consensus the various proposals carried. / Jonas
Re: [XHR2] FormData for form
Note that you can always do: fd = new FormData; That is agreed by everyone to work. The question is how to instantiate one which is prefilled with the data from a form. / Jonas On Tue, Sep 14, 2010 at 10:55 AM, Alex Russell slightly...@google.com wrote: I have a preference for the second syntax. These sorts of classes should always be new-able. On Tue, Sep 14, 2010 at 10:46 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, There was some discussions regarding the syntax for generating a FormData object based on the data in an existing form. I had proposed the following syntax myformelement.getFormData(); however it was pointed out that the downside with this API is that it's not clear that a new FormData object is created every time. Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? I'm fine with either syntax, but since we're getting close to shipping Firefox 4, and I'd like to include this functionality (in fact, it's been shipping for a long time in betas), I'd like to see if how much consensus the various proposals carried. / Jonas
Re: [XHR2] FormData for form
On Tue, 14 Sep 2010 19:46:12 +0200, Jonas Sicking jo...@sicking.cc wrote: Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? Neither. I said (on the WHATWG) list: I could add this to XMLHttpRequest Level 2. Then nobody ever followed up (until now). So in terms of HTML5 the above would invoke Constructing the form data set (defined in HTML5) for the HTMLFormElement passed as parameter and let that data set be the data hold by FormData. Is that what you plan to implement? -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] FormData for form
new FormData(myformelement) sounds good. On Tue, Sep 14, 2010 at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote: Note that you can always do: fd = new FormData; That is agreed by everyone to work. The question is how to instantiate one which is prefilled with the data from a form. / Jonas On Tue, Sep 14, 2010 at 10:55 AM, Alex Russell slightly...@google.com wrote: I have a preference for the second syntax. These sorts of classes should always be new-able. On Tue, Sep 14, 2010 at 10:46 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, There was some discussions regarding the syntax for generating a FormData object based on the data in an existing form. I had proposed the following syntax myformelement.getFormData(); however it was pointed out that the downside with this API is that it's not clear that a new FormData object is created every time. Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? I'm fine with either syntax, but since we're getting close to shipping Firefox 4, and I'd like to include this functionality (in fact, it's been shipping for a long time in betas), I'd like to see if how much consensus the various proposals carried. / Jonas
Re: [XHR2] FormData for form
On Tue, Sep 14, 2010 at 11:04 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 14 Sep 2010 19:46:12 +0200, Jonas Sicking jo...@sicking.cc wrote: Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? Neither. I said (on the WHATWG) list: I could add this to XMLHttpRequest Level 2. Then nobody ever followed up (until now). So in terms of HTML5 the above would invoke Constructing the form data set (defined in HTML5) for the HTMLFormElement passed as parameter and let that data set be the data hold by FormData. Is that what you plan to implement? Yes. / Jonas
Re: [XHR2] FormData for form
On 09/14/2010 07:46 PM, Jonas Sicking wrote: Hi All, There was some discussions regarding the syntax for generating a FormData object based on the data in an existingform. I had proposed the following syntax myformelement.getFormData(); however it was pointed out that the downside with this API is that it's not clear that a new FormData object is created every time. Instead the following syntax was proposed: new FormData(myformelement); however I don't see this syntax in the new XHR L2 drafts. Is this merely an oversight or was the omission intentional? I'm fine with either syntax, but since we're getting close to shipping Firefox 4, and I'd like to include this functionality (in fact, it's been shipping for a long time in betas), I'd like to see if how much consensus the various proposals carried. +1 for new ForData(formElement) -- Sergiu Dumitriu http://purl.org/net/sergiu/
Re: ArrayBuffer and ByteArray questions
Yes, we only need to add it to BlobBuilder so that it can be applied to both FileReader, XHR.send and any other place that take the blob. On Wed, Sep 8, 2010 at 10:57 AM, Eric Uhrhane er...@google.com wrote: On Tue, Sep 7, 2010 at 4:09 PM, Jian Li jia...@chromium.org wrote: Hi, Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html ), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? It seems like an obvious addition for BlobBuilder or XHR.send, but do we need it in both, or is one sufficient? Thanks, Jian
Re: File API exception codes
On Thu, Sep 9, 2010 at 6:39 AM, Arun Ranganathan aranganat...@mozilla.com wrote: - Original Message - On Wed, Sep 8, 2010 at 12:43 AM, Anne van Kesteren ann...@opera.com wrote: That works for me too, but then please use internally consistent numbering rather than some codes matching DOMException and the new codes not matching DOMException as that is just too confusing, especially going forward. I.e. DOMException might gain a similar exception but it will have a different number, so only for the older numbers it will match, etc. It just does not make much sense. OK, so we stick with the current interfaces, but try to keep the numbers all matching/nonconflicting. Works for me. OK, we'll use in-order numbering and not have any kind of dependency on DOMException. Sorry, I misread the conclusion. In-order numbering does make more sense. Let me know when you're about to update your numbering, and I'll fix mine to go with them.
WebIDL types and xsd types
Hi, Just wondering if there is a mapping between xsd types and Web IDL types? would seem to make sense to align, mirror and give common mappings. Best, Nathan
