Re: [HTML Imports]: Sync, async, -ish?

It seems that there are two distinct questions being discussed on this
thread:

1. should <script> tags that come after <link rel=import> block their
execution on load of the <link rel=import> completing?
2. should rendering of page content block on the load of <link rel=import>

These are related, but different, and we should discuss each on its own.
I'll send a separate reply for each.

First: should <script> execution block on previous <link rel=import>?
example:
<link rel=import href=foo.html>
<script>
// should the code in here execute before the <link rel=import> that
precedes it completes?
</script>

As Dimitri notes, scripts do block execution on styles that precede them.
So for example:
<link rel=stylesheet href=foo.css>
<script>
// my execution blocks on foo.css loading and being parsed
</script>

The reason for this is that the script may want to inspect properties of
the document that depend on the style that precedes it.

It's worth noting that at one point, WebKit did not block execution of
(inline) scripts on the load of stylesheets:
https://bugs.webkit.org/show_bug.cgi?id=8852

This was not fixed for quite a long time. The expected behavior has since
been specified as part of HTML5: HTML5 compliant parsers are expected to
block script execution on pending stylesheets (relevant sections:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts
,
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html
)

Once the fix to the WebKit bug was landed, blocking inline scripts on
pending styles, Google saw a 10-20% load time regression for some pages
(bug: https://bugs.webkit.org/show_bug.cgi?id=56842). A lot has changed in
WebKit/Blink since this time (the speculative parser has likely become much
smarter) so I'm skeptical to assume the cost is still 10-20% today, but we
should assume there is a cost.

So, the question:
Do we want to diverge from the spec'd behavior for stylesheets and make the
load of imports not block script execution, or do we want to maintain
consistency with existing spec'd stylesheet behavior at the cost of making
poorly structured pages possibly slower?

I believe it is reasonable to diverge and impose more complexity on
developers who do want their script execution to block on the load of
imports (by e.g. listening to the load event). FWIW Hixie made the same
recommendations for stylesheet loads in 2006:
https://bugs.webkit.org/show_bug.cgi?id=8852#c6 "As far as accessing style
sheets that haven't loaded yet ... that's what the "load" event is for; if
the load hasn't completed yet then trying to access the style sheets isn't
going to work."


> 'Sup yo!
> There was a thought-provoking post by Steve Souders [1] this weekend that
> involved HTML Imports (yay!) and document.write (boo!), which triggered a
> Twitter conversation [2], which triggered some conversations with Arv and
> Alex, which finally erupted in this email.
> Today, HTML Imports loading behavior is very simply defined: they act like
> stylesheets. They load asynchronously, but block <script> from executing.
> Some peeps seem to frown on that and demand moar async.
> I am going to claim that there are two distinct uses of <link rel=import>:
> 1) The import is the most important part of the document. Typically, this
> is when the import is the underlying framework that powers the app, and the
> app simply won't function without it. In this case, any more async will be
> all burden and no benefit.
> 2) The import is the least important of the document. This is the "+1
> button" case. The import is useful, but sure as hell doesn't need to take
> rendering engine's attention from presenting this document to the user. In
> this case, async is sorely needed.
> We should address both of these cases, and we don't right now -- which is a
> problem.
> Shoot-from-the-hip Strawman:
> * The default behavior stays currently specified
> * The "async" attribute on <link> makes import load asynchronously
> * Also, consider not blocking rendering when blocking <script>
> This strawman is intentionally full of ... straw. Please provide a better
> strawman below: