- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 19 Jan 2011 13:28:42 -0500
- To: Ojan Vafai <ojan@chromium.org>
- CC: "Hallvord R. M. Steen" <hallvord@opera.com>, public-html@w3.org
On 1/19/11 1:04 PM, Ojan Vafai wrote: > I believe WebKit is sync for javascript, data and empty URLs. Being sync > for these cases is so much more convenient for web developers that have > to deal with iframes. Especially as we are starting to add APIs for > using iframes in lighter-weight contexts (e.g. seamless), this will > become more important. > > Are there any disadvantages to making these cases sync? Yes. 1) It makes the mental model inconsistent for developers (some loads are sync, some are async). For example, trying to detect a load completing by using an onload handler involves knowing what sort of url you're loading, because otherwise the load may be done before you've set up your onload handler. Or requires very carefully ordering your operations as you insert the new element. This applies to all three of the cases above. Unless the load event is still async, of course... in which case in what sense are things sync here? 2) It's not what browsers used to do, certainly (see https://bugzilla.mozilla.org/show_bug.cgi?id=351633#c0). Right this second it's not what Safari 5 does if you load http://web.mit.edu/bzbarsky/www/testcases/javascript-url/sync-vs-async.html and click "Test iframe" 3) For the javascript: case, it significantly simplifies implementation, especially if you want to support javascript: in a variety of contexts (as Gecko does) because you don't have to worry about random script executing in the middle of other operations. -Boris
Received on Wednesday, 19 January 2011 18:29:19 UTC