- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 08 Mar 2011 09:39:18 -0500
- To: Ojan Vafai <ojan@chromium.org>
- CC: Henri Sivonen <hsivonen@iki.fi>, Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
On 3/8/11 3:58 AM, Ojan Vafai wrote: > Closure's rich text editor (used in a bunch of Google products) relies > on this behavior Which exact "this behavior" of the many being discussed in this thread? >(see > http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/editor/field.js#2461). > It uses iframes for the editing region. To avoid the delay waiting for > the load event, it essentially does the following: > container.appendChild(iframe); > iframe.contentDocument.write(initialHtmlContentsOfTheEditableRegion); This relies on there being a document synchronously available in the iframe. The web relies on that, sure. No one is planning to break it. The open question is how that document got there and what events should be firing, and when, in that testcase. Since you're ignoring all the events anyway, you don't really care about that part of the discussion, sounds like. > So, at least in this one instance it allowed a quite large performance > improvement. That said, Gecko's behavior is wacky. It would make a lot > more sense if the page was not blown away. Which part of Gecko's behavior are we talking about here? The fact that the about:blank loads async and will blow away a modified DOM if you modify it via DOM APIs instead of by doing a load yourself? (Note that document.open() counts as a load here.) -Boris
Received on Tuesday, 8 March 2011 14:40:24 UTC