- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 07 Apr 2013 23:27:07 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>
On 4/7/13 9:52 PM, Ian Hickson wrote: >> The way <iframe srcdoc> is defined, the document URI does not in any way >> encode the document contents. > > This is the same as HTTP URLs where the server returns different content > each time No, because browsers have these things called "caches" and are known to use them. > URLs of Documents that have been document.write()n or otherwise > modified dynamically Yes. > URLs of Documents that have been generated by > POST No, see "caches" (though you do need more state than just a URI in this case, admittedly).. > or that have no-cache headers after the network has been lost See "caches"; Gecko allows the UI to do a forced load from cache, ignoring such headers. > Nothing requires those features to be equivalent to window.open(location) And yet in practice they are (not quite, but in the end similar). So the question is whether we should make that work or whether we just break it and expect all existing UAs and UA extensions to update. > This is obviously non-trivial And hence won't happen for what some will argue is a niche feature in the first place. Your argument seems to come down to "it's already slightly broken in rare cases, so it doesn't matter if we break it completely in what we hope will become the common case", honestly. Maybe you even believe that this is a reasonable approach... -Boris
Received on Monday, 8 April 2013 03:27:37 UTC