[whatwg] defer on style, depends

Mon Feb 9 19:37:11 PST 2009

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