?> One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be used in markup. I.e. you can do
things like:
<html>
<head>
<script src=a.js noexecute onload="...">
<script src=b.js noexecute onload="...">
<script src=c.js noexecute onload="...">
</head>
Doesn't <link rel=prefetch> mostly address the use-case of
load-but-don't-execute in markup? The reason script-inserted script elements
need this capability is more advanced than any use-case for why you'd do so
in markup. In other words, I can't imagine that a script loader would rely
on adding script tags through markup (like with document.write() I guess?)
rather than just using dynamic script elements.
For the sake of the argument though, I *can* see how the "noexecute" would
be useful for *inline* script elements that you wanted to include in your
markup. For instance, the gmail-mobile team does this by wrapping the inline
script content in comments (and then later processing the code to execute
it).
However, it's already possible to address that same use-case using existing
behavior... by simple specifying a bogus `type` for the inline script
element. Some JS templating solutions make use of this behavior, like:
<script type="template/foobar">
...
</script>
What `noexecute` *would* bring additional to the use-case is the ability to
directly execute the script block at a later time without having to process
its contents manually. Currently, if you use the bogus type method, or the
comment-wrapped-content method, you have to manually grab the content,
process it, and re-inject it into a proper script element, which of course
is slightly less performant.
I'm not sure that the slight performance hit of this use-case is important
(or impactful) enough though to define a whole new attribute and its
semantics/complications.
Though of course, if people think that using readystate is enough then
we can flesh out that solution too. We'd have to require that UAs
start downloading the script as soon as .src is set, and that events
fire at reasonable points in time, like when the script has been
downloaded.
Yes, as I said earlier in the thread, I think we'd need to consider changing
the "may" wording in the current spec language to "shall" or "will". And
then we'd have to consider giving some basic framework language for an event
mechanism. Technically, the "preloading" event mechanism isn't strictly
necessary, but it's quite useful for several things you can't do without it,
and so I really don't think it's worth adjusting the spec without also
adding that part in.
I think that we couldn't use the 'load' event has that
might break existing pages which rely on 'load' not firing until the
script has executed.
Agreed, "load" is a binary one-time event, and thus not suitable for
overloading for this purpose. "readyState" is much more suitable since it
defines a progression of states. XHR already makes good use of defining such
an event mechanism, and so there's precedent to draw from here. In the case
of preloading for scripts, there's probably just two states necessary:
"uninitialized" and "complete". Haven't seen any use-cases for which any
intermediate states (like "loading") would be useful, as they are in XHR.
--Kyle
