[whatwg] Proposal for separating script downloads and execution
Simon Pieters
simonp at opera.com
Tue Feb 8 02:31:17 PST 2011
On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
>
>> On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <getify at gmail.com> wrote:
>>> ?> One reason I like the noexecute proposal more than relying on
>>>>
>>>> readyState is that noexecute can be used in markup. I.e. you can do
>>>> things like:
>>>>
>>>> <html>
>>>> <head>
>>>> <script src=a.js noexecute onload="...">
>>>> <script src=b.js noexecute onload="...">
>>>> <script src=c.js noexecute onload="...">
>>>> </head>
>
> I think this would be a bad solution, because existing browsers wouldn't
> honor noexecute, so the solution wouldn't degrade gracefully. On the
> other hand, if the spec required browsers to start fetching external
> scripts as soon as .src is set on script nodes that aren't in the tree,
> the degradation behavior wouldn't be a bigger difference that the
> difference between IE and others today.
>
>> Sure, but we'd also want to fire some event once the script has been
>> fully downloaded so that the page doesn't have to use a timer and poll
>> to figure out when the download is done.
>
> Firing a readystatechange event each time readyState changes would be
> the most natural thing to do. Does IE already do that?
>
> On Feb 4, 2011, at 03:15, Jonas Sicking wrote:
>
>> I agree. I don't think that the readyState mechanism is particularly
>> simpler. Another nice thing about the noexecute design is that it is
>> purely opt-in, which means that you don't risk poor on already
>> existing pages.
>
> I think we should do the readyState thing and put a note in the spec
> saying that implementors should be polite to authors and not implement
> the readyState property until they also implement the behavior that
> setting .src on a not-in-tree node starts the HTTP fetch (in order to
> make the behavior feature detectable from JS).
>
> Adopting the readyState / early .src assignment mechanism has these
> benefits over the proposed alternative:
> * Already (reportedly; I didn't test) work in IE. Always a plus over
> making up some new stuff.
> * Authors already have to deal with IE, so the question of opting in
> doesn't arise.
> * Sites already have to work when scripts haven't been fetched yet and
> when the scripts are already in the HTTP cache. Thus, starting the fetch
> earlier than before shouldn't cause breakage since the "worst" case is
> that the observable behavior becomes similar to the script already being
> in cache by the time the node is attached to the tree.
> * img elements have started fetches upon .src setting since almost
> forever, so making scripts do the same makes the platform more
> self-consistent.
> * noexecute when used in markup has a particularly bad degradation
> story.
I agree with Henri's analysis. Opera already has readyState (with value
always being 'loaded'), but we'd be careful to fix script prefetching and
readyState 'uninitialized' at the same time.
--
Simon Pieters
Opera Software
More information about the whatwg
mailing list