23526 2013-10-15 16:51:02 +0000 [imports]: blocking DOMContentLoaded while HTML imports are loaded 2014-04-15 00:55:37 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED FIXED P2 normal --- 24643 20683 1 sigmund dglazkov adamk dominicc morrita sorvell public-webapps-bugzilla oldest_to_newest 94788 0 sigmund 2013-10-15 16:51:02 +0000 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">  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. 94804 1 dominicc 2013-10-16 00:50:48 +0000 This change makes sense to me. 94805 2 sorvell 2013-10-16 01:32:42 +0000 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. 94806 3 morrita 2013-10-16 03:25:57 +0000 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. 103848 4 morrita 2014-04-15 00:06:04 +0000 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 103851 5 morrita 2014-04-15 00:55:37 +0000 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