- From: Will Alexander <serverherder+whatwg@gmail.com>
- Date: Fri, 11 Feb 2011 12:57:53 -0500
On Feb 11, 2011 10:41 AM, "Nicholas Zakas" <nzakas at yahoo-inc.com> wrote: > > 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? > Early on it seemed there was general consensus that changing the existing MAY fetch-upon-src-assignment to MUST or SHOULD. Since that is only tangential to this proposal, provides immediate benefit to existing code, and can satisfy use cases that do not require strictly synchronous execution. 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 If I am wrong in my assessment of the consensus, does it make sense to consider that change outside of this proposal? > 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? I may have missed it, but what would execute() do if the url has not been loaded? Would it be similar to a synchronous XHR request, lead to ASAP execution, or throw error? > Is there a concrete alternate proposal that's worth building out instead? If execute() must be synchronous, then readystate is not applicable. Otherwise, while it should be considered, it would probably take longer to describe and has no corresponding markup semantics. Glenn's point about noexecute being a natural extension of defer and async is a good one, however neither of those required changing onload semantics or introducing a new event type. Readystate on the other hand is already a well-known concept. Moreover, if history is any indication, we'll continue using it to implement deferred exec for awhile.
Received on Friday, 11 February 2011 09:57:53 UTC