- From: Nicholas Zakas <nzakas@yahoo-inc.com>
- Date: Wed, 23 Feb 2011 14:43:38 -0800
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@lists.whatwg.org [mailto:whatwg-bounces@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
Received on Wednesday, 23 February 2011 14:43:38 UTC