[whatwg] Proposal for separating script downloads and execution
getify at gmail.com
Wed Feb 23 10:16:25 PST 2011
>> 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 see having much trouble (again
as long as the limit is high enough not to cause likely deadlock in the 99%
use-case), nor caring, that the browser had some edge-case limits in place
to prevent true run-away.
Just taking a swag, what would you say is the highest number that limit
could be (by default) that you could still feel reasonably comfortable is
protecting from run-away? 100? 500? 1000? If the number is 10, this may be
impractical. If the number is 100+, I think it's quite unlikely to affect
any of the vast majority use-cases.
Just as a random thought (perhaps too crazy out-there)... if we were
concerned about dead-lock if the limit is reached... could this be a browser
warning dialog to the user, like it is in some where they warn about "long
running scripts"... Something like "This page is attempting to load but not
use a large number of script resources. Do you want to allow this to
continue?" I dunno, that's probably crazy. But again, I think it's probably
rare enough that I wouldn't worry too much if that was the fail-safe at the
end of the line.
>> The goal (from my perspective) is to come up with the simplest proposal
>> that serves the use-cases. Simplest being defined in this particular
>> situation as the least amount of change to the spec, AND the least
>> amount of change to the browser that has by far the slowest release
>> cycle (IE).
> That last part is an important point, yes.
Some people on this thread I think don't give the pragmatism of IE's release
cycle as much weight as I do. If that weren't a concern, I probably would
have been more in favor of Nicholas' v2.1 (current) proposal, based on its
cleaner semantics. Honestly, it's the IE question that causes me still to
favor my own proposal. And that's not meant to be a knock on IE. It's just
meant to recognize the reality of that situation, and try to dance around it
and find some balance/compromise.
Right or wrong, IE9 is feature-complete, and any change to this mechanism is
almost certainly targeted for IE10 or later, which could very well be 1-2
years away (or more). While we may, in practice, still be a ways off from
full browser compat on this topic, I'm still fighting for the path that at
least seems like it has the shortest path. I may be fighting the wrong
battle, but that's my motivations thus far.
>> a) is execute() sync or async? what does this imply about if the script
>> being executed itself calls execute() on other script elements, and so
> Fair enough. Seems to me that execute() should act just like inserting
> an inline script into the DOM does right now. Browsers already have to
> handle that; they could just reuse this code.
There are some additional complications, I think. For instance, if a
script.execute() call is made, and inside that script, it calls .execute()
on its own script element... what does that do?
But yes, I agree that, as I've said many times in this thread, the more we
can reuse of existing code and/or semantics, the better.
>> b) what does it imply about whether/when the event handler(s) would be
>> fired? If it's synchronous, are the event handlers also synchronous or
>> are they async? Are they fired before or after the execute() actually
>> does the executing of the script element?
> Which event handlers?
Well, script.onload for one. And for the IE crowd, also
script.onreadystatechange. Oh, and the script.onerror handler needs to at
least be considered as well. If both the execute and the event handlers are
synchronous, I could see a situation where script.execute() causes a
script.onerror to fire, which then calls another script.execute(), etc. I'm
not specifically saying this type of thing is a problem, per se. I'm
suggesting that there's quite a few questions that have to get thought about
and spelled out. And we may not all agree completely on those answers, which
is going to make getting .execute() even specified (much less implemented)
quite a bit more involved.
If execute() were our only option, that would be the necessary task. If
there's reasonable and simpler alternatives, which I think my (and Nicholas'
current) proposals may very well be, I think the process should tend to
favor that route, absent some strong reason (besides API preference) to
force us down the more difficult path.
>> d) what are the semantics of if you call execute() on a script element
>> before it has finished preloading
> Good question, yes.
In the case of DOM-append-to-execute, this question is moot. In the case of
execute(), it's an open question without full consensus, thus far.
>> e) what happens if a script's .text is modified before execute() is
>> called? What if a script element is cloned before execute() is called?
>> What if it's cloned after execute() is called?
> Also good questions.
Again, in the case of DOM-append-to-execute, these questions are already
handled. In the case of execute(), we have to think about if the same
semantics can cleanly be re-used or not. I don't know if we have consensus
on them yet or not, frankly.
>> 3. If in the future we want to also support preloading of other
>> resources, like stylesheets for instance
> Preloading of stylesheets is already supported in at least Gecko. Just
> mark them as disabled (or an alternate stylesheet not in the main set,
> which is the same thing in effect) and the sheet will be loaded+parsed
> but not applied. Which is presumably what you mean by stylesheet
That's a good point I hadn't considered. Although I'm not sure at the moment
if that is a spec'd thing or not, nor am I sure about the cross-browser
support for it.
There's also the (minor) consideration that a true preloading would,
ostensibly, possibly be avoiding or delaying the "parsing" part of the
equation. I know much earlier in the thread we went around in circles quite
a bit about whether or not the "parsing" of some resource is something that
is useful to delay, or if authors should have any control over it.
AFAICT, the result of that part of the discussion was that explicitly
delaying execution of a resource (and that being an implicit hint to the
browser to consider delaying parsing) was a sufficient compromise. It would
seem at first glance the same semantics for CSS
preloading/parsing/"executing" would apply.
In any case, this is a rabbit trail we don't necessarily need to chase down
right now. I was just mentioning that a little bit of future-thinking about
other types of resource preloading was prudent, so as to not paint ourselves
into a corner, where each type of resource has to have an entirely different
(and perhaps awkwardly incompatible) way to do preloading. If images, CSS,
and scripts (and perhaps other resource types) are all eventually
preloadable in the same manner, that certainly greatly simplifies the
complexity of a resource loader.
>> I strongly disagree with this characterization, based solely on the fact
>> that the wording of the current spec already says to do exactly as I'm
>> proposing. That's not a "compatibility hack", that's further
>> standardizing the wisdom that the spec writers already thought through
>> and codified.
> I think you're overestimating the "wisdom" and "thought through"
Perhaps I am overstating the intentionality behind it being added to the
spec before. I wasn't around when it was added, so I don't know either way.
I give the benefit of the doubt, though, that it wasn't haphazard or
Also, the bigger point is that my proposal to follow existing IE precedent
is not JUST as a compatibility hack, but it's more following the lead that
some spec author (I presume Ian) laid down before.
My presumption, perhaps incorrect, is that it's easier to get existing
wording in the spec modified/clarified/enhanced than it is to get entirely
new concepts written and spec'd.
More information about the whatwg