Okay, so it sounds like everyone is really much more in favor of an approach that doesn't require execute() to run the code that was preloaded. That seems to narrow the field back down to the two proposals outlined on Kyle's wiki. The question really is, even with that preference, are either of these implementable within current browser script loading systems? More precisely, is the preference strong enough to rationalize making changes so that one of these can be implemented?
-Nicholas ______________________________________________ Commander Lock: "Dammit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Boris Zbarsky Sent: Thursday, March 03, 2011 8:28 AM To: Henri Sivonen Cc: [email protected] Subject: Re: [whatwg] Proposal for separating script downloads and execution On 3/3/11 5:20 AM, Henri Sivonen wrote: > Are there the known to be pages that users frequently encounter that create > and set src on a large number of script nodes without inserting them? Not known to me, no. I've seen pages that create lots of scripts (one per each dynamic action they want to do), of course. > Or is this a theoretical concern about accidental resource exhaustion? More this, yes. > Is the expectation that IE is safe because the accident happens on a sniffed > branch that IE doesn't get? No, IE is safe because it coalesces the script loads in weird ways as discussed earlier in this thread. > (I still quite like the idea of starting fetch upon setting .src and making > insertion trigger evaluation. The idea of adding an execute() method scares > me. Mainly because having an execute() method is so radically different from > how things have worked so far and having insertion execute degrades > gracefully(ish) in existing browsers.) I admit the graceful degradation argument is pretty tempting.... -Boris
