[whatwg] Proposal for separating script downloads and

[Kyle Simpson]

>> 3. My (and Nicholas's previous) proposal: Script elements are fetched 
>> when
>> inserted into the DOM[1].  An event is dispatched when the script has 
>> been
>> fetched, eg. "onfetch" or "onpreload"[2].  A "preload" attribute is 
>> added;
>> when true, the script will not be executed when the fetch completes; call
>> script.execute() to run the script.

> I strongly prefer this proposal to either of the other two, for what
> it's worth.  Is the concern that this doesn't degrade as nicely in UAs
> that don't support preload or something?  If not, what _are_ the
> arguments against this proposal?  Links to existing discussion are fine
> if this ground was already covered.


There are several concerns which, at various times, have been brought up 
about this variation of the proposal. As Glenn stated, this was Nicholas' 
original proposal, but given those questions and concerns, he has adjusted 
his proposal several times. The adjustments he's made to his proposal have 
generally been to converge it in the direction of my proposal, at least to 
some extent.

To briefly restate some of the issues with the original proposal (as 
compared to the alternatives):

1. Not only does IE already have the functionality of my proposal 
implemented, but the spec already has this exact wording in it. The spec 
already suggests that browsers could/should do exactly this preloading, when 
the src is set but the element is not yet appended to the DOM. Moreover, my 
proposal draws on existing precedent for `readyState` and 
`onreadystatechange`, and the way that Image preloading works.

Put plainly, the original proposal is much further from:  a) existing spec 
wording; AND b) existing browser implementation; AND c) existing precedent.

The goal (from my perspective) is to come up with the simplest proposal that 
serves the use-cases. Simplest being defined in this particular situation as 
the least amount of change to the spec, AND the least amount of change to 
the browser that has by far the slowest release cycle (IE).


2. The execute() API concept had several other questions that arose, such 
as:
  a) is execute() sync or async? what does this imply about if the script 
being executed itself calls execute() on other script elements, and so on?

  b) what does it imply about whether/when the event handler(s) would be 
fired? If it's synchronous, are the event handlers also synchronous or are 
they async? Are they fired before or after the execute() actually does the 
executing of the script element?

  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)?

  d) what are the semantics of if you call execute() on a script element 
before it has finished preloading, or for a script that wasn't preloaded at 
all? Does this simply turn off preloading execution-deferral flag? Or does 
it throw an error? Would those errors be synchronous (like an actual 
exception that aborts processing) or simply bubble to the script.onerror 
handler?

  e) what happens if a script's .text is modified before execute() is 
called? What if a script element is cloned before execute() is called? What 
if it's cloned after execute() is called?


3. If in the future we want to also support preloading of other resources, 
like stylesheets for instance, which of the proposals offers the best 
precedent for that? For instance, would it make sense to add a .execute() to 
the <link> element for applying a stylesheet that had been preloaded? Or 
would the preloading style from my proposal (or even Nicholas' current 
proposal variation) fit more cleanly?

In exploring these issues and questions (and others), some contradictory 
arguments were brought up. In the end, I think Nicholas found it easier to 
simplify his proposal rather than keep going down this rabbit hole. For the 
most part, my proposal doesn't seem to suffer the same complexity of most of 
these questions. And to the extent that some of the questions are 
applicable, those questions already exist and browsers already have answers 
for the normal dynamic script append semantics.

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.

BTW, I don't necessarily claim that above to be an exhaustive distillation 
of this entire thread as it related to Nicholas' original proposal, and the 
revival of it that Glenn has been pushing for -- I'm sure I missed a few 
points in my memory recall. But I do think it's at least illustrative of how 
the conversation got a lot more complicated as we started exploring how 
.execute() would actually work.


> 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.


> I'd like to know what Opera and Webkit folks think, in terms of
> implementation difficulty.

FWIW, someone from Opera did, earlier in this thread, at least weigh in to 
suggest that they would implement the "readyState preloading" (aka, my 
proposal) completely (if they did so at all), to allay fears that Opera 
might break the assumption of the feature-detection that my proposal relies 
on.

To be clear, they didn't say they'd implement this proposal. But they did 
agree that preserving the feature-detect would be prudent, meaning they 
wouldn't change their implementation of `readyState` unless they were 
bringing it fully in line with IE's behavior (and thus my proposal).



--Kyle