On Mon, 16 Jun 2008 14:43:46 +0200, Mark Birbeck
<[EMAIL PROTECTED]> wrote:
On Fri, Jun 13, 2008 at 6:44 PM, Boris Zbarsky <[EMAIL PROTECTED]> 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/>
