[whatwg] Proposal for separating script downloads and execution

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

Received on Thursday, 3 February 2011 21:29:54 UTC