Re: [XHR] LC comments from the XForms Working Group

On Mon, 16 Jun 2008 14:43:46 +0200, Mark Birbeck  
<mark.birbeck@webbackplane.com> wrote:
> On Fri, Jun 13, 2008 at 6:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> Mark Birbeck wrote:
>>> Since when have W3C specifications been written only for certain
>>> audiences?
>>
>> Uh...  Are you serious?  The SVG Tiny specs aren't written for certain
>> audiences, for example?
>
> Anne was implying that only comments received from certain audiences
> were relevant to the XHR draft. I was saying that this goes against
> the way specs progress within the W3C, since anyone can comment.

I was? How? That was certainly not the intent.


>> For one thing, XMLHttpRequest same-origin checking needs to work the  
>> same exact way as all otehr same-origin checking in the UA, to avoid  
>> introducing security bugs.  HTML5 will define same-origin checking in  
>> HTML.  It was
>> decided to reference this rather than duplicating a large chunk of that  
>> spec and possibly having spec skew).
>
> That's really not a big deal. If people need some help with doing
> this, then I'm sure there are plenty of people who would volunteer
> some time.
>
> I don't see this as a legitimate reason for not taking a more flexible
> approach to the XHR object.

It is a big deal, actually. Besides creating overhead, we also create the  
risk that XHR might get out of sink with the definitions in HTML5 which  
creates confusion, etc. We really want to avoid that. There should be a  
single place for implementors when they are implementing this and not  
multiple conflicting definitions.


>> If we have a better proposal for how that goal (that the same  
>> definition of
>> "same origin" is used everywhere) can be accomplished, I agree that  
>> would be nice.
>
> As above...I think most people would see this as trivial. But it's
> good news to hear that there is scope for the XHR draft to be changed
> to loosen up the requirement on Window.

I don't agree that it's trivial.


>> Similar for the other things Window gives us now (base URI definition,  
>> etc).
>
> Like what? Window gives us Document which gives us the base URI, so
> the dependency is on Document, and not Window.

The dependency is on Window because that has the constructor.


>> Perhaps we should define how these things work when we're in a Window  
>> and make it clear that any use of XHR in any other context will mean  
>> it's the other context's responsibility to define exactly how XHR  
>> behaves there, and list all the constraints such a definition must  
>> satisfy.
>
> That seems very heavy-handed. Why not just indicate that anyone using
> XHR will need to provide a context, and that context needs to provide
> a base URI against which relative URI references can be calculated,
> and security considerations can be resolved.
>
> That doesn't stop authors saying 'and by the way, in the case of
> Window and Document, those constraints are met as defined in HTML 5'.
>
> Pretty straightforward.

It would change the conformance criteria. I'm not sure that's a good idea.  
Especially since the use case put forward is mostly theoretical.


Overall, I'm still not convinced this is a good idea.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 16 June 2008 13:07:22 UTC