Garrett Smith wrote:
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".
If the page does what it is designed to do, and that the design is
flawed, the page would be broken by design. Designing things to be
broken would be "wrong".
My point is that if no UAs implement the new stuff it's easy to make
such a mistake, and then UAs that _do_ implement it will show your page
not as you intended.
In other words, widespread adoption of this in authoring before
implementation would actually raise a bar to implementation, since it
raises the chances that implementing the feature will break sites.
Hence the catch-22 mention above.
>>>> 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).
Not that I think you are wrong, but that statement ought to be backed
up by some tests.
You mean tests showing that current UAs allow <link rel="stylesheet"> at
the end of <body>?
No, just observing that the problem could have been avoided with a
"depends=" attribute, if only such attribute had existed c2000, and
having scripts wait only when depends is set. I like this design.
That's nice, but the question is where we can go now given the current
situation, not the one that existed 10 years ago.
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?
You got it. It doesn't work for today's browsers. However, it isn't
guaranteed *not* to work by any standard. In fact, browsers behave
differently on the matter. Could this new feature result in breaking
code in older browsers?
No, but my point is that if you're concerned about solutions due to
their impact on old browsers, then this solution has the same impact as
all the things Ian has proposed...
You say that stylesheets do not block script loading. That may be true
of "Shiretoko" 1.9.1, however, that is not what I see for Firefox 3.0.
The example I posted shows that stylesheets hold up body content from
rendering. If that content contains a script tag, the script will
*not* load *or* run.
I can tell you for a fact, having implemented this part of Gecko myself,
that a stylesheet will prevent body content from _rendering_, but NOT
from being parsed. It will furthermore not prevent scripts from
loading, but _will_ prevent them from running.
I can point you to the relevant code if desired.
The following example shows this to be true:
http://dhtmlkitchen.com/jstest/block/link-external.html
This example demonstrates that pending script execution blocks parsing
and hence script loading in Gecko 1.9.0. In fact, it says so right in
the example. That's not the same thing as stylesheets blocking script
loading.
And yes, in Gecko 1.9.1 the speculative parser will likely kick off all
the script loads while still waiting for the stylesheet in this case.
The only explanation I have for this behavior is that the browser is
waiting for the stylesheet to complete before it requests the script
in the body.
No, it's waiting for the <head> scripts to execute before parsing the
body and requesting the script. Those scripts happen to be waiting for
the stylesheet, but if you didn't have them there the script in the
<body> would be loaded in parallel with the stylesheet.
Heck, you don't even need the external script in <head>. The inline one
would give you the same behavior.
That is why it would be better for performance to have
that script prefetched
Something that UAs are working on anyway, with speculative parsing used
to prefetch content. That's happening in at least Webkit and Gecko.
What I said was true for all scripts. We do not differentiate between
content in <head> and content in <body> in this regard.
In Shiretoko 3.1, true, but in Firefox 3.1, the bottom script is not
loaded.
That has nothing to do with <head> vs <body>, as you could trivially
test by moving those scripts around in your document. All that matters
is the order of the script tags.
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.
By "all the HTML before the tag has been parsed," I think you mean,
all the HTML before the tag for that IMG or SCRIPT resource.
Correct.
Next you're saying that visual display is not correlated to
script loading or script execution.
Correct.
I'm not sure how this is related.
You keep talking about "until the page content renders", which is visual
display.
In Shiretoko, a script, even a deferred script, will not run until the
stylesheet is loaded.
Correct.
Can we make an improvement on that, or to make that improvement
configurable to the page author?
I think we can, sure. In fact I'm proposing flagging scripts that don't
depend on stylesheets, no?
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.
For Firefox 3.0, IMG and SCRIPT that are part of the body are fetched
around this time. They are not fetched prior. Why not?
Because you have <script>s after your stylesheets, not just stylesheets.
Really, controlled experiments are hard. You have to hold all but one
variable constant.
In that case, the link would not block layout.
Yes, which is why you get a performance hit when it loads. But I
thought we were talking about stylesheets that don't "really" affect
layout (late-loading stylesheets, which you wanted).
In "Shiretoko" 1.9.1b3pre, a deferred script waits for all stylesheets
to load before running. However, this is not guaranteed behavior in
any standard.
True. At least not yet. I suspect it's pretty much required for web
compat, though, which is why it's implemented that way. Or at the very
least the scripts need to wait for the stylesheets that came before them.
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.
What would make it easier? I'd really like to know how to design my
pages so that they are faster and more responsive.
Well, one option is to stop worrying about micromanaging the load order
and assume that speculative parsing will solve your problems.... will it?
A deferred stylesheet being requested by the browser would not be a
problem. Mozilla already makes predictive fetches for links. However,
if a deferred stylesheet is fetched during loading, should that
stylesheet (and rules.length, etc) be accessible via script in that
time? Should the deferred link fire a load event after the request
completes?
In my opinion, prefetching should have no effect on what the DOM sees.
It should just make it look like the network load took a lot less time
than it would otherwise.
In other words, you load the stylesheet, parse it, whatever, but don't
hook it up to the document until you "really" parse the <link> tag.
-Boris
