Once again, the problem with changing how src works is that there's no way
to feature detect this change. It's completely opaque to developers and
therefore not helpful in solving the problem.
I still believe the feature-detect for my proposal is valid. It's obviously
not ideal (often times feature-detects aren't), but I don't think we should
suffer a more complicated solution just so we can get a slightly more
graceful feature-detect, when the simpler solution has a functional
feature-detect. So far, the feature-detect issue is the only thing I've
heard Nicholas push back on with regards to my proposal.
To restate, the feature-detect for my proposal is:
(document.createElement("script").readyState == "uninitialized") // true
only for IE, not for Opera or any others, currently
In fact, the precedent was already set (in the "async=false"
proposal/discussion, which was officially adopted by the spec recently) for
having a feature-detect that uses not only the presence of some property but
its default value.
(document.createElement("script").async === true)
Many of the same reasonings I gave there for that type (slightly
unconventional compared to previous ones) of feature detect are exactly the
reasons I'm suggesting a similar pattern for `readyState`. Extending the
feature-detect to use a property and its default value is a delicate way of
balancing the need for a feature-detect without creating entirely new
properties (more complexity) just so we can feature-detect.
While it isn't as pretty-looking, in the current state of how the browsers
have implemented things, it IS workable. The set of browsers and their
current support for `readyState` is a known-matrix. We know that only IE
(and Opera) have it defined. And given the high visibility of this issue and
our active evangelism efforts to the browser vendors, it's quite likely and
reliable that all of them would know the nature of the `readyState` part of
the proposal being the feature
The only wrinkle would have been Opera possibly changing the default value
to "uninitialized" but not implementing the proposed underlying behavior.
Thankfully, they already commented on this thread to indicate they would act
in good faith to implement the full atomic nature of the proposal (not just
part of it), so as to preserve the validity of the proposed feature-detect.
I know Nicholas has expressed reservations about that feature-detect. But I
would say that there needs to be hard evidence of how it will break, not
just premature fear that some browser vendor will go rogue on us and
invalidate the expressed assumptions.
Summary of changes:
* Changed "noexecute" to "preload"
* No HTML markup usage
* No change to "load" event
* Introduction of "preload" event
* Removed mention of "readyState"
I'd appreciate hearing feedback on this revision from everyone.
Firstly, I like the changes Nicholas made to his proposal. I think "preload"
and "onpreload" are definitely clearer than "noExecute" and whatever the
"onfinishedloading" would have had to be. I still think his proposal is more
complicated (and thus faces a more uphill journey to spec acceptance and
browser adoption) than `readyState` preloading, but it's definitely clearer
and more semantic than the original version.
If we ended up deciding to go with Nicholas' proposal, I'd at least suggest
that `.execute()` on a not-yet-loaded script should not throw an error, but
should just remove/unset the `preload` flag, such that the script will just
execute as normal when it finishes loading.
Also, I'd like someone (with better knowledge than I, perhaps Henri?) to
consider/comment on the implications of Nicholas' statement that
`.execute()` must be synchronous. I recall from the "async=false"
discussions that there were several wrinkles with injected scripts executing
synchronously (something to do with jQuery and their global Eval). We should
definitely verify that this part of his proposal isn't setting us up for the
same landmines that the "async=false" process had to tip-toe around.
For instance, if I call `.execute()` on a script element that is loaded and
ready, and it's going to execute synchronously, what happens if the script
logic itself calls other synchronous `.execute()` calls? And is the script's
"onload" event (which fires after execution) also synchronous? I can see
this leading to some difficult race conditions relating to how script
loaders have to do "cleanup" (to prevent memory-leaks) by unsetting
properties on script elements, etc.
--Kyle
