[whatwg] Proposal for separating script downloads and execution

Tue Feb 8 02:51:06 PST 2011

On Tue, Feb 8, 2011 at 1:28 AM, 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:
>>>>
>>>> <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.

Actually, that depends entirely on what you're putting in the 'onload'
handler. If you're simply waiting for all three scripts to download
and at that point execute all three of them, for example to enable
some feature in the page, then it would degrade just fine in older
browsers. It would just load more slowly.

I don't suspect this is an edge case either, in fact, it's the
original use case we're trying to address here.

Another way to look at it is that

<script src=a.js noexecute onload="this.execute()">

is equivalent to

<script src=a.js async>

which has been deemed to have an acceptable fallback story.

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

That is only the case if there is a readystatechange event. Is that
so? Put it this way, can people solve the use case originally brought
up here in IE9 today, without modifications?

>  * Authors already have to deal with IE, so the question of opting in doesn't arise.

I'm don't understand this.

>  * 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.

There is the risk that you'll tie up a lot of network connections that
won't be used if the <script>s never end up inserted into the DOM.
This doesn't cause site breakage, but performance is also important.

>  * img elements have started fetches upon .src setting since almost forever, so making scripts do the same makes the platform more self-consistent.

I wouldn't call it more consistent. <img> is the only element that
behaves this way. Stylesheets, iframes, plugins and scripts all do
not.

>  * noexecute when used in markup has a particularly bad degradation story.

I'm not convinced that is true. See above.

/ Jonas