Thanks for the changes, some comments below.
On Tue, 31 Aug 2010 01:58:52 +0200, Ian Hickson <i...@hixie.ch> wrote:
On Sat, 7 Aug 2010, Anne van Kesteren wrote:
2) Is there any reason we cannot also use this "no browsing context"
clause to define document.cookie rather than having a special type of
Document object? Seems much better.
Since the spec is already written... I can see cases where you could have
a Document that had no browsing context but did have cookies. So...
But there are no such cases currently. It would be nicer if the special
casing was the other way around so XMLHttpRequest did not have to say
anything. (And Web DOM Core when it is written.)
4) I could not test Internet Explorer but so far only WebKit exposes
document.domain in XMLHttpRequest and it does not throw on getting and
on setting it throws a SECURITY_ERR (not INVALID_STATE_ERR). If we align
with document.cookie as suggested above maybe this should align too and
getting should return the empty string and setting should be ignored.
Done.
I guess throwing is fine too.
5) I think we want to ban document.lastModified too. At least for
cross-origin requests and the way we did it elsewhere was to then ban it
for same-origin as well. (The HTTP header can be read instead. It also
does not seem like a huge loss.)
What's wrong with exposing document.lastModified?
I guess nothing. Last-Modified is safe.
6) If you provide some hook or tell me how to do it I can define the
origin of the Document returned by responseXML in XMLHttpRequest.
HTML already defines this. Or do you mean we should move that to the XHR
spec?
That is what I meant, yes.
If we can do all this that should turn it into a one-way dependency with
most definitions being completely self-contained.
I'm not sure it's worth it in the case of the origin thing.
So what happens when we define how to get a Document out of a File?
--
Anne van Kesteren
http://annevankesteren.nl/
