This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
This change makes sense to me.
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.
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.
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
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