I think there's a valid use case for downloading a script and not
evaluating it immediately.
I think we all agree on that.
Boris-
I wish that were true, at this point, but I'm not sure that it is. The tone
I got from Ian's post (and even subsequent replies) was that he in fact does
not see t
If browsers processed (parsed & compiled) scripts in a background thread
it would mitigate the problem, but not solve it. Suppose I have 100K of
JS I need right now to generate the DOM for the initial page, and I have
another 500K of JS that's only needed if the user clicks on FeatureX.
Assuming
This isn't practical if the contents of the
Sorry for repetition, but we can already preload images and CSS and apply
them to the page at an arbitrary point in time. Why wouldn't we want the
same thing for JavaScript?
I think the question is whether you want _more_ than that for JavaScript.
For images, you can preload them and choose wh
[Apologies for being out of the loop on this thread thus far, as I was one
of the main proponents of it earlier this year. I am now going to dive in
and offer some feedback, both to Ian's comments as well as to others that
have replied. I also apologize that this will be an exceedingly long mess
On 5/27/11 1:10 PM, Aryeh Gregor wrote:
Also, consider a third possibility: currently, the part of
On Thu, May 26, 2011 at 7:04 PM, James Robinson wrote:
> This isn't practical if the contents of the
On Thu, May 26, 2011 at 3:49 PM, Aryeh Gregor wrote:
> On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas
> wrote:
> > I'm a little surprised that this conversation has swooped back around to
> performance and whether or not there's a valid use case here. In addition to
> standalone solutions like
On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas wrote:
> I'm a little surprised that this conversation has swooped back around to
> performance and whether or not there's a valid use case here. In addition to
> standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla and
> Chr
On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas wrote:
> I'm a little surprised that this conversation has swooped back around to
> performance and whether or not there's a valid use case here.
Stopping and reevaluating periodically is a good idea, when proposing
added complexity to the platfor
On 5/26/11 11:56 AM, Nicholas Zakas wrote:
Sorry for repetition, but we can already preload images and CSS and apply them
to the page at an arbitrary point in time. Why wouldn't we want the same thing
for JavaScript?
I think the question is whether you want _more_ than that for JavaScript.
F
Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Ian Hickson
Sent: Thursday, May 26, 2011 12:43 AM
To: Boris Zbarsky
Cc: whatwg; James Robinson
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Thu, 26 May 2011, Boris
On Thu, 26 May 2011, Boris Zbarsky wrote:
> On 5/26/11 1:10 AM, Ian Hickson wrote:
> > It's presumably a whole heck of a lot more complex than brack matching:
> >
> > alert('fail');
> > function test () {
> > // ...megabytes of perfectly fine code...
> > a b;
> > }
> >
> >
On 5/26/11 3:12 AM, James Robinson wrote:
I think there's a valid use case for downloading a script and not
evaluating it immediately.
I think we all agree on that.
The point I was getting at in IRC was that
there is a lot of confusion about what parsing and executing mean in
modern js engine
I think there's a valid use case for downloading a script and not evaluating
it immediately. The point I was getting at in IRC was that there is a lot of
confusion about what parsing and executing mean in modern js engines and I
didn't see much careful measurement in the thread.
- James
On May 25,
On 5/26/11 1:10 AM, Ian Hickson wrote:
It's presumably a whole heck of a lot more complex than brack matching:
alert('fail');
function test () {
// ...megabytes of perfectly fine code...
a b;
}
...had better not alert anything.
And in V8 does not, indeed.
What we rea
On Wed, 25 May 2011, Aryeh Gregor wrote:
>
> # [02:21] the only thing we do on a chunk of script in v8
> currently before starting to execute code is to essentially brace
> match
It's presumably a whole heck of a lot more complex than brack matching:
alert('fail');
function test () {
On 5/25/11 8:44 PM, Aryeh Gregor wrote:
I just discussed this on IRC with jamesr, of the Chrome team:
http://krijnhoetmer.nl/irc-logs/whatwg/20110526#l-97
According to him, the parsing and compilation time of JavaScript can't
be usefully separated from the execution.
That sounds like a V8 imp
On 5/25/11 8:05 PM, Aryeh Gregor wrote:
What do you mean by "execution" here? If the script is already
compiled, and you write it so that all it does is define a function,
then executing it should not take any measurable amount of time
(<1ms). Currently this might not be observable, since if I
On Wed, May 25, 2011 at 8:44 PM, Aryeh Gregor wrote:
> As far as I understand it now, the actual problem here is that we want
> to be able to separate download and execution, not parsing and
> execution.
I think part of the confusion is that most of us think of "parsing" in C
terms: a compiler t
On Wed, May 25, 2011 at 8:44 PM, Aryeh Gregor wrote:
> As far as I understand it now, the actual problem here is that we want
> to be able to separate download and execution, not parsing and
> execution. But you can already do that by putting the whole script in
> a comment, for instance, as Gmai
On Wed, May 25, 2011 at 8:05 PM, Aryeh Gregor wrote:
> There's a big conceptual difference between parsing the script and
> executing it. We need to be careful not to conflate the two, even if
> browsers don't *currently* separate them.
I just discussed this on IRC with jamesr, of the Chrome tea
On Tue, May 24, 2011 at 12:34 PM, Nicholas Zakas wrote:
> Moving parsing and compilation to a background thread solves part of the
> problem, the problem where doing so freezes the UI currently. It doesn't
> solve what I consider to be the important part of the problem, and that is
> the inabil
2011/5/25 Nicholas Zakas :
> I already explained that in my previous email. Parsing and compilation on
a background thread removes some of the problem but not all of it.
Ultimately, even if the script is just a function waiting to be called, the
browser still executes it in a blocking fashion after
mailto:kor...@geekhood.net]
Sent: Tuesday, May 24, 2011 2:33 PM
To: whatwg@lists.whatwg.org
Cc: Nicholas Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Tue, 24 May 2011 17:34:45 +0100, Nicholas Zakas
wrote:
> Your assertion that loading a file that simply defines a
In many (all?) cases below the term "execution" is meant to include
parsing and compilation. I know that's what Nicholas and Kyle have in
mind, and is the motivation behind Gmail's comment hack and my ControlJS
library.
If browsers processed (parsed & compiled) scripts in a background thread
On Tue, 24 May 2011 17:34:45 +0100, Nicholas Zakas
wrote:
Your assertion that loading a file that simply defines a function will
solve the problem is a bit too simplistic for most web applications.
Could you describe the case where wrapping script in a function would not
solve the proble
y, May 23, 2011 6:36 PM
To: wha...@whatwg.org
Subject: [whatwg] Proposal for separating script downloads and execution
This thread was rather light on use cases and heavy on conjecture and
proposals. To make sure that we don't add features that are not actually
necessary, I have reordered thi
Hi Ian,
Thank you for all the time you're spent reading this thread.
My understanding right now is that:
- if we want a script to be downloaded without blocking the UI, we should use
"async"
- implementors shouldn't block the UI while parsing the JS (but it should
still respect the order of e
This thread was rather light on use cases and heavy on conjecture and
proposals. To make sure that we don't add features that are not actually
necessary, I have reordered this thread to go through the use cases first,
and to then only consider proposals based on how they address those use
case
On Fri, Mar 4, 2011 at 3:04 PM, Kyle Simpson wrote:
> Can someone double-check that onreadystatechange does not actually work for
>> this in IE9 in standards mode? IE9 seems to no longer fire
>> onreadystatechange when the script is not in the document. (onerror is,
>> though, which I think is
Can someone double-check that onreadystatechange does not actually work
for
this in IE9 in standards mode? IE9 seems to no longer fire
onreadystatechange when the script is not in the document. (onerror is,
though, which I think is a spec violation.)
http://zewt.org/~glenn/test-script-preload
On Fri, Mar 4, 2011 at 12:49 PM, Nicholas Zakas wrote:
> Okay, so it sounds like everyone is really much more in favor of an
> approach that doesn't require execute() to run the code that was preloaded.
I'm not against execute() as such for a synchronous API, I just don't think
it's necessary fo
hatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On 3/3/11 5:20 AM, Henri Sivonen wrote:
> Are there the known to be pages that users frequently encounter that create
> and set src on a large number of script nodes without inserting them?
N
It seems like IE9 only fires onreadystatechange on scripts which aren't in
the document when in quirks mode. If the HTML5 doctype is present, it'll
still load scripts before inserting them into the document, but
onreadystatechange doesn't seem to be fired. Can someone confirm?
--
Glenn Maynard
So, I'm just curious, what do the participants of this thread (and Ian,
specifically) feel is the most productive next step? We have 3 or 4
proposals that have all garnered various support. We've had at least one
browser-developer informing us on concerns with various aspects of each.
As with al
On Thu, 3 Mar 2011, Kyle Simpson wrote:
>
> So, I'm just curious, what do the participants of this thread (and Ian,
> specifically) feel is the most productive next step? We have 3 or 4
> proposals that have all garnered various support. We've had at least one
> browser-developer informing us on
So, I'm just curious, what do the participants of this thread (and Ian,
specifically) feel is the most productive next step? We have 3 or 4
proposals that have all garnered various support. We've had at least one
browser-developer informing us on concerns with various aspects of each.
I have,
On 3/3/11 5:20 AM, Henri Sivonen wrote:
Are there the known to be pages that users frequently encounter that create and
set src on a large number of script nodes without inserting them?
Not known to me, no. I've seen pages that create lots of scripts (one
per each dynamic action they want to
Boris Zbarsky wrote:
> Think 10,000
On Wed, Mar 2, 2011 at 1:21 PM, Nicholas Zakas wrote:
> After chatting a bit with Boris, it seems important for implementation that
> a
After chatting a bit with Boris, it seems important for implementation that a
I'm sorry, but I'm running out of time and energy for this thread, so
I'm replying where I think doing so is most useful to the discussion.
I'm happy to defer to Boris's opinion on readyState based on what's
already been discussed.
On Thu, Feb 24, 2011 at 1:46 AM, Kyle Simpson wrote:
> "Serious i
Again, I think the spirit we all share is to find the simplest proposal
that gets the job done, and introducing a new .execute() concept raised
more questions than it purported to solve.
The last dozen or two messages were regarding your rabbit hole, which
raised serious issues.
"Serious issu
oun...@lists.whatwg.org]
On Behalf Of Boris Zbarsky
Sent: Wednesday, February 23, 2011 6:18 AM
To: Jorge
Cc: whatwg@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 :
>
I'm curious if we could apply some "limit" to the number of scripts that
will be simultaneously preloaded, at say 100 scripts for instance?
I would be fine with that from an implementation standpoint; not sure
about the author-facing aspect of it.
As one of the concerned web-authors, I can't s
On 2/23/11 8:33 AM, Kyle Simpson wrote:
I'm curious if we could apply some "limit" to the number of scripts that
will be simultaneously preloaded, at say 100 scripts for instance?
I would be fine with that from an implementation standpoint; not sure
about the author-facing aspect of it.
-Bor
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 tha
I don't understand why the preloading specifically would imply different
HTTP caching semantics than normal dynamic script loading?
It doesn't have to. It's just that if preloading is easy to trigger by
accident and authors don't notice when they accidentally preload lots of
stuff then we may h
On Wed, Feb 23, 2011 at 10:16 AM, Jorge wrote:
> On 23/02/2011, at 04:57, Boris Zbarsky wrote:
>> On 2/22/11 10:42 PM, Glenn Maynard wrote:
>>> Including execute() being synchronous, raising SyntaxError exceptions
>>> for parse errors, and uncaught exceptions from the script being
>>> propagated u
On 23/02/2011, at 04:57, Boris Zbarsky wrote:
> On 2/22/11 10:42 PM, Glenn Maynard wrote:
>> Including execute() being synchronous, raising SyntaxError exceptions
>> for parse errors, and uncaught exceptions from the script being
>> propagated up through execute() to its caller?
>
> Hmm. That las
On 2/22/11 10:42 PM, Glenn Maynard wrote:
Including execute() being synchronous, raising SyntaxError exceptions
for parse errors, and uncaught exceptions from the script being
propagated up through execute() to its caller?
Hmm. That last one might take some work in Gecko, if it's even sanely
On Tue, Feb 22, 2011 at 10:17 PM, Boris Zbarsky wrote:
> I also think the other side benefits of this approach are significant, so
>> long as they don't make it too hard to implement. That really needs
>> implementor feedback--if you can give that, let me know if you want a more
>> detailed rec
On 2/22/11 9:55 PM, Glenn Maynard wrote:
The main arguments for the readyState approach over this have been: it's
what IE does now, and the "preloading when src is set" has precedent with
images.
I sympathize with that, since they're aiming to improve the likelihood of
being implemented--but the
On Tue, Feb 22, 2011 at 9:24 PM, Boris Zbarsky wrote:
> On 2/22/11 8:54 PM, Glenn Maynard wrote:
>
>> 3. My (and Nicholas's previous) proposal: Script elements are fetched when
>> inserted into the DOM[1]. An event is dispatched when the script has been
>> fetched, eg. "onfetch" or "onpreload"[2
On 2/22/11 8:54 PM, Glenn Maynard wrote:
3. My (and Nicholas's previous) proposal: Script elements are fetched when
inserted into the DOM[1]. An event is dispatched when the script has been
fetched, eg. "onfetch" or "onpreload"[2]. A "preload" attribute is added;
when true, the script will not
On 2/22/11 8:05 PM, Will Alexander wrote:
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.
Well, more precisely it would make it less likely that someone would
accidentally author broken conten
On Tue, Feb 22, 2011 at 8:14 PM, Kyle Simpson wrote:
> First of all, which two proposals are we talking about here?
>>
>
> 1. Nicholas' proposal, which is currently to "preload" a script if its
> script element is marked with a `preload` attribute, before the setting of
> the `src` property. To
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
On 2/22/11 7:19 PM, Kyle Simpson wrote:
For #1, I think we've established this is probably true (for those rare
corner cases). Perhaps a more sophisticated in-memory content-uniqueness
cache could be constructed, but it may be more work than it's worth. To
push the ball forward, in a rough (non-b
This can cause the wrong image to show temporarily, until replaced by the
right one (which I consider a bug; I think the cache needs to be less
aggressive).
That approach is clearly not workable for scripts... ;)
No, clearly not. I think we're finally in agreement on something. :)
I think w
On 2/22/11 6:39 PM, Kyle Simpson wrote:
This seems strange to me. Generated images (like in captchas, etc) have
to be common enough
The captchas I just looked at use different URIs for different captcha
images.
I oversimplified a bit: the image cache in Gecko does do some http-like
stuff, b
But note that image loads very explicitly do NOT have HTTP semantics, last
I checked. In Gecko they coalesce very aggressively in a cache that sits
in front of the network layer, including coalescing across documents, etc.
This cache applies to both in-progress loads and completely loads (it's
On 2/22/11 6:21 PM, Will Alexander 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.
Is there some way to accomplish this in Gecko now for a pre-fetched Image?
If you hold a refe
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 l
On 2/22/11 3:07 PM, Kyle Simpson wrote:
Look above at what Will says... he says "before a URL loads" in (a). I
interpreted that to mean that if I make two requests in rapid fire
succession, and the browser hasn't yet gotten the response headers (from
the first request) to tell it not to cache, th
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for every
On 2/22/11 1:50 PM, Kyle Simpson wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for every
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for every
On 2/22/11 1:25 PM, Will Alexander wrote:
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
> 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
On 2/17/11 4:15 PM, Glenn Maynard wrote:
Boris: The "2.0" preload proposal--not 2.1--avoids the preload issues
you're worried about, right? With that version, only script nodes in
the DOM tree are loaded.
I've lost track of the various proposals, honestly. If only nodes in
the DOM are loade
Boris: The "2.0" preload proposal--not 2.1--avoids the preload issues
you're worried about, right? With that version, only script nodes in
the DOM tree are loaded.
Another issue: with the preload-when-not-in-DOM model, it's impossible
to listen for all script events by capturing them. To do tha
On 2/17/11 2:38 PM, Kyle Simpson wrote:
I don't know of any browsers which are set to download more than 8
parallel connections.
You don't need it, if the content is cached, right?
I can't imagine that you'd have 10,000 separate
downloads of the same resource. Depending on race conditions, yo
Do you have any example where hundreds of megabytes of JavaScript is
being loaded onto pages? Even "tens of megabytes" seems quite
extraordinary.
Think 10,000
On 2/17/11 12:23 PM, Kyle Simpson wrote:
My worries are cases where a page inadvertently makes you hold on to
tens or hundreds of megabytes of js, not about the 200k case.
Do you have any example where hundreds of megabytes of JavaScript is
being loaded onto pages? Even "tens of megabytes" seem
I dunno if
I'd call that a "memory leak" as much as I'd call it a "higher memory
utilization", or maybe "potential memory waste".
Most users will call continuously increasing memory (which is what you'd
get if a page creates script elements, sets src, and then doesn't insert
them, perhaps by a
On 2/17/11 11:39 AM, Kyle Simpson wrote:
Memory leak in the sense that the page is holding onto more memory than
it *potentially* needs to. But not memory leak in the sense that this
memory stays around after the page unloads/reloads, right?
Right.
I dunno if
I'd call that a "memory leak" as
The problem with prefetching immediately on src set is that you have no
idea when or whether the node will get inserted. So you have to keep the
data alive... for how long? From a user's point of view, that's a memory
leak pure and simple, if the node never gets inserted into the DOM.
Memory
(so in IE preload would default to true while in FF it would default to
false).
Let's be clear. In Nicholas' proposal, while the `preload` property may
default to true or false, the property (I think confusingly misnamed)
controls a *behavior*, which is NOT binary true/false. The more useful
On 2/17/11 11:07 AM, Nicholas Zakas wrote:
With regards to #1, I do think it could be user-agent defined if
agreement can’t be reached on the correct default behavior (so in IE
preload would default to true while in FF it would default to false).
That seems like a reasonable first step.
CCing Bo
Steve
Souders
Subject: Re: RE: [whatwg] Proposal for separating script downloads and execution
On Feb 15, 2011 6:34 PM, "Nicholas Zakas"
mailto:nza...@yahoo-inc.com>> wrote:
>
> 1) Should the default behavior for dynamic script nodes be to start
> downloading the file up
On Wed, Feb 16, 2011 at 9:28 AM, Will Alexander
wrote:
> 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
Possibly related:
http://code.google.com/p/chromium/issues/detail?id=3
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
On Tue, Feb 15, 2011 at 6:33 PM, Nicholas Zakas wrote:
> That being said, I think we're going a bit off-track now. Both Kyle's and my
> proposals are based on already-existing functionality that we know doesn't
> break the web (code hacks aside). We'd both like to formalize that behavior
> in s
Simpson [mailto:get...@gmail.com]
Sent: Tuesday, February 15, 2011 3:29 PM
To: Will Alexander
Cc: Glenn Maynard; Nicholas Zakas; whatwg@lists.whatwg.org; Nicholas C. Zakas;
Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution
> Although I'm not
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.
It's true
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 compatibilit
You may be correct in that people may never want to set preload to false.
You'll note that I put in my proposal that an alternate approach would be
for preload to be set to true by default.
Since your proposal also says that setting `preload` to `false` wouldn't do
anything except not *require
_
From: Glenn Maynard [mailto:gl...@zewt.org]
Sent: Monday, February 14, 2011 1:37 AM
To: Kyle Simpson
Cc: Nicholas Zakas; whatwg@lists.whatwg.org; Nicholas C. Zakas; Will Alexander;
Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Sun, Feb 13, 20
On Sun, Feb 13, 2011 at 11:09 PM, Kyle Simpson wrote:
> You seem to suggest this is a bad thing. I actually think it's a good
> thing that we're keeping script execution as much as possible in the
> existing architecture. There's lots of different reasons why the queues and
> behavior are set up
This change wasn't mentioned here, and introduces a lot of problems.
-
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
>
> In essence, the two are somewhat converging, though
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
In essence, the two are somewhat converging, though are still distinct in
important ways. Nicholas's proposal now
On Fri, Feb 11, 2011 at 7:31 PM, Glenn Maynard wrote:
> I think the example code can be simplified a lot to demonstrate the API
> more clearly. I've attached a simplified version. It also explicitly
> catches exceptions from execute() and calls errorCallback, and demonstrates
> feature checking
Note that there's still concern that the feature in general hasn't been
justified properly. In particular, the major real-world example used to
justify this is the Gmail scripts-in-comments hack, and I don't think we
actually know the complete justification for that. We know it's for mobile
brows
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
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 still believe the feature-detect for my proposal is valid. It's obviously
not ideal (often times fe
s.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Kyle Simpson
Sent: Friday, February 11, 2011 3:42 PM
To: whatwg@lists.whatwg.org
Cc: Will Alexander; Nicholas C. Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution
> We've gone back and for
oposal that achieves all of
them.
-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
1 - 100 of 184 matches
Mail list logo
