- From: <bugzilla@jessica.w3.org>
- Date: Thu, 15 Jul 2010 12:16:01 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 --- Comment #4 from Henri Sivonen <hsivonen@iki.fi> 2010-07-15 12:16:00 --- (In reply to comment #0) > > I'd rather not punch a special hole for that event handler without a compelling use case or site compat requirement. (Also, it seems inconsistent to make load on <script> fire synchronously when load events in general are async.) > > I guess I don't fully understand the implementation constraints you're > operating under. There are two issues: > > 1) Should the script load even fire synchronously. > 2) Should synchronous events that call document.write use the current > insertion point. > > There are a number of benefits to firing the script load event synchronously: > > A) The behavior matches all the shipping browsers I've tested. > B) Firing the script load event synchronously is more predictable for > developers and less likely to lead to race conditions. > C) There are unknown compatibility implications for changing when the > event is fired. > > There are a number of benefits for having synchronous events use the > current insertion point. > > a) The behavior matches all the shipping browsers I've tested. > b) Reusing the current insertion point is more predictable for > developers and less likely to lead to race conditions. > c) Reusing the current insertion point better matches the mental model > for how HTML documents are processed (basically, it abstracts away how > much of the document input stream is buffered in the network layer and > how much is buffered inside the tokenizer). > d) There are unknown compatibility implications for changing how > document.write in synchronous events behaves. > > The only "con" I see to (1) and (2) is a new implementation constraint > in Gecko that I don't quite understand given that we're not creating > any new insertion points (these events are just using insertion points > that already exist for the <script> elements themselves). I had a look at the code. It's certainly doable to reorder the script load event firing and the insertion point getting undefined. What I'm not quite sure about is how this will interact with the relative ordering of multiple document.write()s when the script load handler initiates nested document.write()s. It's easier to see in a debugger what happens than to try to read the code... I'll report back. Let's keep this spec bug open for a moment longer. (Sorry about the slow response.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 15 July 2010 12:16:05 UTC