[whatwg] Proposal for separating script downloads and execution

Diego Perini diego.perini at gmail.com
Wed Feb 9 10:35:11 PST 2011

On Wed, Feb 9, 2011 at 6:57 PM, Alexandre Morgaut
<Alexandre.Morgaut at 4d.com> wrote:
> On Feb 9, 2011, at 4:40 PM, Nicholas Zakas wrote:
> I had chatted with a few folks about using rel=prefetch, but there seems to be a lot of issues that would have to be resolved to get the behavior I'm after. Prefetching in this way is very passive, currently implemented as happening during user idle time, which is unpredictable (not to mention the issues Glen mentioned below).
> I think you guys are perfectly right as "prefetch" is not meant to say that the interface will need the resource ASAP
> I think Glen summed this up correct by saying that prefetching is a hint, and when you want to load a script you want it to happen. This isn't to say that you wouldn't want to prefetch a script, but I see that as more of a way to help the next page you'll navigate to by priming the cache vs. helping the currently loaded page.
> Good point
> In any event, it seems that rel=prefetch would have to change a lot vs. the changes to the script element to allow the same behavior.
> Surely, if starting from the specific "prefetch" behavior
> I still think that using a more declarative way to define required HTTP resources would be a gain and may work in your case
> The link type list is rich:
> - http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes
> Adding a "required" relationShip could be more appropriate way
> <link id="someScript" rel="required" type="text/javascript" src="someData.js">
> <link id="someData" rel="required" type="application/json" src="someData.json">
> <link id="aTemplate" rel="required" type="text/html" src="myTemplate.html">
> This would still need:
> - a "content" property on HTML link elements (which may be also useful to access raw CSS definition)
> Binding an execute(), run() or eval() method on link elements may be more discussable but it doesn't hurt me that much
> This way, pre-parsing Script resources would be still possible

Completely agree, your proposal seems better, probably easier to
implement and seem less prone to backward compatibility issues to me.

I believe it would be better to leave out the script tag and try to
obtain the same benefits by defining the correct "rel" on link

Having script access to the content of the HTTP resource is what is
really missing and seems to me would cover most of the presented

Maybe not completely related to script loading, but bubbling all
"load" events up to the document like Opera does would also help
authors in determining the correct timings (when to execute/use the
resource once it is fully loaded).


More information about the whatwg mailing list