On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen <hsivo...@iki.fi> wrote:

On Feb 4, 2011, at 03:13, Jonas Sicking wrote:

On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <get...@gmail.com> wrote:
?> 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>

I think this would be a bad solution, because existing browsers wouldn't honor noexecute, so the solution wouldn't degrade gracefully. On the other hand, if the spec required browsers to start fetching external scripts as soon as .src is set on script nodes that aren't in the tree, the degradation behavior wouldn't be a bigger difference that the difference between IE and others today.

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.

Firing a readystatechange event each time readyState changes would be the most natural thing to do. Does IE already do that?

On Feb 4, 2011, at 03:15, Jonas Sicking wrote:

I agree. I don't think that the readyState mechanism is particularly
simpler. Another nice thing about the noexecute design is that it is
purely opt-in, which means that you don't risk poor on already
existing pages.

I think we should do the readyState thing and put a note in the spec saying that implementors should be polite to authors and not implement the readyState property until they also implement the behavior that setting .src on a not-in-tree node starts the HTTP fetch (in order to make the behavior feature detectable from JS).

Adopting the readyState / early .src assignment mechanism has these benefits over the proposed alternative: * Already (reportedly; I didn't test) work in IE. Always a plus over making up some new stuff. * Authors already have to deal with IE, so the question of opting in doesn't arise. * Sites already have to work when scripts haven't been fetched yet and when the scripts are already in the HTTP cache. Thus, starting the fetch earlier than before shouldn't cause breakage since the "worst" case is that the observable behavior becomes similar to the script already being in cache by the time the node is attached to the tree. * img elements have started fetches upon .src setting since almost forever, so making scripts do the same makes the platform more self-consistent. * noexecute when used in markup has a particularly bad degradation story.

I agree with Henri's analysis. Opera already has readyState (with value always being 'loaded'), but we'd be careful to fix script prefetching and readyState 'uninitialized' at the same time.

--
Simon Pieters
Opera Software

Reply via email to