On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen <hsivo...@iki.fi> wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <get...@gmail.com> wrote:
?> One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be used in markup. I.e. you can do
things like:
<html>
<head>
<script src=a.js noexecute onload="...">
<script src=b.js noexecute onload="...">
<script src=c.js noexecute onload="...">
</head>
I think this would be a bad solution, because existing browsers wouldn't
honor noexecute, so the solution wouldn't degrade gracefully. On the
other hand, if the spec required browsers to start fetching external
scripts as soon as .src is set on script nodes that aren't in the tree,
the degradation behavior wouldn't be a bigger difference that the
difference between IE and others today.
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.
Firing a readystatechange event each time readyState changes would be
the most natural thing to do. Does IE already do that?
On Feb 4, 2011, at 03:15, Jonas Sicking wrote:
I agree. I don't think that the readyState mechanism is particularly
simpler. Another nice thing about the noexecute design is that it is
purely opt-in, which means that you don't risk poor on already
existing pages.
I think we should do the readyState thing and put a note in the spec
saying that implementors should be polite to authors and not implement
the readyState property until they also implement the behavior that
setting .src on a not-in-tree node starts the HTTP fetch (in order to
make the behavior feature detectable from JS).
Adopting the readyState / early .src assignment mechanism has these
benefits over the proposed alternative:
* Already (reportedly; I didn't test) work in IE. Always a plus over
making up some new stuff.
* Authors already have to deal with IE, so the question of opting in
doesn't arise.
* Sites already have to work when scripts haven't been fetched yet and
when the scripts are already in the HTTP cache. Thus, starting the fetch
earlier than before shouldn't cause breakage since the "worst" case is
that the observable behavior becomes similar to the script already being
in cache by the time the node is attached to the tree.
* img elements have started fetches upon .src setting since almost
forever, so making scripts do the same makes the platform more
self-consistent.
* noexecute when used in markup has a particularly bad degradation
story.
I agree with Henri's analysis. Opera already has readyState (with value
always being 'loaded'), but we'd be careful to fix script prefetching and
readyState 'uninitialized' at the same time.
--
Simon Pieters
Opera Software