Garrett Smith wrote:
In general, I want better declarative control over loading external
resources. The solution(s) should not cause compatibility problems
with existing browsers (because I have to support IE6 and Firefox 2).
Honestly, by the time anything we're discussing now will be shipping in
a browser Firefox 2 marketshare should be nonexistent. I can't speak
for IE6.
I want the browser to be able to load and run a script without being
in the position of trying to determine if it should wait for
stylesheet data to complete.
As in you don't want the browser to make this determination, right?
That is, you know that your script doesn't depend on any style data and
you want the browser to just run it?
I would be fine with a way to flag scripts with that information, though
there is a catch-22: if you flag such a script and it DOES depend on
style information, then existing UAs will get it "right" and any UA
implementing the new spec will get it "wrong".
Of course the same is true for the "flag-the-stylesheet" proposal...
In browsers that do support defer, the script would run *after* the
document parsed, and that would occur after the stylesheet loaded.
I'm not sure why this is a performance problem, per se.
2) want to load stylesheets later, (infoPanel example)
Not sure what this example is, or why this is insufficienty served by, say,
putting the <link> at the end of the HTML (assuming HTML allowed that, of
course).
Are you proposing HTML allow that?
That's one possible solution to the issue of starting stylesheet loads
as late as possible, yes. It's not a great one a priori, but has the
benefit of good compat with existing UAs (which you said was a priority
for you).
The script could declare whether it needs such resource by its
"depends=" attribute. However, browsers today delay (some) scripts
from running. Scripts depend on stylesheets; content depends on
scripts and stylesheets. Content can contain more scripts. Omitting
depends for scripts could not possibly solve the problem for browsers
today (because they already depend on stylesheets).
Honestly, I don't think anything would solve the problem for browsers
_today_.
An "independent" attribute on a link says that a browser does not need
to wait for that resource to finish loading before it loads other
resources (like loading a script). When the parser parses that
"independent" attribute, it sets a flag for the browser go ahead and
download and run any subsequent script.
That doesn't work for today's browsers, though, just like flagging the
script doesn't. Or am I missing something?
A "nodepends" type attribute on a script would work, too. I like that
idea, though it does mean the browser has to do some lookahead (then
again, apparently they already do).
What sort of lookahead? Gecko, for example, just keeps parsing right
past a stylesheet load. The only thing we stop the parser for is
<script>s, because those can do document.write. And even then, the
speculative parser continues doing loads past that point.
All that style sheets hold up is the script running, not the script
loading (in Gecko). If the script were marked as "doesn't have to wait
for stylesheets", we could just run it as soon as it loads.
That's exactly what Gecko does in this case, for what it's worth. It will
load the script in parallel, but won't _execute_ the script until the
non-alternate stylesheet has loaded.
For a script in the head, that is what Gecko and Webkit will do.
What I said was true for all scripts. We do not differentiate between
content in <head> and content in <body> in this regard.
However, external resources such as SCRIPT or IMG that appear in the
BODY will not get requested by the browser until the page content
renders.
You mean until all the HTML before the tag has been parsed? Or
something else? There's no dependency between script loading+execution
and page rendering, in Gecko. Heck, you can run scripts in a
display:none iframe, with no rendering in sight.
In both cases (head script or body script), the browser will not
execute the script until the stylesheet is downloaded. It won't render
content that occurs after the script until the script is executed.
That's correct, yes.
So what we have here is a daisy chain. Content depends on Script
depends on Style. That is very crude order of affairs and offers the
developer little control over load order.
Yes, agreed.
to fulfill example 2, I would defer the stylesheet, and declare the
script at the end depends on it. Before that script could run, the
stylesheet would need to be loaded. Since the linked stylesheet is
deferred, the body content would render and not be blocked by the
linked stylesheet loading.
Ah, that is one thing that Gecko does do: we don't start _layout_ (as
opposed to parsing) until all the stylesheets in <head> have loaded.
You can get around this trivially by putting a stylesheet as the first
thing in <body>; that stylesheet won't block rendering in Gecko 1.9.
You get a performance hit when the sheet loads, of course, because of
the ensuing restyle, but you might be ok with that (I presume you are
given that you want to load the stylesheet after the content has been
rendered).
In fact, if you use a <script defer> after the sheet and a sheet at body
start you'll get the behavior you want in Gecko 1.9.
Again, I doubt we can come up with any declarative solution that would
work with UAs that don't implement defer already....
Question: When the stylesheet is eventually applied, could the reflow
be optimized for performance?
Not easily, no. Or rather, the reflow already is; the style data
recomputation is the hard part.
A deferred a stylesheet would load after the page loads
Note that this is not the behavior deferred scripts have, by the way, at
least in Gecko. They load eagerly, but execute lazily...
-Boris
