[whatwg] Proposal for separating script downloads and execution

Kyle Simpson getify at gmail.com
Mon Feb 14 07:55:48 PST 2011

> You may be correct in that people may never want to set preload to false. 
> You'll note that I put in my proposal that an alternate approach would be 
> for preload to be set to true by default.

Since your proposal also says that setting `preload` to `false` wouldn't do 
anything except not *require* the preload (in other words, it wouldn't 
strictly prevent the preload), then what would be the use of someone being 
able to set it to `false`? In other words, what's the benefit of being able 
to tell the browser, "Preloading is not required, but you can still preload 
if you want to?" That seems basically like a moot no-op.

If preload is going to default to `true`, and setting it to `false` is 
really a moot functionality, we're almost back to my core proposal, except 
for the fact that having an explicit `preload` property gives an admittedly 
nicer feature-detect.

> This would allow even easier feature detection...

Honestly, whether `preload` defaults to `false` or `true`, your 
feature-detect for your proposal can be more simplified (no use of `typeof`) 
like this:

if (script.preload === true)  /* or */  if (script.preload === false)

> I think changing the behavior of dynamic script elements to match IE's isn't 
> a bad idea, but...

Nicholas, I would still like to hear your thoughts/response on the core 
reason I'm pushing to **identically** match IE: that if we specify something 
that IE will have to change about their implementation, we're automatically 
pushing out the time-frame of when we might possibly get to full-compat on 
this issue, from say 4-8 months (reasonable for all other browsers to 
respond) to 1-2 years (the typical release-cycle for IE).

I have conceded that your v2.1 proposal is both more semantic and has a 
better feature-detect than my proposal. BUT, as is often the case, the 
pragmatics of how we can achieve full-compat sometimes outweigh the benefits 
of holding out for the more "correct" solution.

Given the convergence of proposals, with that point being really the last 
major sticking point, I think it's time to start talking in terms of the 
pragmatics. I believe this is a case where the pragmatics of existing 
implementation and spec wording have greater influence than the desire to 
create new precedent for the sake of correctness.


More information about the whatwg mailing list