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
On Thu, 06 Apr 2006 03:04:53 +0200, Mark Nottingham [EMAIL PROTECTED]
wrote:
Great stuff! A few quick comments on the draft;
* responseText attribute - type the response as an HTTP entity
explicitly (you already do this for the request data); that way, there's
no ambiguity about what
* Mark Nottingham 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.
On 2006/04/21, at 6:34 AM, Anne van Kesteren wrote:
* responseText attribute - type the response as an HTTP entity
explicitly (you already do this for the request data); that way,
there's no ambiguity about what level the implementation operates
at. I.e., XHR won't give you direct access
[ from the big comment e-mail; raising as a separate issue, as
requested ]
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
[ from the big comment e-mail; raising as a separate issue, as
requested ]
The current draft says that:
If the method is POST or PUT, then the data passed to the send()
method must be used for the entity body.
This doesn't account for other request methods that may have a
request body,
The specs last a *lot* longer than the current versions of Mozilla,
Safari and IE.
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
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,
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
On Fri, 21 Apr 2006, Mark Nottingham wrote:
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,
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
On 2006/04/21, at 11:13 AM, Anne van Kesteren wrote:
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
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
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
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
Bjoern Hoehrmann [EMAIL PROTECTED]
* Jim Ley 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.
It is very useful if it is
On Apr 21, 2006, at 12:56 PM, Anne van Kesteren wrote:
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
The documentation for the |uri| argument to XMLHttpRequest.open says:
A URI, which MUST be resolved to an absolute URI using the script's context
window.location.href value as base if available.
What is the script's context exactly? It's not defined in the spec. Assuming
we limit
Mark Nottingham wrote:
[ from the big comment e-mail; raising as a separate issue, as requested ]
The current draft says that:
If the method is POST or PUT, then the data passed to the send() method
must be used for the entity body.
This doesn't account for other request methods that may
On 4/21/06, 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.
Completely agreed. This is how we get
Brad Fults wrote:
Agreed. Also, I think the what if someone uses a good property name
for a lame implementation isn't as much of a concern because we're
talking about major browser vendors, not any random paster.
Are you talking about the same browsers we've been living with for the last 12
21 matches
Mail list logo
