Re: [whatwg] as a dedicated tag
On Wed, 2011-02-23 at 11:12 -0800, Tab Atkins Jr. wrote: > > """ > I have untrusted markup from a third party which I would like to > safely insert into my page, knowing that the rest of my page is safe > from whatever the untrusted markup is doing. Also, the untrusted > markup may be doing expensive things, particularly on load, so I'd > like to wait until after the rest of the page is loaded before loading > the markup. > """ > > Is this accurate? Correct me if not, but I'll assume it is for now. In many cases the code itself is considered trustworthy, but the ad server's performance suspect. In that case, asynchronous execution of the script is desired. Unfortunately, as the original email points out, the use of document.write() prevents this. Especially for ads, there are considerable advantages to using iframes; however, fully-privileged scripts have advantages too. Despite a decade of warning/ridiculing authors, document.write()'s continued prevalence seems to be evidence of the fact that it is the only mechanism to address a common problem: Where in the document should a script place the content it generates? A patch to Gecko [1] , originally discussed on the list last August [2], seems to address this.It adds a `currentScript` property which references (surprise) the currently executing script. When a script can reliably find itself, authors can use the current semantics of "put this script wherever you want the widget to go," asynchronously if they so choose. The proposal seems to have been stalled by the specifics of some additional compilation events that were also included. Beyond the Gecko patch, I'm not sure where adoption stands. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=587931 [2] http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23015.html > Will
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 6:35 PM, Boris Zbarsky wrote: > >> >> Would a means by which authors can mark a pre-fetched script as >> "stale" allay some of your concerns? > > I wouldn't expect anyone to actually use such a means. Understandable. I ask because at one point you stated if DOM attachment triggers the pre-load (instead of src assignment), that would address the memory consumption. It would seem that would require devs "clean up" after themselves too. Given you don't sound thrilled with some of the concessions required for Images, it sounds like you're more concerned with the consequences of pre-loading in general, not the specifics of an interface. Is that accurate? Will
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 4:13 PM, Boris Zbarsky wrote: > Uh... In that situation I would expect the event handler to > keep the script alive until the load finishes. > Anything else is just a bug that exposes GC timing to the web page. Yes, quite strange. It's fixed in IE9 (at least my test no longer fails) so clearly considered a bug. > IE shows ... bad memory behavior To your original point, Boris, if there's no way to reclaim the memory for a pre-fetched script _until_ its executed, then even legitimate use-cases (e.g. pre-fetching auto-completion data) by "responsible" authors would be of concern. Would a means by which authors can mark a pre-fetched script as "stale" allay some of your concerns? Is there some way to accomplish this in Gecko now for a pre-fetched Image?
Re: [whatwg] Proposal for separating script downloads and execution
> On Thu, 2011-02-17 at 15:24 -0500, Boris Zbarsky wrote: > > 1) If your script is no-cache, or max-age:0, does IE make a new > request for it for every
Re: [whatwg] Proposal for separating script downloads and execution
On Feb 15, 2011 6:34 PM, "Nicholas Zakas" wrote: > > 1) Should the default behavior for dynamic script nodes be to start downloading the file upon the setting of src and only execute when added to the document (IE's behavior) or not? Could the default behavior be defined by the user-agent and the value of this property reflect that? So in IE the def value would be true, but false in other browsers. > 2) Can the proposals on the table be used to better detect the correct behavior from #1? > 3) Are the proposals close to being feasible with, perhaps, some changes? Or are they completely outlandish and have no possibility of reaching implementation? In this bug report Boris Zbarsky expresses concern that prefetching without creating memory leaks is difficult. https://bugzilla.mozilla.org/show_bug.cgi?id=621553 >
Re: [whatwg] Proposal for separating script downloads and execution
While they are converging, I think the first proposal is simpler,
defines a much more generic interface with applicability beyond script
elements, provides a mechanism for opting into or out of the behavior,
and will lead to cleaner javascript and, unlike readyState, does not
introduce compatibility issues.
Although I'm not aware of anyone wrapping a 250KB style-sheet in
comments, the pre-loading interface could seemingly be applied to any
number of elements. Nicholas' original e-mail referenced a blog post
by Stoyan Stefanov which details a way to pre-fetch both scripts and
stylesheets.
Requiring authors opt-into the behavior seems best at least in the
short term and readyState does not provide this mechanism. Making RPC
or Ad calls can require disabling this functionality in IE and create
quite a kluge. (1)
The pre-load proposal will encourage separating that logic into (at
least) two functions, leading to javascript that is easier to manage
and more clearly communicates its intent. OTOH, with readystate, the
tendency will be to add logic for both "preload" and "onload" into a
single handler, despite the fact they completely different reasons to
change. While certainly not the spec's problem, **anything** that
leads to better ES is a win.
Most concerning, however, is that adopting readyState will undoubtedly
create compatibility issues. It's quite common to registerfor both
onload and onreadystatechange, testing for the readyState property
within the handler. Code like this will execute callback() twice.
script.onload= script.onreadystatechange= function(){
if(
this.readyState &&
this.readyState != 'loaded' &&
this.readyState != 'complete'
) return;
callback();
}
If the spec decides to deviate from IE's behavior (2), and requires
readyState transition to both loaded and complete, it could fire three
times. Specifying IE's behavior (which most will admit seems
non-intuitive) would also seem to be difficult. Even though there is
an existing precedent in the spec and something of a "reference"
implementation, dragons lurk.
Will
(1) I do think it's wise to give user-agents the latitude to decide
the default behavior that works best for their audience. Instead of
defining the default value for preload, should the value reflect
agent-specific default? IOW, if IE implements this, should its
default preload value be "true"?
(2) A cached script will have its readyState set to "loaded" when the
src attribute is assigned, but will not fire the readystatechange
event. Attaching the script triggers synchronous execution, fires
readystatechange, but does NOT set the readystate to "complete".
On Sun, Feb 13, 2011 at 6:44 PM, Kyle Simpson wrote:
> I've compiled a WHATWG Wiki page detailing both Nicholas' most recent (and
> simplified) proposal (v2.1), as well as mine:
>
> http://wiki.whatwg.org/wiki/Script_Execution_Order_Control
>
Re: [whatwg] Proposal for separating script downloads and execution
On Feb 11, 2011 5:00 PM, "Nicholas Zakas" wrote: > > Once again, the problem with changing how src works is that there's no way to feature detect this change. It's completely opaque to developers and therefore not helpful in solving the problem. > I completely agree with what you're saying as it relates to *this* feature. My only point is, even absent feature testing, readystate,or an ondownload event, this behavior is useful and benefits existing code. Execution order mgmt is one example. Many of these loaders create and then queue the script elements, using onload chaining to manage their attachment. Without the use of any prefetching hacks, scripts will load in parallel in IE. This is because IE implements the specs current performance suggestion, *not* because it also provides a readystate. The loader does not need to know whether a script is in cache before attaching, it only needs to know the prerequisite libs have been loaded. There are a number of add'l use-cases that do not require that prefetching or ondownload be either available or implemented. Browsers that prefetch simply perform better than those that do not. Many authors are willing to accept this tradeoff, and more will be prone to do so if this achieves wider adoption. We have it for Image's, so why not scripts? > will throw an error. I don't think its a stretch to see how an error might not always be "appropriate". For many of those, however, opaque pre fetching would be perfectly acceptable. Consider the controljs example in which the menu code does not load until it is clicked. There's no requirement that it run synchronously so it is acceptable for the script's execution to simply be scheduled in response to the click event. A non-prefetching browser would not be as "performant" but would still work. > > As I said before, I'm not married to all bits of this proposal. If there's some other way to achieve the same functionality, I'm all for it. The main goals are listed in the doc, and I'm happy to support any proposal that achieves all of them. > Just to reiterate, prefetching alone is clearly not the solution to your problem statement. I failed to make that clear before. My point is only that it is useful, does not require readystate to be so and it seems like an easy change to the spec. It also belongs in a separate discussion. I should not have clouded this thread with more slightly-related-but-mostly-off-topic fud. > -N > > > -----Original Message- > From: whatwg-boun...@lists.whatwg.org [mailto: whatwg-boun...@lists.whatwg.org] On Behalf Of Will Alexander > Sent: Friday, February 11, 2011 12:58 PM > To: whatwg@lists.whatwg.org > Subject: Re: [whatwg] Proposal for separating script downloads and execution > > On Feb 11, 2011 10:41 AM, "Nicholas Zakas" 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.
Re: [whatwg] Proposal for separating script downloads and execution
On Feb 11, 2011 10:41 AM, "Nicholas Zakas" 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.
Re: [whatwg] Proposal for separating script downloads and execution
On Feb 11, 2011 12:31 PM, "Will Alexander" wrote: > > > On Feb 11, 2011 10:41 AM, "Nicholas Zakas" 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 feature-detection or strictly synchronous execution. 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 always 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.
Re: [whatwg] Proposal for separating script downloads and execution
>> Doesn't mostly address the use-case of >> load-but-don't-execute in markup? The reason script-inserted script elements >> need this capability is more advanced than any use-case for why you'd do so >> in markup. In other words, I can't imagine that a script loader would rely >> on adding script tags through markup (like with document.write() I guess?) >> rather than just using dynamic script elements. >> Technically, the "preloading" event mechanism isn't strictly >> necessary, but it's quite useful for several things you can't do without it, >> and so I really don't think it's worth adjusting the spec without also >> adding that part in. > > I'm not quite sure I follow you here. I would humbly submit that being able to query the status of a script, while useful, is not necessary. Fetching the src immediately upon assignment is entirely sufficient. The readyState, while nice to have, is not germane to the goals of this proposal. When would the executor need to know ahead of time that the script will run synchronously? > What I was thinking was that we > say that implementations MUST (in the rfc 2119 sense) start loading > the script immediately. > The proposal's stated reason for not making this mandatory seems sensible. While there may be a high degree of probability, there is no guarantee the script will actually be used. It would seem to me that it makes more sense to leave this decision up to the browser, allowing it to adapt its pre-fetching behavior (perhaps based on available bandwidth) if it chooses. Perhaps SHOULD conveys a more appropriate level of requirement? > > Sure, but we'd also want to fire some event once the script has been > fully downloaded so that the page doesn't have to use a timer and poll > to figure out when the download is done. IE will set the readyState property to "loading" but only when the script has a document ancestor, otherwise the value is "uninitialized" If the value were always set to "loading" to indicate pre-fetching is being performed would that provide an appropriate level of feature detection? (IE currently will set the readyState to "loaded" once the download has finished in either case) Will
