?
I'm not sure why you are narrowing the scope to "script loaders"? (I
imagine you're referring to js-libraries which help with loading
scripts faster?)
Yes, script loaders like LABjs are the primary use-case that I'm concerned
about in terms of giving the load-but-defer-execution behavior to. That
doesn't mean it's the only use-case, just that it's (in my mind) the
majority use-case for this feature.
My idea was that webservers would output the above markup directly,
avoiding the need to go through special libraries at all.
Yes, web servers could output markup like that. BUT, there'd still need to
be some special library or code logic on the page that knew how and when to
execute the scripts. So, in my mind, if you already need to have such logic
in place for the execution, wrapping that logic into an existing script
loader which is almost certainly going to use a dynamic script element
(instead of script markup) makes natural sense.
I'm not saying the markup use-case is invalid, just that from my perspective
it's less prevalent than the rise of all the different script loaders
wanting to access this behavior on dynamic script elements, loaders like
LABjs, RequireJS, HeadJS, ControlJS, and many others.
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'm not quite sure I follow you here. What I was thinking was that we
say that implementations MUST (in the rfc 2119 sense) start loading
the script immediately.
This is the wording that's already in the spec:
-----------
For performance reasons, user agents may start fetching the script as soon
as the attribute is set, instead, in the hope that the element will be
inserted into the document. Either way, once the element is inserted into
the document, the load must have started. If the UA performs such
prefetching, but the element is never inserted in the document, or the src
attribute is dynamically changed, then the user agent will not execute the
script, and the fetching process will have been effectively wasted.
-----------
I was just saying that since this wording currently says "may", it's only
taken as guidance and a suggestion. To make this a true requirement, we'd
likely change "may" to "shall"/"will"/"must", right?
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.
Sure, but we'd also want to fire some event once the script has been
fully downloaded so that the page doesn't have to use a timer and poll
to figure out when the download is done.
I think we're in agreement here. At least I hope so. I think that the
`onreadystatechange` event firing when the `readyState` property becomes
"complete" is quite sufficient for an event to notify when the script
finishes loading, correct? That's how the current IE implementation works.
I *do* see a possibility that an event for `readyState=complete` (fired when
the script has finished *loading*) and an `onload` event (fired when the
script has finished *parsing & executing*) could be a little confusing (name
wise) to some developers. I wish that it hadn't ever been called "onload",
but for clarity sake, instead called something like "onrun" or "ondone",
etc. However, "load" has been for a long time commonly taken to mean
"completely loaded and run" -- that boat sailed long ago. There'd probably
be far too much compat breakage if we changed the semantics of the `onload`
event now.
IMHO, `readyState=complete` (or `readyState=loaded`) will be fine for the
true "loaded" event and `onload` can remain as-is for the "loaded and run"
event.
--Kyle
