- From: Nicholas Zakas <nzakas@yahoo-inc.com>
- Date: Fri, 11 Feb 2011 14:44:32 -0800
Thanks Kyle, those comments were helpful. I've simplified and refined my proposal based on them and the others in this thread: https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=en&authkey=CJ6z2ZgO Summary of changes: * Changed "noexecute" to "preload" * No HTML markup usage * No change to "load" event * Introduction of "preload" event * Removed mention of "readyState" I'd appreciate hearing feedback on this revision from everyone. -N -----Original Message----- From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Kyle Simpson Sent: Friday, February 11, 2011 3:42 PM To: whatwg at lists.whatwg.org Cc: Will Alexander; Nicholas C. Zakas Subject: Re: [whatwg] Proposal for separating script downloads and execution > We've gone back and forth around implementation specifics, and now I'd > like to get a general feeling on direction. It seems that enough people > understand why a solution like this is important, both on the desktop and > for mobile, so what are the next steps? > > Are there changes I can make to my proposal that would make it easier to > implement and therefore more likely to have someone take a stab at > implementing? Nicholas, if you're sticking with your original proposal of the `noexecute` on script elements, then a mechanism should be specified by which the event can be detected for when the script finishes loading. As stated earlier, `onload` isn't sufficient, since it doesn't fire until after a script has finished (including execution). Are you proposing instead a new event, like "onloadingcomplete" or something of that nature? Otherwise, the next most obvious candidate for an event, using existing precedent, would be the `readyState=loaded`, coupled with that event being fired by `onreadystatechange`, as happens currently in IE (similar to XHR). Once we have some event mechanism to detect when the script finishes loading, then your original proposal breaks down to: 1. Add a `noexecute` property on dynamic script elements, default it to false, let it be settable to true. 2. Add an `execute()` function. For the `noexecute`, We need clearer definition on if this proposal is that it's only a property on dynamic script elements, or is it also a boolean attribute in markup script elements? If the proposal includes the markup attribute, we need clearer definition around the semantics of how that would be used. As stated, <script src="..." noexecute onload="this.execute()"> doesn't work (chicken-and-the-egg), so in place of that, what is a concrete example of how the `noexecute` boolean attribute in markup would be used and useful? The `execute()` function needs further specification as to what happens if execute() is called too early, or on a script that already executed, or on a script that wasn't `noexecute`, as Will pointed out. > Is there a concrete alternate proposal that's worth building out instead? Aside from the event system questions, which is required for either proposal, the "concrete alternate proposal" (from me) is simply: 1. Change the suggestion behavior of preloading before DOM-append to required behavior, modeled as it is implemented in IE. As to whether this one is more "worth building out" than your original proposal, my support arguments are: 1. entirely uses existing precedent, both in wording in the spec and in IE's implementation. 2. requires less new additions (no extra function call), which means less complexity to work through semantics on (see above questions about `execute()` semantics) I haven't heard on this thread any serious discussion of other workable proposals besides those two. Correct me if I'm wrong. > Early on it seemed there was general consensus that changing the existing > MAY fetch-upon-src-assignment to MUST or SHOULD. I'm not sure there's been consensus on this yet, but there's definitely been some strong support by several people. I'd say the two proposals are about even (maybe slightly in favor of `readyState`) in terms of vocalized support thus far. > Since that is only > tangential to this proposal, provides immediate benefit to existing code, > and can satisfy use cases that do not require feature-detection or > strictly > synchronous execution. I'm not sure what you mean by "do not require feature-detection". I think it's clear that both proposals need feature-detection to be useful. In both cases, we're creating opt-in behavior, and you only want to opt-in to that behavior (and, by extension, *not* use some other method/fallback) if the behavior you want exists. If I created several script elements, but don't attach them to the DOM, and I assume (without feature-testing) that they are being fetched, then without this feature they'll never load. So I'd definitely need to feature-test before making that assumption. Conversely, with `noexecute`, I'd definitely want to feature-test that `noexecute` was going to in fact suppress execution, otherwise if I start loading several scripts and they don't enforce execution order (which spec says they shouldn't), then I've got race conditions. > I'm hopeful the change would generate activity around these bug reports. > > https://bugs.webkit.org/show_bug.cgi?id=51650 > https://bugzilla.mozilla.org/show_bug.cgi?id=621553 I think it's a mistake for those two bug reports not to make it clear that an event system for detecting the load is a must. Without the event system, a significant part of this use-case is impossible to achieve. --Kyle
Received on Friday, 11 February 2011 14:44:32 UTC