Bug 23526 - [imports]: blocking DOMContentLoaded while HTML imports are loaded
[imports]: blocking DOMContentLoaded while HTML imports are loaded
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC Linux
: P2 normal
: ---
Assigned To: Dimitri Glazkov
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:


Attachments

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:

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

other.html:
<script>
  console.log('3');
  window.addEventListener('DOMContentLoaded',
      function () { console.log('4'); });
</script>

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. 
http://www.w3.org/2014/04/11-webapps-minutes.html

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.

https://github.com/w3c/webcomponents/commit/0cb84f294070821976de57a4029a506473375107
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