<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 20, 2009, at 7:30 PM, Boris Zbarsky wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Ian Hickson wrote:<br><blockquote type="cite">Actually what's going on is more subtle than that. When you set innerHTML, it's actually triggering the deferred scripts right there, if it has them loaded (e.g. inline scripts or cached scripts). If it doesn't have them loaded yet, it drops them on the floor and doesn't ever run them.<br></blockquote><blockquote type="cite">I've specced this, except that the spec requires that not-yet-loaded scripts be loaded then run, rather than dropped, before innerHTML continues, so there's no race conditions.<br></blockquote><br>Er... wait. So innerHTML has to block on network access? And possibly spin the event loop as it does so?<br><br>This doesn't seem desirable to me.... Why do we want this behavior?<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>innerHTML blocking on network access seems seriously problematic to me. I don't think blocking the UI is preferable to a race condition, when we are talking about a compatibility quirk for content doing something dubious.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>