[whatwg] Proposal for separating script downloads and

[Boris Zbarsky]

On 2/22/11 8:14 PM, Kyle Simpson wrote:
>> First of all, which two proposals are we talking about here?
>
> 1. Nicholas' proposal, which is currently to "preload" a script if its
> script element is marked with a `preload` attribute, before the setting
> of the `src` property. To "execute" the script, you add the script
> element to the DOM. To detect when the preload finishes, you listen to
> the `onpreload` event.
>
> 2. My proposal, which is (by and large) to standardize the functionality
> that IE already has, and that the spec already suggests, which is that
> preloading happens when setting the `src` property before adding the
> script to the DOM. To "execute", add the script to the DOM. TO detect
> when the preload finishes, listen for the `onreadystatechange` event to
> signal that the `readyState` property is "loaded".

The api of #2 seems somewhat cleaner to me.

#1 seems safer to implement.

I'm not sure which one I prefer...

>> It would certainly make implementing it soon unlikely, if such a beastie
> is needed.
>
> I guess that's the crux of the question. Is such a mechanism needed to
> make either of those two proposals something palatable to a browser like
> Mozilla?

I don't think we'd need anything like this for proposal #1 above.  For 
#2, I'm not sure yet.

>> For some things (e.g. stylesheets and images) browsers don't do this in
>> many cases (and the HTML5 spec in fact requires such behavior). What
>> should the script behavior be?
>
> Let me restate: I'm not purporting to know what the semantics should or
> should not be. I'm suggesting they should be, per browser, exactly the
> same as normal dynamic script loading, in each browser, already behaves.
> In other words, I've been operating under the assumption that neither
> proposal requires explicitly defining or changing the current HTTP
> caching semantics. I'm hoping that if this assumption is wrong, someone
> can help me understand why?

This assumption is not wrong, per se.

> I don't understand why the preloading specifically would imply different
> HTTP caching semantics than normal dynamic script loading?

It doesn't have to.  It's just that if preloading is easy to trigger by 
accident and authors don't notice when they accidentally preload lots of 
stuff then we may have a problem if we don't coalesce identical-object 
(whatever that means) loads.

Normal script loading doesn't have the "don't notice" issue much, 
because a typical script running is noticeable.

-Boris