[whatwg] defer on style, depends

Thu Feb 12 08:41:20 PST 2009

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