- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 24 Aug 2010 22:54:34 -0400
On 8/24/10 6:13 PM, Ian Hickson wrote: > So basically, translating this to specese: > > Document objects on which you call open() have an "override reload" > flag set and an initially empty source cache added. > > When you call document.write() on a document with the "override reload" > flag set, also append the text to the document source cache. > > When you reload a document that has the "override reload" flag set, > instead of reloading from the network, just stream the data in from the > document source cache. > > Is that right? That seems like an accurate description of the Gecko behavior. There's some weirdness in terms of the document encoding being set to whatever it's set to while the data is actually just read directly as UTF-16, etc, but that seems like an implementation detail; the spec just needs to specify that the data is read as characters, not bytes, and what the document encoding should be set to. >>> Because it ends up with an infinite regression of iframes; the reload >>> is just making the page load the page instead of about:blank, since >>> calling document.open() changes the document's address to the caller's >>> address. >> >> Right. This infinite regression is not a desirable consequence; the >> spec requiring this behavior seems like a bad idea. > > I don't know, it seems pretty desireable to me From whose perspective? The user just hits the reload button, and the page suddenly breaks. Why is this desirable? > -- it's far simpler than caching the results of document.write()! Well, sure. Broken behavior is often simpler to implement than correct behavior... ;) > Also doing this for history navigation is rather scary too, but I guess > could be done. History navigation across document.open() is supported in at least IE and Gecko right now. I seem to recall it being rather broken if supported at all in Webkit. I don't know that I've ever tested Opera. -Boris
Received on Tuesday, 24 August 2010 19:54:34 UTC