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



--Kyle




More information about the whatwg mailing list