Re: [AC] Helping server admins not making mistakes

2008-06-12 Thread Jonas Sicking 


Hi Thomas and everyone,

So I realize that I'm not quite understanding your previous mail. It 
sounds like you have some alternative proposal in mind which I'm not 
following.


So let me start by stating my concerns:

My concern with the current spec is that once a server in the pre-flight 
request has opted in to the Access-Control spec, it is not going to be 
able to correctly handle all the possible requests that are enabled by 
the opt-in. With correctly here defined as what the server operator 
had in mind when opting in.


I have this concern since currently opting in means that you have to 
deal with all possible combinations of all valid http headers and http 
methods.


There is currently no way for the server operator to opt in without also 
having to deal with this.


In the initial mail in this thread I had a proposal to address this 
concern. At the cost of some complexity in the client.



It sounds like you have a counter proposal. Before you describe this 
proposal, I have four questions:


What is the purpose of the proposal?
Does this proposal still address all or part of my above concern?
Is it simpler than my proposal?
Is it simpler than the current spec?

And then finally I'm of course interested to hear what your proposal 
actually is :)


Best Regards,
/ Jonas

Re: [XHR] (Late) LC Comments

2008-06-12 Thread Julian Reschke 


Geoffrey Sneddon wrote:


On 12 Jun 2008, at 13:55, Julian Reschke wrote:


Anne van Kesteren wrote:

...
I think it would be better if HTTP defined what clients should assume 
(200 and OK most likely) in case the response data does not include 
it. Your HTTP parsing specification could do this for instance.

...


In HTTP/1.*, the status code is what the response says, and the status 
text is purely decorative. If it's not there, it's not there. Claiming 
it was OK would be misleading.


Still, throwing INVALID_STATUS_ERR seems to defy logic, and current 
implementations.


The error should be treated like any other network error.


WRT earlier HTTP versions: how would care?


s/how/who/, I assume?


Yes.

There's still (amazingly) a number of servers that do still have 
HTTP/0.9 behaviour, and support _is_ still needed. The behaviour 
everywhere, as far as I can tell, it to just return 200/OK.


Really? Evidence please? And are there use cases for accessing thise 
using XHR?


BR, Julian

Re: [WebIDL] Assigning to constants

2008-06-12 Thread Andrew Oakley 


Simon Pieters wrote:


What should happen when you assign something to a constant? e.g.:

   Node.ELEMENT_NODE = 'Hello world';

Web IDL doesn't say, AFAICT. Firefox and Opera allow the assignment. In 
WebKit it silently fails. I had expected an exception to be thrown, just 
like for readonly attributes.


It'd be good if this was defined.



http://dev.w3.org/2006/webapi/Binding4DOM/#es-constants says the 
property has attributes { DontDelete }.  That would imply that it 
doesn't have the ReadOnly attribute, and as such the assignment should 
be allowed.

Re: [WebIDL] Assigning to constants

2008-06-12 Thread Bjoern Hoehrmann 

* Andrew Oakley wrote:
Simon Pieters wrote:
 
 What should happen when you assign something to a constant? e.g.:
 
Node.ELEMENT_NODE = 'Hello world';
 
 Web IDL doesn't say, AFAICT. Firefox and Opera allow the assignment. In 
 WebKit it silently fails. I had expected an exception to be thrown, just 
 like for readonly attributes.
 
 It'd be good if this was defined.
 

http://dev.w3.org/2006/webapi/Binding4DOM/#es-constants says the 
property has attributes { DontDelete }.  That would imply that it 
doesn't have the ReadOnly attribute, and as such the assignment should 
be allowed.

With ReadOnly setting would be silently ignored, without ReadOnly you
know nothing.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: [XHR] SVG WG LC comments

2008-06-12 Thread Ian Hickson 
On Fri, 13 Jun 2008, Cameron McCormack wrote:
 Jonas Sicking:
   I wonder if this can be fixed in the HTML5 spec to say that when 
   serializing a whole document, no xmlns= attribute needs to be 
   inserted.
 
 That sounds like a good solution to me.
 
 Ian Hickson:
  We still somewhat want them in that case too, in case the string is then 
  used to assign into an elemnet in another document:
  
 var s = doc.documentElement.innerHTML;
 ...
 someOtherElement.innerHTML = s;
 
 But that’s serialising the document element, not the whole Document.

Ok, removed the requirement for documents.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'