[whatwg] Proposal for separating script downloads and

[Glenn Maynard]

On Wed, Feb 23, 2011 at 9:14 AM, Kyle Simpson <getify at gmail.com> 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 <bzbarsky at mit.edu> 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