Hallvord R. M. Steen wrote:
Note that document.domain (when set by both source and target frame)
also lets you ignore port and protocol differences, which once again
is not desirable for XHR.
I know we ignore port differences but I don't think we ignore protocol.
That's Gecko's behavior as
Hi Sunava,
Glad to get feedback from Microsoft on the spec.
I do however fully agree with Maciej here. If all we developed was a
spec with a basic description of the various functions and what
arguments they accept, we would not be accomplishing anything here.
There are plenty of tutorials o
On Sat, 22 Sep 2007 05:28:13 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
I think HTML5 needs to define this as my understanding is that
document.domain is also relevant in deciding whether or not a request
is same-origin. I'm not sure if that's happening soon though.
I don't thi
I haven't been following the technical discussion in enough detail to have
a definitive opinion about whether there is a need to address Microsoft's
concerns about ensuring backwards compatibility with existing web content,
but I have a knee jerk positive reaction whenever I hear a browser vendor
Anne van Kesteren wrote:
Hmm, actually, per HTML5 it seems that's impossible because the origin
of bar.com and foo.bar.com are not the same and therefore you can't
access any members of foo.bar.com from bar.com or vice versa.
document.domain can change this I suppose
Exactly.
but doesn't i
On Wed, 26 Sep 2007 16:06:08 +0200, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
Yes. If I get all this stuff correctly a script could be running on
bar.com using the XMLHttpRequest from another frame which is on
foo.bar.com. Depending on which definition is used it can
Anne van Kesteren wrote:
Yes. If I get all this stuff correctly a script could be running on
bar.com using the XMLHttpRequest from another frame which is on
foo.bar.com. Depending on which definition is used it can either access
bar.com or foo.bar.com content (but not both), right?
Basically
On Wed, 26 Sep 2007 15:51:45 +0200, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
Thanks. So it say the that the origin of the Document object associated
with the Window pointer is the origin of the request. With a reference
to HTML5 to see what the origin of such a Docum
Anne van Kesteren wrote:
Thanks. So it say the that the origin of the Document object associated
with the Window pointer is the origin of the request. With a reference
to HTML5 to see what the origin of such a Document object actually is.
Or should it simply be the origin of the script?
Thos
On Tue, 25 Sep 2007 22:55:53 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
I'm not sure offhand if baseURI is the right way to determine the
security domain. While setting document.domain does not apply, frames or
windows initially loaded with about:blank or no URI at all generally ge
Jon Ferraiolo wrote:
The idea that there is a new JavaScript class (XHR2?) or a different
version of the XHR object seems reasonable to me.
Introducing a brand new version of XHR doesn't solve the existing
interoperability problems the current version that people actually use.
I am opposed
On Sep 26, 2007, at 12:41 AM, Maciej Stachowiak wrote:
Hi Sunava,
Thanks for sending this feedback.
Here are my high-level comments:
1) I am strongly opposed to greatly weakening the implementation
conformance requirements. Changing the spec requirements so that
existing implementation
On Tue, 25 Sep 2007 12:32:05 +0200, Asbjørn Ulsberg <[EMAIL PROTECTED]>
wrote:
Can't overload in JS.
Not in the normal sense, but I think you understand what I'm looking for.
There isn't any toString on HTMLFormElement.
So it can't be introduced? Aren't we introducing new features here
Hi Sunava,
Thanks for sending this feedback.
Here are my high-level comments:
1) I am strongly opposed to greatly weakening the implementation
conformance requirements. Changing the spec requirements so that
existing implementations, even if they vary significantly in behavior,
are alrea
14 matches
Mail list logo