- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 18 Jan 2010 22:53:59 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Adam Barth <w3c@adambarth.com>, public-html@w3.org
On Mon, 18 Jan 2010, Boris Zbarsky wrote: > On 1/18/10 12:48 PM, Adam Barth wrote: > > On the other hand, @doc would work is a follows: > > > > 1) There's a function that gets called whenever the user agent > > encounters a new attribute on an element. When this function gets > > called for an "doc" attribute on an iframe (or whichever elements > > support the doc attribute), the following steps occur. > > > > 2) Navigate the iframe to a new document. > > > > 3) Feed the tokenizer for that document the contents of the doc attribute. > > For what it's worth, my personal preference is that the @doc be parsed/loaded > asynchronously, just like @src would be. At least in Gecko's case we could > actually pretty much reuse our normal pageload code, with just a small shim to > create a "network load" that feeds in the @doc data, to implement that. I > can't speak to other implementations. This is more or less what I had in mind, except that I would blow away the old browsing context and create a new one, rather than navigating the previous one. I believe this is what happens with setting src="", too. > Of course this all ties back somewhat to the synchronous about:blank issue.... Unless someone can indicate a reason why not to do this, I expect that I'll make about:blank asynchronous, and only make initial browsing context creation synchronous (like it already is -- this doesn't involve actually loading about:blank using the regular "navigation" steps). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 18 January 2010 22:54:32 UTC