- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Thu, 20 Jan 2011 01:08:25 -0800 (PST)
- To: public-html@w3.org
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? In addition to what Boris said: 1) It makes syncness dependent on what the page loaded from the javascript: or data: URL contains. If the page contains an external script, it can't be sync anyway. Thus, the only way to avoid surprises depending on the presence of external scripts is to make page loads categorically async. 2) Making some loads sync requires another code path, which would be especially annoying in Gecko now that the usual (non-about:blank) case for URL loads is that the HTML parser lives on another thread. 3) Especially making data: URLs sync while http: URLs are async (by necessity) is bad for test cases, since people writing test cases tend to assume that tests written with data: URLs test the same things above the network stack as writing tests with http: URLs would. I'm strongly opposed to making any URLs other than about:blank load synchronously. And even about:blank is painful, but it's needed for compat. (Firefox 4 loads about:blank using the old parser, because making a reimplementation capture the exact legacy behavior expected by our test suite was too hard an exercise to put on the critical path of getting the HTML5 parser shipped!) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Thursday, 20 January 2011 09:09:29 UTC