Knowing whether or not a script will run synchronously is key to the user experience. As soon as the script starts to run, the UI is frozen, so being able to determine when that script will run is incredibly important.
In any event, it seems like no one disagrees that the end goal would be useful. How can we continue with a productive conversation to get to a resolution? -N -----Original Message----- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Will Alexander Sent: Thursday, February 03, 2011 11:58 PM To: Jonas Sicking Cc: whatwg@lists.whatwg.org; Kyle Simpson Subject: Re: [whatwg] Proposal for separating script downloads and execution >> Doesn't <link rel=prefetch> mostly address the use-case of >> load-but-don't-execute in markup? The reason script-inserted script elements >> need this capability is more advanced than any use-case for why you'd do so >> in markup. In other words, I can't imagine that a script loader would rely >> on adding script tags through markup (like with document.write() I guess?) >> rather than just using dynamic script elements. >> 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. I would humbly submit that being able to query the status of a script, while useful, is not necessary. Fetching the src immediately upon assignment is entirely sufficient. The readyState, while nice to have, is not germane to the goals of this proposal. When would the executor need to know ahead of time that the script will run synchronously? > What I was thinking was that we > say that implementations MUST (in the rfc 2119 sense) start loading > the script immediately. > The proposal's stated reason for not making this mandatory seems sensible. While there may be a high degree of probability, there is no guarantee the script will actually be used. It would seem to me that it makes more sense to leave this decision up to the browser, allowing it to adapt its pre-fetching behavior (perhaps based on available bandwidth) if it chooses. Perhaps SHOULD conveys a more appropriate level of requirement? > > 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. IE will set the readyState property to "loading" but only when the script has a document ancestor, otherwise the value is "uninitialized" If the value were always set to "loading" to indicate pre-fetching is being performed would that provide an appropriate level of feature detection? (IE currently will set the readyState to "loaded" once the download has finished in either case) Will
