On Wed, Feb 23, 2011 at 9:14 AM, Kyle Simpson <[email protected]> wrote: > Again, I think the spirit we all share is to find the simplest proposal that > gets the job done, and introducing a new .execute() concept raised more > questions than it purported to solve.
The last dozen or two messages were regarding your rabbit hole, which raised serious issues. > c) does this run the risk of going afoul of the same issue that tripped of > Firefox with their synchronous execution of inline script elements (that > jQuery used for global-eval)? I don't know how an opt-in API that doesn't yet exist and which nobody is using can run afoul of existing code, so you'll need to be more specific. >> I sympathize with that, since they're aiming to improve the likelihood of >> being implemented--but the precedent it's drawing on seems like a bad one, >> which should be treated as a compatibility hack rather than a precedent for >> new APIs. > > I strongly disagree with this characterization, based solely on the fact that > the wording of the current spec already says to do exactly as I'm proposing. > That's not a "compatibility hack", that's further standardizing the wisdom > that the spec writers already thought through and codified. There's no need to load images that aren't in the DOM, since you can simply add them to a hidden container in the document. Loading images that aren't in any document avoids breaking existing pages--a compatibility hack. It's odd to assume, in an architecture bogged down in so much backwards-compatibility, that everything it does is good precedent. On Wed, Feb 23, 2011 at 9:28 AM, Boris Zbarsky <[email protected]> wrote: > Preloading of stylesheets is already supported in at least Gecko. Just mark > them as disabled (or an alternate stylesheet not in the main set, which is > the same thing in effect) and the sheet will be loaded+parsed but not > applied. Which is presumably what you mean by stylesheet preloading? Hmm. Here's a related idea: - Add an "onfetch" event, when the fetch completes (put aside the question of this vs. onreadystatechange for now). - Add a "noexecute" attribute. When true, the "execute a script block" steps set an internal "pending-execution" flag and aborts. This is done at the start of the "If the load was successful" subsection. - If the "noexecute" attribute is changed, and the "pending-execution" flag is true, clear the "pending-execution" flag and queue a task to run "execute a script block". - The "pending-execution" flag is not propagated to clones, but always set to false. Put more roughly: set "noexecute" to preload the script, and clear it to execute it. The implications of this: - Scripts still receive onerror on fetch errors ("for example a DNS error, or an HTTP 404 error"), even if noexecute is set. That is, you can detect network errors without executing the script. - Scripts can still only be executed once, regulated by the "already started" flag. - Capturing "error" on window can still be used to capture all error events. (Fetching scripts without them being in any document breaks this, which is a serious problem with the other proposals.) - Once a node has had its "already started" flag set, the "prepare a script" steps never run on it again, even if the node is cloned. Clearing the "pending-execution" flag follows this, preventing an already-prepared script from being executed twice when cloned. - For feature detection: typeof(document.createElement("script").noexecute) == "boolean". -- Glenn Maynard
