?
I don't think readyState as Kyle describes is an appropriate candidate
mechanism because it's not an actual indicator that the functionality
exists. The only thing you can really be sure of if readyState is
"uninitialized" is that the script element supports readyState. The fact
the only browser supporting this presently is the same one that supports
the desired behavior is a happy coincidence.
You are correct, it a little bit of a weak feature-test (compared to other
alternatives). But then again, consider something like the `defer` property
(which not all browsers currently support yet). Since `defer` is clearly
spelled out in the spec, we have to hope that any browser which does not
currently support `defer`, when they decide to add `defer`, that they will
add it correctly based on how the spec says it should work. If a browser
chose to implement a feature (like `defer`) in direct willful violation of
the spec in a way that broke feature-detection, this would be a quite
unfortunate situation and the community could rightly cry out to that
browser to come back into alignment with the spec and the norm.
The same would be true of my proposal of feature-testing `readyState` (and
its initial value) on the script element. Since FF and Webkit do not
currently have a `readyState` property on the script element, if we were to
amend the spec now to say that a `readyState` property must be added to
indicate the progress of the "preloading" (implying of course that the
preloading itself must also be implemented), then we could also somewhat
confidently assume that FF and Webkit would follow the spec's instructions
for the functionality when/if they decide to add a `readyState` property
down the road.
Is this a perfect guarantee? Absolutely not. But it's definitely within
reason for advocacy and evangelism to the browser vendors that they properly
implement atomic/related chunks of the spec and not pick-and-choose pieces
or make willful violations of critical aspects. I'm not saying that problems
couldn't arise, I'm just saying that the general likelihood is that browser
vendors would implement things the way the spec says to, and the
feature-test I propose would be viable.
So... "happy coincidence"? Yes. But if the spec acts quickly enough before
any other browsers implement `readyState` in an incompatible way (that is,
without the attached preloading behavior we're discussing), then there's a
decent and clear path forward which will allow the feature-test to be
reliable. And that "happy coincidence" may just be our saving grace.
The only wrinkle is Opera, which has a `readyState` property on the script
tag already, but it's non-functioning. The other "happy coincidence" is that
Opera at least has a different default value than IE (and what is being
proposed), so the pragmatic feature-test including not only the presence of
the `readyState` property but also its initial value is still viable. Again,
we would have to hope/assume that Opera would not act contrary to the spec
to change the behavior/default-value of its `readyState` until such a time
as they were prepared to implement the whole atomic changeset of
functionality being discussed in this thread. If the spec is clear and
unambiguous in that regard, this is perfectly reasonable to request and
expect of all the browser vendors.
-----------
Just to reiterate, it's not that I'm "against" the "noexecute" proposal
Nicholas put forth. It's just that this "readyState preloading"
functionality is already implemented as we want it to be in one browser, AND
it's already a suggestion in the spec, so the path to getting it fully
adopted as a spec requirement, and evangelizing it to other browser vendors,
is cleaner and simpler than starting from scratch across the board.
More than anything, I support the "readyState" concept out of a pragmatic
desire to see *something* reasonable and workable for this use-case that is
feasible to be adopted sooner rather than much later. And the path of least
resistance is usually the best path to take on such matters.
--Kyle
