- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 31 Aug 2010 07:16:32 +0200
Thanks for the changes, some comments below. On Tue, 31 Aug 2010 01:58:52 +0200, Ian Hickson <ian at 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/
Received on Monday, 30 August 2010 22:16:32 UTC