[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

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

I'd like to know if anyone has further suggestions for how to improve this proposal.

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Nicholas Zakas
Sent: Wednesday, February 23, 2011 2:44 PM
To: Boris Zbarsky; Jorge
Cc: whatwg at lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution

Sorry, I've been traveling and out of the loop for a bit. Just catching up on the thread.

One thing I want to throw out there: the proposals I put together were intended to start a discussion, not to end it. If there are parts that could be changed to make implementation easier, then let's make those changes. In my experience, things don't move until someone makes a concrete proposal that people can poke holes in. :)

It seems like the conversation has turned back to my original proposal, or at the very least, version 2: https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=en&authkey=CJ6z2ZgO

So to answer some of the questions brought up:

1) If execute() is called before the script is fully loaded, it should throw a ReferenceError. Part of the rationale for having readyState was so you could determine if the script was ready for execute() to be called. That purpose can also be served via onload and onerror.

2) Any attempt to set the text property on a dynamic script element already marked with preload is ignored. If the preload property is set to true after the text property is set to a value, then the preload property is ignored and remains false.

3) If cloneNode() is called on a script marked as preload, then the cloned script node cannot be executed. Any call to execute() will return false and do nothing.

I'm much more a fan of v2.1, as I think it decreases the surface area of changes and eliminates some of these edge cases. It also allows vendors to determine what the default behavior should be while allowing developers to accurately feature detect that decision.

So question is: what are the changes that can be made to one of these proposals that would make people feel comfortable implementing?

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Boris Zbarsky
Sent: Wednesday, February 23, 2011 6:18 AM
To: Jorge
Cc: whatwg at lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On 2/23/11 4:16 AM, Jorge wrote:
> Wouldn't this :
>
> HTMLScriptElement.prototype.execute= function execute () {
>    // ...
>    return (1, eval)( this.innerText ); // global eval
> }
>
> do it ?

No.  First of all, the script can be an external script, so innerText 
doesn't do the right thing.

> (only that it should be "privileged": able to bypass the usual s.o.p. restrictions wrt .innerText...)

That's the thing.  The privileged bit involves things that make it very 
difficult to transport exceptions across it correctly, especially if the 
caller of execute() is not in the same window as the script itself.  At 
least in Gecko.

-Boris