Bug 23526 - [imports]: blocking DOMContentLoaded while HTML imports are loaded
Summary: [imports]: blocking DOMContentLoaded while HTML imports are loaded
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
Depends on: 24643
Blocks: 20683
  Show dependency treegraph
Reported: 2013-10-15 16:51 UTC by sigmund
Modified: 2014-04-15 00:55 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description sigmund 2013-10-15 16:51:02 UTC
Should HTML imports block the DOM content loaded event?

The imports spec says that HTML imports block script tags. Script tags block the DOM content loaded event. So, I made an intuitive leap and thought that, even if I have no script tags on my main HTML document, an import would block that event as well.

I couldn't find anything about it in the spec, and playing with the native implementation I prove myself wrong. However, I was wondering if we should change that.

Here is a simple example:

      function () { console.log('2'); });
<link rel="import" href="other.html">
     <!-- <script> // this is not empty </script> -->

      function () { console.log('4'); });

Loading index.html will print 1, 2, 3; but commenting out the last line in index.html changes the code to print 1, 3, 2, 4.
Comment 1 Dominic Cooney 2013-10-16 00:50:48 UTC
This change makes sense to me.
Comment 2 Steve Orvell 2013-10-16 01:32:42 UTC
I'm in favor of this change as well. I had a similar expectation and was surprised to learn that this was not the case.

If a set of imports loads resources on which a page wants to act, it's cumbersome to have to listen for load events to fire. It's also tricky to setup load event listeners since either the onload attribute or an a priori MutationObserver must be used.

In the future, we may want to give imports an async attribute so that they can behave similarly to async scripts.
Comment 3 Morrita Hajime 2013-10-16 03:25:57 UTC
This might be just an implementation bug rather than a spec bug.
Let me see if <link rel=stylesheet> blocks the DOMContentLoaded event.
If it doesn't and <link rel=import> should, the spec should be explicit about that.
Comment 4 Morrita Hajime 2014-04-15 00:06:04 UTC
Discussed briefly in the last F2F. 

And I didn't see any objection. rniwa mentioned that this is similar to <script defer>, that is good point.

I removed the FIXME section as this behavior happened to be captured in the spec already.

Comment 5 Morrita Hajime 2014-04-15 00:55:37 UTC
On second thought, I found that this should be rather handled by load event
instead of DOMContentLoaded event. That is because:

- Imports can be nested and have unpredictable delay, that is not what
  users of DOMClientLoaded expect. <script defer> is counter example of this,
  but I think it is mainly for compatibility reason - Script has been expected
  to be loaded before the parser ends.
- HTML standard has a hook for load event [1] but doesn't have one for DOMContentLoaded. It is not expected to be extensible and the load event is more generic extension point. 

We might want an event for signaling import readiness, or we could use some
promise based API for waiting the readiness, that is proposed at Bug 25007.

I landed the change that employs the |load| hook and eliminating a monkey patch for waiting DOMContentLoaded [2]. Less of monkey patch indicates that this is saner way to go.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end
[2] https://github.com/w3c/webcomponents/commit/b5ca1fbf683f8c7bbc0ff6b097476b18f1e25e22