[whatwg] Proposal for separating script downloads and execution

[Alexandre Morgaut]

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