[whatwg] Proposal for separating script downloads and execution
Glenn Maynard
glenn at zewt.org
Wed Mar 2 11:21:46 PST 2011
On Wed, Mar 2, 2011 at 1:21 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> After chatting a bit with Boris, it seems important for implementation that
> a <script> node is already in the DOM before download begins. Given that, it
> seems like this proposal is closest to being implementable:
>
>
> https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=en&authkey=CJ6z2ZgO
>
> One of the suggested alterations was to replace execute() with simply
> setting preload back to false. The reason I like execute() better is that it
> provides the opportunity for feedback in the form of a return value (false
> if code was not executed, and true if code was executed).
>
That's true if execute() is synchronous. The attribute-based approach is
asynchronous. There's not much feedback an asynchronous execute() can give,
since the code won't actually be executed during execute(). (If you want to
know whether the script has been executed, a readonly attribute could be
exposed which returns "already-started && !pending-execution".)
The attribute-based version is very lightweight; there are more details that
need to be worked out for a synchronous version and nobody's tried to
express it in spec terms yet (which would help nail down precisely what
it'll do). I don't mind trying to hammer those out if we think it's worth
it; the attribute approach is specifically if we go in the asynchronous
direction.
--
Glenn Maynard
More information about the whatwg
mailing list