[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I had thought a bit about a new rel for <link>s, but always got caught up on the execute() method and how inappropriate it was for any other content types. It seemed weird to be able to call such a method on <link> to execute a script when <script>'s sole job is to execute scripts. If <link> then becomes capable of executing scripts, do we need <script>? 

If you can't get agreement to add a method on <link>, then we're back to possibly having a double-download situation, where you include the script via <link> and then need to create a dynamic <script> node to point to the same URL.

In the end it seemed that keeping <script> as the sole executor of scripts would be more likely agreed upon than augmenting <link> to do the same. It still seems like there would be more changes necessary for a <link> approach than a <script> approach, and I'm not sure it addresses backwards compatibility any better.

Once again, I expect the common case to be the script loader case, where <script> elements are created using JavaScript. In that case, there is zero impact on backwards compatibility when feature testing is used. The only backwards compatibility issue is when you use noexecute in markup, but a similar issue would occur using <link> in that case.

-N


-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Diego Perini
Sent: Wednesday, February 09, 2011 1:35 PM
To: Alexandre Morgaut
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

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

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

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

--
Diego