[whatwg] Proposal for separating script downloads and execution

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-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Will Alexander
Sent: Thursday, February 03, 2011 11:58 PM
To: Jonas Sicking
Cc: whatwg at 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

Received on Monday, 7 February 2011 11:40:50 UTC