[whatwg] Proposal for separating script downloads and execution
simonp at opera.com
Tue Feb 8 02:31:17 PST 2011
On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
>> On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <getify at 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:
>>>> <script src=a.js noexecute onload="...">
>>>> <script src=b.js noexecute onload="...">
>>>> <script src=c.js noexecute onload="...">
> 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
> * noexecute when used in markup has a particularly bad degradation
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.
More information about the whatwg